Is this a bug on Asus firmware? WAN disconnections

[tsunami2311]

what WAN disconnects? I have never had them in all this time short of the modem it self resting or connection to it droping

 

[primitivo]

what WAN disconnects? I have never had them in all this time short of the modem it self resting or connection to it droping

Yeah I am sure that thousands of users are wrong...

I have DSL-AC68U running solid on PPPoE renewing the lease every 24 hour from my ISP.
I have RT-AC56U running through bridged fibre modem PPPoE - works solid.

The problem is with Automatic WAN DHCP protocol, which is buggy when it comes to DHCP renewal from bridged modem. The problem is especially visible for ISPs with very short WAN DHCP lease time, e.g. 5-10mins, where Asus stock/Merlin (who doesn't touch WAN anyway) fails to renew the lease sometimes.

The nature of this cause is unknown, below is one of the explanation from AT&T I found on another forum, which could be one of the reasons for this behaviour:

“What seems to be happening is that when your ASUS router's DHCP lease comes within half of the lease time (or 5 of the 10 minutes), it starts trying to renew it by asking the Gateway to do so. But the AT&T Gateways don't reply like most DHCP servers would (IIRC, they use a "different" address in the from server that most everyone else), thus the ASUS's filters dump it.

The most typical way to address this is to staticaly set in your ASUS router the public IP address that it's been given via DHCP. AT&T rarely (if ever) changes your "dynamic" public address, so this shouldn't be an issue for quite a while.”

Source.

As mentioned with Tomato this problem is gone.

 

[RMerlin]

As mentioned with Tomato this problem is gone.

The real problem here is that AT&T's DHCP servers are broken. The iptables filter is there for a reason: to prevent a rogue server from sending bogus DHCP replies when it sees requests on the LAN, potentially allowing it to hijack your connection. Here's the actual patch from Tomato's commit log:

commit fa41424345ce1f1ecaad2309a625d9c6b9749a75
Author: Fedor <fedork@ubuntu.(none)>
Date:   Thu Jun 24 01:59:22 2010 -0400

    Accept DHCP responses from WAN by default.
    With some broken ISPs, the dhcp server reply to RENEW may come from an
    unexpected source and get blocked by the firewall. Accept DHCP responses
    from any source (OpenWRT does the same) by default, but allow to disable
    this via nvram variable.
  
    Ref:
    http://www.dd-wrt.com/wiki/index.php/Iptables_command#Firewall_blocks_DHCP_renewal_responses
    https://dev.openwrt.org/browser/trunk/package/firewall/files/firewall.config
    https://dev.openwrt.org/ticket/4108

So Tomato didn't "fix anything", they are reducing their firewall security to accommodate such broken DHCP servers.

Now the interesting bit: Asuswrt has the exact same patch. Only difference is Asus chose to ONLY allow it if obtaining your initial lease (when the IP is 0.0.0.0). I suspect AT&T might have the issue on renewals, not just on initial lease.

I can easily reproduce Tomato's behavior, however I really feel that broken ISPs need to fix their broken sh*t, and stop relying on router developers for dealing with that kind of stuff on their behalf.

 

[eddiez]

The real problem here is that AT&T's DHCP servers are broken. The iptables filter is there for a reason: to prevent a rogue server from sending bogus DHCP replies when it sees requests on the LAN, potentially allowing it to hijack your connection. Here's the actual patch from Tomato's commit log:

commit fa41424345ce1f1ecaad2309a625d9c6b9749a75
Author: Fedor <fedork@ubuntu.(none)>
Date:   Thu Jun 24 01:59:22 2010 -0400

    Accept DHCP responses from WAN by default.
    With some broken ISPs, the dhcp server reply to RENEW may come from an
    unexpected source and get blocked by the firewall. Accept DHCP responses
    from any source (OpenWRT does the same) by default, but allow to disable
    this via nvram variable.
 
    Ref:
    http://www.dd-wrt.com/wiki/index.php/Iptables_command#Firewall_blocks_DHCP_renewal_responses
    https://dev.openwrt.org/browser/trunk/package/firewall/files/firewall.config
    https://dev.openwrt.org/ticket/4108

So Tomato didn't "fix anything", they are reducing their firewall security to accommodate such broken DHCP servers.

Now the interesting bit: Asuswrt has the exact same patch. Only difference is Asus chose to ONLY allow it if obtaining your initial lease (when the IP is 0.0.0.0). I suspect AT&T might have the issue on renewals, not just on initial lease.

I can easily reproduce Tomato's behavior, however I really feel that broken ISPs need to fix their broken sh*t, and stop relying on router developers for dealing with that kind of stuff on their behalf.

@primitivo Didn't we have a conversation about this just a while back? Quite clear that the Asus rant was a bit unfounded, wouldn't you say?

 

[RMerlin]

Since the code was already there, I extended it to also apply on renewals, not just on the initial lease request.

 

[eddiez]

Since the code was already there, I extended it to also apply on renewals, not just on the initial lease request.

Does this patch introduce security issues for non-AT&T users?

 

[RMerlin]

Does this patch introduce security issues for non-AT&T users?

The hole was already there, the only change is that it's not there only at the initial lease request, but at subsequent renewals as well.

The risk should be fairly small overall, as it requires a rogue DHCP to be on your WAN side. For the vast majority of people, that would mean within your ISP's network.

 

[primitivo]

Since the code was already there, I extended it to also apply on renewals, not just on the initial lease request.

I am not using AT&T, but have this issue in Poland with 4G connection. I have Dovado Tiny AC setup in bridge mode + Huawei E398 USB and I have to use Automatic DHCP IP on the router - as this is the way Dovado handles the bridge by giving out 300 seconds lease time (they claim to do this as this is the only way to make sure router will get new IP in case of changed by ISP).

Anyway, if such problems occurs in many ISPs worldwide, I do not expect for them to fix it quickly.

Good idea to apply the patch on renewals too - I think this is where the issue was actually, with DHCP renewals and not initial leases. Will you include it in the current 380.62 alpha version?

 

[RMerlin]

Good idea to apply the patch on renewals too - I think this is where the issue was actually, with DHCP renewals and not initial leases. Will you include it in the current 380.62 alpha version?

Next build.

 

[mstombs]

I don't understand the patch, the accept rule is already there on 380.59 N66U, its just an OR with 0.0.0.0?

ASUSWRT-Merlin RT-N66U 380.59-0 Tue May 10 15:44:44 UTC 2016
admin@RT-N66U:/tmp/home/root# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target     prot opt in     out     source               destination
3805  200K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID
2184K  228M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
166K   10M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           state NEW
442K   32M ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           state NEW
3806 1253K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spt:67 dpt:68

I still have a problem with dhcp renewals (and used to have with Tomato too), but thought that the problem was that BusyBox udhcpc unicasts the reply message to the specific machine that it gave it a lease in the first place, and ISP uses a cluster of machines. When the lease expires and IP lost the discovery request is broadcast to any listening device. Not sure with cable modem what machine actually replies because when cable down the cable modem will issue a local IP, so when connected does it get the real IP and pass it on?

Lease time 5 days 20 hours 39 minute(s) 24 seconds
Lease expires 1 days 1 hours 3 minute(s) 28 seconds

[edit] I remember a fix to Tomato many years ago
http://www.linksysinfo.org/index.php?threads/compiling-toastman-rt-with-full-udhcpc-verbosity.69592/

I just tried this with Asusswrt, and it does work my 7 day release renewed, I prompted a renew using "killall -usr1 udhcpc" but get a log entry

Sep 10 21:14:14 kernel: NAT: no longer support implicit source local NAT
Sep 10 21:14:14 kernel: NAT: packet src 255.255.255.255 -> dst 62.253.131.43

[edit2] I think BusyBox udhcpc is the problem - does not implement the T2 timer specified in
RFC2132 to revert to renew at 7/8 timer

http://www.tcpipguide.com/free/t_DHCPLeaseRenewalandRebindingProcesses-2.htm

It seems this has been patched in some padavan firmware? https://code.aliyun.com/yaoruisheng/k2-router/commit/bbc65ffc3375efd2edc2a8fbe026d6ae2ab48f8d

 

[RMerlin]

I don't understand the patch, the accept rule is already there on 380.59 N66U, its just an OR with 0.0.0.0?

The change is in the code, not in the rule. The rule was only being added to the firewall if the WAN interface didn't have a lease yet. Restarting the firewall after obtaining a lease would remove the rule.

[edit2] I think BusyBox udhcpc is the problem - does not implement the T2 timer specified in RFC2132 to revert to renew at 7/8 timer

That was fixed months ago.

 

[mstombs]

The change is in the code, not in the rule. The rule was only being added to the firewall if the WAN interface didn't have a lease yet. Restarting the firewall after obtaining a lease would remove the rule.



That was fixed months ago.

I have a lease and the rule in 380.59 and before, maybe it was broken in subsequent update?
My main router is now a couple of revs behind head, the T2 thing gives me a good reason to upgrade to the next release (and I am first to download 380.62 alpha2 for the N66U) , thanks.

 

[Scott Jacobs]

Next build.

Is this change to the code in the 380.62_1 build? I am seeing this same message in my logs - I have a dual wan failover setup with Comcast as primary and Uverse as secondary. My problem may not be related to a renewal however. The reason I say that is that I got this message in my log this morning well before I would have expected the lease to be expiring. The Comcast link lease time is > 3 days. And with the newly renewed lease from just this am - it shows 2 days 20 hours, etc as time remaining. I have both of my WAN connections set to Normal mode for the DHCP query frequency.

Unlike some others that see this problem in their logs - it does establish the connection eventually. Not sure what is triggering this - here is a relevant portion from my log showing the first indication of a problem with the primary WAN DHCP - no previous message to that indicating any problem or dropped connection or anything. And you can see that the same problem is reported for secondary WAN connection as it starts failing over to that connection:


Oct 29 05:36:20 WAN(0) Connection: ISP's DHCP did not function properly.
Oct 29 05:36:20 stop_nat_rules: apply the redirect_rules!
Oct 29 05:37:19 rc_service: wanduck 433:notify_rc restart_wan_if 0
Oct 29 05:37:21 rc_service: wanduck 433:notify_rc restart_wan_if 1
Oct 29 05:37:22 WAN(1) Connection: ISP's DHCP did not function properly.
Oct 29 05:37:24 rc_service: udhcpc 17351:notify_rc start_firewall
Oct 29 05:37:25 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan3_vlan3)!
Oct 29 05:37:25 wan: finish adding multi routes
Oct 29 05:37:25 rc_service: udhcpc 17351:notify_rc stop_upnp
Oct 29 05:37:25 rc_service: waitting "start_firewall" via udhcpc ...
Oct 29 05:37:26 rc_service: udhcpc 17351:notify_rc start_upnp
Oct 29 05:37:26 rc_service: waitting "stop_upnp" via udhcpc ...
Oct 29 05:37:27 WAN(1) Connection: WAN was restored.

Is the fix you are talking about applicable to this you think? Is is already in the firmware I am running? If so then I guess I am running into a horse of a different color...

 

[RMerlin]

Is this change to the code in the 380.62_1 build?

It is, but in the end that change doesn't do anything. Looks like the placebo effect struck, as some people "magically" reported that things started working after I made that change, even tho that change did absolutely nothing to the firewall rules generation.

 

[Kim Puleston]

I also get these WAN issues with my ISP router (Sky) a real pain. Rebooting my AC-88U fixes the issue on a temp basis but will powerdown the isp router for a bit and power back up..
Nothing to lose.

 

[philfna1]

When I was on .59 things seemed to be fine, and now I have random drops with the same error message on 380.62_1 build. I am on Comcast, and never had this issue before on AC87U. This is the first release that seems kind of unstable ever. I am wondering if there was a change between .59 and .62_1?

 

[primitivo]

The fix by RMerlin didn't fix the issues on my end either.

 

[Scott Jacobs]

When I was on .59 things seemed to be fine, and now I have random drops with the same error message on 380.62_1 build. I am on Comcast, and never had this issue before on AC87U. This is the first release that seems kind of unstable ever. I am wondering if there was a change between .59 and .62_1?

Hmm - interesting - I suppose I could try reverting back to that level. I was on that level only briefly so I am not sure I noticed one way or the other whether this was happening to me then. And with the firmware format change - I would guess I would have to go into recovery mode to be able to even go back to that level. Not sure that I want to go to that effort yet. Are you configured for just single WAN connection or dual WAN?

 

[philfna1]

I am a single WAN connection, but .59 was rock solid and .62_1 has been a mess. Just moved to .63 beta to see if it works better.

 

[RMerlin]

Then you will have to wait for either Asus to fix it, or your ISP to stop being so picky, because I have no idea what is happening, and it's 100% rock stable with my own ISP.