Subject: Re: tlp strangeness
To: Chris Tribo <ctribo@college.dtcc.edu>
From: Matt Fredette <fredette@theory.lcs.mit.edu>
List: current-users
Date: 09/27/2003 13:06:51
> For my own enjoyment I decided I was going to fill up an old machine with 
> ethernet cards to make sure that the drivers were happy with them. 
> Unfortunately, they aren't.
> 
> ex0 - 3c905a in pci slot
> tlp0 - Linksys LNE-100TX version 4.1
> tlp1 - Netgear FA310TX rev D2
> tlp2 - Asante Fast 10/100 Ethernet Mac/PC DECchip 21140-AF, should be
> 	attaching a DAVICOM DM9101F phy, but isn't.
> ex1 - 3c905a onboard
> 
> - tlp0 tlp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         address: 00:04:5a:55:16:9a
>         media: Ethernet autoselect (100baseTX full-duplex)
>         status: active
>         inet 192.168.1.104 netmask 0xffffff00 broadcast 192.168.1.255
> 
> 	reports this every time dhclient runs:
> 
> 	DHCPREQUEST on tlp2 to 255.255.255.255 port 67
> 	DHCPREQUEST on tlp0 to 255.255.255.255 port 67
> 	DHCPDISCOVER on tlp1 to 255.255.255.255 port 67 interval 6
> 	ip length 576 disagrees with bytes received 580.
> 	accepting packet with data after udp payload.
> 
> 	Come to think of it, I've seen this with le(pmax), bm(macppc), and 
> 	tlp(i386,macppc), ex interfaces never report this.

Quoting myself in http://mail-index.netbsd.org/port-sun2/2003/02/24/0000.html :

] Apparently in rev. 1.80 of src/sys/dev/ic/tulip.c,
] a change was made to explicitly pass the CRC to the upper layers, 
] including BPF.  Passing it to BPF was probably unintentional, since it 
] makes BPF on tulip work slightly differently than on other interfaces.

The 4-byte CRC should account for the length disagreement.

-- 
Matt Fredette