WAN ip address not renewed 1.3.10

[1an]

I had problems getting 1.3.10 to work with new firmware, but solved most after manually reentering settings from 1.3.9.

I still have a problem though, because the WAN ip address does not seem to automatically get renewed, so I lose the WAN connection periodically. If I click the "renew lease" button on the Connections page, the new time stated is in the past (usually yesterday's date)

I am in Australia (UTC +10, currently DST), and the time settings in the System/Time page seem to work properly

Ian

[1an]

Additional info:

I'm using a WRT54GL, and this problem is driving me nuts.
I haven't found a reproducible way of getting the router to acquire a new WAN ip lease. Various combinations of power-cycling router and cable modem with ethernet cable connected/disconnected have sometimes worked, but not every time. Clicking on the "Renew lease" button on the "Connections/basic" page does not seem to renew the lease, despite the "Renewing DHCP lease" message, and the new lease expiry after doing this is in the past!
I have tried various settings of the time zone/date format (because the date format set on the System/Time page does not seem to be applied to the "Connections/basic" page, so I wondered if this might be part of the problem)
I have bricked and unbricked the router several times trying to up and downgrade the firmware (and learned a few new tricks in the process)!!

A couple of questions

[1] Has anybody successfully updated to 1.3.10 with this model? Or is the 16Mb memory available too small?
[2] Is there a command line method of forcing the WAN interface to renew the lease? At least then I can continue to experiment with this firmware version, if I know I can manually re-acquire the WAN connection if needed without resorting to multiple downgrade/upgrade attempts.
[3] Other suggestions? I had a look at comparing the saved configuration from a working version of 1.3.9, to the equivalent version saved under 1.3.10, but without really knowing enough about the inner workings, I couldn't find anything that looked like a problem.
[4] Is it worth running Wireshark to compare the difference between the initial DHCP request from the router with the later (lease expired) version and/or manual DHCP lease renewal request? I would need some help with this, since I'm not sure what I'm looking for in the logs.

I don't mind if the answer is that 16Mb memory is not enough, time to get a newer router , but I have done everything I could think of to try to solve this issue if possible, and would appreciate some help!

thanks

Ian

[pbix]

Based on your report I pulled out my WRT54GL and loaded v1.3.10 on it. Starting with all default settings I configured the WAN as "Wireless DHCP" and connected to my home network. Then I connected my PC to a LAN port of the GL.

I went to the connections->basic page and pressed renewed and it worked. I did notice some difference in operation using Firefox vs. Chrome. Subsequent presses of the button with Chrome seemed to do nothing. Not sure why that is but Firefox workes everytime. What browser are you using?

I do not see any problems on the GL with v1.3.10. That does not mean that there are none it just means I could not reproduce what you report and no one else has reported any.

Now I do have some things you can try. You can cause a renew from the command line using the command "kill -s USR1 <pid>". You have to replace <pid> with the pid of the udhcpc process. Hopefully you know how to use 'ps' to get that. After you do this what about 10 seconds and then go back to the basic screen, refresh and see if your renew date is correct.

Let me know how that works for you.

[1an]

Thanks pbix,
After your report of problem free installation, I tried again.
* reinstalled 1.3.10
* restored my backed up configuration (the one I built manually after finding out about the incompatibility of wireless settings between 1.3.9 and 1.3.10, that had worked at least for a while)
* tried your suggestion

You can cause a renew from the command line using the command "kill -s USR1 <pid>". You have to replace <pid> with the pid of the udhcpc process. Hopefully you know how to use 'ps' to get that.

I was able to use ps to find the correct <pid> and kill it. The time and date of lease expiry were updated (13hours in future), but still no WAN connection.

I then went back to 1.3.9 to do some testing:
I discovered that the renew lease button didn't work correctly for me (using Firefox Win 3.6.13) in 1.3.9 either! I had never needed to use it before, so hadn't noticed.

I was quite sure that my initial update to 1.3.10 had worked for a while, so upgraded again to 1.3.10 but started testing with the default configuration. I will add configuration options one section at a time and reboot / test after each one to see if I can identify what breaks it.
* default configuration (I'm using DHCP wired): works
+ wireless switched on AP mode, encryption WPA2 PSK: works
+ date format changed to yyyy/mm/dd: works
* at this point checked that renew lease button works (it does, but only updates lease by 1 hour (Win PC connected directly to cable modem, command line ipconfig /release, ipconfig /renew gives 24 hours)
+ change timezone to my local time (UTC+10) from GMT. Now "Connection/basic" page shows same numerical time/date as before TZ change, just has AEDT after it. ie time date not converted to global time zone settings.
* tried rebooting to see if this got fixed - NO, time still wrong
* tried command line udhcpc restart - lease expiry date updated by 1 day, time unchanged.
* tried clicking renew lease button, updated time, date format used changes to mm/dd/yy (global settings are yyyy/mm/dd), date goes BACK by 1 day

Summmary: looks like the script(s) involved for renewing on button click and/or auto renewal may not be using the global date/time settings from the System/Time page, and this may be causing the problem.

What do you think I should try next?

Ian

[pbix]

I spent some more time on this and found that there are indeed some date issues in converting between timezones and what not. I made two new files which I attach to this post.

On your router put basic.sh in your \www directory and basic.js in your \www\js directory renaming the files of the same name in those locations first to save them if you need to go back.

Since this is only a display issue I cannot see how this could be related to your inability to get a DHCP lease. But perhaps we will learn something if you test again with these files.

[1an]

With the WAN DHCP renewal apparently working as long as I left the timezone at GMT and the date format at mm/dd/yy, I decided to try putting the rest of my settings in (fixed ip addresses, quotas, time restrictions for some ip ranges etc) and the router has been working perfectly since.
Interestingly, it has been issued a new WAN ip address, after having the same one with all previous versions of gargoyle firmware for almost a year. (1.3.10 had previously not seemed able to negotiate the WAN ip lease correctly) I am not using a custom MAC address with the firmware (either previously or now). Do ISP's usually issue an ip address based on this MAC address? I did try connecting my laptop directly to the cable modem and renewed the lease that way, before I got your previous suggestion about renewing lease from gargoyle command line. Just trying to understand how these things are implemented. I don't know enough about linux and the scripts used in gargoyle to be know where to look, or how to interpret what I find. If you have any links to information that would help me get up to speed, I would appreciate it!

On your router put basic.sh in your \www directory and basic.js in your \www\js directory renaming the files of the same name in those locations first to save them if you need to go back

Ok, did that. I had a little initial trouble because I used WinSCP to transfer files, and forgot to set permissions (execute permissions were missing), but once I set permissions to match the rest of files already there, everything worked OK. Initially shown lease expiry was 01/01/70 01:00 GMT. Clicking the renew lease now button updated it to 24 hours from time of click.
Changing time time settings options to my local timezone, and preferred date format (yyyy/mm/dd). Clicking the button again renews for 24 hours, displayed using the global time and date format
I will now leave it for 24 hours, to check if the auto renew is working.
If all goes OK, as I expect it will, I will try changing basic.* files back to standard versions for 24 hours. From my comments at the top of this post, I suspect that it was the combination of outdated WAN ip address and maybe timing issues (although I note that you said the times are display only and shouldn't affect WAN lease renewal). If this is the case, it may not be possible now to duplicate my original issue.

Thanks for your effort in helping me get things working properly.

Ian

[1an]

Problem not as solved as I had hoped

At about 12 hours after last WAN lease renew, I noticed WAN access was down.
basic.sh page showed lease time/date of 12MN 1970/1/1 + time zone offset.
* "renew lease now" clicked --> update time/date to 24hrs post click time, but NO WAN access.
* command line kill udhcpc process, still no WAN access
* click renew lease, still no WAN access
* reboot router from web interface, still no WAN access
* power cycle router, still no WAN access
* reboot router from command line, yay! WAN access!!

Am I right in thinking that the router attempts to renew its WAN ip lease about halfway through a 24hour lease?

where is the script that does this aspect?

Ian

[pbix]

1an,

There are no scripts that run on your router related to DHCP unless you reboot the router or press the renew button. So the theory that WAN access suddenly disappears because some DHCP related script is running seems impossible.

Without your action nothing happens on your router until the DHCP lease time expires as which point udhcpc will request a refresh. Its a very simple process actually.

The fact that a power reset did not restore your WAN function indicates a hardware problem to me. I do not know of any way software can do this. How long did you wait? Sometimes it can take minutes for the router to establish WAN access.

The basic.sh page showing a time of 1/1/1970 seems very strange. There is no way the DHCP related processes are going to result in this value.

Given what you have written I am leaning towards one of the following:

1) Your GL has an intermittent hardware issue. This one is not easy to confirm.

2) Your GL is crashing due to other things running on your router besides DHCP. The next time you see the 1/1/1970 date run dmesg and logread before doing anything else and post the results. Also run "uci show -P /var/state" and post the results. Finally run "ifconfig" and post the result.

[1an]

It's still happening. I had the 1/1/1970 date showing again yesterday. So here are the log files you suggested.

I accept what you say about an intermittent hardware problem, but I am struggling to understand why it only occurs with 1.3.10 ....
I've downgraded back to 1.3.9 for a while, just to check that it isn't a co-incidence that a new HW problem started at the same time as I upgraded to 1.3.10 (if so, 1.3.9 should also be unreliable, since it isn't the fault of the FW in that case).

Ian

[pbix]

Well I have been pondering this problem this weekend. Can't say I have any definite ideas. The files you sent for the most part look normal.

Your ifconfig output shows that your WAN interface is up and running with configured IP address. Why do you think that you are disconnected from the WAN? I can only assume that you made these files while the problem was occuring and not after a reboot. Next time it happens just try a ping to your gateway 'ping 211.30.183.1". If it responds your WAN is up. If it does not respond then the output of the 'route' would be interesting.

I cannot come up with a reason as to why the lease dates are messed up but I cannot say these are directly related to WAN problems either.

I do see from your logread output (and mine) that both rdate and ntpclient are running which to me seems strange and a possible source of conflict on setting the system date/time.

On a lark you could move /etc/hotplug.d/iface/40-rdate -> /etc/40-rdate. This will prevent rdate from running. It would be interesting to me to see if this has an effect on your situation.