dietpi-wifi-monitor.sh forces disconnect every 10s #3359

borpin · 2020-01-25T15:56:11Z

Creating a bug report/issue

Required Information

DietPi version | cat /DietPi/dietpi/.version
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=28
G_DIETPI_VERSION_RC=0
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
Distro version | echo $G_DISTRO_NAME or cat /etc/debian_version
buster 10.2
Kernel version | uname -a
Linux DietPi-OrPi1 5.4.12-sunxi #rc0 SMP Sun Jan 19 21:11:41 CET 2020 armv7l GNU/Linux
SBC device | echo $G_HW_MODEL_DESCRIPTION or (EG: RPi3)
OrangePi Zero (armv7l)
Power supply used | (EG: 5V 1A RAVpower)
Generic 1A
SDcard used | (EG: SanDisk ultra)
SanDisk ultra

Additional Information (if applicable)

Software title | (EG: Nextcloud)
Was the software title installed freshly or updated/migrated?
Can this issue be replicated on a fresh installation of DietPi?

Bug report ID | sed -n 5p /DietPi/dietpi/.hw_model
5494d63e-d34c-424b-860d-a364d6e8c572

Steps to reproduce

enable WiFi

Expected behaviour

WiFi should not disconnect

Actual behaviour

Wi-Fi disconnects every 10s

Extra details

More logs etc on this discussion. https://dietpi.com/phpbb/viewtopic.php?t=7220

DietPi/rootfs/var/lib/dietpi/services/dietpi-wifi-monitor.sh

Line 29 in 67ae9e4

URL_PING=$(ip r s 0.0.0.0/0 dev $ADAPTER | mawk '{print $3}')

On this system this command does not return anything

ip r s 0.0.0.0/0 dev wlan0

Therefore the monitor disconnects every 10s

This could be an issue with the use of ip as the command.

An alternative might be to use the output from iwconfig or ifquery.

Interface up...

root@DietPi-OrPi1:~# iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"home123"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 94:83:C4:00:C4:3B
          Bit Rate=1 Mb/s   Tx-Power=20 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=55/70  Signal level=-55 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:1   Missed beacon:0

Interface down

wlan0     IEEE 802.11  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

It seems though that ifquery always returns the same output.

The text was updated successfully, but these errors were encountered:

borpin · 2020-01-25T16:18:34Z

Locally I have changed the test to

if grep -q $ADAPTER /proc/net/wireless; then

This has stopped the disconnects (as expected).

MichaIng · 2020-01-26T13:41:55Z

@borpin
Many thanks for your report and solution.

Do you use WiFi for main internet connection? It is strange then that the ip r commands does not find a default gateway on that device, as this should be the default target for all network requests then.

Your solution only checks if the adapter is available but not if it is connected to any access point, hence it breaks the aim of the script to reconnect, if I am not mistaken?

What we should definitely add is to check if the found URL_PING is actually a valid IP. This gateway estimation could be added to the main loop, which would also allow a changed gateway IP without having to restart the service.

borpin · 2020-01-26T15:18:13Z

Do you use WiFi for main internet connection?

In this case I had both eth0 and wlan0 connected as it is the only way (no video out on this device). I did hit more problems with the Wi-Fi - the driver for the OrangePi has always been iffy; I was hoping this was better. Even with this solution, I still could not get the wlan0 to come up when eth0 is disconnected on boot.

Your solution only checks if the adapter is available but not if it is connected to any access point, hence it breaks the aim of the script to reconnect, if I am not mistaken?

Possibly. As soon as the link was lost then the entry disappeared. The iwconfig result Access Point: Not-Associated might be better, I just needed a quick and dirty solution.

What we should definitely add is to check if the found URL_PING is actually a valid IP.

In this case it doesn't help as it would still assume the link was down and disconnect!

MichaIng · 2020-01-26T22:11:56Z

@borpin

In this case it doesn't help as it would still assume the link was down and disconnect!

Yes, that is still strange to me. Could you please paste the output of these commands:

ip l
ip a
ip r

borpin · 2020-01-27T08:40:24Z

I had disabled the Wi-Fi so I re-enabled it and connected via both eth0 and wlan0.

First point of note is that the WLAn is very slow in comparison.
If I disconnect the cable, I lose access via WLAN! However, I have managed to connect without the cable previously so this is not consistent behaviour.

I feel possibly the right route is not being added and it is falling back to the eth0 route all the time.

eth0

root@DietPi-OrPi1:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 56:fe:22:0c:a7:64 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 02:42:a6:91:b5:2c brd ff:ff:ff:ff:ff:ff
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 12:42:a6:91:b5:2c brd ff:ff:ff:ff:ff:ff
root@DietPi-OrPi1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 56:fe:22:0c:a7:64 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:42:a6:91:b5:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.28/24 brd 192.168.7.255 scope global eth0
       valid_lft forever preferred_lft forever
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 12:42:a6:91:b5:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.240/24 brd 192.168.7.255 scope global dynamic wlan0
       valid_lft 86261sec preferred_lft 86261sec
root@DietPi-OrPi1:~# ip r
default via 192.168.7.25 dev eth0 onlink
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.28
192.168.7.0/24 dev wlan0 proto kernel scope link src 192.168.7.240
root@DietPi-OrPi1:~# ip r s 0.0.0.0/0 dev eth0
default via 192.168.7.25 onlink
root@DietPi-OrPi1:~#

wlan0

root@DietPi-OrPi1:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 56:fe:22:0c:a7:64 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 02:42:a6:91:b5:2c brd ff:ff:ff:ff:ff:ff
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 12:42:a6:91:b5:2c brd ff:ff:ff:ff:ff:ff
root@DietPi-OrPi1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 56:fe:22:0c:a7:64 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 02:42:a6:91:b5:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.28/24 brd 192.168.7.255 scope global eth0
       valid_lft forever preferred_lft forever
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 12:42:a6:91:b5:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.240/24 brd 192.168.7.255 scope global dynamic wlan0
       valid_lft 86255sec preferred_lft 86255sec
root@DietPi-OrPi1:~# ip r
default via 192.168.7.25 dev eth0 onlink
192.168.7.0/24 dev eth0 proto kernel scope link src 192.168.7.28
192.168.7.0/24 dev wlan0 proto kernel scope link src 192.168.7.240
root@DietPi-OrPi1:~# ip r s 0.0.0.0/0 dev wlan0
root@DietPi-OrPi1:~#

borpin · 2020-01-27T10:04:06Z

Digging around, I discovered this (installed net-tools).

root@DietPi-OrPi1:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.7.25    0.0.0.0         UG    0      0        0 eth0
192.168.7.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.7.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

Checking an RPi running Raspbian;

pi@emonpi:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.7.25    0.0.0.0         UG    202    0        0 eth0
0.0.0.0         192.168.7.25    0.0.0.0         UG    303    0        0 wlan0
192.168.7.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.7.0     0.0.0.0         255.255.255.0   U     303    0        0 wlan0

pi@rpi:~ $ ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:60:4c:19 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DORMANT group default qlen 1000
    link/ether b8:27:eb:35:19:4c brd ff:ff:ff:ff:ff:ff
pi@rpi:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:60:4c:19 brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.243/24 brd 192.168.7.255 scope global dynamic noprefixroute eth0
       valid_lft 86186sec preferred_lft 75386sec
    inet6 fe80::4962:e6fa:4989:391a/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:35:19:4c brd ff:ff:ff:ff:ff:ff
    inet 192.168.7.237/24 brd 192.168.7.255 scope global dynamic noprefixroute wlan0
       valid_lft 86208sec preferred_lft 75408sec
    inet6 fe80::3ed3:367f:2aac:527d/64 scope link
       valid_lft forever preferred_lft forever
pi@rpi:~ $ ip r
default via 192.168.7.25 dev eth0 proto dhcp src 192.168.7.243 metric 202
default via 192.168.7.25 dev wlan0 proto dhcp src 192.168.7.237 metric 303
192.168.7.0/24 dev eth0 proto dhcp scope link src 192.168.7.243 metric 202
192.168.7.0/24 dev wlan0 proto dhcp scope link src 192.168.7.237 metric 303

MichaIng · 2020-01-27T12:21:33Z

@borpin
Okay now things start to become clear 🙂.

You cannot simply connect multiple network adapters to the same network without having a routing table that tells the system which adapter to send requests to. Otherwise you face this issue with the switching default route. It is basically this issue: #2103
The question is what your purpose is:

If Ethernet is connected, why would you want WiFi to be used?
If you want WiFi as fallback, then WiFi monitor is not the right tools currently, but we have a feature request to allow this: DietPi-WiFi-Monitor | Option: Check for Ethernet, else fallback to WiFi #3254
- I do not see a reasonable way to adjust the current WiFi monitor behaviour in a way that it correctly checks for connection state while allowing the default route on another network adapter. Even "connected" to an access point (iwconfig output) does not necessarily mean that it has a correct IP + subnet + gateway assigned, so that it can really connect to other local network members, gateway or internet. For this we must verify that either the access point/gateway or an internet resource can be pinged, AFAIK. Since internet resource takes much longer, and if it fails, it could be simply a connection loss on router-side (where WiFi reconnect would not solve anything), pinging the gateway is really the best option I can think of.
- So we need a new "mode" for WiFi monitor to tell it: "Check if default route on Ethernet adapter is active, if so => disable WiFi, else => check if default route on WiFi adapter is active, else reconnect WiFi"

Now your Raspbian setup is interesting with two default routes active concurrently. While this might work, since one always overrides the other, this is dangerous since loosing one route might lead to requests from one adapter might be answered on the other adapter. I am no expert, probably this is ruled out, but at least it doesn't look like a robust network setup. Is regular Raspbian Lite, which tools manage the network connection, e.g. what is:

cat /etc/network/interfaces
ip rule show

borpin · 2020-01-27T13:10:34Z

I can add a route using the 'route' command such as

root@DietPi-OrPi1:~# route add default gw 192.168.7.25 metric 100 dev wlan0
root@DietPi-OrPi1:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.7.25    0.0.0.0         UG    0      0        0 eth0
default         192.168.7.25    0.0.0.0         UG    100    0        0 wlan0
192.168.7.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.7.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

The metric seems to help routing when both interfaces are up.

But I cannot find a syntax to do the same with ip route add. I cannot therefore get it added so it survives the interface being restarted.

MichaIng · 2020-01-27T18:21:55Z

@borpin
ip tcp_metrics? https://manpages.debian.org/buster/iproute2/ip-tcp_metrics.8.en.html

But hmm, that does not really fit to the explanation of the route man page:
https://manpages.debian.org/buster/net-tools/route.8.en.html#OUTPUT

Metric The 'distance' to the target (usually counted in hops).

https://manpages.debian.org/buster/net-tools/route.8.en.html#OPTIONS

metric M set the metric field in the routing table (used by routing daemons) to M. If this option is not specified the metric for inet6 (IPv6) address family defaults to '1', for inet (IPv4) it defaults to '0'. You should always specify an explicit metric value to not rely on those defaults - they also differ from iproute2.

And ip tcp_metrics has no "set" command, hence cannot change it, only delete and flush 🤔. Probably the default gateway of the device with lower metric is preferred in case, but it doesn't look like it is designed to be used for that...

Ah and the German language man page states about route metric output:
https://manpages.debian.org/buster/net-tools/route.8.de.html#AUSGABE

Dieser Wert wird von aktuellen Kernen nicht verwendet, kann aber u.U. von Routendämonen benötigt werden.

Means:
https://www.deepl.com/translator#de/en/Dieser%20Wert%20wird%20von%20aktuellen%20Kernen%20nicht%20verwendet%2C%20kann%20aber%20u.U.%20von%20Routend%C3%A4monen%20ben%C3%B6tigt%20werden.
"not used by current kernel", but it seems to work in your case, strange...

Can you please paste from Raspbian:

cat /etc/network/interfaces
ip rule show

Probably there is some routing table applied via ip rules to manage the two gateways.

MichaIng · 2021-11-06T13:57:36Z

I'll mark this as closed. Requests for WiFi => Ethernet support and native support for multiple active network adapters (aside of classic WiFi Hotspot) exist already

MichaIng added the Investigating 🤔 label Jan 26, 2020

MichaIng added the Known Issue 🐛 label Jan 27, 2020

MichaIng removed the Investigating 🤔 label Jul 5, 2020

MichaIng removed the Known Issue 🐛 label Nov 6, 2021

MichaIng closed this as completed Nov 6, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

dietpi-wifi-monitor.sh forces disconnect every 10s #3359

dietpi-wifi-monitor.sh forces disconnect every 10s #3359

borpin commented Jan 25, 2020 •

edited by MichaIng

Loading

borpin commented Jan 25, 2020

MichaIng commented Jan 26, 2020

borpin commented Jan 26, 2020 •

edited

Loading

MichaIng commented Jan 26, 2020

borpin commented Jan 27, 2020 •

edited

Loading

borpin commented Jan 27, 2020 •

edited

Loading

MichaIng commented Jan 27, 2020

borpin commented Jan 27, 2020

MichaIng commented Jan 27, 2020 •

edited

Loading

MichaIng commented Nov 6, 2021

dietpi-wifi-monitor.sh forces disconnect every 10s #3359

dietpi-wifi-monitor.sh forces disconnect every 10s #3359

Comments

borpin commented Jan 25, 2020 • edited by MichaIng Loading

Creating a bug report/issue

Required Information

Additional Information (if applicable)

Steps to reproduce

Expected behaviour

Actual behaviour

Extra details

borpin commented Jan 25, 2020

MichaIng commented Jan 26, 2020

borpin commented Jan 26, 2020 • edited Loading

MichaIng commented Jan 26, 2020

borpin commented Jan 27, 2020 • edited Loading

borpin commented Jan 27, 2020 • edited Loading

MichaIng commented Jan 27, 2020

borpin commented Jan 27, 2020

MichaIng commented Jan 27, 2020 • edited Loading

MichaIng commented Nov 6, 2021

borpin commented Jan 25, 2020 •

edited by MichaIng

Loading

borpin commented Jan 26, 2020 •

edited

Loading

borpin commented Jan 27, 2020 •

edited

Loading

borpin commented Jan 27, 2020 •

edited

Loading

MichaIng commented Jan 27, 2020 •

edited

Loading