Date: Fri, 01 Mar 2002 11:37:03 +0000 From: Bob Bishop <rb@gid.co.uk> To: Luigi Rizzo <rizzo@icir.org>, "George V. Neville-Neil" <gnn@neville-neil.com> Cc: Doug Ambrisko <ambrisko@ambrisko.com>, hackers@FreeBSD.ORG Subject: Re: Multicast problem with sis interface? Message-ID: <4.3.2.7.2.20020301112956.00c5b550@gid.co.uk> In-Reply-To: <20020301011035.A31942@iguana.icir.org> References: <200203010557.VAA1802420@meer.meer.net> <rb@gid.co.uk> <4.3.2.7.2.20020222165515.00c14850@gid.co.uk> <200203010557.VAA1802420@meer.meer.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, At 01:10 01/03/02 -0800, Luigi Rizzo wrote: >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. Correct, but the trailing 1's were supplied by the switch between the box with the sis and the box running tcpdump. George's patch looks plausible, I'll check it out tonight (GMT). >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. I tried this, but missed m_pkthdr.len (whacks self round head). >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 ? Appletalk NBP, for instance. >Which are the other drivers that "work" ? ed, vr, rl > 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 gnn@neville-neil.com > > NIC:GN82 > > > > "Those who would trade liberty for temporary security deserve neither" > > - Benjamin Franklin > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message -- Bob Bishop +44 (0)118 977 4017 rb@gid.co.uk fax +44 (0)118 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.2.7.2.20020301112956.00c5b550>