Network stops working after 2 hours

Bug #36965 reported by Ricardo Pérez López
6
Affects Status Importance Assigned to Milestone
dhcp3 (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

I don't know if this is a dhcp3-client issue, but I think it is.

I have a cablemodem for my Internet connection. The cablemodem sends the TCP/IP parameters to my Ubuntu via DHCP.

The connection works since Ubuntu boot, but suddenly it stops working after 2 hours.

It seems that it's a lease renewal issue, but I don't know very much about the DHCP protocol to confirm that.

Revision history for this message
Ricardo Pérez López (ricardo) wrote : My dhclient.eth1.leases

This morning (2006/03/28) I turn on the Ubuntu box at 10:00 o'clock (08:00 UTC). As you can see, the leases file seems to be untouched since yesterday midnight.

I don't know if this is the correct behavior, but seems rare.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

You have localtime in your hardware clock, right? Can you try setting UTC=yes in /etc/default/rcS? This could be related to bug #33968. Otherwise, I see your lease time is 2 hours (7200s), so it might be the renewal fails. Anything in /var/log/daemon.log?

Changed in dhcp3:
status: Unconfirmed → Needs Info
Revision history for this message
Ricardo Pérez López (ricardo) wrote :

> You have localtime in your hardware clock, right?

Yes.

> Can you try setting UTC=yes in /etc/default/rcS?

I'm going to change it from "no" to "yes", and I'll try.

> Anything in /var/log/daemon.log?

Mmmm... not for now. I'll see with the UTC=yes and I'll tell you.

Thanks a lot for the fast reply.

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

By the way... I forgot to say that I'm using Dapper, and that this problem appears several days ago (it works perfectly until that day).

Revision history for this message
Ricardo Pérez López (ricardo) wrote : My new dhclient.eth1.leases, two hours after

This is the dhclient.eth1.leases file, two hours after (at 12:20 localtime, 10:20 UTC).

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

Mmmm... I have something in my /var/log/daemon.log.

Revision history for this message
Ricardo Pérez López (ricardo) wrote : My daemon.log

I have a 'Permission denied'...

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

2 hours and 40 minutes ago since boot, and the network connection still works!

It seems that the "UTC=yes" solves the problem, at least by now...

Nevertheless, the 'Permission denied' messages seems not be right.

Revision history for this message
Ricardo Pérez López (ricardo) wrote : New daemon.log

New daemon.log, at 15:00 localtime (13:00 UTC).

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

Confirmed: with UTC=yes, lease renewal works well. With UTC=no, not.

With UTC=yes, I get the following messages in /var/log/daemon.log:

Mar 29 12:55:54 localhost dhclient: DHCPREQUEST on eth1 to 10.175.239.30 port 67
Mar 29 12:55:54 localhost dhclient: DHCPACK from 10.175.239.30
Mar 29 12:55:54 localhost dhclient: can't create /var/lib/dhcp3/dhclient.eth1.leases: Permission denied
Mar 29 12:55:54 localhost dhclient: bound to 84.122.157.239 -- renewal in 3116 seconds.

With UTC=no, these messages doesn't appears, and there's no lease renewal.

Curiously, the problem appears since last Sunday (march, 26th), when here in Spain we changed timezone from CET (UTC+1) to CEST (UTC+2). Until now, I had UTC=no without problems. But now I need to have UTC=yes to workaround the problem.

Revision history for this message
Jérémie Corbier (jcorbier) wrote :

Marked this bug as a duplicate of bug #33968.

Revision history for this message
Fredrik (fredrk) wrote :

This one is VERY important to solve.

I can't have UTC = yes as Windows will get totaly wrong time.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for dhcp3 (Ubuntu) because there has been no activity for 60 days.]

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.