Re: wlan0 goes down but system doesn't notice

Adrian Chadd <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <CAJ-VmonmmapXquCkGm8zGz=FWe03sJMQy3eC3scfE1n81iF7eg@mail.gmail.com>
On Sun, 23 Nov 2025 at 07:14, bob prohaska <[email protected]> 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 <[email protected]> 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
> > >
> > >
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.