Re: wlan0 goes down but system doesn't notice

On Sun, 23 Nov 2025 at 07:14, bob prohaska <fbsd@www.zefox.net> wrote:

> On Sat, Nov 22, 2025 at 08:14:49PM -0800, Adrian Chadd wrote:
> > hi!
> >
> > Would you please do
> >
> > dmesg | grep run0
> >
> > and report it here?
> >
> > i have plenty of run devices, I can go grab one and stick it in my RPI4
> and
> > see if it slowly goes deaf/blind like yours.
> > (Then I can figure out what to do to fix that. :-)
>
>
>
> # dmesg | grep 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: <Ralink 802.11 n WLAN, class 0/0, rev 2.00/1.01, addr 5> 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
>

Thanks!


>
> I'm not entirely sure this is a FreeBSD-specific problem; Raspberry Pi's
> (both 2 and 5) have behaved similarly in the past in this location.
> At the moment a Pi2 running Bookworm with an rtw_8822bu gets "sticky"
> but recovers after tens of seconds delay. The Pi5 with internal wifi
> was prone to remaining silently stuck, but I haven't checked that for
> a couple of months.
>
>
Well yeah, RF is like that. :-) But at least now I can go and reproduce it
here and
dig into the driver to tell you what else to enable for diagnostics!


-adrian


> Thanks for the quick reply, please let me know if I can furning more
> information.
>
> bob prohaska
>
>
>
>
> >
> > -adrian
> >
> >
> > On Sat, 22 Nov 2025 at 18:18, bob prohaska <fbsd@www.zefox.net> wrote:
> >
> > > A Pi2 running
> > > 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
> > >
> > > seems to be dropping its wifi without noticing.
> > >
> > > It picks up a connection hands off on boot but loses it after a few
> hours.
> > > Sometimes it reports
> > >
> > > Nov 22 17:12:53 generic dhclient[4381]: send_packet: No buffer space
> > > availableg: Name could not be resolved at this time (2)
> > >
> > > Attempts to ping by name seem to fail silently, ping by number fails
> with
> > >
> > > # ping 192.168.1.254
> > > PING 192.168.1.254 (192.168.1.254): 56 data bytes
> > > ^C
> > > --- 192.168.1.254 ping statistics ---
> > > 21 packets transmitted, 0 packets received, 100.0% packet loss
> > >
> > > Resetting the interface seems to fix the problem without difficulty:
> > >
> > > # ifconfig wlan0 down
> > > Nov 22 17:29:23 generic dhclient[4381]: My address (192.168.1.11) was
> > > deleted, dhclient exiting
> > > #
> > > # Nov 22 17:29:26 generic dhclient[4381]: connection closed
> > > Nov 22 17:29:26 generic dhclient[4381]: exiting.
> > >
> > > # ifconfig wlan0 up
> > > run0: firmware RT3071 ver. 0.33 loaded
> > > # Nov 22 17:29:58 generic wpa_supplicant[3373]: ioctl[SIOCS80211,
> op=20,
> > > val=0, arg_len=7]: Can't assign requested address
> > > # ping www.zefox.net
> > > PING www.zefox.net (50.1.20.27): 56 data bytes
> > > 64 bytes from 50.1.20.27: icmp_seq=0 ttl=63 time=5.868 ms
> > > 64 bytes from 50.1.20.27: icmp_seq=1 ttl=63 time=4.630 ms
> > > 64 bytes from 50.1.20.27: icmp_seq=3 ttl=63 time=4.892 ms
> > > 64 bytes from 50.1.20.27: icmp_seq=4 ttl=63 time=4.890 ms
> > >
> > > It isn't surprising the wifi link drops, signal has been poor for
> > > some time. It's more surprising that the failure isn't noticed and
> > > corrected by the system. Dmesg duly notes my manual resets of wlan0
> > > but reports no other problems.
> > >
> > > Any suggestions appreciated.
> > >
> > > Thanks for reading,
> > >
> > > bob prohaska
> > >
> > >
>