Re: -current network buffer exhaustion on RPi2 armv7

On 2/16/26 15:32, bob prohaska wrote:
> 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

"no carrier" is a form of indicating "network down" at that point as far
as I know. It does not indicate any detailed stage of error handling at
the time, however.

>         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?

It might be losing and later re-gaining the connectivity periodically,
for all I know (via its error handling).

> Or maybe
> noticing but getting stuck in a loop trying to recover? The 
> status: no carrier
> seems to indicate a problem.

It does indicate a problem at the time.

[Sorry for forgetting and sending my prior message via a plain Email
based reply.]


-- 
===
Mark Millard
marklmi at yahoo.com