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
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;
vr pads
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;
I point
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
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
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
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
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;
I
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;
vr pads
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
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
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
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 some
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 a
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,
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
16 matches
Mail list logo
