jerpelea opened a new pull request, #20070: URL: https://github.com/apache/nuttx/pull/20070
## Summary Two independent defects in net/arp that together make a peer periodically unreachable when two network interfaces share an IPv4 subnet. Both are needed: fixing either one alone produces a worse result than the bug, which is why they are submitted together as separate commits. 1. arp_find() can answer with another interface's MAC. The ARP table itself is keyed by (device, address), but on a cache miss arp_find() falls back to netdev_foreach(arp_match, ...), and arp_match() compares only the IP address. Any interface holding that address wins and its MAC is returned, regardless of the device the frame is going out on. A frame transmitted on interface A can therefore be addressed to the MAC of interface B. Note the asymmetry with route selection, which already filters on IFF_IS_RUNNING (netdev_prefixlen_findby_lipv4addr()). 2. arp_send() leaks dev->d_lock. The -EINPROGRESS branch does goto wait, jumping over the netdev_unlock(dev) further down, and arp_wait() does not release the lock either. The caller therefore sleeps holding d_lock, while netdev_upper_rxpoll_work() needs that same lock to dispatch incoming frames — so the ARP reply being waited for can never reach arp_input(). Because d_lock is recursive, retries re-acquire it and the recursion depth is never unwound, so the interface stays blocked. Defect 2 is normally invisible: the wrong-MAC shortcut of defect 1 keeps the code from ever reaching real ARP resolution. Remove the shortcut without fixing the lock and a self-healing outage becomes a permanent loss of connectivity. ## Impact RELEASE ## Testing CI -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
