But I have it switched off and in the journalctl of ifplugd, as I posted here before, I can see the reconnection attempts, and also after each failed attempt there is an increase in the time after the next attempt
You can see it for example in this line:
Which has the numer of failed attempts, and the duration until the next attempt, that is the output of wpa supplicant
Also this line shows when that time ends and is ready for the next attempt:
jun 21 10:27:35 DietPi wpa_supplicant[887]: wlan0: CTRL-EVENT-SSID-REENABLED id=0 ssid=“CasitaAP”
But anyway, what I want to fix is the WiFi connection
Ah okay, yes that is not dietpi-wifi-monitor.service then but wpasupplicant failing to connect to WiFi on Ethernet unplug invoked by ifplugd. Probably wpasupplicant has an internal retry mechanism when initial connection fails. But I doubt that it reliably reconnects when WiFi connection was established successfully and then lost with DHCP and/or static IP, due to the steps required after the WiFi connection to gain network access. But would be actually nice .
About country code, we switched from wpasupplicant-based country code assignment to crda only. When adding it to /etc/defaults/crda, it is applied to the WiFi adapter via udev rule once it is plugged/detected, which seems cleaner than setting it again on every AP connection. This means you should be able to remove country=es from wpasupplicant config.
Calling crda requires the COUNTRY variable to be set yes. However it fails with error code -7.
What does the following show? iw reg set ES
Interesting is that iw reg get does show ES indeed.
I read that some USB WiFi adapters have the country code hardcoded:
Could you check: dmesg | grep cfg80211
Okay, there is a problem, i booted the raspberry to get that info and without modifying anything it does connect to both 5ghz and 2.4ghz wifi… i don’t know if this is gonna be any relevant but i will put here the info. Anyway, i have used those commands before and it is the same output that it is showing now:
Also, in /etc/defaults/rdca i have REGDOMAIN=ES set
I don’t know, as it does work for now i suppose i cannot reproduce the issue, so i will keep using it as normally for now and if it stops working again i will come here to try to find the issue, i supose. But i dont think it is hardcoded, as it would mean that i would never be able to connect to it but i have been able to connect some times to those wifis. There must be some conflict of several services imposing regdomains, or some cache giving problems
the 2.4ghz was at first in channel 1 and now i have changed it to channel 13, both works, and both using 40mhz of bandwidth if that matters, and the 5ghz is in channel 48, 80mhz bandwidth
i just changed the channel of the wifi it was connected and i see that it doesnt reconnect by itself, i had to plug and unplug the ethernet cable so that it triggers the connect command, im gonna search for some script for the ifplugd that reconnects when wifi is dropped while ethernet is unplugged
i have clean flashed the distro again, as i have been editing several config files of the system trying to fix the network issues and i dont even remember anymore all the files i modified, and also to discard any other problem i decided to cleanflash and apply my new knowledges in the new install
okay so, clean flash, and as i know two interfaces active will be problematic i went throught the setup only with ethernet
then i installed ifplugd to have it already installed in case internet connection doesnt work at some point throught the process, then i just set the internet using the dietpi-config for both ethernet, with static ip, and then a reboot, and then the wifi with static and both ssid, the country, the inboard wifi, and then a reboot, and then proceed to edit the config files of wpa_supplicant (it doesnt have to be modified, dietpi-config does it right, but i check it just in case), /etc/network/interface (commenting the hotplugging of eth0, and checking that both interfaces has correct static ips), checking that /etc/default/crda has REGDOMAIN=ES, and finally edit /etc/ifplugd/ifplugd.action to contain:
#!/bin/sh
set -e
if [ -z "$1" ] || [ -z "$2" ] ; then
echo "Wrong arguments" > /dev/stderr
exit 1
fi
if [ "$1" != "eth0" ]; then
echo "Wrong interface!" > /dev/stderr
exit 1
fi
if [ "$2" = "up" ] ; then
echo "bring down WiFi"
/sbin/ifdown wlan0 --force
/sbin/ifup eth0 --force
exit 0
elif [ "$2" = "down" ] ; then
echo "bring up WiFi"
/sbin/ifdown eth0 --force
/sbin/ifup wlan0 --force
exit 0
fi
exit 1
finally,
systemctl enable ifplugd.service
systemctl start ifplugd.service
reboot
and voilá, it is working
Now, i have set both interfaces to have the same static ip, and it “works”, as in it works sometimes but i think hotswitching from one to the other makes the second one to not actually work, but no errors of wifi connection shown, it is connected, it is just that the router doesnt like two macs attatched to the same ip, at least if it happens too recently both of them… but no problem for me, i dont plan to be switching from one to another in a short time
so, conclusions: i suggest the devs to add ifplugd as an option inside the network menu, it is simple to install and configure, and seems to avoid a lot of headaches in common network configurations… Now i would have to try the dietpi-wifi-monitor to see if it makes some trouble if i activate it with my current settings (with ifplugd, i mean), but yeah, im happy with this
Akrai
Amazing, that is indeed a great setup, would you like to copy he instructions to tutorials? https://dietpi.com/phpbb/viewforum.php?f=15
I’m still thinking if we should implement it with ifplugd as well or go with an own implementation so that ifplugd is not occupied and can still be used for other purpose. But its great to have a working solution.
I don’t want to try and enable the wifi monitor for reconnecting yet, is it safe in this setup? does the monitor keeps running when ethernet is connected, for example?
nice, so the autoreconnect option of dietpi config is just a systemctl enable & start a systemd service? if so, then it would be as easy as changing the content of
/etc/ifplugd/ifplugd.action
#!/bin/sh
set -e
if [ -z "$1" ] || [ -z "$2" ] ; then
echo "Wrong arguments" > /dev/stderr
exit 1
fi
if [ "$1" != "eth0" ]; then
echo "Wrong interface!" > /dev/stderr
exit 1
fi
if [ "$2" = "up" ] ; then
echo "bring down WiFi"
/sbin/ifdown wlan0 --force
/sbin/ifup eth0 --force
---> systemctl stop name of the .service
---> systemctl disable name of the .service
exit 0
elif [ "$2" = "down" ] ; then
echo "bring up WiFi"
/sbin/ifdown eth0 --force
/sbin/ifup wlan0 --force
---> systemctl start name of the .service
---> systemctl enable name of the .service
exit 0
fi
exit 1
you would need to call systemctl with the full path like
/bin/systemctl
Otherwise the command will not be interpreted correctly, I guess. Unfortunately I already removed my test installation for other suppot requests. Therefore I’m not able to test. But you can give it a try
okay, no problem, but can you confirm if the dietpi-config option of autoreconnect is just enabling the service? or i would need to do something more to emulate the same thing?
Use
systemctl disable --now name.service
and
systemctl enable --now name.server
to disable/enable + stop/start the services with one command .
And yes dietpi-wifi-monitor.service just needs to be started, no other step required.
I didn’t know about the one line systemctl flag, good to know, thanks!
Okay so i have just added it and it works! it reconnects quickly, very good
Now, for a proper testing i should test if there is any reconnection feature without adding those lines but im lazy right now and as it probably doesnt have any reconnect feature, it will disconnect when i disable the wifi from the router, and it wont reconnect again and i would need to take the raspi to connect it from ethernet or reboot it or whatever… meh, lets just assume there wasnt any reconnection feature going on by default and we just added one and it works reliably, so nice! And it is a simple setup, to be honest, which is cool too
Thanks!
If I boot the raspberry with ethernet plugged in, this happens:
systemctl status ifup@wlan0.service → status: failed, which then implies that if i do a systemctl, it says status: degraded, because an unit has a failed status
Starting WiFi during boot is as expected becasue we set allow-hotplug wlan0 within /etc/network/interfaces. This means WiFi is always being started during boot, but will be switched off as soon as ifplugd is detecting the Ethernet connection. On my test it was needed to set allow-hotplug wlan0, otherwise WiFi was not working correctly if the system was booted with WiFi only.
.
.