Linksys WRT54G disconnects clients regularly

I have the same problem with my linksys. cannot find "timeout option " as well. Could Jeff please show the path to this option? gr dee

I have noticed something additional: every time the deadness happens, I seem to get a new IP from the router. I realized this when I noticed my current IP was 192.168.1.144, which is strange because the DHCP range starts at

192.168.1.100 and we are only two users. So apparently the IP increases by one every time the problem occurs. (Wonder what will happen when I hit the end of the DHCP range)

Again, any suggestions are highly valued.

Not the total answer you want, but just wondering what is the timeout period for the DHCP server. I wonder if its closely matched to the times that your system drops. Then the question is why would the PC not refresh its IP address. I presume you have a firewall running on the PC. For a test, try disabling the firewall. If the timeout does seem to be close, then perhaps try a manual IP address renew Before the expected failure. Start -> run "cmd" In the black window type in "ipconfig /renew" If your system is able to talk to the DHCP server easily then it should come back with an address in a couple of seconds. If it takes 5-10 or fails then we might be getting closer to understanding the result of the error (loss of comms to the server) but not why, unless its some funny setting on your firewall

Tony

I'm not sure what you mean by "timeout period" for the DHCP server, but the setting called "Client Lease Time" is set to 1440 minutes (24 hours). The timeouts I see happen a lot more frequent than this. Today, for instance, everything was fine for 100 minutes, then fail, then 180 minutes, fail, then 120, fail, 80, fail, 60, fail (numbers are approximates). So it's not even "regularly" as I wrote in the subject, but it always seems to happen once every 1-3 hours.

I have no firewall on my PC (which I'm comfortable with, because my PC runs Linux and my ISP nats us). The other PC (laptop running WinXP) has a firewall, so this does not seem to affect the problem.

It's very hard to know when to expect the failure. Trying a DHCP renew right now went very well, I got back the same IP and it said "renewal in 37887 seconds". Trying more times gives the same result, but with slightly varying number of seconds until renewal.

I will try as an experiment to run a DHCP renew every 20 minutes and see if it still happens. If it doesn't, we may at least be a little bit further in identifying the problem.

Thanks!

That turned out not to help -- the problem just recurred. This time, as soon as I noticed it happening, I ran a dhcp renew. It went like this:

$ dhclient ra0 Internet Systems Consortium DHCP Client V3.0.1 Copyright 2004 Internet Systems Consortium. All rights reserved. For info, please visit

sit0: unknown hardware address type 776 Corrupt lease file - possible data loss! sit0: unknown hardware address type 776 Listening on LPF/ra0/00:08:a1:85:8f:4a Sending on LPF/ra0/00:08:a1:85:8f:4a Sending on Socket/fallback DHCPREQUEST on ra0 to 255.255.255.255 port 67 DHCPNAK from 192.168.1.1 DHCPDISCOVER on ra0 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 192.168.1.1 DHCPREQUEST on ra0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 bound to 192.168.1.149 -- renewal in 34554 seconds.

The messages about unknown hardware address type, and the message about the corrupt lease file, do not usually show up. In a subsequent renew, they were not there. I don't know what they mean, but perhaps someone does (perhaps they're irrelevant too for all I know).

I've been meaning to look into that. I'm pretty sure it's for IPv6 support. I'm also sure it doesn't matter for this purpose.

That's not related to the sit0 message, and looks bad.

It would be nice if you could copy the lease file before doing the DHCP renew, to see if anything appears really odd - but I can't really see why this would make a difference, anyway. It shouldn't be needing the lease file under normal conditions - that's only checked when it renews its lease.

Yes, indeed - but it's only reading the file _because_ you force a "renew" (you're getting a new lease because it can't figure out what the old lease was, and the DHCP server still thinks the old one is good).

I didn't copy it, but today on one of the times the problems occurred, I ran dhclient, got an error about problems parsing the leases file (!), took a look at /var/lib/dhcp3/dhclient.leases, and between two lease { ... } blocks were a large amount of strange non-ascii characters. Running dhclient again worked, and now the leases file looked normal. I'll keep an eye on that.

Well I guess a renew is what happens when I run dhclient during the "dead" periods (although maybe not, since I get a new IP?).

Anyway, due to earlier problems resulting in packet loss due to BitTorrent draining the router of memory (now fixed), I set up QoS for various services in an attempt to fix things. I now added DHCP as a "premium" service just in case (it was on its default "normal" before). I hope that helps, but I'll just have to wait and see (the horrible suspense!).

Now I got this:

$ dhclient ra0 Internet Systems Consortium DHCP Client V3.0.1 Copyright 2004 Internet Systems Consortium. All rights reserved. For info, please visit

sit0: unknown hardware address type 776 /var/lib/dhcp3/dhclient.leases line 65: expecting lease declaration. lease ^ /var/lib/dhcp3/dhclient.leases line 77: expecting semicolon.

^ /var/lib/dhcp3/dhclient.leases line 77: unterminated lease declaration.

^ sit0: unknown hardware address type 776

And it's no wonder. Here's the relevant part of the file:

lease { interface "ra0"; fixed-address 192.168.1.100; option subnet-mask 255.255.255.0; option routers 192.168.1.1; option dhcp-lease-time 345600; option dhcp-message-type 5; option domain-name-servers 217.13.4.24,217.13.7.140; option dhcp-server-identifier 192.168.1.1; renew 5 2005/9/16 14:31:43; rebind 0 2005/9/18 04:58:29; expire 0 2005/9/18 16:58:29; lease { interface "ra0"; fixed-address 192.168.1.101; option subnet-mask 255.255.255.0; option routers 192.168.1.1; option dhcp-lease-time 345600; option dhcp-message-type 5; option domain-name-servers 217.13.4.24,217.13.7.140; option dhcp-server-identifier 192.168.1.1; renew 5 2005/9/16 09:32:19; rebind 0 2005/9/18 05:28:28; expire 0 2005/9/18 17:28:28; }

It seems the first block hasn't been closed properly. Anyway, this may be just a bug with my DHCP client and not related to the problem.

This did not help.