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