wifi disconnect sends ARP announcement 255.255.255.255

[ZivLow]

Issue description

• Using wireless sniffer, found that STA sends gratuitous ARP (Address Resolution Protocol) announcement, with sender IP & target IP as 255.255.255.255, upon wifi disconnection.
• However, sending ARP announcement 255.255.255.255 is invalid.

Why ARP announcement 255.255.255.255 is invalid

• ARP announcement means "both the sender and target IP address fields contain the IP address being announced. It conveys a stronger statement than an ARP Probe, namely, "This is the address I am now using." RFC 5227, section 1.1
• So, ARP Announcement's sender/target IP is supposed to be the specific unicast address the host is claiming
• But the limited broadcast address 255.255.255.255 "must not be used as source address" RFC 1122, section 3.2.1.3 (c)
• There is a Cisco bug CSCug19184, which talks about potential negative impact on networking equipment due to sending out of ARP announcement 255.255.255.255.

Expected behaviour

• STA should never send ARP announcement with 255.255.255.255 IP, as that is invalid address.

Wireless sniffer

• ailite_disconnect_arp_255.255.255.255.zip
• wireshark filter: wlan.addr == 9c:5c:8e:b6:68:3c && wlan.addr == 74:22:0d:18:68:72 && !wlan.fc.type_subtype == 0x24

Setup

• Tested on TizenRT, master branch, commit 149e1628f.
• RTL8730E (AmebaSmart)
• config: flat_dev_psram

Reproduce issue

• In TASH shell

wm_test start
wm_test join <SSID> wpa2_aes <PASSWORD>
wm_test leave

• May need to wait a while (~20s) after connection before doing the disconnect, to observe the 255.255.255.255 ARP being sent out
• If disconnect too early, then may not be able to see 255.255.255.255 ARP sent out. Maybe still getting IP.
• Reproduce rate: always

Analysis

Trace function call flow

• Flow downwards

_netdev_dhcpc_stop #struct in_addr in = {.s_addr = INADDR_NONE};
_netdev_set_ipv4addr
netifapi_netif_set_addr
netifapi_do_netif_set_addr
netif_set_addr
netif_set_ipaddr
netif_issue_reports #checks !ip4_addr_isany_val
etharp_gratuitous
etharp_request
etharp_request_dst
etharp_raw
ethernet_output

AI analysis

1. RTK WiFi driver detects disconnect → posts LWNL_EVT_STA_DISCONNECTED (rtk_netmgr.c:245).
2. wifi_manager_state.c (e.g. line 641) handles WIFIMGR_EVT_STA_DISCONNECTED → calls dhcpc_close_ipaddr().
3. wifi_manager_dhcpc.c:67 → dhcp_client_stop() → ioctl DHCPCSTOP.
4. netmgr_ioctl_lwip.c:170 _netdev_dhcpc_stop() builds in.s_addr = INADDR_NONE (255.255.255.255, not INADDR_ANY/0.0.0.0 as intended) and passes it as ip/netmask/gw to _netdev_set_ipv4addr(), which calls netifapi_netif_set_addr(dev, 255.255.255.255, ..., ...).
5. lwIP's netif_set_addr() (os/net/lwip/src/core/netif.c:353): since the new IP is not "any" (ip4_addr_isany() false because it's 255.255.255.255, not 0.0.0.0), it takes the "else" branch (line 361-365) and calls netif_set_ipaddr().
6. netif_set_ipaddr() (netif.c:497) detects the address changed, sets netif->ip_addr = 255.255.255.255, then calls netif_issue_reports() (line 524).
7. netif_issue_reports() (netif.c:607) only guards against 0.0.0.0 (ip4_addr_isany_val, line 610) — 255.255.255.255 passes this check — and calls etharp_gratuitous(netif) (line 614).
8. etharp_gratuitous (etharp.h:106) → etharp_request(netif, netif_ip4_addr(netif)) → etharp_request_dst() (etharp.c:1156-1161) sends the ARP request using netif_ip4_addr(netif) — now 255.255.255.255 — as the source IP, broadcasting to ethbroadcast.

Fix / Workaround

DHCP stop, set IP to 0.0.0.0

TizenRT/os/net/netmgr/netmgr_ioctl_lwip.c

Lines 173 to 175 in 149e162

	int _netdev_dhcpc_stop(const char *intf)
	{
	struct in_addr in = {.s_addr = INADDR_NONE};

• When DHCP client stops, set IP address to INADDR_ANY (0.0.0.0), instead of INADDR_NONE (255.255.255.255).
• No longer observe ARP 255.255.255.255 sent out upon wifi disconnection.

Questions

1. Is setting the IP address to 255.255.255.255 when wifi disconnect an intentional design decision?