Re: -current network buffer exhaustion on RPi2 armv7

On Mon, Feb 16, 2026 at 12:08:53PM -0800, Mark Millard wrote:
> On 2/16/26 09:13, bob prohaska wrote:
> > From time to time a Raspberry Pi 2 v1.1 (armv7) running -current reports
> > 
> > Feb 16 08:23:34 generic syslogd: last message repeated 1 times, op=20, val=0, arg_len=7]: Can't assign requested address send_packet: No buffer space available
> 
> It looks like the text after "times," may have missing text before the
> "op=20,".
> 
Indeed. 

There's a very similar line (repeated lots of times) in /var/log/messages :
root@generic:/usr/src # cat /var/log/messages | grep -i arg_len
Feb 15 20:03:34 generic wpa_supplicant[3384]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address
Feb 16 01:23:35 generic wpa_supplicant[3384]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address
Feb 16 02:03:33 generic wpa_supplicant[3384]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Can't assign requested address

It's still unclear if wpa_supplicant is suffering the error, or it's
merely reporting an error on behalf of an underlying process.

Are there other places to look for added details? 

> contrib/wpa/src/drivers/driver_bsd.c has (up to line wrapping):
> 
> static int
> bsd_set80211(void *priv, int op, int val, const void *arg, int arg_len)
> . . .
>         if (ioctl(drv->global->sock, SIOCS80211, &ireq) < 0) {
>                 wpa_printf(MSG_ERROR, "ioctl[SIOCS80211, op=%u, val=%u, "
>                            "arg_len=%u]: %s", op, val, arg_len,
>                            strerror(errno));
>                 return -1;
>         }
> . . .
> 
> I've not found anything else that looks to be a match.
> 
> So, apparently, 802.11 WiFi as the communication channel "media".
> 
> My guess for op:
> 
> sys/net80211/ieee80211_ioctl.h:
> #define IEEE80211_IOC_DELKEY            20
> 
> "Can't assign requested address" Looks to be from EADDRNOTAVAIL in:
> 
> sys/net80211/ieee80211_ioctl.c :
> 
> . . .
> static int
> ieee80211_ioctl_delkey(struct ieee80211vap *vap, struct ieee80211req *ireq)
> . . .
>         if (dk.idk_keyix == (uint8_t) IEEE80211_KEYIX_NONE) {
>                 struct ieee80211_node *ni;
> 
>                 if (vap->iv_opmode == IEEE80211_M_STA) {
>                         ni = ieee80211_ref_node(vap->iv_bss);
>                         if (!IEEE80211_ADDR_EQ(dk.idk_macaddr,
> ni->ni_bssid)) {
>                                 ieee80211_free_node(ni);
>                                 return EADDRNOTAVAIL;
>                         }
>                 } else {
> . . .
> 
> 
> > (I think the numerical values repeat, but I'm not certain of it)
> > n
> > In this case, the ethernet network (via a usb-wifi adapter) remained up:
> 
> Yep: Looks to be that WiFi usage that is involved.
> 
> > 
> > root@generic:/usr/src # ping 192.168.1.254
> > PING 192.168.1.254 (192.168.1.254): 56 data bytes
> > 64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=4.406 ms
> > 64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=4.101 ms
> > 64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=3.989 ms
> > 64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=4.186 ms
> > 64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=4.119 ms
> > 64 bytes from 192.168.1.254: icmp_seq=5 ttl=64 time=3.948 ms
> > 64 bytes from 192.168.1.254: icmp_seq=6 ttl=64 time=4.478 ms
> > 64 bytes from 192.168.1.254: icmp_seq=7 ttl=64 time=5.119 ms
> > 64 bytes from 192.168.1.254: icmp_seq=8 ttl=64 time=4.417 ms
> > ^C
> > --- 192.168.1.254 ping statistics ---
> > 9 packets transmitted, 9 packets received, 0.0% packet loss
> > round-trip min/avg/max/stddev = 3.948/4.307/5.119/0.339 ms
> > 
> > Anybody have an idea what the machine is complaining about? 
> 
> I've not managed to get the point of referencing any specifics for the
> "No buffer space available", so: not me.
>
 
It turn out that running
root@generic:/var/log # grep -ir "no buffer" *
daemon.log:Feb 16 03:53:37 generic dhclient[35171]: send_packet: No buffer space available
messages:Feb 16 03:53:37 generic dhclient[35171]: send_packet: No buffer space available

but it's still unclear what process owns the buffer which is full, at
least to me.




> > At the time of these observations the machine was running a
> > -j4 buildworld with about 500M of swap in use. Within a few
> > minutes swap use declined to ~70M and no further complaints
> > were reported.
> > 
> > The ethernet adapter is a
> > ugen0.5: <RT5370 Wireless Adapter Ralink Technology, Corp.> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (450mA)
> > running on a powered hub, together with the root device, a usb-sata 
> > mechanical hard disk drive. 
> > 
> > Could this be indicative of a conflict or traffic jam between the
> > root device and the network by way of USB?
> 
> The USB being a single shared channel across the RPi2 v1.1 USB2 ports,
> any saturation of the channel could lead to either waiting and/or
> buffering/queuing for later (if possible at the time).
> 
In years past the OOMA system was quite vocal about slow swap. Even
when the system is obviously swap bound there are no warnings about
swap during the present exercise.  

> But I've no clue what type of buffer had no space available.
> 
> I'm not likely to get beyond what I have above. May be someone with
> background knowledge of the areas can indicate more.

Thanks for writing!

bob prohaska