netdev - Re: 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 for Android: free password hash cracker in your pocket

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

Message-id: <4A494AB1.7010407@sun.com>
Date:	Mon, 29 Jun 2009 16:13:53 -0700
From:	Matheos Worku <Matheos.Worku@....COM>
To:	Rick Jones <rick.jones2@...com>
Cc:	Chris Friesen <cfriesen@...tel.com>, netdev@...r.kernel.org
Subject: Re: sun neptune mis-detecting ethernet crc faults?

Rick Jones wrote:
> Chris Friesen wrote:
>> 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.)
>
> A simplistic question, but are you sure that the eavesdropper board is 
> checking CRCs?
>
>> 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.
>
> Do you mean TCP timestamp options?
>
>> Has anyone heard of anything like this on the Neptune hardware?
At Sun, we haven't seen such RX CRC error before.
>
> Can't say as I have, but the history of "networking" is littered with 
> data pattern induced bugs in all manner of hardware.
>
>> MTU is set to 2000 if it matters, though we're planning on retesting
>> with it set to 1500.
>
> An MTU of 2000 bytes means a TCP segment with timestamps enabled will 
> be 2032 plus the ethernet header (assuming no vlan tags) of 14 bytes 
> for 2046 and then there is the trailing CRC - which is getting very 
> close to a magic power of two boundary, another place where history is 
> repleat with examples of bugs. One that comes to mind is that the old 
> Alteon AceNICs got very unhappy if one crossed a 4G boundary with a 
> DMA...

>
> rick jones
>
>>
>> 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().
That is right.

Regards,
Matheos

>>
>> 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
>
> -- 
> 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

--
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