|
|
|
|
|
|
|
|
|
|
xen-users
RE: [Xen-users] Xen () ethernet padding
>
> I made some tests about ethernet padding ( in my dummy works:
> an expected behavior from ethernet 10/100 on-wire, that needs at
> least 60 bytes of data to be able to CRC and the NIC chipset has the
> job of fullfill the packet if it is smaller than this- padding ) and
> I notice a behavior that is not expected (at least for me).
>
Maybe not relevant to you problem, but I have a router which uses the
'via_rhine' linux Ethernet driver, and it simply doesn't bother padding
packets when sending them out on the wire. The Cisco switch that it is
connected to reflects those packets in the 'runt frames' counter, but
otherwise isn't bothered. Nothing else on the network appears to be
bothered either.
I've raised the problem with the author of the driver, the linux kernel
mailing list, and even submitted a patch, but nobody seems to care.
(it may actually be fixed by now, I haven't checked as the only problem
it appears to cause is the counter incrementing on the cisco router)
I think that the minimum frame size was only really imported on single
duplex unswitched networks (eg a 'hub' or 10base[25]), where you had to
be absolutely sure that if you were up one end of the wire, you'd be
able to sense a device transmitting from the other end of the wire
whilst you were still transmitting your packet, so that you could detect
the collision. If you had finished your packet (because it was too
short), then you'd not see the packet from the other end of the wire
until you were idle again, and the packet would be lost.
James
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
|
|