netdev - sun neptune mis-detecting ethernet crc faults?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4A492AA1.2020204@nortel.com>
Date:	Mon, 29 Jun 2009 14:57:05 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	netdev@...r.kernel.org
Subject: sun neptune mis-detecting ethernet crc faults?

Hi all,

David Miller is busy and suggested someone on the list might be able to
help.

We have some boards using the Sun Neptune ethernet adapters.  We're
seeing behaviour that at this point looks like a hardware glitch
in the ethernet CRC validation on the receive path.  It appears to be
incorrectly detecting a corrupt CRC and dropping the frames.  (We've
enabled port mirroring on the switch and the frames are received without
errors on the eavesdropper board.)

The odd thing is that we're using a TCP connection and once the CRC
glitch shows up for a particular chunk of data it continues to drop all
the retransmissions for that chunk as having bad CRCs, even though their
CRC values are totally different due to different embedded timestamps.

Has anyone heard of anything like this on the Neptune hardware?  MTU is
set to 2000 if it matters, though we're planning on retesting with it
set to 1500.

I'm considering disabling the hardware CRC check as a
verification--looking at the niu driver I think I should be able to do
this by not including XMAC_CONFIG_RX_CRC_CHK_DIS in the big list of
flags being OR'd in niu_init_rx_xmac().

Anyone have any suggestions?

Thanks,

Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html