Re: -current network buffer exhaustion on RPi2 armv7

On 2/21/26 13:43, bob prohaska wrote:
> On Sat, Feb 21, 2026 at 11:10:39AM -0800, Mark Millard wrote:
>> On 2/20/26 10:03, bob prohaska wrote:
>>> It looks rather as if the "no buffer space available" text isn't
>>> coming from wpa_cli, but rather from syslogd reporting directly
>>> to the console (at the moment the serial console is the only
>>> interactive connection to the Pi2). 
>>
>>
>> You previously supplied text indicating that one source of "send_packet:
>> No buffer space available" was dhclient's activity:
>>
>> QUOTE
>> daemon.log:Feb 16 03:53:37 generic dhclient[35171]: send_packet: No
>> buffer space available
>> END QUOTE
>>
>> I've not noticed your reports indicating anyplace else so far.
> 
> I'm running wpa_cli on the serial console. The output contains
> system console messages interleaved with wpa_cli messages.  
> 
> It's dawned on me that line breaks aren't always preserved and
> so I could be seeing run-on output from more than one source. 
> This can be seen if a top session is left running for several
> hours; the formatting begins to mix fragments of different
> process outputs.
>  
> As a result, it's possible that the above quote mixes contents
> of different messages. It isn't certain that the  "no buffer space
> available" has anything to do with dhclient.

Well, send_packet is part of the context as well:

# grep -r '"send_packet: [%N]' /usr/src/
/usr/src/sbin/dhclient/bpf.c:		warning("send_packet: %m");
/usr/src/libexec/tftpd/tftp-io.c:	tftp_log(LOG_ERR, "send_packet: %s",
strerror(errno));

src/sbin/dhclient/bpf.c :

void
send_packet_priv(struct interface_info *interface, struct imsg_hdr *hdr,
int fd)
{
. . .
        if (result < 0)
                warning("send_packet: %m");
}

src/sbin/dhclient/errwarn.c :

. . .
static char mbuf[1024];
static char fbuf[1024];
. . .

int
warning(const char *fmt, ...)
{
        va_list list;

        do_percentm(fbuf, sizeof(fbuf), fmt);

        va_start(list, fmt);
        vsnprintf(mbuf, sizeof(mbuf), fbuf, list);
        va_end(list);

#ifndef DEBUG
        cap_syslog(capsyslog, log_priority | LOG_ERR, "%s", mbuf);
#endif

        if (log_perror) {
                write(2, mbuf, strlen(mbuf));
                write(2, "\n", 1);
        }

        return (0);
}
. . .
/*
 * Find %m in the input string and substitute an error message string.
 */
static void
do_percentm(char *obuf, size_t size, const char *ibuf)
{
        char ch;
        const char *s = ibuf;
        char *t = obuf;
        size_t prlen;
        size_t fmt_left;
        int saved_errno = errno;

        /*
         * We wouldn't need this mess if printf handled %m, or if
         * strerror() had been invented before syslog().
         */
        for (fmt_left = size; (ch = *s); ++s) {
                if (ch == '%' && s[1] == 'm') {
                        ++s;
                        prlen = snprintf(t, fmt_left, "%s",
                            strerror(saved_errno));
                        if (prlen >= fmt_left)
                                prlen = fmt_left - 1;
                        t += prlen;
                        fmt_left -= prlen;
                } else {
                        if (fmt_left > 1) {
                                *t++ = ch;
                                fmt_left--;
                        }
                }
        }
        *t = '\0';
}
. . .

src/lib/libc/string/strerror.c uses src/lib/libc/gen/errlst.c 's:

const char *const sys_errlist[] = {
. . .
        "No buffer space available",            /* 55 - ENOBUFS */
. . .

> 
> One thought is a brute-force search for the phrase "No buffer space
> available" anywhere in /usr/src. I've not seen that message again
> and knowing where it came from might be interesting. 

It looks like it came from dhclient indirectly using strerror and the
associated sys_errlist indexed by the errno value involved: ENOBUFS

Note that the "send_packet:" text is not part of the centralized, shared
message text for ENOBUFS . It is closer to unique for where it comes
from, given the place can also produce the text you are referencing.

> 
> In the meantime a grep search for "Can't assign requested address" has
> turned up several sources: libdtrace, libdxo, libntp and libc. There
> are a few more, but they're in places like test or unbound, which is 
> inactive now. 
> 
> I plan to attempt a similar search for "No buffer space available"
> when the present search finishes. 
> 
> My hope is that knowing which process can report what error will
> clarify what's going wrong. If there are more fruitful things to
> explore please indicate. 

Good hunting. (I did not show all the steps for tracking down what I
showed.)


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