-
Notifications
You must be signed in to change notification settings - Fork 8.3k
Description
When testing IPv4 link local address configuration with SAM E70 Xplained board, it was found that the five first packets where Zephyr announces its intended link local address are sent with ethernet type 0x0800, which means IPv4. The packets should instead be sent with ethernet type 0x0806, which is ARP. Wireshark thus sees five bogus IPv4 packets and complains that the IP version in the IPv4 header is zero, but must be 4.
Setting type 0x0800 probably happens in ethernet_send() in subsys/net/l2/ethernet/ethernet.c, since the net_pkt_family(pkt) is AF_INET. Now the problem is that while the called ethernet_ll_prepare_on_ipv4() function correctly checks for net_pkt_ipv4_auto(pkt), ethernet_send() is also used when sending regular IPv4 packets and ARP ones if necessary, which means that changes to the logic handling also IPv4 link local ARP messages seems to get a bit tricky in that function. Thus only a bug report and no patch.
It also seems that the IPv4 link local packets are all ARP requests, but the latter ones are not ARP announcements, since the packets always have the same content and do not change the sender IPv4 address from 0.0.0.0 to the selected IPv4 interface address, see https://tools.ietf.org/html/rfc3927#section-2.4.
This is the hex dump from wireshark, notice the ethernet type 0x0800 in the 13th byte and the all zero sender address at the 28th byte:
0000 ff ff ff ff ff ff fc c2 3d 12 f3 ab 08 00 00 01
0010 08 00 06 04 00 01 fc c2 3d 12 f3 ab 00 00 00 00
0020 00 00 00 00 00 00 a9 fe 19 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00
As it is now, IPv4 link local addresses can't work reliably, as they are not recognized by hosts on the link.