From wollman@khavrinen.lcs.mit.edu Fri Sep 17 10:48:05 1999
Return-Path: <wollman@khavrinen.lcs.mit.edu>
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id 23B6714C80
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 17 Sep 1999 10:47:58 -0700 (PDT)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA52014;
	Fri, 17 Sep 1999 13:47:57 -0400 (EDT)
	(envelope-from wollman)
Message-Id: <199909171747.NAA52014@khavrinen.lcs.mit.edu>
Date: Fri, 17 Sep 1999 13:47:57 -0400 (EDT)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Reply-To: wollman@khavrinen.lcs.mit.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: ti driver truncates some packets
X-Send-Pr-Version: 3.2

>Number:         13793
>Category:       kern
>Synopsis:       ti driver truncates some packets
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Sep 17 10:50:03 PDT 1999
>Closed-Date:    Fri Sep 17 11:06:49 PDT 1999
>Last-Modified:  Fri Sep 17 11:14:59 PDT 1999
>Originator:     Garrett Wollman
>Release:        FreeBSD 4.0-CURRENT i386
>Organization:
MIT Laboratory for Computer Science
>Environment:

	-current as of September 10, 1999
	$FreeBSD: src/sys/pci/if_ti.c,v 1.17 1999/08/29 09:03:57 bde Exp $
	Hardware is a Netgear GA620 in an Intel BB440FX server
	platform (Pentium Pro with 440FX chipset).

>Description:

	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.

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

>Fix:

	Unknown.


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: wpaul 
State-Changed-When: Fri Sep 17 11:06:49 PDT 1999 
State-Changed-Why:  

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. 
>Unformatted:
