Problem: udhcpc does not deconfig upon WAN cable disconnect

Lynx

Senior Member
I have just identified that:
Code:
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:
See this OpenWrt patch (and related discussion):
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:
Code:
ip monitor route dev eth0 | while read event; do
    case "$event" in
    'Deleted default'*)
        ...
        ;;
    'local '*)
        ...
        ;;
    ...)
        ...
        ;;
    ...
    esac
done
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:
Code:
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':
Code:
#!/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?
 
Last edited:

dave14305

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

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

New Around Here
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

Senior Member
Thanks @dave14305 I amended the readme.


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:

Code:
#!/bin/sh

I will amend that too. Done:


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

New Around Here
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:

hger.PNG
 
Last edited:

Lynx

Senior Member
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):

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

New Around Here
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):

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

Senior Member
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.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top