YazFi YazFi v4.x - continued

[Wako]

When YazFi is enabled, all connected clients lose LAN access every time the internet connection (WAN) is lost. We can simulate this scenario by unplugging the WAN cable for 5 seconds and then plugging it back in. Within a minute, the WiFi will restart, and all devices lose LAN access, including the main network (non-guest). This becomes problematic when watching a Netflix show or transferring large files between two computers.

Interestingly, the loss of WiFi also occurs when the internet remains connected. It appears to be random. There might be an underlying trigger causing this reset. However, if I disable all YazFi Guest Networks, everything works normally, and there are no connection issues.

Is there a way to resolve this problem? And why is a reset necessary when the internet connection is lost?

 

[Ripshod]

Is there a way to resolve this problem?

Yeah, find out what's causing the WAN to drop and fix it.

 

[Wako]

Yeah, find out what's causing the WAN to drop and fix it.

Certainly! The issue lies in the fact that the “/jffs/scripts/YazFi runnow” command is invoked when the “/jffs/scripts/firewall-start” script runs. Specifically, the “runnow” command triggers the execution of the “Config_Networks” function, which in turn calls “Iface_BounceClients”. It is within this function that clients are forced to reauthenticate by toggling the WiFi radio off and then back on.

The question at hand is: Is there a way to prevent reauthentication when the WAN cable is unplugged or Internet access is lost?

If you have any other constructive comments or insights, feel free to share them!

 

[bennor]

When YazFi is enabled, all connected clients lose LAN access every time the internet connection (WAN) is lost.

What router?
What YazFi version?
Are any other ad-on scripts running?
What do does the system log show at the time the WAN goes down?

Edit to add: Just did a quick test and observed similar. It appears, per the system log, that the firewall and dnsmasq get restarted then YazFi is restarted after WAN access is lost and restored. Relevant portion of system.log (some information redacted):

Mar 26 14:34:00 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link DOWN.
Mar 26 14:34:06 WAN_Connection: WAN(0) link down.
Mar 26 14:34:54 kernel: eth0 (Int switch port: 0) (Logical Port: 0) (phyId: 1) Link Up at 1000 mbps full duplex
Mar 26 14:34:57 WAN_Connection: WAN(0) link up.
Mar 26 14:34:57 rc_service: wanduck 1543:notify_rc restart_wan_if 0
Mar 26 14:34:57 custom_script: Running /jffs/scripts/service-event (args: restart wan_if)
Mar 26 14:34:57 lldpd[2473]: removal request for address of 11.111.111.111%17, but no knowledge of it
Mar 26 14:34:57 dnsmasq[27317]: read /etc/hosts - 24 names
Mar 26 14:34:57 dnsmasq[27317]: read /jffs/addons/YazDHCP.d/.hostnames - 44 names
Mar 26 14:34:57 kernel: potentially unexpected fatal signal 6.
Mar 26 14:34:57 kernel: CPU: 0 PID: 27317 Comm: dnsmasq Tainted: P           O      4.19.183 #1
Mar 26 14:34:57 kernel: Hardware name: RTAX86U_PRO (DT)
Mar 26 14:34:57 kernel: pstate: 00070010 (nzcv q A32 LE aif)
Mar 26 14:34:57 kernel: pc : 00000000f78a63a4
Mar 26 14:34:57 kernel: lr : 00000000ff8028a0
Mar 26 14:34:57 kernel: sp : 00000000ff8028a0
Mar 26 14:34:57 kernel: x12: 0000000000000000
Mar 26 14:34:57 kernel: x11: 00000000ff802b30 x10: 00000000f799cde0
Mar 26 14:34:57 kernel: x9 : 0000000000000002 x8 : 0000000000000001
Mar 26 14:34:57 kernel: x7 : 00000000000000af x6 : 00000000ff802ae0
Mar 26 14:34:57 kernel: x5 : 00000000ff802ae0 x4 : 0000000000000006
Mar 26 14:34:57 kernel: x3 : 0000000000000008 x2 : 0000000000000000
Mar 26 14:34:57 kernel: x1 : 00000000ff8028a0 x0 : 0000000000000000
Mar 26 14:34:58 lldpd[2473]: removal request for address of 311.111.111.111%17, but no knowledge of it
Mar 26 14:34:58 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Mar 26 14:34:58 wan: finish adding multi routes
Mar 26 14:34:58 YazFi: Firewall restarted - sleeping 10s before running YazFi
Mar 26 14:34:58 dhcp_client: bound 11.111.111.111/255.255.248.0 via 11.111.111.111 for 1800 seconds.
Mar 26 14:35:01 rc_service: watchdog 2384:notify_rc start_dnsmasq
Mar 26 14:35:01 custom_script: Running /jffs/scripts/service-event (args: start dnsmasq)
Mar 26 14:35:01 custom_config: Appending content of /jffs/configs/dnsmasq.conf.add.
Mar 26 14:35:01 custom_script: Running /jffs/scripts/dnsmasq.postconf (args: /etc/dnsmasq.conf)
Mar 26 14:35:01 dnsmasq[17679]: started, version 2.90 cachesize 1500
Mar 26 14:35:01 dnsmasq[17679]: asynchronous logging enabled, queue limit is 5 messages
Mar 26 14:35:01 dnsmasq-dhcp[17679]: DHCP, IP range 192.168.7.2 -- 192.168.7.254, lease time 1d
Mar 26 14:35:01 dnsmasq-dhcp[17679]: DHCP, IP range 192.168.4.2 -- 192.168.4.254, lease time 1d
Mar 26 14:35:01 dnsmasq-dhcp[17679]: DHCP, IP range 192.168.102.2 -- 192.168.102.254, lease time 1d
Mar 26 14:35:01 dnsmasq-dhcp[17679]: DHCP, IP range 192.168.101.2 -- 192.168.101.254, lease time 1d
Mar 26 14:35:01 dnsmasq-dhcp[17679]: DHCP, IP range 192.168.2.2 -- 192.168.2.254, lease time 1d
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for _dns.resolver.arpa
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for use-application-dns.net
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for lan
Mar 26 14:35:01 dnsmasq[17679]: read /etc/hosts - 24 names
Mar 26 14:35:01 dnsmasq[17679]: read /jffs/addons/YazDHCP.d/.hostnames - 44 names
Mar 26 14:35:01 dnsmasq-dhcp[17679]: read /jffs/addons/YazDHCP.d/.staticlist
Mar 26 14:35:01 dnsmasq-dhcp[17679]: read /jffs/addons/YazDHCP.d/.optionslist
Mar 26 14:35:01 dnsmasq[17679]: using nameserver 9.9.9.11#53
Mar 26 14:35:01 dnsmasq[17679]: using nameserver 149.112.112.11#53
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for _dns.resolver.arpa
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for use-application-dns.net
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for lan
Mar 26 14:35:01 dnsmasq[17679]: using nameserver 9.9.9.11#53
Mar 26 14:35:01 dnsmasq[17679]: using nameserver 149.112.112.11#53
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for _dns.resolver.arpa
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for use-application-dns.net
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for lan
Mar 26 14:35:01 WAN_Connection: WAN was restored.
Mar 26 14:35:01 dnsmasq[17679]: read /etc/hosts - 24 names
Mar 26 14:35:01 dnsmasq[17679]: read /jffs/addons/YazDHCP.d/.hostnames - 44 names
Mar 26 14:35:01 dnsmasq-dhcp[17679]: read /jffs/addons/YazDHCP.d/.staticlist
Mar 26 14:35:01 dnsmasq-dhcp[17679]: read /jffs/addons/YazDHCP.d/.optionslist
Mar 26 14:35:01 dnsmasq[17679]: using nameserver 9.9.9.11#53
Mar 26 14:35:01 dnsmasq[17679]: using nameserver 149.112.112.11#53
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for _dns.resolver.arpa
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for use-application-dns.net
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for lan
Mar 26 14:35:01 dnsmasq[17679]: using nameserver 9.9.9.11#53
Mar 26 14:35:01 dnsmasq[17679]: using nameserver 149.112.112.11#53
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for _dns.resolver.arpa
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for use-application-dns.net
Mar 26 14:35:01 dnsmasq[17679]: using only locally-known addresses for lan
Mar 26 14:35:08 YazFi: YazFi v4.4.4 starting up
Mar 26 14:35:10 YazFi: wl0.2 (SSID: Asus2) - sending all interface internet traffic over WAN interface
Mar 26 14:35:14 YazFi: wl1.2 (SSID: Asus2_5G) - sending all interface internet traffic over WAN interface
Mar 26 14:35:17 YazFi: Forcing YazFi Guest WiFi clients to reauthenticate

 

[Wako]

What router?
What YazFi version?
Are any other ad-on scripts running?
What do does the system log show at the time the WAN goes down?

RT-AX88U (YazFi 4.4.4). I use YazFi and YazDHCP. I explained the problem in the message I posted just before you sent yours. YazFi turns the WiFi radio off for 10 seconds, then back on every time the WAN cable is unplugged and then plugged back in.

EDIT: I did try YazFi 4.4.5, but the same issue persists. Chromecast doesn’t auto-reauthenticate when it is in sleep mode after a WiFi radio restart. Consequently, there is no way to turn it on using a Google Home speaker. I need to manually turn it back on for it to reconnect to the WiFi automatically. Additionally, my Canon printer is picky and won’t always obtain a new IP from the DHCP when the WiFi radios are restarted. To resolve this, I either power off/on my printer or restart the WAN interface or the router for it to acquire an IP.

 

[bennor]

YazFi turns the WiFi radio off for 10 seconds, then back on every time the WAN cable is unplugged and then plugged back in.

Yep. The YazFi script is performing as expected when the Firewall starts/restarts. The script would likely have to be rewritten to account for keeping YazFi WiFi up rather than restarting when the WAN goes down which triggers the Firewall restart when it comes back up. Its possible/likely there is a valid reason why YazFi is restarted after the Firewall is started/restarted. Perhaps @Martinski may have some input or explanation as to the script's actions due to their recent working with YazFi.

 

[Wako]

Yep. The YazFi script is performing as expected when the Firewall starts/restarts. The script would likely have to be rewritten to account for keeping YazFi WiFi up rather than restarting when the WAN goes down which triggers the Firewall restart when it comes back up. Its possible/likely there is a valid reason why YazFi is restarted after the Firewall is started/restarted. Perhaps @Martinski may have some input or explanation as to the script's actions due to their recent working with YazFi.

For now, I have commented out that code in the Iface_BounceClients() function:

    for IFACE in $IFACELIST; do
        wl -i "$IFACE" radio off >/dev/null 2>&1
    done

    sleep 10

I hope this won’t break the script too much while waiting for a better solution.

 

[Martinski]

Yep. The YazFi script is performing as expected when the Firewall starts/restarts. The script would likely have to be rewritten to account for keeping YazFi WiFi up rather than restarting when the WAN goes down which triggers the Firewall restart when it comes back up. Its possible/likely there is a valid reason why YazFi is restarted after the Firewall is started/restarted. Perhaps @Martinski may have some input or explanation as to the script's actions due to their recent working with YazFi.

I don't know the specific reasons behind @Jack Yaz's design decision to essentially do a full reset & reconfiguration of the YazFi Guest Networks (including turning OFF & then back ON the WiFi radios) when the script is called from within the firewall-start script. My guess is that since the firewall can be restarted for several different reasons and YazFi doesn't know the specific reason each time it happens, the only way to ensure a clean setup of the Guest Networks is to reset/reconfigure from scratch. But again, only Jack Yaz would know with certainty.