| Summary: | ti driver truncates some packets | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Garrett A. Wollman <wollman> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->closed The bug here was that I was initializing the maximum packet size for the mini receive ring incorrectly. The maximum length determines how small a packet has to be in order for it to be DMAed into the mini receive ring instead of the normal ring. I set the length to MHLEN, however the mini ring receive buffers are actually sized at MHLEN - ETHER_ALIGN; the first two bytes are shaved off in order to produce proper payload alignment. It happens that MHLEN is 96, so frames of exactly 95 and 96 bytes in size would be corrupted. In your failing case, the frame is 95 bytes long. I patched if_ti.c in -current and -stable to fix this. You can also fix this by changing: rcb->ti_max_len = MHLEN; to: rcb->ti_max_len = MHLEN - ETHER_ALIGN; in ti_gibinit() if you're in a rush and don't want to cvsup again. |
Certain odd-length packets are truncated. One particular, easy-to-reproduce example is shown below. By comparison with another network interface on the same machine, it is clear that the truncation is not happening elsewhere in the network. netstat(1) reports: 6638 with data size < data length With bpf and tcpdump, we see the following behavior: Correct (via fxp0): 13:34:05.892764 wcarchive.cdrom.com.ftp > 24-6-254.wireless.lcs.mit.edu.4676: P 1931:1972(41) ack 132 win 17520 [tos 0x10] (ttl 51, id 52165) 4510 0051 cbc5 0000 3306 7f0e d19b 5212 1218 06fe 0015 1244 457e f0b4 113a fceb 5018 4470 b361 0000 3235 3720 222f 2e32 2f46 7265 6542 5344 2220 6973 2063 7572 7265 6e74 2064 6972 6563 746f 7279 2e0d 0a Truncated (via ti0): 11:56:39.586371 truncated-ip - 1 bytes missing!wcarchive.cdrom.com.ftp > xyz.lcs .mit.edu.4526: P 1931:1972(41) ack 132 win 17520 [tos 0x10] (ttl 52, id 936) 4510 0051 03a8 0000 3406 4316 d19b 5212 1218 0a14 0015 11ae 92a2 96e8 ca62 3873 5018 4470 c8d9 0000 3235 3720 222f 2e32 2f46 7265 6542 5344 2220 6973 2063 7572 7265 6e74 2064 6972 6563 746f 7279 2e0d As you can see, the IP header claims the packet is 81 octets long, but only 80 bytes have arrived via ti0. fxp0 does not truncate the packet. Fix: Unknown. How-To-Repeat: (set up default route over ti0 as appropriate for your network) ftp ftp.freebsd.org cd /pub/FreeBSD get ls-lR.gz pwd (connection hangs and eventually times out)