Re: -current network buffer exhaustion on RPi2 armv7

From: Adrian Chadd <adrian_at_freebsd.org>
Date: Mon, 16 Feb 2026 23:55:56 UTC
On Mon, 16 Feb 2026 at 15:30, bob prohaska <fbsd@www.zefox.net> wrote:
>
> 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
>         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? Or maybe
> noticing but getting stuck in a loop trying to recover? The
> status: no carrier
> seems to indicate a problem.

Yup, it looks like for some reason it's hung; wpa_supplicant should be
kicking off a scan and well,
the above is telling me that it is stuck.

Try running "wpa_cli" to see what decisions its making. it logs them
to the wpa_cli tool whilst its running.
You may first need to put this in /etc/wpa_supplicant.conf :

ctrl_interface=/var/run/wpa_supplicant

Meanwhile I'll go test out that NIC in a test device as its primary
internet connection and report back.



-adrian