der Mouse writes:

| Router ---- hub --- NetBSDbridge --- switch --- station-b
|              |                        |
|            station-a                station-c
|
| and then have station-a and station-c simultaneously sniff a failing
| attempt between station-b and the outside world, keeping full packet
| contents for comparison...

I can do this with a 2nd hub (the switch by design SHOULD NOT send
station-b<>world traffic to station-c's port) later, once I get
some packet-capturing instrumention (ethereal) in place.

This'll take a few hours because of other obligations.

Meanwhile I'd be really really grateful if ANYONE could 
offer up a "works for me" or "I see similar problems"
for a topology like:

   ssh2-host [internet] --- ANY-Router --- NetBSD-bridge --- any-ssh2-host

to eliminate a wide variety of hardware issues local to my machines,
and to help distribute the problem-solving.  :-)

A GENERIC kernel + "ifconfig bridge0 create" + "brconfig bridge0 add ifN add ifM"
on the NetBSD-bridge is about all one needs.

If you can do this, please make note of what the model of the router is,
as well as details about the NetBSD-bridge box...

| I've seen data-dependent bugs in network infrastructure before,
| not often, but I've seen 'em.

Me too; it's what I do professionally, just with radically different 
hardware and software.  I am out of my depth with household stuff.  :-)

My gut tells me there's something in the bridging code in -current
that is borked, and instinct is aiming me at the difference between
stations on the bridged LAN and stations beyond the bridged LAN.

	Sean.