Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Mar 2002 03:56:23 -0800
From:      Luigi Rizzo <rizzo@icir.org>
To:        Bob Bishop <rb@gid.co.uk>
Cc:        "George V. Neville-Neil" <gnn@neville-neil.com>, Doug Ambrisko <ambrisko@ambrisko.com>, hackers@FreeBSD.ORG
Subject:   Re: Multicast problem with sis interface?
Message-ID:  <20020301035623.A32974@iguana.icir.org>
In-Reply-To: <4.3.2.7.2.20020301112956.00c5b550@gid.co.uk>
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> <4.3.2.7.2.20020301112956.00c5b550@gid.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 01, 2002 at 11:37:03AM +0000, Bob Bishop wrote:
> 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.

I find this hard to believe. The "sis" driver does the padding
itself, using ones for the padding. I have verified this locally.
And a switch which receives a short packet (runt packet) is
not supposed to pass it through.

> >What kind of protocol are we talking about ?
> 
> Appletalk NBP, for instance.

can you try and instruments the calls in the protocol stack which
are issued to generate the packet ?

> >Which are the other drivers that "work" ?
> 
> ed, vr, rl

ok, these three drivers behave as follows:

 "ed" pads with whatever is left in the transmit buffer from
      earlier transmissions;
 "vr" pads with whatever is available in the mbuf after the actual data;
 "rl" pads with zeroes (in the driver)
and of course
 "sis" pads in hardware (with ones)

The beauty of diversity...

	cheers
	luigi

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?20020301035623.A32974>