Posted: Fri Jan 18, 2019 15:38 Post subject: Re: same problem with build 35531 on WRT54GL v1.1
kernel-panic69 wrote:
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....
I told BS about it long ago, to remove or change the default on those targets. :-/ _________________ #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
Joined: 08 May 2018 Posts: 14126 Location: Texas, USA
Posted: Fri Jan 18, 2019 19:00 Post subject: Re: same problem with build 35531 on WRT54GL v1.1
jwh7 wrote:
kernel-panic69 wrote:
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....
I told BS about it long ago, to remove or change the default on those targets. :-/
I think the problem is, there is no separate pages for non-SFE builds ... "one size fits all"... at least in the SVN tree, as best I can tell. I would have to dig to see if there is some kind of javascript or other function that is involved on what shows and what doesn't show or whatever. I guess to quote a movie... "at the whim of a madman..."
That's odd. I remember seeing this suggestion which I did try before experimenting with the external renew.
However, the earliest build I have in my config backups (I did one after each successful upgrade) was from 36330. Plus, I mostly used the mini builds. So it's possible that something happened between 35531 and 36330, or there is a difference between mini and std which breaks the SFE toggle.
Edit:
I went back to the beginning of this thread to get myself up-to-date with what exactly happened. And there's still an anomaly here:
aehimself wrote:
My ISP initially gives a 1 hour lease, after that a 24 hour one. I kept a close eye on the timer, as soon as it reached 30 minutes the lease time jumped up to 24 hours.
If it's the SFE, it works... once. Then it breaks.
I can not explain the first successful automatic renewal with anything else.
Posted: Sun Apr 14, 2019 18:46 Post subject: WRT54GL WAN DHCP lease time reaching 0
The problem of the lease timing-out after the first automatic renew (after a reboot) or after a manual renew (via the GUI) remains. The router temporarily stopped losing WAN access because it coincidently began receiving DHCP leases from my ISP that were longer than the time between weekly router reboots.
The DHCP leases have again become short (1 - 48 hours), thus allowing the "single automatic DHCP lease renewal" problem to again manifest.
My apology for confusion, fustration, or unnecessary diagnostic/analysis efforts resulting from my error.
Posted: Thu Apr 18, 2019 21:05 Post subject: Re: WRT54GL WAN DHCP lease time reaching 0
Bernie wrote:
My apology for confusion, fustration, or unnecessary diagnostic/analysis efforts resulting from my error.
No need to apologize, no input is wrong (it works when..., it doesn't work when...) when it comes to development! Let's just hope that one day someone will get rid of this bug.
Let me try to explain my findings(as i experienced the same stupid behavior in the past) and i hope it's not gonna get confusing.
So the culprit here is the udhcpc script as it is set by default(and never was corrected by the devs) to ask the ISP's DHCP for only one hour lease.And this is what most likely confusing the DHCP as it's usually is set to accept requests for something around 24 hours.So that's why every time one do release/renew the lease is weird(sometime is one hour only,sometime 15 hours and so on).I'm still testing this but if you run udhcpc with additional parameters to ask the DHCP for a normal lease time i think(in theory) this should fix that problem.I can say only one thing here,it's really depend on the ISP and how they set things on their end but that problem is very much present.
@kernel-panic69 i know you are on a newer build then me as i'm still waiting on <Kong> so let me ask you,is udhcpc still in play there when it comes to obtaining the IP,subnets,lease from the ISP or it's dnsmasq only(i'm kind of confused on how this should work)?
Give me so insights please so i can be prepare at least a little bit on what's coming.Thanks. _________________ Router: ASUS AC1900(RT-AC68U)
the udhcpc script as it is set by default to ask the ISP's DHCP for only one hour lease.
dTX wrote:
but if you run udhcpc with additional parameters to ask the DHCP for a normal lease time i think(in theory) this should fix that problem.
I don't know too much about udhcpc, but this is not how a proper implementation of the DHCP protocol works. The lease is not defined by the Client (DD-WRT) at any time, it is always "offered" by the server (ISP) during the negotiation process. The Client has the authority to reject it, though. This is confirmed by the man page publishing no options to define this behaviour.
dTX wrote:
And this is what most likely confusing the DHCP as it's usually is set to accept requests for something around 24 hours.
Again, I have doubts here as the only automatic IP renewal happened after the initial 1-hour lease in my case. Like it's that's the only one which it could handle in my case.
dTX wrote:
I can say only one thing here,it's really depend on the ISP and how they set things on their end but that problem is very much present.
This is exactly what I was thinking back then. I know that there are a number of us who experienced this issue but it was not widespread enough for the devs to be forced to look into it. Also - unfortunately - I was unable to find a detailed thread with information I can compare (router model, ISP name, network captures, etc).
My guess is that the root cause will be some kind of compatibility issue (between chipset and udhcpc version for example) as:
1, it's present in a small number (special cases) only despite DD-WRT is used widely around the globe
2, using a different firmware solves the problem
So that's why every time one do release/renew the lease is weird(sometime is one hour only,sometime 15 hours and so on).
This actually got me thinking. I did a release-renew and the working firmware showed the same, initial, 1-hour long lease time from my ISP.
This way I can confirm that the weird lease times are indeed received and processed correctly by DD-WRT, it just fails to renew the second time / after longer lease times.
Could it be some kind of a memory shortage / buffer overflow on devices with low NVRAM?
Posted: Thu Jan 23, 2020 21:39 Post subject: WRT54GL WAN DHCP lease time reaching 0
I stumbled on a work-around to the WRT54GL WAN DHCP lease time reaching 0 and the router not automatically asking to renew the lease; My work-around is to leave my WRT54GL's WiFi transceiver enabled. An explanation follows.
During the months I was experiencing the DHCP timeout/lease-renewal problem I enabled my WRT54GL's WiFi transceiver only during narrow time-windows when WiFi was needed - which back then was once for 20-30 minutes every day or two.
Several months ago however I began needing WiFi intermittently throughout the day so I reconfigured my WRT54GL (running DD-WRT build v3.0-r38253 std) to enable its WiFi transceiver when booting - and the DHCP lease renewal problem magically disappeared.
The problem reappeared only when I ran a weeklong test whereby I again configured my WRT54GL to disable its WiFi transceiver when booting. During that weeklong test I enabled the transceiver when WiFi was needed, and disabled the transceiver immediately afterward (as I had been doing until late 2019).
So - in my case - DD-WRT will not automatically renew its DHCP lease more than once after booting unless the WRT54GL's WiFi transceiver is enabled. I have not performed enough tests to confidently assert whether this correlation is coincidental or causal.
So does anyone have a precise process of what we need to do in the DD-WRT interface?
because with r41686 I noticed on both of my routers (ASUS WL-520gU/Linksys WRT54GS v1.1) the counter hits zero on 'Status > WAN' and it just stays there. but at least as of a day or two over the end of the lease my internet still seems to work.
I just wonder when it will act up? ; 2 weeks into it or more? ; either way, does anyone have the exact commands we need to enter into the DD-WRT interface to fix it?
or should the "iptables -I INPUT -p udp --dport 68 -j ACCEPT" saved on Firewall be enough?
EDIT (Feb 18th 2020): for the moment I decided to go back to FreshTomato 2020.1 on the Linksys WRT54GS v1.1 router (I overclocked it 240Mhz from telnet prompt since FreshTomato GUI does not seem to offer any overclocking ability) as I figure having a functioning WAN DHCP should be safer as even if the router had a slight uptime issue once every some odd days, besides losing my traffic data, it should be 'good enough' as I never had any obvious LAN/wireless issues with general internet connection with it as far as I noticed. plus, I can do a test to see if the new capacitors fixed FreshTomato's instability issues on the WRT54GS v1.1.
for those wondering how I did the overclock on my WRT54GS v1.1 on FreshTomato 2020.1 you just telnet into the router and issue the following commands (and upon reboot the FreshTomato interface will report 240Mhz (even "cat /proc/cpuinfo" (without the ") shows 'BogoMIPS = 238.38' which is basically 240Mhz)...
nvram set debug_clkfix=0
nvram set clkfreq=240
nvram commit
reboot _________________ Primary Router: Linksys WRT54GS v1.1 /w dd-wrt.v24_mini_generic (r46640 May 13th 2021) ; new Panasonic capacitors Feb 11th 2020 | Backup Router: Linksys WRT54GS v6 /w dd-wrt.v24_micro_generic (r46640 May 13th 2021)
So does anyone have a precise process of what we need to do in the DD-WRT interface?
I'm afraid there's nothing what you can set on the interface to get this issue solved. I remember researching for months before turning to the community. With that said, I'm a happy user of the mentioned firmware for a long time now so the situation could have changed since the beginning of this thread and I wouldn't know. Maybe it's fixed, maybe it's not - my bug report is still open without any replies.
So does anyone have a precise process of what we need to do in the DD-WRT interface?
I'm afraid there's nothing what you can set on the interface to get this issue solved.
After more than 5 years, I decided to upgrade my WRT610N(V1) firmware about one month ago. I hit the same issue and searched the Internet. Thanks for your research and others' posts. I came up with a workaround and it works for me. It is to renew the lease time every hour by adding a cron job to Administration-Management.
My ISP provides 48 hours lease time. I have checked it for a week and can see /tmp/udhcpc.expires is touched every hour but the lease time is only reset back to 48 hours when it is down to 24 hours. Other ISP may reset it differently. I am using r42617 mega. If the lease time is one hour, it may be better to renew it early such as every 15 minutes or so.
Joined: 08 May 2018 Posts: 14126 Location: Texas, USA
Posted: Mon Apr 20, 2020 3:31 Post subject:
I presume this is on K2.4 builds only and not K2.6. BTW, there is an "edit" button upper right of your posts to edit them with as well as an "x" to delete them with. I fixed your typo. Good to see this workaround, but this makes me wonder which udhcp folder and version is being used on K24 and if the udhcpc is actually in need of being patched because of a bug, or if it is actually a webUi glitch. I had forgotten about this situation until I saw your post. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Posted: Fri Apr 24, 2020 14:01 Post subject: K2.6 build has no such issue
kernel-panic69 wrote:
I presume this is on K2.4 builds only and not K2.6.
Yes, it is K2.4 build. I updated the firmware to K2.6 on Apr 21 and it has renewed the lease time twice when reaching 0. I am now using dd-wrt.v24-42954_NEWD-2_K2.6_mega.