I do not agree with the explaination. Padding is padding, the actual
value is irrelevant. Plus, in the tcpdump below, the are actually
46 bytes of data, which together with the 14 of the MAC header and
the 4bytes of CRC make a perfectly legal packet.
I strongly suspect a bug elsewhere, e.g. the upper layer calling
ether_output() with a short length.
The thing is, other drivers might implement padding differently --
e.g. the "vr" just artificially increases m_pkthdr.len and m_len
to make sure that the packet has the right size, thus letting out
any junk that is already in the mbuf. This "junk" might actually
be useful data for the receiver, and this would mask the bug in
passing the short length to ether_output().
What kind of protocol are we talking about ?
Which are the other drivers that "work" ?
cheers
luigi
On Thu, Feb 28, 2002 at 09:57:02PM -0800, George V. Neville-Neil wrote:
> > At 13:10 19/02/02 -0800, Doug Ambrisko wrote:
> > >Bob Bishop writes:
> > >| No dice with last night's -STABLE. And it's definitely the interface, I've
> > >| tried a variety and netatalk works with everything (including the dreaded
> > >| Via Rhine) except for the onboard sis0.
> > >|
> > >| I suppose it's time for some comparative tcpdumping...
> > >
> > >Pity that would have been an easy fix. Doing tcpdump should help.
> > >I like Ethereal so I can drill down a little easier.
> >
> > This is what tcpdump (on a disinterested machine) sees:
> >
> > sis - fails:
> >
> > 20:53:43.423585 255.0.158.nis > 0.0.nis: nbp-lkup 1: "=:=@*"
> > [addr=255.0.158.128]
> > aaaa 0308 0007 809b 001a 8369 0000 ff00
> > ff9e 0202 0221 01ff 009e 8000 013d 013d
> > 012a ffff ffff ffff ffff ffff ffff
> >
> > vr - works:
> >
> > 20:54:55.022827 255.0.158.nis > 0.0.nis: nbp-lkup 1: "=:=@*"
> > [addr=255.0.158.128]
> > aaaa 0308 0007 809b 001a 8369 0000 ff00
> > ff9e 0202 0221 01ff 009e 8000 013d 013d
> > 012a 0050 baec bd66 00ff 009e 0000
> >
> > Those trailing 1's look suspicious to me. The NBP lookup packet is only 48
> > bytes, so needs padding to the ethernet minimum 60 on the wire. I suspect
> > this isn't happening on the sis. The packets are otherwise well-formed (and
> > the ethernet headers (not shown above) are correct).
>
> No need. The problem seems to be that at least the National Semi
> version of the chip does have "Auto Padding" which pads runt packets
> out to the necessary 60 bytes for Ethernet but that the padding is
> 1s and not 0s. I seem to remember that according to the Ethernet
> spec the pad bytes should be 0 but don't quote me.
>
> I figured that Auto Padding was not on, but actually it is by default in the
> driver.
>
> You can easily reproduce this bug by doing a
>
> ping -s 1 224.0.0.1
>
> on the machine with the sis device.
>
> To fix this someone would have to modify sis_encap to pad
> to the minimum 60 bytes by hand. I'll take a crack at that now.
>
> Later,
> George
>
> --
> George V. Neville-Neil [EMAIL PROTECTED]
> NIC:GN82
>
> "Those who would trade liberty for temporary security deserve neither"
> - Benjamin Franklin
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
