on Mon, Apr 29, 2002 at 03:40:30AM +0000, Sean Doran wrote:
> When the NetBSD box is installed with bridging enabled, the "in"
> boxes cannot sustain a large (multimegabyte) scp protocol 2 
> connection with the outside world; the boxes complain about
> MAC corruption on input.  There are other signs of
> silent corruption of otherwise valid TCP segments received
> across the bridge (bugged-out jpegs and so on from the web).

I'm not sure if this is coincedence. I note you're using BTopenworld as
your ISP. Me too.

I recently also noticed packet corruption (about 2% of packets if there
is any), and packet loss (about 2% to 10%). I traceroute'd to the site
that was giving me the problems, then did a ping -c 200 half way between
myself and the destination, and kept halving the distance between myself
and the destination. The part of the route that was failing was from my
ADSL modem to BT. They still haven't got back to me about this and I know
of at least one person who's having this problem too.. No doubt it'll be
around 4 weeks before anything happens, that appears to be the current
BTo timeout.
IP checksums aren't incorrect. Data corruption is intermittent.

I'm not using bridging, but there is an "Efficient" Networks modem.

ping -c 200 www.google.com gives:
PING www.google.com (216.239.37.101): 56 data bytes
...
64 bytes from 216.239.37.101: icmp_seq=59 ttl=45 time=96.1 ms
wrong data byte #54 should be 0x36 but was 0x76
	14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 
	34 35 76 77 0 0 0 0 0 0 0 0 0 0 0 0 
64 bytes from 216.239.37.101: icmp_seq=60 ttl=45 time=95.0 ms
64 bytes from 216.239.37.101: icmp_seq=61 ttl=45 time=103.4 ms
wrong data byte #54 should be 0x36 but was 0xb6
	14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 
	34 35 b6 b7 0 0 0 0 0 0 0 0 0 0 0 0 

I doubt it's NetBSD, because a ping -c 1000 against the ef modem is fine..
(ping -f doesn't get any packet loss..)