How to purge all network related config?

okay but that is the default behaviour of wpa_supplicant right? enabling that option would be the same as the default behaviour?
i have it disabled right now and it tries to connect (failing) continuously

Nope, wpasupplicant has not internal auto-reconnection feature (that I am aware of). The one in dietpi-config starts dietpi-wifi-monitor.service which does that by checking connection state every 10 seconds. However just to be clear it is very simple and does not know about ifplugd or other intentions, hence is not compatible with the ifplugd-based auto-switch on Ethernet connection. It will try to reconnect WiFi until you either stop the service (or dietpi-config option) or physically unplug the adapter :wink:.

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:

jun 21 10:27:21 DietPi wpa_supplicant[887]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid=“CasitaAP” auth_failures=1 duration=10 reason=CONN_FAILED

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 :frowning:

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 :thinking:.

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:

root@DietPi:~# iw reg get
global
country ES: DFS-ETSI
        (2400 - 2483 @ 40), (N/A, 20), (N/A)
        (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
        (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
        (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
        (5725 - 5875 @ 80), (N/A, 13), (N/A)
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

root@DietPi:~# iw reg set ES
root@DietPi:~# iw reg get
global
country ES: DFS-ETSI
        (2400 - 2483 @ 40), (N/A, 20), (N/A)
        (5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
        (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
        (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
        (5725 - 5875 @ 80), (N/A, 13), (N/A)
        (57000 - 66000 @ 2160), (N/A, 40), (N/A)

root@DietPi:~# dmesg | grep cfg80211
[    2.146142] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    2.159436] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    3.352689] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
[   23.454176] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled

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

which channels are used on your WiFi AP now?

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

you can use dietpi-wifi-monitor.service to watch the WiFi connection. It should try to reconnect WiFi if connection get lost.

okay so it seems like this is fixed:

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 :rofl:

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

and /etc/default/ifplugd

INTERFACES="eth0"
HOTPLUG_INTERFACES="auto"
ARGS="-q -f -u0 -d5 -w -I"
SUSPEND_ACTION="stop"

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

thanks to both devs for your time!

ok good that we found a working solution for you.

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.

Done
https://dietpi.com/forum/t/using-ethernet-wlan-interfaces-not-at-the-same-time-in-v6-30/4251/1

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?

in theory you could start the wifi monitor service together with ifup wlan0 and bring it down as soon as the script calls ifdown wlan0

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 :wink:

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 :slight_smile:.
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

journalctl -u ifup@wlan0.service

jul 01 20:42:56 DietPi systemd[1]: Started ifup for wlan0.
jul 01 20:42:56 DietPi wpa_supplicant[377]: Successfully initialized wpa_supplicant
jul 01 20:42:59 DietPi wpa_supplicant[469]: wlan0: Trying to associate with SSID 'CasitaAP_5G'
jul 01 20:43:02 DietPi wpa_supplicant[469]: wlan0: Associated with cc:32:e5:53:9e:99
jul 01 20:43:02 DietPi wpa_supplicant[469]: wlan0: CTRL-EVENT-CONNECTED - Connection to cc:32:e5:53:9e:99 completed [id=0 id_str=]
jul 01 20:43:02 DietPi wpa_supplicant[469]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
jul 01 20:43:19 DietPi systemd[1]: ifup@wlan0.service: Main process exited, code=exited, status=1/FAILURE
jul 01 20:43:19 DietPi wpa_supplicant[469]: nl80211: Failed to open /proc/sys/net/ipv4/conf/p2p-dev-wlan0/drop_unicast_in_l2_multicast: No such file or directory
jul 01 20:43:19 DietPi wpa_supplicant[469]: nl80211: Failed to set IPv4 unicast in multicast filter
jul 01 20:43:19 DietPi wpa_supplicant[469]: nl80211: Failed to open /proc/sys/net/ipv4/conf/p2p-dev-wlan0/drop_unicast_in_l2_multicast: No such file or directory
jul 01 20:43:19 DietPi wpa_supplicant[469]: nl80211: Failed to set IPv4 unicast in multicast filter
jul 01 20:43:19 DietPi wpa_supplicant[469]: nl80211: deinit ifname=p2p-dev-wlan0 disabled_11b_rates=0
jul 01 20:43:19 DietPi wpa_supplicant[469]: p2p-dev-wlan0: CTRL-EVENT-TERMINATING
jul 01 20:43:19 DietPi wpa_supplicant[469]: wlan0: CTRL-EVENT-DISCONNECTED bssid=cc:32:e5:53:9e:99 reason=3 locally_generated=1
jul 01 20:43:19 DietPi wpa_supplicant[469]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
jul 01 20:43:20 DietPi wpa_supplicant[469]: wlan0: CTRL-EVENT-TERMINATING
jul 01 20:43:20 DietPi systemd[1]: ifup@wlan0.service: Failed with result 'exit-code'.

Why did it tried to connect? wpa_supplicant didn’t had to be launched at all at any time since ethernet is plugged in from the beggining

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.