Problem: udhcpc does not deconfig upon WAN cable disconnect

[Lynx]

I have just identified that:

7252 admin     3492 S    /sbin/udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -t1 -T5 -A0 -O33 -O249

does not renew upon a physical WAN cable disconnect and reconnect. See here:

How to deconfigure/reconfigure eth interface when cable is connected/disconnected with Busybox

I'm running Alpine Linux, which is based on Busybox and musl, on Raspberry Pi. When I run ifup eth0, it also starts udhcpc in the background for that interface. That means that if the ethernet cabl...

unix.stackexchange.com

See this OpenWrt patch (and related discussion):

[OpenWrt-Devel] [PATCH] add ifplugd

www.mail-archive.com

ifplugd is a Linux daemon which will automatically configure your ethernet device when a cable is plugged in and automatically unconfigure it if the cable is pulled. This is useful on laptops with onboard network adapters, since it will only configure the interface when a cable is really connected.

I have done my own testing and found that wanduck.c is very slow to detect a physical cable disconnect. It must be disconnected for > 5 seconds to restart wan. I tried setting wandog_interval to '1' from its default '5', but it made no difference.
What is the best way to deal with this, i.e. to force the expected renew upon eth0 down/up?
Would it be to write a script based on:

ip monitor route dev eth0 | while read event; do
    case "$event" in
    'Deleted default'*)
        ...
        ;;
    'local '*)
        ...
        ;;
    ...)
        ...
        ;;
    ...
    esac
done

ip monitor : responding to events

I want to run a script in response to certain network events and to do this I am monitoring network routes using ip monitor route dev enp3s0 ip monitor waits for events and prints them as they ...

unix.stackexchange.com

That way eth0 down/up could be detected and the necessary signal sent to udhcpc? I think this would be more efficient than polling every 0.5 seconds or so. Like this:

ip monitor link dev eth0 | while read event; do echo $event; done
11: eth0: <NO-CARRIER,BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast state DOWN group default
link/ether f0:2f:74:92:41:68 brd ff:ff:ff:ff:ff:ff
11: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default
link/ether f0:2f:74:92:41:68 brd ff:ff:ff:ff:ff:ff

I propose this script to deal with this problem 'maintain-wan-lease':

#!/bin/bash

renew_wan_lease=0

ip monitor link dev eth0 | while read event; do

        logger "maintain-wan-lease detected eth0 event: "$event

        case $event in

        *'NO-CARRIER'* )
                if [ $renew_wan_lease -eq 0 ]; then
                        logger "maintain-wan-lease detected eth0 state change to: 'NO-CARRIER', so forcing udhcpc to release wan lease."
                        killall -SIGUSR2 udhcpc
                        renew_wan_lease=1
                fi
        ;;

        *'LOWER_UP'* )
                if [ $renew_wan_lease -eq 1 ]; then
                        logger "maintain-wan-lease detected eth0 state change from: 'NO-CARRIER' to: 'LOWER_UP', so forcing udhcpc to renew wan lease."
                        killall -SIGUSR1 udhcpc
                        renew_wan_lease=0
                fi
        ;;
        esac

done

Does that make sense?
If so, where would be the best place to put this script? Could anyone suggest a script form to send the necessary signal? Presumably this should be on 'eth0' goes 'up'? Or first detect 'down' then detect 'up' and then send KILL signal to force udhcpc into action?

 

[Lynx]

Update: uploaded script onto my GitHub for resolving this issue. Confirmed to work by myself and at least @optimalo:

maintain-wan-lease/README.md at master · lynxthecat/maintain-wan-lease

Resolve problem with Asus Merlin routers in terms of release/renew of udhcpc. - lynxthecat/maintain-wan-lease

github.com

 

[dave14305]

Update: uploaded script onto my GitHub for resolving this issue. Confirmed to work by myself and at least @optimalo:

maintain-wan-lease/README.md at master · lynxthecat/maintain-wan-lease

Resolve problem with Asus Merlin routers in terms of release/renew of udhcpc. - lynxthecat/maintain-wan-lease

github.com

The bash she-bang isn’t right for Asus routers. Also, using post-mount would require that a USB drive be inserted into to router in order for this to execute, so it’s less than ideal. Why not services-start?

 

[optimalo]

So can I just rename the script to "services-start" in the JFFS Scripts folder, and the script should automatically be executed after a Router reboot?

 

[Lynx]

Thanks @dave14305 I amended the readme.

GitHub - lynxthecat/maintain-wan-lease: Resolve problem with Asus Merlin routers in terms of release/renew of udhcpc.

Resolve problem with Asus Merlin routers in terms of release/renew of udhcpc. - lynxthecat/maintain-wan-lease

github.com

The scripts I had saved from my Asus Router that were auto generated by ATM (IIRC) seem to include a mixture of sh / bash shebangs. Should all the scripts use:

#!/bin/sh

I will amend that too. Done:

maintain-wan-lease/maintain-wan-lease at master · lynxthecat/maintain-wan-lease

Resolve problem with Asus Merlin routers in terms of release/renew of udhcpc. - lynxthecat/maintain-wan-lease

github.com

I hope this will be helpful for others that encounter this issue. Took me a good few hours to figure it out and I think the solution here is fairly elegant.

 

[optimalo]

Thanks dave14305, seems to be working now with using services-start. I rebooted the router and Lynx's script was still active afterwards. I also ran the command "dos2unix /jffs/scripts/My_script.sh" on both files, just in case. dos2unix makes sure, that the script has some proper formatting that would not be right if it was created under windows or something. Not sure if that was necessary using winscp's edit function to edit the scripts directly in winscp.

For anyone interested, this is how it should look like using WinSCP:

 

[Lynx]

Have you tested post reboot by manually unplugging cable and plugging in again? And checking syslog to see the entries?

By the way, it is these lines in the B818-263 log that result in 'eth0' going down and back up (at which point we need the release/renew to get new WAN IP):

2022-03-02 14:24:26
System Notice
WAN connection INTERNET_R_UMTS1:IPv4 connected

2022-03-02 14:24:24
System Notice
WAN connection INTERNET_R_UMTS1:IPv4 disconnected

Alternatively I think if someone just unplugged the WAN cable from one modem and plugged in to another modem, I think the same issue would exist since in that situation the release/renew would also not get called.

Although I think it's temperamental because 'wanduck.c' also does some monitoring and I think resets connection in certain situations (e.g. if 'eth0' down for > 5 seconds or so?), but working through that code was a nightmare and I gave up. I tried editing the various watchdog parameters in 'nvram' to no avail.

 

[optimalo]

Have you tested post reboot by manually unplugging cable and plugging in again? And checking syslog to see the entries?

By the way, it is these lines in the B818-263 log that result in 'eth0' going down and back up (at which point we need the release/renew to get new WAN IP):

2022-03-02 14:24:26
System Notice
WAN connection INTERNET_R_UMTS1:IPv4 connected

2022-03-02 14:24:24
System Notice
WAN connection INTERNET_R_UMTS1:IPv4 disconnected

Alternatively I think if someone just unplugged the WAN cable from one modem and plugged in to another modem, I think the same issue would exist since in that situation the release/renew would also not get called.

Although I think it's temperamental because 'wanduck.c' also does some monitoring and I think resets connection in certain situations (e.g. if 'eth0' down for > 5 seconds or so?), but working through that code was a nightmare and I gave up. I tried editing the various watchdog parameters in 'nvram' to no avail.

Yes, I did unplug and replug the cable after reboot and found the respective lines in the log.


Today I also installed the newest merlin version which came out a few days ago. Maybe the issue is fixed in the new version, the red WAN LED didn't show up when I unplugged the cable before testing your script. I didn't get to thoroughly check this though. I probably would have to deactivate your script and leave the Router running for 1-2 weeks to see if the issue pops up or not

 

[Lynx]

If you have a spare sim you could hot swap it on the B818-263. I think this might force the same event. Otherwise for me it happened exactly every 48 hours. I would deactivate script and test personally. You only want the script if it is needed. Then again, if you are pushed for time and don't like messing about, I don't see the harm in leaving it on - it will just issue another unnecessary release/renew. But I'd strongly favour you testing if you have time, for the benefit of others.