Subject: Re: hw ip4csum-tx bug on ex(4)? (Re: RTL8169 hw IP4CSUM_Tx workaround)
To: None <tech-kern@NetBSD.org, tech-net@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 11/08/2006 11:45:19
>>> (I'm not sure if there is any protocol other than ICMP which could
>>> generate 21 or 22 byte IP fragment packets)
>> A UDP packet ever so slightly larger than your MTU can do it, surely?
> Hmm, is there any actual protocal which could create "slightly (i.e.
> 1 or 2) larger than our MTU"?
An NFS(-over-UDP) read of a suitably sized file can do it - as,
presumably, can an NFS write of a suitably sized chunk of data. I ran
into a slight variation on this problem in the wild in a past job. NFS
between two machines was hanging when trying to read certain files -
always the same files and never others, and only a few files. I
eventually tracked it down to a disagreement over what the minimum
Ethernet packet size was - one NIC couldn't receive packets smaller
than ETHER_MIN_LEN+4, I think it was, so if the file size was such that
the last read returned just the right amount of data, the last frag of
the response would be smaller than that and the packet would get
dropped, fragmentation reassembly would fail, the read would be retried
only to suffer the same fate....
The workaround we used was to mount it wsize=1024,rsize=1024 (wsize
probably unnecessary), so that bulk data never generated packets big
enough to get fragmented.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B