Corrupted MAC on input
Darren Tucker
dtucker at zip.com.au
Tue May 4 12:09:41 EST 2004
Deron Meranda wrote:
> Note that I am going through a Linksys router. It is a BEFSR41
> firmware "1.44.2, Dec 13 2002".
The Linksys should be your prime suspect:
http://bugzilla.mindrot.org/show_bug.cgi?id=510
According to other reports 1.43.1 works OK.
> It certainly could
> be a network/hardware issue. But what could cause a MAC error,
> while surviving the TCP checksum?
Well, the TCP checksum is only 16 bits, so one error in 65536 is going
to go undetected (the chance of it going undetected by the MAC is
somewhat smaller :-).
Also, the checksum is on the TCP header and data, so if the device is
messing with with the header (eg changing the source IP/port for NAT)
then it will have to recompute the TCP checksum. If a corruption occurs
to the packet data before that step then the recomputed checksum on the
corrupted packet will be correct.
> Also, another observation, aside from using HP-UX on the server,
> I have only witnessed this problem when using an Athlon-based
> PC for the client (an older 800 MHz Slot-A model). But it is
> multi-OS, and I've seen the MAC error under both Windows 98SE
> (with PuTTY), as well as under Linux using OpenSSH client. I
> wonder if there may be an Athlon client-side issue?
Maybe a flaky memory, network card or cabling?
> More datapoints would certainly help. Who else has seen these
> MAC errors?
I've opened a bug[1] to capture the details. If anyone is experiencing
them, please add a brief summary to the bug.
[1] http://bugzilla.mindrot.org/show_bug.cgi?id=860
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
More information about the openssh-unix-dev
mailing list