Hi,
Seems there might be some problem with multicast on sis interfaces.
Specifically, netatalk doesn't work right on this box through the sis
interface but it's fine through the RealTek.
This is the onboard interface on a K7S5A m/b, dmesg follows. Ideas, anyone? TIA
Copyright (c) 1992-2002 The F
Bob Bishop writes:
| Seems there might be some problem with multicast on sis interfaces.
| Specifically, netatalk doesn't work right on this box through the sis
| interface but it's fine through the RealTek.
| This is the onboard interface on a K7S5A m/b, dmesg follows. Ideas, anyone? TIA
|
| Cop
Hi,
At 21:01 -0800 18/2/02, Doug Ambrisko wrote:
>Bob Bishop writes:
>| Seems there might be some problem with multicast on sis interfaces.
>| Specifically, netatalk doesn't work right on this box through the sis
>| interface but it's fine through the RealTek.
>| This is the onboard interface on
Bob Bishop writes:
| Hi,
|
| At 21:01 -0800 18/2/02, Doug Ambrisko wrote:
| >Bob Bishop writes:
| >| Seems there might be some problem with multicast on sis interfaces.
| >| Specifically, netatalk doesn't work right on this box through the sis
| >| interface but it's fine through the RealTek.
| >
Hi,
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
> 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
Here is a context diff that fixes the driver. Not the most performant solution
(it requires allocating a new, zero'd, mbuf) but it's the most straightforward
fix. Auto Padding is still on in the driver. I saw no reason to disable this
even
though we're now go around it.
This fix is against -C
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 u
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 pa
On Fri, Mar 01, 2002 at 11:37:03AM +, 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 t
> 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.
I have verified this as well, and did before I hacked that patch to
OK, here is the official answer:
4.2.3.3 Minimum frame size
The CSMA/CD Media Access mechanism requires that a minimum frame
length of minFrameSize bits be transmitted. If frameSize is less than
minFrameSize,
then the CSMA/CD MAC sub layer shall append extra bits in units of octets,
after
th
In a message written on Fri, Mar 01, 2002 at 03:56:23AM -0800, Luigi Rizzo wrote:
> 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;
On Fri, Mar 01, 2002 at 01:41:23PM -0500, Leo Bicknell wrote:
> In a message written on Fri, Mar 01, 2002 at 03:56:23AM -0800, Luigi Rizzo wrote:
> > ok, these three drivers behave as follows:
> >
> > "ed" pads with whatever is left in the transmit buffer from
> > earlier transmissions;
>
Leo Bicknell wrote:
> I point out both of these are security risks. Granted, fairly
> minor, but they allow someone to get all/part of a previous packet's
> data, when they should have it. This sort of thing has been used
> as an attack vector before. I think fixing these to pad with some
> gen
On Fri, Mar 01, 2002 at 01:41:23PM -0500, Leo Bicknell wrote:
> In a message written on Fri, Mar 01, 2002 at 03:56:23AM -0800, Luigi Rizzo wrote:
> > ok, these three drivers behave as follows:
> >
> > "ed" pads with whatever is left in the transmit buffer from
> > earlier transmissions;
>
On Sat, Mar 02, 2002 at 12:12:33PM -0800, Crist J. Clark wrote:
> > > 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;
Hi,
The padding thing is a red herring - sorry about that. The real problem
seems to be the interface's filtering, because setting the interface
promiscuous makes the problem go away.
See kern/35511 for details and a workaround. I imagine the proper fix is a
2 minute job for someone who under
18 matches
Mail list logo