Re: -current network buffer exhaustion on RPi2 armv7
bob prohaska <[email protected]> Mon, 16 Feb 2026 15:32:49 -0800
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Feb 16, 2026 at 03:15:24PM -0800, bob prohaska wrote:
> On Mon, Feb 16, 2026 at 01:42:40PM -0800, Adrian Chadd wrote:
> > [snip snip]
> >
> > * the "no buffer space available" is the ENOBUFS returned somewhere
> > before the link status goes completely up for normal traffic.
> >
> > * the "ioctl failure" is because wpa_supplicant has 802.11w compiled
> > in now but we don't do 802.11w, so net80211 errors out on trying to
> > set key indexes 4 and 5.
>
> Ahh, so it's not really a bug then.
>
> After the previous post the same error message popped up on the console.
> There's a flurry of complaints tacked on to /var/log/daemon.log:
> root@generic:/usr/src # tail /var/log/daemon.log
> Feb 16 14:56:59 generic wpa_supplicant[3384]: wlan0: Reject scan trigger since one is already pending
> Feb 16 14:56:59 generic wpa_supplicant[3384]: wlan0: Failed to initiate AP scan
> Feb 16 14:57:00 generic wpa_supplicant[3384]: wlan0: Reject scan trigger since one is already pending
> Feb 16 14:57:00 generic wpa_supplicant[3384]: wlan0: Failed to initiate AP scan
> Feb 16 14:57:01 generic wpa_supplicant[3384]: wlan0: Reject scan trigger since one is already pending
> Feb 16 14:57:01 generic wpa_supplicant[3384]: wlan0: Failed to initiate AP scan
> Feb 16 14:57:02 generic wpa_supplicant[3384]: wlan0: Reject scan trigger since one is already pending
> Feb 16 14:57:02 generic wpa_supplicant[3384]: wlan0: Failed to initiate AP scan
> Feb 16 14:57:03 generic wpa_supplicant[3384]: wlan0: Reject scan trigger since one is already pending
> Feb 16 14:57:03 generic wpa_supplicant[3384]: wlan0: Failed to initiate AP scan
> root@generic:/usr/src #
>
> Does this likewise represent expected behavior?
> The messages seem to come about once per second and don't stop.
> Meanwhile, connectivity is good enough to run git pull successfully.
Oops, I'm mistaken. The network connection turned out to be down.
However, the system didn't seem to know it. ifconfig reported:
lan0: flags=8c43<UP,BROADCAST,RUNNING,DRV_OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=0
ether 00:0f:60:05:37:4f
inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::20f:60ff:fe05:374f%wlan0 prefixlen 64 scopeid 0x3
groups: wlan
ssid "" channel 2 (2417 MHz 11g)
regdomain ETSI2 country US authmode WPA1+WPA2/802.11i privacy ON
deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS wme
roaming MANUAL
parent interface: run0
media: IEEE 802.11 Wireless Ethernet DS/1Mbps mode 11g (autoselect)
status: no carrier
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
but ping reported network is down. Running ifconfig wlan0 up provoked
no response and no change in behavior. Running ifconfig wlan0 down
reports dhclient exiting, followed by
ifconfig wlan0 up seems to restore connectivity, at least for a while.
Is the system losing its connectivity and not noticing? Or maybe
noticing but getting stuck in a loop trying to recover? The
status: no carrier
seems to indicate a problem.
Thanks for reading!
bob prohaska