Problems with WLAN connectivity - solved

rkorell

Dear mirror fans,
for your information and reference some findings with my mirror.
I’m running a MagicMirror on a PI5 with an NVME HAT as boot device.
My first approach was to de-assemble an original Pi power supply (because of its form factor) and to build this internally into the mirror-frame.
As reported earlier in a different thread this power supply died due to overheating.

My next approach was to use a new PI-power supply - this time externally.
Caused by the circumstances of my installation (power plug far below mirror position and Pi mounted on the top of the mirror) I have used a USB-C to USB-C cable (150cm, 5A) to extend the standard-cable.

As it turns out now this wasn’t a good idea, ether:
It worked pretty long (several weeks) good and without any problem.
But since some days I got more and more really stubborn WLAN losses which were often unrecoverable - only plugging out power supply to reforce a restart helped (I’m working headless as majority of you).

In the meantime I was able to implement a tiny service which automatically detects the connectivity loss and restarts the WLAN, so a sufficient symptomatic treatment is in place - this discovers connectivity every five minutes, which is OK to me.

While I was just tinkering I’ve thought it could be a nice idea to identify the root cause and so I added some logging features in the mentioned service.

Now the interesting (unexpected) finding: Obvious root cause was an undervoltage!

I’ve searched around (because initially I failed to remember my “cable-extension”) but couldn’t find any reason for this (nothing attached else than the NVME and my mirror doesn’t have anything heavily using the harddisk)…

Then the additional cable came in my mind and - voilà - this was the root cause - despite its thickness and 5A specification.
For now I have added some 230V cabeling to the top of the mirror, installed there (outside the mirror frame) a third (de-assembled) PI power supply and connected the standard-long cable of this power supply to the Pi.
Since then no undervoltage detected (prior to this every few minutes).

So my learning: Pi is bitchy with cable extensions and tiny undervoltages can lead to heavy WLAN problems.

May one or the other can benefit from these findings.

Warm regards,
Ralf

sdetweil

@rkorell awesome post, great info!

rkorell

@sdetweil :-)
Thanks.

In addition: If somebody is interested in the scripts and system-services definitions for own purposes - give me a ping and I will share this for sure…

Regards,
Ralf

schlomm

@rkorell Thanks for your Insights! Interesting!
One question: How you got the idea that the issue is caused by power/energy circumstances?
Are there any specific logs with those information?

And yes - it would be great to get an idea of your scripts :)

rkorell

Dear @schlomm ,
I initially had no clue at all regarding root cause :-)
And the finding “undervoltage” was never expected but came out off my logfiles.

After a LOT of tinkering and playing with syptomatic “solutions” system kept to be unstable so I decided to dig in and do some logging to identify root cause.

For this I wrote a shellscript and installed a system service which collects this data every five minutes.

shellscript:

sudo nano /usr/local/bin/wlan-diagnose.sh

content:

#!/bin/bash
LOGFILE="/var/log/wlan-diagnose.log"
DATE=$(date '+%a %d %b %H:%M:%S %Z %Y')
WLAN_IF="wlan0"

echo "===== $DATE =====" >> $LOGFILE

# IP-Adresse
echo "--- IP-Adresse ---" >> $LOGFILE
ip addr show $WLAN_IF >> $LOGFILE 2>&1

# Link-Status
echo "--- Link Status ---" >> $LOGFILE
iw dev $WLAN_IF link >> $LOGFILE 2>&1

# Default Route
echo "--- Routing ---" >> $LOGFILE
ip route >> $LOGFILE 2>&1

# Wpa_supplicant Status
echo "--- wpa_supplicant ---" >> $LOGFILE
systemctl status wpa_supplicant --no-pager >> $LOGFILE 2>&1

# Letzte wpa_supplicant Logs
echo "--- wpa_supplicant journal (letzte 20 Zeilen) ---" >> $LOGFILE
journalctl -u wpa_supplicant -n 20 --no-pager >> $LOGFILE 2>&1

# Kernel/Treiber Logs
echo "--- dmesg wlan0 ---" >> $LOGFILE
dmesg | tail -n 20 >> $LOGFILE 2>&1

# Ping-Test
PING_TARGET="8.8.8.8"
ping -I $WLAN_IF -c3 -W3 $PING_TARGET >> $LOGFILE 2>&1

echo "" >> $LOGFILE

set as executable:

sudo chmod +x /usr/local/bin/wlan-diagnose.sh

systemd-timer for this diagnosis script:

sudo nano /etc/systemd/system/wlan-diagnose.timer

content:

[Unit]
Description=WLAN Diagnose alle 5 Minuten

[Timer]
OnBootSec=1min
OnUnitActiveSec=5min
Persistent=true

[Install]
WantedBy=timers.target

service file:

sudo nano /etc/systemd/system/wlan-diagnose.service

content:

[Unit]
Description=WLAN Diagnose Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/wlan-diagnose.sh

activate the service:

sudo systemctl daemon-reload
sudo systemctl enable --now wlan-diagnose.timer

Created logfile: /var/log/wlan-diagnose.log

possible command for filtering for errors:

grep -i "fail\|error\|disconnect" /var/log/wlan-diagnose.log

in my personal case directly after starting the service the undervoltage warnings appeared in the logfile:

Sep 24 19:23:02 MagicMirrorPi5 wpa_supplicant[702]: wlan0: CTRL-EVENT-CONNECTED - Connection to f8:bc:0e:51:50:48 completed [id=0 id_str=] Sep 24 19:23:02 MagicMirrorPi5 wpa_supplicant[702]: bgscan simple: Failed to enable signal strength monitoring --- dmesg wlan0 --- [ 385.672898] hwmon hwmon4: Voltage normalised [ 399.780700] hwmon hwmon4: Undervoltage detected! [ 401.796721] hwmon hwmon4: Voltage normalised [ 403.812728] hwmon hwmon4: Undervoltage detected! [ 405.831888] hwmon hwmon4: Voltage normalised [ 425.988994] hwmon hwmon4: Undervoltage detected! [ 428.008109] hwmon hwmon4: Voltage normalised [ 434.052979] hwmon hwmon4: Undervoltage detected! [ 438.087587] hwmon hwmon4: Voltage normalised [ 442.117090] hwmon hwmon4: Undervoltage detected! [ 444.133104] hwmon hwmon4: Voltage normalised [ 452.198182] hwmon hwmon4: Undervoltage detected! [ 454.213171] hwmon hwmon4: Voltage normalised [ 470.341318] hwmon hwmon4: Undervoltage detected! [ 478.405369] hwmon hwmon4: Voltage normalised [ 488.485467] hwmon hwmon4: Undervoltage detected! [ 490.505469] hwmon hwmon4: Voltage normalised [ 514.693689] hwmon hwmon4: Undervoltage detected! [ 516.709733] hwmon hwmon4: Voltage normalised [ 520.744884] hwmon hwmon4: Undervoltage detected! PING 8.8.8.8 (8.8.8.8) from 172.23.56.157 wlan0: 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=13.2 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=33.6 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=27.5 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 13.220/24.756/33.576/8.529 ms

So I had identified my root cause with first strike.

In the meantime (today) I had severe additional problems (also “identified” by this mentioned log) - but this was a kernel/device driver problem which I cannot solve today.
But this leads to a modified recovery script because the version from yesterday only tried to restart the WPA_Supplicant which was not sufficient for my problem today.

If you are interested in, this is the recovery script:

#!/bin/bash
# wlan-recovery.sh
# Prüft WLAN-Verbindung und startet wpa_supplicant / Interface bei Ausfall neu

LOGFILE="/var/log/wlan-recovery.log"
WLAN_IF="wlan0"
PING_TARGET="8.8.8.8"
DATE=$(date '+%a %d %b %H:%M:%S %Z %Y')

# 1. Power save prüfen & ggf. deaktivieren
PS=$(iw dev $WLAN_IF get power_save)
if [ "$PS" = "Power save: on" ]; then
    echo "$DATE: Power Save ist ON → deaktiviere" >> $LOGFILE
    iw dev $WLAN_IF set power_save off
fi

# 2. Verbindung prüfen
ping -I $WLAN_IF -c1 -W3 $PING_TARGET > /dev/null 2>&1
if [ $? -ne 0 ]; then
    echo "$DATE: Keine Verbindung. Versuche wpa_supplicant restart..." >> $LOGFILE
    systemctl restart wpa_supplicant
    sleep 5

    ping -I $WLAN_IF -c1 -W3 $PING_TARGET > /dev/null 2>&1
    if [ $? -ne 0 ]; then
        echo "$DATE: Verbindung immer noch nicht da. Interface + Treiber toggle..." >> $LOGFILE
        
        # Interface herunterfahren
        ip link set $WLAN_IF down
        sleep 2
        
        # Treiber neu laden
        modprobe -r brcmfmac
        sleep 2
        modprobe brcmfmac
        sleep 2

        # Interface wieder hochfahren
        ip link set $WLAN_IF up
        sleep 5

        ping -I $WLAN_IF -c1 -W3 $PING_TARGET > /dev/null 2>&1
        if [ $? -ne 0 ]; then
            echo "$DATE: Wiederherstellung fehlgeschlagen." >> $LOGFILE
        else
            echo "$DATE: Verbindung wiederhergestellt nach Interface + Treiber reload." >> $LOGFILE
        fi
    else
        echo "$DATE: Verbindung wiederhergestellt nach wpa_supplicant restart." >> $LOGFILE
    fi
else
    echo "$DATE: Verbindung ok." >> $LOGFILE
fi

Hope this helps you.
Do not hesitate to ask for futher information …

Warmest regards,
Ralf

rkorell

addition:
the recovery script is: /usr/local/bin/wlan-recovery.sh

set executable:

sudo chmod +x /usr/local/bin/wlan-recovery.sh

Systemd-Service

sudo nano /etc/systemd/system/wlan-recovery.service

content:

[Unit]
Description=WLAN Recovery Script
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/wlan-recovery.sh

timer:

sudo nano /etc/systemd/system/wlan-recovery.timer

content:

[Unit]
Description=Run WLAN Recovery every 5 minutes

[Timer]
OnBootSec=1min
OnUnitActiveSec=5min
Persistent=true

[Install]
WantedBy=timers.target

activate this service:

sudo systemctl daemon-reload
sudo systemctl enable --now wlan-recovery.timer

logfile: /var/log/wlan-recovery.log

schlomm

@rkorell Thanks for all these detailed Information! I’ll setup your scripts on my MagicMirror Instances - I have 6 different ones to manage and at least one has some weird problems - maybe also relating to power issues.

Thanks und Vielen Dank :)

rkorell

@schlomm Sehr gern und VIEL ERFOLG!

melde Dich, wenn Du noch was benötigst.
Ralf