RPz(W) wlan down detection - help

I have this problem where I have a RPz(W) and now and then the wlan0 interface goes down.

I don't know if it is because the WAP goes down - which I hope it isn't happening - or something on the RPI is stopping the interface for a while.

What ever.

So, where I am at now is how to detect when wlan0 goes down.

Sorry if this is a dumb question. I seem to be good at asking them.

Not a dumb question in any way!

I have a similar issue with both of my Pi Zero W. Now and then, they drop out of my WiFi for about 70-72 minutes (every time). Very sporadically, sometimes after days/weeks without any issue. Nothing unusual in the log files.

As a crude and quick solution I was thinking about a small Node-RED flow that restarts the Wifi service after n failed pings. :thinking:

The curious thing is the duration of ~72 minutes, but I haven't had the time to investigate any deeper, because the devices always reconnect after that period. :see_no_evil:

My problem isn't as easy as yours.

Alas though I have seen WAP outages and restores the RPz usually comes back.

Now and then it doesn't and I know it is M.I.A. the LED on it is going nuts. (Crazy blinking)
and it never reconnects.

I need to reboot it.

So I am wanting to find out how to detect if the wlan0 is up or down.

Then, after n attempts, it issues a command to try and get the interface back up.

BTW, what command do you use to get the wlan0 interface back up?

Did you configure it with systemd?

If so, you could use networkctl status wlan0 and parse the output somehow.

If haven't built the flow yet (because it always comes back after 72min), but I would try sudo systemctl restart wpa_supplicant@wlan0.service.

You would need to add this to your sudoers file, of course.


I have dug (and dug and dug) and I was told this command will work.

ip link set wlan0 up

But thanks for the networkctl status wlan0 bit.

I will have to just add this as part of the existing flow.

I'll have to work out how to implement the how part.

Oh, the output of the networkctl status wlan0. . . . what indicates that it is down?

If think ip link set wlan0 up is just for the interface part.

Regardless of how you manage wlan0, I think restarting the wpa_supplicant could be necessary.

ifup wlan0 and ifdown wlan0 should take care of that, if you use the standard Debian network scripts.

I have read to NOT use those commands as they are depricated.

What I posted is more up to date.

LEDs crazy blinking reminds me of the kernel panics... might be worth looking into what happens at that moment, but if you can’t access the machine at all when it happens that gets harder.


Being a headless machine it is rather difficult to see.

sudo dmesg doesn't give me much.
I've checked other logs and they too don't show much.

I can ping the machine, but can't ssh to it.

So I can only unplug the power supply and plug it in again.

If you can’t ssh to it, you can’t do a sudo dmesg.

It might be that it is checking the filesystem, which could take a while, after that it starts sshd.

Just as a bit more, this is the block of text I found:

What you want is the modern way of configuring network interfaces, which is event-driven: when an interface is brought up, an event is fired and dhcpcd configures networking (see /etc/dhcpcd.conf). When an interface disappears, an event is fired and dhcpcd deconfigures networking.
In a sense, it is all "hotplug" by default now.

Forget the old commands "ifup wlan0" / "ifdown wlan0".
Instead get in the habit of using "ifconfig wlan0 up" / "ifconfig wlan0 down". Or, to be entirely up-to-date, "ip link set wlan0 up" / "ip link set wlan0 down". These commands will make dhcpcd do something.

ifup and ifdown are not deprecated, these scripts are the standard Debian configuration scripts for network interfaces.

I believe you mean ifconfig... that one is getting superseded by the newer ip tool.

Yeah, ok. Sorry. Tripped on the terms.

But that block is what I found while digging.

Hope that helps you a bit too.

True. But can't sudo dmesg see back a couple of boots?

I reboot it, let it settle down, SSH to it and do the command.

I don't see anything worrying or indicative of a kernel panic.

(Though I have had fun with kernel panics not being recorded on another machine. LUCKILY the message had some junk in it which then led to finding the kernel panic. This one doesn't have anything like that.)

No, dmesg like that only shows for the current boot, from the moment you turned it on.

If it really panics, then the logs may be lost anyway. :frowning: These Pi Zeros are hell to debug once they are deployed without a display connected to it.

Well, that's interesting.

On the other machine when the dmesg was done the dates were dating back days and it was only at the end when we saw the recent events. (and the corruption of the file) which led to working out it was a kernel panic.
But that's on another machine.

Ok. So if it happens, I unplug it, move it to a good place plug in monitor/keyboard and see what dmesg says then?

But that will show that boot, not the previous session which hung.


Ah. Thanks. That's good to know. Kinda.

I'm hoping that it is just upset and if I reset the wlan0 with the command it will be happy.

Alas it is a catch 22.
I can't really prove it and will have to wait for it to happen again.

Thing is: How do I detect it?

The command you said.... Yeah. Nice, but when the interface is down, what does it given?
I'm guessing I am going to have to parse it looking for something specific which indicates it is down.

On my Pi3 (via ethernet) it says for the wlan0 state: State: off (unmanaged)

The PiZ (via Wifi): State: routable (configured)

BTW: If anyone has a better idea how to get the connection status using Node-RED... please shoot. :grinning:

Again: Thanks.

ITMT, I double looked at what happened when I did the command you said:

pi@TelePi:~ $ networkctl status wlan0
WARNING: systemd-networkd is not running, output will be incomplete.

● 2: wlan0
       Link File: n/a
    Network File: n/a
            Type: wlan
           State: n/a (unmanaged)
            Path: platform-20300000.mmc
          Driver: brcmfmac
      HW Address: b8:27:eb:2f:8f:57 (Raspberry Pi Foundation)
pi@TelePi:~ $ 

First line.
That's not good - yeah?
BTW, I use FIXED IP addresses.