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