Re: -current network buffer exhaustion on RPi2 armv7

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.

Thanks for writing!

bob prohaska