Ethernet server full - mac_tx -> packet size > 64 ?

[voodoosound]

Hi everyone,

I have found something odd.

If I try to send an Ethernet frame with a size less then 64 Byte, it is not transmitted!
Nothing on the wire!

I couldn't figure out the reason, did someone else?

Am I doing something wrong?

Regards,
Ck

[segher]

Your too small frames probably _are_ sent on the wire.
Any receiver is supposed to throw away all frames less than
64 bytes ("runt frames"), since they are not valid frames,
which they are not because they are typically caused by
collissions or underruns. If you look at the statistic counters
of your receiving MAC you should see one of those error
counters steadily increase.

Don't send too short frames :-)

[voodoosound]

But the other way around works fine. The ethernet server on the L16 is receiving frames with 42 bytes length. And processes them as it should be.

And the receiver of my frames expects them to be shorter then 64 bytes...

[segher]

If that receiver code (sc_ethernet? You don't say) accepts
runt frames, that is a bug. If you send runt frames, that
is a bug. If your protocol requires such frames, that is a
bug.

[voodoosound]

This would mean, that to your statement IEEE 1722.1 are buggy and wrong.

IEEE 1722.1 2013 - 7.4.40 GET_AVB_INFO Command:
Ethernet Header: 14 Byte
1722 Header: 12 Byte
1722.1 GET_AVB_INFO: 16 Byte
= 42 Byte
Wireshark verified!


It seems, thet mac_tx needs at least 64 als length. the rest of the message is then zero padded.

[segher]

Yes, ethernet frames that contain AVB stuff are at least 64
bytes long, just like all other ethernet frames.

To debug your problem you can look at what the code actually
does, whether it puts the necessary padding in by itself or
if that is your responsibility; or you can attack the problem
from the other direction, look at what is on the wire. Do note
that wireshark does not show you that: it shows sniffed data
at some point above the NIC you use for sniffing (depending
on the device driver you use).