From nobody Mon Nov 24 15:19:28 2025 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dFTwt0jHkz6HLym for ; Mon, 24 Nov 2025 15:18:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dFTws4R6Rz3jhh; Mon, 24 Nov 2025 15:18:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 5AOFJXwJ072813 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 24 Nov 2025 07:19:33 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 5AOFJXdg072812; Mon, 24 Nov 2025 07:19:33 -0800 (PST) (envelope-from fbsd) Date: Mon, 24 Nov 2025 07:19:28 -0800 From: bob prohaska To: Adrian Chadd Cc: freebsd-arm@freebsd.org Subject: Re: wlan0 goes down but system doesn't notice Message-ID: References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dFTws4R6Rz3jhh Here's a perhaps slightly more coherent account of wifi dropout and recovery, copied and pasted from the serial console. The system had been running buildworld overnight and was still running: # ifconfig lo0: flags=1008049 metric 0 mtu 16384 options=680003 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 groups: lo nd6 options=23 ue0: flags=8843 metric 0 mtu 1500 options=80009 ether b8:27:eb:18:f8:42 inet6 fe80::ba27:ebff:fe18:f842%ue0 prefixlen 64 scopeid 0x2 media: Ethernet autoselect (none) status: no carrier nd6 options=23 wlan0: flags=8843 metric 0 mtu 1500 options=0 ether 00:0f:60:05:37:4f inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::20f:60ff:fe05:374f%wlan0 prefixlen 64 scopeid 0x3 groups: wlan ssid d-link.zefox.net channel 1 (2412 MHz 11g) bssid 00:13:46:86:6d:0c regdomain ETSI2 country US authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 3:128-bit AES-CCM ucast:128-bit txpower 30 bmiss 7 scanvalid 60 protmode CTS wme roaming MANUAL parent interface: run0 media: IEEE 802.11 Wireless Ethernet DS/1Mbps mode 11g status: associated nd6 options=23 # ping 50.1.20.27 PING 50.1.20.27 (50.1.20.27): 56 data bytes ^C --- 50.1.20.27 ping statistics --- 17 packets transmitted, 0 packets received, 100.0% packet loss # ping 192.168.1.254 PING 192.168.1.254 (192.168.1.254): 56 data bytes ^C --- 192.168.1.254 ping statistics --- 23 packets transmitted, 0 packets received, 100.0% packet loss # dmesg | grep -i wlan0 wlan0: Ethernet address: 00:0f:60:05:37:4f wlan0: link state changed to UP wlan0: link state changed to DOWN ...........about 60 repeats.......... wlan0: link state changed to DOWN wlan0: link state changed to UP wlan0: link state changed to DOWN wlan0: link state changed to UP # dmesg | grep -i run #6 0xc03405f4 at run_interrupt_driven_config_hooks+0x98 #7 0xc0340978 at boot_run_interrupt_driven_config_hooks+0x20 #11 0xc03405f4 at run_interrupt_driven_config_hooks+0x98 #12 0xc0340978 at boot_run_interrupt_driven_config_hooks+0x20 run0 on uhub2 run0: on usbus0 run0: MAC/BBP RT5390 (rev 0x0502), RF RT5370 (MIMO 1T1R), address 00:0f:60:05:37:4f run0: [HT] Enabling 802.11n run0: firmware RT3071 ver. 0.33 loaded run0: firmware RT3071 ver. 0.33 loaded run0: firmware RT3071 ver. 0.33 loaded # ifconfig wlan0 down # Nov 24 06:54:03 generic dhclient[47314]: My address (192.168.1.11) was deleted, dhclient exiting Nov 24 06:54:05 generic dhclient[47314]: connection closed Nov 24 06:54:05 generic dhclient[47314]: exiting. # ifconfig wlan0 up run0: firmware RT3071 ver. 0.33 loaded # Nov 24 06:54:28 generic wpa_supplicant[3373]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address # ping 192.168.1.254 PING 192.168.1.254 (192.168.1.254): 56 data bytes 64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=6.168 ms 64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=3.957 ms 64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=4.064 ms 64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=4.137 ms 64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=4.010 ms ^C --- 192.168.1.254 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.957/4.467/6.168/0.852 ms # ping 50.1.20.27 PING 50.1.20.27 (50.1.20.27): 56 data bytes 64 bytes from 50.1.20.27: icmp_seq=0 ttl=63 time=4.652 ms 64 bytes from 50.1.20.27: icmp_seq=1 ttl=63 time=6.679 ms 64 bytes from 50.1.20.27: icmp_seq=2 ttl=63 time=7.213 ms 64 bytes from 50.1.20.27: icmp_seq=3 ttl=63 time=4.578 ms ^C --- 50.1.20.27 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 4.578/5.780/7.213/1.181 ms # # Obviously the link came back up without difficulty, but the line about "....can't assign requested address" which was apparently an interjected console warning, looks suspicious. For a long time I though it had something to do with DHCP's IP address, either given or requested, but the reference to IOCTL makes me think it's something in the local host. The local host reports # uname -a FreeBSD generic 16.0-CURRENT FreeBSD 16.0-CURRENT #5 main-n281932-07e6bfeae5a1: Fri Nov 21 00:43:58 PST 2025 root@generic:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm # uname -KU 1600004 1600004 This is one of the hosts formerly reporting an assertion failure from changes in jemalloc; the reversion suggested by Warner has been applied to the sources but this network problem predates that issue so I don't _think_ it matters. Otherwise the sources are unmolested. Thanks for reading, I hope this helps.... bob prohaska