On Wed, 2010-04-14 at 13:00 +0200, Frédéric Boiteux wrote: > Le Wed, 14 Apr 2010 11:32:25 +0100, > Ben Hutchings <ben@decadent.org.uk> a écrit : > > > On Wed, 2010-04-14 at 09:28 +0200, Frédéric Boiteux wrote: > > > Package: linux-2.6 > > > Version: 2.6.32-11 > > > Severity: normal > > > Tags: upstream > > > > > > Some minutes after booting (cold boot, or resume from hibernation, > > > at least before #534422 prevents me to use hibernation), my > > > Iceweasel session launched through a SSH connection always fail > > > with following error message : Corrupted MAC on input. > > > Disconnecting: Packet corrupt Restarting the SSH connection, the > > > problem don't occur anymore before next reboot. I've checked and > > > replaced the ethernet cable, without change. I also tested the > > > memory, seems ok. I thought at start it was a iceweasel or openssh > > > problem, but then found other people have the same problem, like : > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/60764 > > > https://bugzilla.kernel.org/show_bug.cgi?id=12282 and perhaps also > > > https://bugzilla.kernel.org/show_bug.cgi?id=13404 The problem is > > > here at least since 2.6.30, and is always present with latest > > > kernel from Sid. > > > > The bug could be at either end of the connection (or between them). > > Is the remote system on the same local network? If so, please can you > > provide the output of these commands on the remote system: > > > > ls -l /sys/class/net/*/device/driver > > grep . /sys/class/net/*/features > > I don't think so, because the remote system is on a local network, and > I use same type of ssh connection from other systems without problem. > But here is the output you request (the remote system is an HP > DL380G5) : OK, I think I can generally trust bnx2. As I understand it, you are doing this: 1. Run ssh on Eeepc, connecting to server 2. Run iceweasel on server with X forwarding over ssh 3. ssh on Eeepc fails with this error message, indicating it received corrupt data If we can trust the server's driver and hardware, this implies that a received packet has been corrupted after its CRC and TCP/IP checksums were verified by the Eeepc's network controller. Based on the bug reports at bugzilla.kernel.org I believe this is a hardware fault and there is unlikely to be any way to fix this in software. However you may be able to work around it by disabling RX checksum offload via ethtool. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part