WRT54GL WAN DHCP lease time reaching 0 (Test images on pg 5)

Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14126
Location: Texas, USA

PostPosted: Wed Nov 07, 2018 11:04    Post subject: Reply with quote
https://svn.dd-wrt.com/ticket/6456#comment:2

"Ok, did you contact your ISP to have them reset the mac address info for your connection? If your ISP is expecting the modem to be in router mode and not bridge mode, their system may allow an initial lease, but it may not renew it if the mac address is not in the system, perhaps?"

Just some thoughts to consider, if you already have not.
Sponsor
aehimself
DD-WRT Novice


Joined: 19 Nov 2017
Posts: 23

PostPosted: Wed Nov 07, 2018 15:17    Post subject: Reply with quote
I might give it a shot, but I doubt this is the case; please correct me if my theory if wrong. What I am 100% sure so far:
- My early discoveries confirms that automatic DHCP lease renewal is not being done by the router (see the post here)
- Connection keeps stable if I manually press the renew button on the web UI. In this case WAN IP address stays the same, only lease time jumps back to 24h

If we assume that because of a MAC address mismatch my ISP is not allowing renews, I'd say it would neither work if I renew manually.
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14126
Location: Texas, USA

PostPosted: Wed Nov 07, 2018 15:59    Post subject: Reply with quote
That is possibly true regarding the ISP. I don't recall having issues when I was testing things on my E4200 v1 devices with the main modem/router in bridge mode, but I wasn't testing for an extended period. I forgot to copy some information to save regarding another ticket related to udhcpc and default gateway assignment issues ( https://svn.dd-wrt.com/ticket/3318 ), but I'm also wondering if this is a(nother) BusyBox-related issue or not since it seems to me that the current implementation in DD-WRT is not 100% in sync and aligned with the upstream reported version (1.29.3) or the latest git as best I can tell. It could also be an issue with the DD-WRT base code itself. Regarding the ticket I mentioned, are you having issues with default route assignments with your current configuration?
aehimself
DD-WRT Novice


Joined: 19 Nov 2017
Posts: 23

PostPosted: Wed Nov 07, 2018 21:20    Post subject: Reply with quote
I will be completely honest, I never looked at the issue as a routing one! That's going to be my homework; I'll make some investigation if the routing table / WAN IP address change follow each other correctly. I still have to give a voice to my doubts - if it would be a routing issue the Internet connection after the router would fail after any / a number of renewals; and in my case the renewals do not seem to happen at all. But as I said - routing can make sense and I'll definitely look into it.

As for continuing my experiment, the script seems to be working so far. My ISP is giving 24h leases, so I waited for a while. The below is the debug log from the executable:

Code:
Grabbing remaining WAN DHCP lease time...
*** HTTP response code: 200
*** Router time: 21:10:33, up since 2 days, 13:21, WAN IP: 1.2.3.4, remaining lease time: 0 days 05:19:51
Trying to execute a command...
*** HTTP response code: 200 (Ok)
[...] here is the complete HTML output of apply.cgi, returning an empty form of Diagnostics.asp [...]
Grabbing remaining WAN DHCP lease time...
Grabbing remaining WAN DHCP lease time...
*** HTTP response code: 200
*** Router time: 21:11:16, up since 2 days, 13:22, WAN IP: 1.2.3.4, remaining lease time: 0 days 23:59:34


The WAN IPs are the same in the actual output; the lease time jumps from 5-ish hours to a day. You can see 2 "Grabbing remaining […]" outputs; that's because something actually drops when I kill the udhcpc process (not sure if it's WAN or Wi-Fi, will have to look into it; but the first re-grab attempt failed).
I am about to make a Windows service out of this and see if it will function correctly unattended.
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14126
Location: Texas, USA

PostPosted: Thu Nov 08, 2018 2:46    Post subject: Reply with quote
At least your workaround seems to be working. The last time I messed with a WRT54 series device was with HyperWRT (and it worried my sister that I was bastardizing her router!). I'm sure somewhere between the 14*** revision build and current build, there has to be a working, stable firmware. I haven't seen anything that would affect or fix this in changes between the build you are using and the current released build that I recall.
aehimself
DD-WRT Novice


Joined: 19 Nov 2017
Posts: 23

PostPosted: Fri Nov 09, 2018 12:44    Post subject: Reply with quote
My wife had the same feelings when she saw me frequently re-flashing ours Smile

I switched to DD-WRT because it is the only firmware supporting WRT54GL to fix KRACK and other well-known vulnerabilities. If I have to downgrade to a 14xxx version I'll loose these fixes and will be at the same spot as I was with Tomato 1.28.
I'd rather not go back there.

I think the drop with Administration / Commands page will be because of how it works. Just because why not I changed the command to 'ping google.com' and I had the same disconnect AND - which is even more strange - the timestamp of /tmp/udhcpc.expires got updated! In base.c I found out that Ping - start (Administration / Commands) invokes SERVICE_RESTART, while Status_Internet - renew only calls REFRESH. While it gets the job done, I don't want to have even a tiny connection drop.

I reverted everything back to the original HTTP request and had to realize that the timestamp of the lease file is actually updating! As it turns out it works perfectly fine. Most probably I failed in the beginning because I spammed it to test and either the ISP or DD-WRT simply started to ignore me.

I quickly compiled a Windows service application which can run silently on any Windows PC and updated some critical logic... if it works fine I can share the source. It's not a fix, but it seems to be a really viable workaround.
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14126
Location: Texas, USA

PostPosted: Fri Nov 09, 2018 16:46    Post subject: Reply with quote
aehimself wrote:
I switched to DD-WRT because it is the only firmware supporting WRT54GL to fix KRACK and other well-known vulnerabilities. If I have to downgrade to a 14xxx version I'll loose these fixes and will be at the same spot as I was with Tomato 1.28.
I'd rather not go back there.


I'm not aware that the KRACK fixes were implemented for the WRT54 series devices, since it's a 2.4 kernel, but don't quote me on that one.

Another firmware I tinker around with is FreshTomato, and their aim is to fix vulnerabilities and bugs left over from all the other previous mods of Tomato (Shibby, Victek, Toastman, etc.) as best I understand it. That's about as far as I can go discussing that here, but.
aehimself
DD-WRT Novice


Joined: 19 Nov 2017
Posts: 23

PostPosted: Fri Nov 09, 2018 20:08    Post subject: Reply with quote
FreshTomato sounds promising, but I'm an average middle-aged man. I have a routine and don't like changes... this is why I still code in Delphi, targeting Windows platforms Smile I'd like to stick to DD-WRT, even if I have to use a workaround for a showstopper until the source is fixed.

I'm 100% sure that KRACK was fixed - I remember browsing the forums like a madman back in those days. Of course I'll not be able to find the exact posts, but
https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1100316#1100316
and
https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1103037#1103037
still fill me with confidence Smile

P.s.: in 3 hours I finally can state if my DD-WRT WAN DHCP renewal Windows service works as intended!
Code:
2018.11.09. 15:05:53 - WAN DHCP lease will expire at 2018.11.10. 08:17:22, attempting renewal at 2018.11.09. 23:41:37
aehimself
DD-WRT Novice


Joined: 19 Nov 2017
Posts: 23

PostPosted: Sat Nov 10, 2018 10:34    Post subject: Reply with quote
It works! The service succeeded in monitoring and triggering the WAN IP renewal in time multiple times now.

Code:
2018.11.09. 15:05:53 - Downloading status page from DD-WRT...
2018.11.09. 15:05:53 - Router time: 15:05:51, up since 7:18, WAN IP: 1.2.3.4, remaining lease time: 0 days 17:11:29
2018.11.09. 15:05:53 - WAN DHCP lease will expire at 2018.11.10. 08:17:22, attempting renewal at 2018.11.09. 23:41:37
[...]
2018.11.09. 23:41:37 - Attempting to renew WAN DHCP lease...
2018.11.09. 23:41:51 - Downloading status page from DD-WRT...
2018.11.09. 23:41:51 - Router time: 23:41:48, up since 15:54, WAN IP: 1.2.3.4, remaining lease time: 0 days 21:35:34
2018.11.09. 23:41:51 - WAN DHCP lease will expire at 2018.11.10. 21:17:25, attempting renewal at 2018.11.10. 10:29:38
[...]
2018.11.10. 10:29:38 - Attempting to renew WAN DHCP lease...
2018.11.10. 10:29:52 - Downloading status page from DD-WRT...
2018.11.10. 10:29:52 - Router time: 10:29:47, up since 1 day, 2:42, WAN IP: 1.2.3.4, remaining lease time: 0 days 23:59:46
2018.11.10. 10:29:52 - WAN DHCP lease will expire at 2018.11.11. 10:29:38, attempting renewal at 2018.11.10. 22:29:45


During the renewal there was no disturbance in WiFi or Internet. I still have to verify the functionality if the IP actually changes (or renewal was triggered by something other than the service). In theory I covered these scenarios but had no chance to test yet. Every 10 minutes it polls the status page and checks if the lease expiration changed. If yes, it sets a timer to trigger a renew request at halftime. After a renewal request was triggered, it'll re-query the DHCP lease in 10 seconds to verify if it succeeded. I'm more than happy to share the source if needed (it was written in Delphi 10.2.3, can be compiled with the free Community edition).

Verdict: WAN IP renewal can be triggered by sending a HTTP POST request to http(s)://{routerip}/apply.cgi

Required form fields (values should be URL encoded):
submit_button = Status_Internet
change_action = gozila_cgi
action = Apply
submit_type = renew

Required HTTP headers should be set:
Referer = http(s)://{routerip}/Status_Internet.asp
Authorization = Basic {base64 encoded USERNAME:PASSWORD}

Notes:
- Even if the lease time was not extended, the success can be verified by checking the timestamp on the file /tmp/udhcpc.expires before and after sending the HTTP request
- Make sure not to spam renew, otherwise the ISP's DHCP server might start to ignore your router and won't extent the lease time even if it should/could be!



Workaround in place. Now just to stand by until it's officially fixed Smile
aehimself
DD-WRT Novice


Joined: 19 Nov 2017
Posts: 23

PostPosted: Sat Dec 01, 2018 22:27    Post subject: Reply with quote
The other WRT54GL died last week; it was unable to host WLAN, said the module was turned off. Since the rest seemed to work fine I announced it as my sandbox and installed an other firmwre on it.

Later it turned out that only one of the elcos gave up - which is an easy repair. Out of curiosity I plugged it in my modem and I had to realize that it is handling WAN DHCP IP address leases as any device should: just before reaching 12 hours (half time) it was automatically renewed.
Checking the activity of real updates on TRAC I have a true fear in my heart that this issue will not be looked at in the near future. I'm really sad to say but after my years of loyalty to DD-WRT I switched to an other (beta) firmware even on my main router.

Nonetheless, my workaround works. If any future visitor would like to stick to this (by the way awesome) firmware it can mean a solution.

I would like to thank all who attempted to help.
This thread can now be closed.
swazz99jhb
DD-WRT Novice


Joined: 02 Apr 2018
Posts: 1

PostPosted: Wed Dec 19, 2018 10:40    Post subject: Same issue Reply with quote
Hi

Running dd-wrt.v24_std_generic_build37305.bin and experiencing the same issue.

Other than manually renewing via the GUI I haven't really tried played/debugging the issue.
aehimself
DD-WRT Novice


Joined: 19 Nov 2017
Posts: 23

PostPosted: Fri Dec 21, 2018 11:21    Post subject: Re: Same issue Reply with quote
swazz99jhb wrote:
Hi

Running dd-wrt.v24_std_generic_build37305.bin and experiencing the same issue.

Other than manually renewing via the GUI I haven't really tried played/debugging the issue.


If you wish I can share the source / compile a version of the small program which will automatically renew the WAN IP for you. The best way for it to function is to have it continuously running; I don't know how efficient it will be if its running for a couple of hours per day. I was running it on my ESXi guest, which is on 24/7.
Bernie
DD-WRT Novice


Joined: 18 Jan 2019
Posts: 5

PostPosted: Fri Jan 18, 2019 4:08    Post subject: same problem with build 35531 on WRT54GL v1.1 Reply with quote
But the problem disappeared when I turned off the "Shortcut Forwarding Engine".

DD-WRT v3.0-r35531 std (03/26/18)
ftp://ftp.dd-wrt.com/betas/2018/03-26-2018-r35531/broadcom/dd-wrt.v24_std_generic.bin
jwh7
DD-WRT Guru


Joined: 25 Oct 2013
Posts: 2670
Location: Indy

PostPosted: Fri Jan 18, 2019 12:34    Post subject: Re: same problem with build 35531 on WRT54GL v1.1 Reply with quote
Bernie wrote:
But the problem disappeared when I turned off the "Shortcut Forwarding Engine".

DD-WRT v3.0-r35531 std (03/26/1Cool
ftp://ftp.dd-wrt.com/betas/2018/03-26-2018-r35531/broadcom/dd-wrt.v24_std_generic.bin
Interesting; I've always had it off on my k2.4 devices, as it should really default off anyway for pre-k3.10 builds, since SFE isn't supported on them. Sounds like the GUI is still doing something with it though...
_________________
# NAT/SFE/CTF: limited speed w/ DD # Repeater issues # DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo #
OPNsense x64 5050e ITX|DD: DIR-810L, 2*EA6900@1GHz, R6300v1, RT-N66U@663, WNDR4000@533, E1500@353,
WRT54G{Lv1.1,Sv6}@250
|FreshTomato: F7D8302@532|OpenWRT: F9K1119v1, RT-ACRH13, R6220, WNDR3700v4
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14126
Location: Texas, USA

PostPosted: Fri Jan 18, 2019 15:18    Post subject: Re: same problem with build 35531 on WRT54GL v1.1 Reply with quote
jwh7 wrote:
Bernie wrote:
But the problem disappeared when I turned off the "Shortcut Forwarding Engine".

DD-WRT v3.0-r35531 std (03/26/1Cool
ftp://ftp.dd-wrt.com/betas/2018/03-26-2018-r35531/broadcom/dd-wrt.v24_std_generic.bin


Interesting; I've always had it off on my k2.4 devices, as it should really default off anyway for pre-k3.10 builds, since SFE isn't supported on them. Sounds like the GUI is still doing something with it though...


The 2.4, 2.6, 3.2, and 3.5 kernel builds shouldn't even have that in the webUI page, whatsoever IMHO. It probably should be defaulted to 'off', or there should be a sticky note to turn it off.... Rolling Eyes
Goto page Previous  1, 2, 3, 4, 5, 6  Next Display posts from previous:    Page 2 of 6
Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum