MicrochipTech / oa-tc6-lib

Microchip OPEN Alliance TC6 Protocol Driver for LAN8650/1 source code and example applications.
20 stars 7 forks source link

tc6-lwip.c: MIN_HEADER_LEN: what calculation leads to the value of 42? #17

Open knieriem opened 6 months ago

knieriem commented 6 months ago

The tc6-lwip.c implementations in the example projects contain a C macro definition MIN_HEADER_LEN that is set to the value 42, like in:

./oa-tc6-lib/examples/lwIP-SAM-E54-Curiosity/app/firmware/src/tc6-lwip.c:478: #define MIN_HEADER_LEN  (42u)

This macro is used in the callback implementation TC6_CB_OnRxEthernetPacket to check wether the length of the received packet is beyond the minimum of 42 bytes.

This value could be the sum of

But how did it actually get calculated? Given that the preamble is not part of the packet handed over to TC6_CB_OnRxEthernetPacket, I wonder why the MIN_HEADER_LEN value is not 6 + 6 + 2 = 14 (i.e. dest and src MAC addresses + length field), or taking an IP header of 20 bytes into account, 14+20 = 34 bytes.

On the other hand, the minimum Ethernet frame length is 64, so packets that are handed over to OnRxEthernetPacket must have a length of at least 64 bytes. Wouldn't it be plausible then to rename MIN_HEADER_LEN to MIN_PACKET_LEN and set it to 64?

I would appreciate if you could clarify the origin of the value 42.

tkummermehr commented 6 months ago

Hi, the value 42 has been chosen, because its the combined ETH + IP + UDP header size.

You are right, the Ethernet packet is getting stuffed to 64 Byte, but only on the Physical Layer. On the software layer, which we are here, the packets can be smaller than that.

knieriem commented 6 months ago

Hi, thank you for the explanation and the quick response.

BTW, I noted that even when sending a UDP packet with 1 byte of data (i.e. a 43 byte sized packet, see details below) -- e.g. by using echo | nc -u -w1 192.168.5.100 9999 -- to the T1S node running oa-tc6-lib, TC6_CB_OnRxEthernetPacket reports a packetLen of 64, not 43. So perhaps something in my setup of the oa-tc6 lib ensures that the callback function receives the stuffed packet.

wireshark details:

Frame 1: 43 bytes on wire (344 bits), 43 bytes captured (344 bits) on interface sshdump, id 0
Ethernet II, Src: 04:05:06:01:02:03 (04:05:06:01:02:03), Dst: 11:22:33:44:55:66 (11:22:33:44:55:66)
Internet Protocol Version 4, Src: 192.168.5.1, Dst: 192.168.5.100
User Datagram Protocol, Src Port: 59729 (59729), Dst Port: distinct (9999)
Data (1 byte)
0000   11 22 33 44 55 66 04 05 06 01 02 03 08 00 45 00
0010   00 1d e3 9b 40 00 40 11 cb 7e c0 a8 05 01 c0 a8
0020   05 64 e9 51 27 0f 00 09 59 c5 0a