net: ARP is broken in master (at least) on STM32

[therealprof]

I was trying to introduce networking support to new STM32 boards earlier today and was scratching my head about was was wrong with the driver because I couldn't get a single ARP reply into the ARP cache. Out of desperation I ripped out a known good device (Nucleo-F429ZI) board out of a setup and tried the latest Zephyr version on that one and low-and-behold: it shows the same problem.

So I went back to an older version and it worked fine, so I reduced my sample config and bisected the latest changes. The bisection is not 100% conclusive (because the changes don't seem to be 100% separate) but the build fails somewhere around: 89eeba4.

Signs of the problem are constant ARP resends with the responses being ignored:

[net/arp] [DBG] arp_entry_find_move_first: (0x200064b0): dst 192.168.11.200
[net/arp] [DBG] arp_entry_find_pending: (0x200064b0): dst 192.168.11.200
[net/ethernet] [DBG] net_eth_fill_header: (0x200064b0): iface 0x2000ba20 src 00:80:E1:E1:11:5E dst FF:FF:FF:FF:FF:FF type 0x806 len 0
[net/arp] [DBG] net_arp_prepare: (0x200064b0): Resending ARP 0x20007f40
[net/ethernet] [DBG] ethernet_send: (0x200064b0): Sending arp pkt 0x20007f40 (orig 0x20007f88) to iface 0x2000ba20
[net/ethernet] [DBG] ethernet_recv: (0x200044b8): iface 0x2000ba20 src C8:0E:14:BC:64:B2 dst 00:80:E1:E1:11:5E type 0x806 len 60
[net/ethernet] [DBG] ethernet_recv: (0x200044b8): ARP packet from C8:0E:14:BC:64:B2 received
[net/arp] [DBG] arp_update: (0x200044b8): src 192.168.11.200
[net/arp] [DBG] arp_entry_get_pending: (0x200044b8): dst 192.168.11.200

and net arp always yielding an exactly empty list.

[therealprof]

Probably caused by either #8029 and/or #8608.

[tbursztyka]

Can you give more information? what test do you run, what .config content (grep on CONFIG_NET_)

I quickly retried on dhcpv4_client sample (enabled CONFIG_NET_SHELL to get the ping command and arp/ethernet logging) and it seems to work fine, though I am on a frdm_k64f.

In your case looks like there is already a pending request registered, do you ever get this:

[net/arp] [DBG] arp_entry_cleanup: (0x20002148): 0x20001a88
[net/arp] [DBG] arp_entry_cleanup: (0x20002148): Releasing pending pkt 0x20003120 (ref 0)

?

Seems like you arp_update can't find the pending one, thus why he does not finally put the entry on table.

[therealprof]

@tbursztyka I'm using samples/net/lwm2m_client/ with the standard configuration but IPv6 disabled, fixed static default IP removed and CONFIG_NET_APP_PEER_IPV4_ADDR set to my default server. I've had the problem on various STM32 boards (including the previously working Nucleo-F429ZI and two new boards I'm working on right now) but I have a FRDM-K64F here with me, too so I can quickly retry there.

[therealprof]

NB: I've also tried varying the size of the ARP cache but no change. arp_entry_cleanup doesn't seem to be called at all, at least I've nothing in the logs.

[therealprof]

@tbursztyka FRDM-K64F works for me. One suspicion I had yesterday was incorrect initialisation of the ARP entries list, maybe the NXP platform initialisation (or the MCU itself) does something different to STM32 which just happens to work with the new ARP code?

[tbursztyka]

Could be indeed. All these:

static bool arp_cache_initialized;
static struct arp_entry arp_entries[CONFIG_NET_ARP_TABLE_SIZE];

static sys_slist_t arp_free_entries;
static sys_slist_t arp_pending_entries;
static sys_slist_t arp_table;

struct k_delayed_work arp_request_timer;

"should" be zero-ed by default since there are not on a noinit section.
In my PR I specifically set arp_cache_initialized to false, but checkpatch issued me an error that static bool should not be set to false (since it's 0). Can you instrument arp.c like:

NET_DBG("ARP already initialized");

line 658.

[tbursztyka]

btw try also a memset(&arp_entries[i], 0, sizeof(struct arp_entry)); in the arp_init for loop before entry is being inserted into free list.

[pfalcon]

For reference, for me frdm_k64f works too with 58e40cb (current HEAD). Using samples/net/sockets/dumb_http_server, I can ping the board and issue HTTP requests to it.

[therealprof]

LOL, you're not going to believe it: I found the problem and it is something completely different... Missing call to ethernet_init() in the stm_eth driver, it's exposed by the move of net_arp_init() into ethernet_init().