Solved UPDATE: No longer required. See thread. - [Feature request] Option for DHCP Query Frequency Backoff Mode

[mekki]

Current options for WAN DHCP query frequency are:

• Normal: When router does not get a response from ISP, send another query after 120 seconds and make 2 more attempts.
• Aggressive: When router does not get a response from ISP, send another query after 20 seconds and make 3 more attempts.
• Continuous: Not defined in tooltip. Presumably initiates new DHCP request as soon as previous request times out.

As described in the tooltip, "some ISPs block MAC addresses if the device makes DHCP queries too often." This problem is compounded when some (too many) ISPs' DHCP servers are unable to detect when their own last mile routing drops and reconnects, believing the router to be requesting a /2nd/ IP address when it receives a DHCP query but doesn't realize yet that the previous DHCP-assigned IP is no longer connected (due to its own last mile disconnect, usually only for a few seconds). Worse, such ISPs have their DHCP servers configured to /escalate/ the block if a new DHCP query is received after a MAC block is already in place. The result is that even in Normal mode, a router can get indefinitely blocked from getting a DHCP IP address from the ISP because the ISP punitively escalates the block time for each request.

Suggested solution (and feature request): Additional option for DHCP query frequency of "backoff mode". Ideally, the backoff timings would be user configurable, along with number of attempts, but if a simple 4th option in the pull list is preferred, something like, "When router does not get a response from ISP, send another query after 120 seconds, and then make 3 (ideally with an option for unlimited) more attempts. Each query after the first query will be delayed by double the previous query time delay, i.e., 120 seconds, 240 seconds, 480 seconds, etc."

Reasoning for feature request: This problem is common to many ISPs and the solution is not ISP specific so won't lead to issues with having to maintain ISP specific code. Solves problems where disconnects, both intermittent short term, and medium term eventually lead to a situation where either the ISP's DHCP blocks the router from getting a WAN IP address indefinitely (leading to a need to disconnect the ISP modem for a lengthy period to reset); or, the situation where the router DHCP requests give up after 2-3 attempts and then stop trying to reconnect to WAN until user manual intervention (e.g. reboot) is done, which can be a frequent problem in the case of sufficiently common ~6-10 minute outages without it being clear that the router gave up trying to connect to the WAN DHCP and won't try again (nothing in the log files about this, so many users assumed it would keep trying indefinitely, myself included); or, solves both.

 

[mekki]

It's my suspicion that many (though not likely all) of the reported "ISP DHCP Not Functioning Properly" problems frequently reported in other threads could be resolved with the addition of this feature.

 

[sfx2000]

DHCP query behavior is defined by IETF as a best practice..

I realize that these options outside of normal are due to ISP servers not behaving well...

 

[mekki]

If there is no interest in adding this feature, would someone be so kind as to point me to the SSH command line equivalents of what is created by the current DHCP query frequency options in the pull list so that I can try to come up with a manual command to set "backoff" mode that I can at least set via SSH for my use case, please?

 

[mekki]

DHCP query behavior is defined by IETF as a best practice..

I realize that these options outside of normal are due to ISP servers not behaving well...

You're right, of course. Unfortunately, at least in Canada, the "ISP servers not behaving well" is not accidental and is used as an anticompetitive practice by the oligopoly ISPs who control the last mile to mess with 3rd party ISPs (e.g. Teksavvy)'s customers. I guarantee that their own customers don't get punitive DHCP timeout escalations outside of IETF spec. A cursory glance at other monopoly/oligopoly ISP situations in the USA suggests similar bad actors.

 

[sfx2000]

You're right, of course. Unfortunately, at least in Canada, the "ISP servers not behaving well" is not accidental and is used as an anticompetitive practice by the oligopoly ISPs who control the last mile to mess with 3rd party ISPs (e.g. Teksavvy)'s customers. I guarantee that their own customers don't get punitive DHCP timeout escalations outside of IETF spec. A cursory glance at other monopoly/oligopoly ISP situations in the USA suggests similar bad actors.

On your WAN connection - are you bridging the ISP modem/gateway?

If so, that's likely where the problem is...

 

[sfx2000]

I guarantee that their own customers don't get punitive DHCP timeout escalations outside of IETF spec.

I'll stay out of the politics - I don't think the technical/engineering folks are going out of their way to break things.

That being said - there are RG's out there that have issues with devices running in their DMZ modes

 

[mekki]

I also have a ticket open for this feature request with ASUS for their base firmware. L1 validated that the use case makes sense and has moved it to L2/L3 for consideration/prioritization. I'll post any updates I receive from them. Ideally they do this rather than Merlin having to do it, but I thought it worth adding here as well, in case they aren't interested.

 

[mekki]

On your WAN connection - are you bridging the ISP modem/gateway?

If so, that's likely where the problem is...

The ISP modem is in passthrough mode, yes. The alternative requires setting up double NAT or putting the router in the ISP modem's router-mode's DMZ, which the user cannot configure due to lockdown of the modem's router config by the ISP.

N.B.: Passthrough mode IS officially supported by the ISP. It's not a hack. That being said, I recognize that there are issues related to this approach.

 

[mekki]

I'll stay out of the politics - I don't think the technical/engineering folks are going out of their way to break things.

That being said - there are RG's out there that have issues with devices running in their DMZ modes

Definitely not blaming the technical/engineering folk. I'm a comp eng myself. This is not a technical issue... This is a management issue.

 

[ColinTaylor]

If there is no interest in adding this feature, would someone be so kind as to point me to the SSH command line equivalents of what is created by the current DHCP query frequency options in the pull list so that I can try to come up with a manual command to set "backoff" mode that I can at least set via SSH for my use case, please?

asuswrt-merlin.ng/release/src/router/rc/udhcpc.c at 24569f613492df9c1b428bece93af0f70d010fdc · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

Normal mode
-t2 -T5 -A160

Aggressive mode
-t3 -T3 -A5

Continuous mode
-t1 -T5 -A0

BusyBox v1.25.1 (2023-12-02 12:49:52 EST) multi-call binary.

Usage: udhcpc [-fbqRB] [-a[MSEC]] [-t N] [-T SEC] [-A SEC/-n]
        [-i IFACE] [-s PROG] [-p PIDFILE]
        [-oC] [-r IP] [-V VENDOR] [-F NAME] [-x OPT:VAL]... [-O OPT]...

        -i,--interface IFACE    Interface to use (default eth0)
        -s,--script PROG        Run PROG at DHCP events (default /tmp/udhcpc)
        -p,--pidfile FILE       Create pidfile
        -B,--broadcast          Request broadcast replies
        -t,--retries N          Send up to N discover packets (default 3)
        -T,--timeout SEC        Pause between packets (default 3)
        -A,--tryagain SEC       Wait if lease is not obtained (default 20)
        -n,--now                Exit if lease is not obtained
        -q,--quit               Exit after obtaining lease
        -R,--release            Release IP on exit
        -f,--foreground         Run in foreground
        -b,--background         Background if lease is not obtained
        -S,--syslog             Log to syslog too
        -a[MSEC],--arping[=MSEC] Validate offered address with ARP ping
        -r,--request IP         Request this IP address
        -o,--no-default-options Don't request any options (unless -O is given)
        -O,--request-option OPT Request option OPT from server (cumulative)
        -x OPT:VAL              Include option OPT in sent packets (cumulative)
                                Examples of string, numeric, and hex byte opts:
                                -x hostname:bbox - option 12
                                -x lease:3600 - option 51 (lease time)
                                -x 0x3d:0100BEEFC0FFEE - option 61 (client id)
        -F,--fqdn NAME          Ask server to update DNS mapping for NAME
        -H,-h,--hostname NAME   Send NAME as client hostname
        -V,--vendorclass VENDOR Vendor identifier (default 'udhcp VERSION')
        -C,--clientid-none      Don't send MAC as client identifier
Signals:
        USR1    Renew lease
        USR2    Release lease

 

[sfx2000]

The ISP modem is in passthrough mode, yes. The alternative requires setting up double NAT or putting the router in the ISP modem's router-mode's DMZ, which the user cannot configure due to lockdown of the modem's router config by the ISP.

N.B.: Passthrough mode IS officially supported by the ISP. It's not a hack. That being said, I recognize that there are issues related to this approach.

So it's likely a FW issue with the upstream modem/gateway...

This is an answer, but not a solution - the challenge is how to deal with a broken gateway, but even there, it's a "one-off" solution that can actually break proper upstream implementations...

 

[Tech9]

This problem is common to many ISPs

to mess with 3rd party ISPs (e.g. Teksavvy)'s customers

TekSavvy customers used to receive refurbished Rogers gateways with older firmware. There was disconnection issue in bridge mode in the past, but got corrected with gateway firmware update. I have 2x TekSavvy accounts on Rogers Cable and I used to play with many different models Asus routers. I've never seen "ISP DHCP Not Functioning Properly" message in logs. Folks in the US on specific ISP used to complain often, but I haven't seen any complaint recently. I don't see a "problem" at the moment.

 

[mekki]

asuswrt-merlin.ng/release/src/router/rc/udhcpc.c at 24569f613492df9c1b428bece93af0f70d010fdc · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

Normal mode
-t2 -T5 -A160

Aggressive mode
-t3 -T3 -A5

Continuous mode
-t1 -T5 -A0

BusyBox v1.25.1 (2023-12-02 12:49:52 EST) multi-call binary.

Usage: udhcpc [-fbqRB] [-a[MSEC]] [-t N] [-T SEC] [-A SEC/-n]
        [-i IFACE] [-s PROG] [-p PIDFILE]
        [-oC] [-r IP] [-V VENDOR] [-F NAME] [-x OPT:VAL]... [-O OPT]...

        -i,--interface IFACE    Interface to use (default eth0)
        -s,--script PROG        Run PROG at DHCP events (default /tmp/udhcpc)
        -p,--pidfile FILE       Create pidfile
        -B,--broadcast          Request broadcast replies
        -t,--retries N          Send up to N discover packets (default 3)
        -T,--timeout SEC        Pause between packets (default 3)
        -A,--tryagain SEC       Wait if lease is not obtained (default 20)
        -n,--now                Exit if lease is not obtained
        -q,--quit               Exit after obtaining lease
        -R,--release            Release IP on exit
        -f,--foreground         Run in foreground
        -b,--background         Background if lease is not obtained
        -S,--syslog             Log to syslog too
        -a[MSEC],--arping[=MSEC] Validate offered address with ARP ping
        -r,--request IP         Request this IP address
        -o,--no-default-options Don't request any options (unless -O is given)
        -O,--request-option OPT Request option OPT from server (cumulative)
        -x OPT:VAL              Include option OPT in sent packets (cumulative)
                                Examples of string, numeric, and hex byte opts:
                                -x hostname:bbox - option 12
                                -x lease:3600 - option 51 (lease time)
                                -x 0x3d:0100BEEFC0FFEE - option 61 (client id)
        -F,--fqdn NAME          Ask server to update DNS mapping for NAME
        -H,-h,--hostname NAME   Send NAME as client hostname
        -V,--vendorclass VENDOR Vendor identifier (default 'udhcp VERSION')
        -C,--clientid-none      Don't send MAC as client identifier
Signals:
        USR1    Renew lease
        USR2    Release lease

Thank you. I'll see if I can wrangle something with this.

 

[Tech9]

What problem do you have, on what ISP and with what equipment?

 

[mekki]

TekSavvy customers used to receive refurbished Rogers gateways with older firmware. There was disconnection issue in bridge mode in the past, but got corrected with gateway firmware update. I have 2x TekSavvy accounts on Rogers Cable and I used to play with many different models Asus routers. I've never seen "ISP DHCP Not Functioning Properly" message in logs. Folks in the US on specific ISP used to complain often, but I haven't seen any complaint recently. I don't see a "problem" at the moment.

Glad you're not affected. I'm not convinced it's a modem firmware issue but rather an upstream DHCP server configuration issue. Discussion with Teksavvy support confirmed that they see this issue due to upstream configuration. It doesn't always manifest as "ISP DHC Not Functioning Properly." In my case, most of the time, it just manifests as WAN never reconnecting after a short (couple seconds) outage.

 

[mekki]

So it's likely a FW issue with the upstream modem/gateway...

This is an answer, but not a solution - the challenge is how to deal with a broken gateway, but even there, it's a "one-off" solution that can actually break proper upstream implementations...

I'm not convinced it's a ISP modem firmware issue. I believe it's an upstream DHCP server configuration issue. Discussion with my (3rd party) ISP suggests that the upstream DHCP configuration is to blame (which is managed by the oligopoly ISP that controls last mile, including DHCP for WAN IP addresses.)

 

[mekki]

What problem do you have, on what ISP and with what equipment?

While I understand why you're asking this question, I believe it would be better served to move it to a separate thread. I've spent a very long time troubleshooting this issue with several different combinations of equipment and configurations to reach the conclusion that I have drawn that lead to this feature request. I'm happy to go through that extensive troubleshooting and reasoning with you to see if I've erred anywhere and there's another approach possible, but best to not redirect this thread.


Where would such a discussion be best housed? A new thread in the Asuswrt-Merlin forum? Or a higher level SNB Forum?

 

[sfx2000]

Glad you're not affected. I'm not convinced it's a modem firmware issue but rather an upstream DHCP server configuration issue. Discussion with Teksavvy support confirmed that they see this issue due to upstream configuration. It doesn't always manifest as "ISP DHC Not Functioning Properly." In my case, most of the time, it just manifests as WAN never reconnecting after a short (couple seconds) outage.

To be honest - I don't think this is a common issue, otherwise it would have been fixed...

The Carrier Provide GW's seem to work fine, so it's mostly on the DMZ/Passthrough/Bridge when working with their gateways... and it's likely a bug on the device, not your router/AP...

 

[Tech9]

You have to replace your modem. This is obviously not a widespread issue. Otherwise TekSavvy forums will be full of similar complaints. They are not. Fido had disconnections with their Hitron gateways. The same Rogers Cable network. Firmware update fixed it. This is a modem issue, not the router behind it.