Linksys WRT54G disconnects clients regularly

I hope you'll excuse my revival of a question from a recent thread.

(E-Mail Removed) wrote:

>>everything works fine, but the connection is disconnected for about
>>5-10 secs. once or twice an hour!!

I seem to have this problem too. Every hour or two, all traffic between any
wireless client and the WRT54G stops for some 10-60 seconds, and then
starts working again. This causes most long-lived connections such as IRC,
Jabber, and SSH to disconnect. Highly annoying. Through-out the "dead"
period I can ping the router fine, with no packet loss.

Jeff Liebermann wrote:

> Go to the Main WAN setup page on the WRT54G and change the "timeout"
> at the bottom of the page from the default of 5 minutes to zero
> minutes.

This sounds promising, but after exhaustive searches through the web
interface, I simply cannot find any timeout setting anywhere. My Linksys is
revision 2.2, and the firmware is Sveasoft Alchemy-V1.0 v3.37.6.8sv. Does
this setting translate to some file in /proc or similar on the router, so
that I can change it through SSH instead? Or is there something else I can
do to make the disconnects go away?

Thanks in advance!

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

"Haakon Nilsen" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I hope you'll excuse my revival of a question from a recent thread.
>
> (E-Mail Removed) wrote:
>
>>>everything works fine, but the connection is disconnected for about
>>>5-10 secs. once or twice an hour!!
>
> I seem to have this problem too. Every hour or two, all traffic between
> any
> wireless client and the WRT54G stops for some 10-60 seconds, and then
> starts working again. This causes most long-lived connections such as IRC,
> Jabber, and SSH to disconnect. Highly annoying. Through-out the "dead"
> period I can ping the router fine, with no packet loss.
>
> Jeff Liebermann wrote:
>
>> Go to the Main WAN setup page on the WRT54G and change the "timeout"
>> at the bottom of the page from the default of 5 minutes to zero
>> minutes.
>
> This sounds promising, but after exhaustive searches through the web
> interface, I simply cannot find any timeout setting anywhere. My Linksys
> is
> revision 2.2, and the firmware is Sveasoft Alchemy-V1.0 v3.37.6.8sv. Does
> this setting translate to some file in /proc or similar on the router, so
> that I can change it through SSH instead? Or is there something else I can
> do to make the disconnects go away?
>
> Thanks in advance!
>

Haakon Nilsen wrote:

> I seem to have this problem too. Every hour or two, all traffic between
> any wireless client and the WRT54G stops for some 10-60 seconds, and then
> starts working again. This causes most long-lived connections such as IRC,
> Jabber, and SSH to disconnect. Highly annoying. Through-out the "dead"
> period I can ping the router fine, with no packet loss.

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.

> Haakon Nilsen wrote:
>
> > I seem to have this problem too. Every hour or two, all traffic between
> > any wireless client and the WRT54G stops for some 10-60 seconds, and
then
> > starts working again. This causes most long-lived connections such as
IRC,
> > Jabber, and SSH to disconnect. Highly annoying. Through-out the "dead"
> > period I can ping the router fine, with no packet loss.
>
> 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

Tony Field wrote:

> 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.

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.

> 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.

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.

> If the timeout does seem to be close, then perhaps try a manual IP address
> renew Before the expected failure.

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!

Haakon Nilsen wrote:

> 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.

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 http://www.isc.org/products/DHCP

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).

Haakon Nilsen wrote:

> $ dhclient ra0
> Internet Systems Consortium DHCP Client V3.0.1
> Copyright 2004 Internet Systems Consortium.
> All rights reserved.
> For info, please visit http://www.isc.org/products/DHCP
>
> sit0: unknown hardware address type 776

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.

> Corrupt lease file - possible data loss!

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.
--
derek

Derek Broughton wrote:

>> Corrupt lease file - possible data loss!
>
> 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.

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.

> It shouldn't be needing the lease file under normal conditions - that's
> only checked when it renews its lease.

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!).

Haakon Nilsen wrote:

> Derek Broughton wrote:
>
>>> Corrupt lease file - possible data loss!
>>
>> 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.
>
> 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.
>
>> It shouldn't be needing the lease file under normal conditions - that's
>> only checked when it renews its lease.
>
> 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?).

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).
--
derek

Haakon Nilsen wrote:

> 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 (!)

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 http://www.isc.org/products/DHCP

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.

> 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!).

This did not help.