DietPi-WiFi-Monitor | Option: Check for Ethernet, else fallback to WiFi

[camdenorrb]

Creating a bug report/issue

Required Information

• DietPi version |
  G_DIETPI_VERSION_CORE=6
  G_DIETPI_VERSION_SUB=26
  G_DIETPI_VERSION_RC=3

• Distro version | buster

• Kernel version | Linux DietPi 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux

• SBC device | RPI 4

• Power supply used | CanaKit Raspberry Pi 4 Power Supply (USB-C)

• SDcard used | Samsung 64GB 100MB/s (U3) MicroSDXC EVO Select Memory Card with Full-Size Adapter (MB-ME64GA/AM)

Additional Information (if applicable)

• Can this issue be replicated on a fresh installation of DietPi? Probably, this was pretty fresh
  If you sent a "dietpi-bugreport", please paste the ID here: 4f353ae1-f948-4745-8bb3-00374244b90e

Steps to reproduce

1. Install dietpi
2. Connect to Ethernet with a static ip
3. (Might be optional) Install via dietpi-software: Gitea, Docker, NoIp, Pi-hole, Wireguard, iftop, build-essentials, git client
4. Connect to WI-FI with a non-static setup
5. Watch your WI-FI drop everytime you view it

Expected behaviour

• Connect to WI-FI and not drop

Actual behaviour

• WI-FI drops randomly and when you view it

Extra details

Unknown wpa_supplicant error in the logs for dietpi-wifi-monitor:

Dec 06 06:06:32 DietPi dietpi-wifi-monitor.sh[812]: DHCPRELEASE of 192.168.1.242 on wlan0 to 192.168.1.1 port 67
Dec 06 06:06:33 DietPi wpa_supplicant[1524]: wlan0: CTRL-EVENT-DISCONNECTED bssid=d4:a9:28:08:f6:06 reason=3 locally_generated=1
Dec 06 06:06:33 DietPi wpa_supplicant[1524]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Dec 06 06:06:33 DietPi wpa_supplicant[1524]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US
Dec 06 06:06:33 DietPi wpa_supplicant[1524]: nl80211: Failed to open /proc/sys/net/ipv4/conf/p2p-dev-wlan0/drop_unicast_in_l2_multica
st: No such file or directory
Dec 06 06:06:33 DietPi wpa_supplicant[1524]: nl80211: Failed to set IPv4 unicast in multicast filter
Dec 06 06:06:33 DietPi wpa_supplicant[1524]: nl80211: Failed to open /proc/sys/net/ipv4/conf/p2p-dev-wlan0/drop_unicast_in_l2_multica
st: No such file or directory
Dec 06 06:06:33 DietPi wpa_supplicant[1524]: nl80211: Failed to set IPv4 unicast in multicast filter

[MichaIng]

@camdenorrb
Many thanks for your report. I'll have a look into your bug report upload.

[camdenorrb]

The issue seems to go away if I turn off auto reconnect and change the static ip to dhcp, I can't have them on together nor separately as it disconnects randomly. This may be a work around, but I would like to have both features enabled if possible.

[MichaIng]

@camdenorrb
First of all please purge dhcpcd: G_AGP dhcpcd5
This is not required on DietPi, which uses isc-dhcp-client, which integrates with ifupdown (networking.service) much better. For some strange reason Pi-hole installs dhcpcd as additional DHCP client to then disable DHCP... Of course via its config you can configure it to not configure an interface, however installing a potentially conflicting DHCP client to not use DHCP is.. yeah 🤣

But the reason for your issue most likely is this:

192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.249
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.242

You have WiFi and Ethernet both active on the same local network. When doing a request, it is not clear for the system which adapter to send it through, since both share the same route. In such cases a routing table is required, to define which requests to send to which adapter, but most likely this setup is not what you want. There is usually no point in connecting with two adapters in parallel to the same network, I guess you want to use either Ethernet or WiFi? Please disable the other adapter then via dietpi-config.

Auto reconnect btw tries to ping the default route on the WiFi adapter. Could you paste what in your case this is:

ip r s 0.0.0.0/0 dev wlan0

Since your default route is attached to eth0, probably the above does not give a valid output. Probably we can find a better ping target when WiFi is not used for the default route.

[camdenorrb]

It appears to give no output

Also what is G_AGP?

And the goal was to have a redundant network connection in case the ethernet cable gets pulled out while I'm away from home

[MichaIng]

@camdenorrb
Ah yeah that is exactly the same that was reported >1 year ago: #2103 (comment)
We still didn't manage to add some workaround, e.g. to warn user or disable Ethernet if WiFi is enabled on same network, vise versa 😅. A real routing table based would be better, but again more work to create some reliable method + GUI for this.

Actually, since the idea of redundancy is reasonable, we could add an alternative WiFi monitor mode:

• Regularly check if Ethernet is up and has IP assigned
• If so, disable WiFi and attach default route to Ethernet
• If not, enable WiFi and attach default route to WiFi

So you can plug&play on different locations and it will always use Ethernet, when available, else fallback to WiFi.

Other way round doesn't make much sense, does it? If Ethernet is connected, why would one want WiFi, and if one uses WiFi for reason, then because one doesn't want or can lay out a cable.

I plan to rework our network configs to make them more flexible and compatible with custom setups. I'll add this issue to the project as well: https://github.com/MichaIng/DietPi/projects/1

[Akrai]

I don't know how you plan to do it but i'll leave here some info about it, or specifically about what I was trying to do (having the same static IP for both interfaces but only having active ethernet, and if Ethernet is unplugged then connect the wifi), it makes use of network bonding, and optionally it uses systemd networkd

https://raspberrypi.stackexchange.com/questions/83845/automatically-switch-between-wifi-and-ethernet-with-static-ip
https://raspberrypi.stackexchange.com/questions/78787/howto-migrate-from-networking-to-systemd-networkd-with-dynamic-failover/78788#78788
https://wiki.archlinux.org/index.php/Systemd-networkd#Bonding_a_wired_and_wireless_interface
https://wiki.archlinux.org/index.php/Wireless_bonding

[Joulinar]

@MichaIng
currently I'm playing with ifplugd. It's looking promising to have some fallback to wlan0 if eth0 cable was unplugged. As well it's working to use same STATIC IP on both eth0 as well as on wlan0. I know a much better solution would be using bonding between eth0 and wlan0. But using ifplugd is quite simple 😄

I will link the related forum post. For using same IP on both interfaces, some tweaks necessary
https://dietpi.com/phpbb/viewtopic.php?p=25620#p25620

[Akrai]

Yeah, ifplugd is working really well to keep only one interface up at the same time, and I really suggest that it is added to dietpi config as an option in the network menu, as it is really simple to configure as we have tested in that forum thread
The bonding suggestion is (I think, I havent read it too much) to have an unified interface and so you can have a single static IP, which you probably cannot have as your router will reject the static IP from the second interface you use, as the first one has leave a register in the memory of the router, and so until a while or after a reboot the router wont accept a static IP for the same IP for a different MAC

[MichaIng]

At least it works with ifplugd although its not really its intention to switch interfaces but only to auto-configure/de-configure Ethernet interfaces on cable (un)plug and device hotplug. Basically we can do the same thing with DietPi-WiFi-Monitor without probably messing with other concurrent ifplugd use-cases. But we check connection state only every 10 seconds via ping, for Ethernet plug/connection state could use ip or ethtool. We could shorten the time but this would increase CPU usage by calling the mentioned external commands so regularly. Probably ifplugd allows a more immediate switch with less CPU usage, despite the scripts and config file overhead it generally ships.

So finally when I am (or someone else is) able to do the planned network setup rework, we can do some benchmarks. One argument for an own integration is that we can better combine it with WiFi auto-reconnections. Otherwise ifplugd action would need to stop and restart WiFi monitor (when active) on Ethernet plug/unplug.

[Joulinar]

as far as I can see, ifplugd is quite a simple tool. It's doing nothing else than calling a script ifplugd.action with 2 variables (interface + status)

/etc/ifplugd/ifplugd.action eth0 down - cable unpluged
or
/etc/ifplugd/ifplugd.action eth0 up - cable plugged-in

Inside ifplugd.action we could do whatever we want. I found a script doing ifup/down to manage interfaces. There you could include/execute as well tons of other thinks like starting/stopping additional services.

For example the script I found on the web

#!/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

[MichaIng]

Jep I see it is working fine and also RAM usage of the daemon is low. CPU usage alone would not be a killer argument.

What I am more thinking about is that I aim to make our network setup much more compatible and flexible in combination with other/custom setups. Since ifplugd has only a single actions script, it would be great if we could leave it untouched, so users can use ifplugd aside of DietPi network setup scripts, e.g. use our scripts for the internet connection (Ethernet + WiFi fallback) + ifplugd for an additional local network connection for file sharing, media streaming or such. My dream is that we do not alter any standard config file so that one can use DietPi scripts completely optionally and that their usage does never mess with any other done or planned custom setup by leaving behind a changed standard config/script. Not possible for everything, I know 😉.

EDIT: Ah, the daemon can be called like this:

ifplugd -r /path/to/our/script.action ...

But this requires an own udev rule and/or service file then as well, or we call it manually on boot 🤔.

[Joulinar]

I would not say ifplugd is a perfect tool. Even it seems not being maintained anymore, because last Debian package update was in 2018. Or it's running that perfect, that further development is not needed. But for someone looking for a quick solution, why now. At the end it's up to you as developer. You know best what fit into DietPi Eco System 😄

[SilverIce]

This issue also prevents HotSpot package from working properly. dietpi-wifi-monitor.sh always scans for wifi networks around, even if hotspot mode is ON
DietPi v8.10.2

[MichaIng]

Yes, it makes sense to disable the WiFi monitor if the hostspot is enabled. We can do that automatically on WiFi hotspot install.