Re: -current network buffer exhaustion on RPi2 armv7

On Feb 16, 2026, at 13:26, bob prohaska <[email protected]> wrote:

> 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

So, based on the later below as well, that looks to be parts of 3 messages:

) one from syslogd
) one from wpa_supplicant
) one from dhclient

in that order, with more missing than I identified earlier.

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

Adrian explained this one as an issue related to 802.11w code
being involved but not other parts of the FreeBSD OS.

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

The wording may be about not being able to allocate a buffer instead
of about not having space inside a pre-existing one.

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



===
Mark Millard
marklmi at yahoo.com