dhclient fails when not using UTC in hwclock

[Walther Zwart]

When UTC=no is set in /etc/default/rcS, dhclient3 won't acquire an ip-address on boot.
ifconfig shows the interface (but no ip). I can see the process still running, but the pid file (/var/run/dhclient3.rausb0.pid I think) is empty and has a timestamp in the future.

When I set UTC=yes in /etc/default/rcS, then it all works fine.

Note: the original reporter indicated the bug was in package 'dhclient'; however, that package was not published in Ubuntu.

[Loïc Corbasson (cnb)]

Same here, this workaround works.

In fact, I first thought I was affected by bug #19740, but it seems I'm not, or maybe it's the same problem? I'll post a comment there too to see if this workaround works for them too.

[Loïc Corbasson (cnb)]

Same here, but this workaround works.

In fact, I first thought I was affected by bug #19740, but it seems I'm not, or maybe it's the same problem? I'll post a comment there too to see if this workaround works for them too.

[Walther Zwart (wahez)]

You mean that UTC=yes works?
That is true, but some people need the hardware clock to be in local time.

There are still some people that dual-boot with some other operating system that expects the clock to be in local time. I know that is a problem in itself, but we can't change that before Dapper :)

And for me personally it is not a nice solution, because my computer case shows the time even when the computer is turned off. And I can't explain my wife why it shows the time in UTC :)

[Loïc Corbasson (cnb)]

Sorry Walther, I didn't mean "it's not a bug, it's a feature", like some operating system vendor(s?) do (see bug #1 :)).
I just meant that maybe these two bugs were somewhat related. People at bug #19740 seem to need more info because they can't understand what's happening there, and this bug may be the real reason behind #19740. I have the impression they didn't find any, and the utc thing is not quite an evident one in a network-related package. Let's see what it brings anyway.

[ed-ong (ed-ong)]

I also thought I was affected by #19740, but this is the actual bug I am affected by. As I wrote there, I actually made a change to the interfaces file to add a delay.

[Walther Zwart (wahez)]

For the record, ed-ong means adding this line to the interface in /etc/network/interfaces:
   pre-up sleep 10

This works for me too. I cannot tell there is a delay during startup, so it is a pretty good workaround. But I feel there should be a better solution to this (and it should be enabled by default.)

[Walther Zwart (wahez)]

It seems more people are affected by this problem. And I'd say it is pretty serious, because you end up without a working network connection.

[Tormod Volden (tormodvolden)]

I can confirm this in Dapper 060327, and that setting UTC=yes makes it work. Now I set it back to UTC=no, and it still works :) but I think this could be my combination of timezone +1 and still having a valid lease.

[Ricardo Pérez López (ricardo)]

I have a similar problem (which I describe in #36965).

With UTC=no, dhclient works during boot (therefore, I have a working connection just after boot), but fails in lease renewal. Therefore, the network connection stops working after 2 hours (the lease time).

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.

[Ricardo Pérez López (ricardo)]

More info from bug #36965:

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.

[Tormod Volden (tormodvolden)]

I am not sure how dhclient thinks, but I suppose it might look at some timestamp of the lease. This gets messed up by bug #35423, and it thinks it is 2 hours (in Ricardo's case) in the future. A very common lease time is also 2 hours. Therefore the problem arise only when you are 2 hours or more off UTC (like Ricardo and I after Daylight Saving Time started). The ubuntu developers in UTC or UTC+1 won't see this :)

[Tormod Volden (tormodvolden)]

I justed booted after today's updates, and for once the network was running by itself. At the same time, the clock was now running two hours wrong (UTC). The correleation is clear. This seems to be some kind of macrobug in the handling of localtime in hwclock.

[Randakar (randakar)]

As a temporary workaround, maybe a simple "rm /var/lib/dhcp3/dhclient.eth1.leases" before attempting to bring the network interface up during boot might be an option.

Or perhaps "touch" ing it to bring it up to speed on the current time.

[Tormod Volden (tormodvolden)]

I noticed today the network was running fine after boot, but there's no traces of dhcp in daemon.log. It seems it's using a 3-day old (expired) lease without asking for a new one...

There's no trace of ntpdate having been run either.

[Ricardo Pérez López (ricardo)]

Today (2006-04-14) I tried again, and the problem is still here.

I tried with:

- UTC=no and timezone=Europe/Madrid (UTC+2) => doesn't works
- UTC=no and timezone=Europe/Lisbon (UTC+1) => doesn't works
- UTC=yes and any timezone => works

So, obviously, if UTC=no, then the problem appears. If UTC=yes, then the problem is gone.

I think this is a very important bug, with important consequences.

Imagine this scenario (a very typical scenario here in Spain):

An Spanish (UTC+2 now) Windows user, with an Internet connection via cablemodem, has heared about Ubuntu, and she would like to try it, but without removing her Windows installation. During the installation, the installer ask her for the timezone (she select Europe/Madrid because she's in Spain, therefore it's UTC+2 now in Summer time), and ask her if the clock is in GMT or localtime. The installer suggests her to select 'localtime' because she has another operating system installed in her machine, so she select 'localtime' (UTC=no). After installation, she booted into her new Ubuntu, and Internet stops working after two hours. Always.

Therefore, she goes back to Windows and forget Ubuntu. :(

I insist: this is a very typical scenario, applicable to hundred of thousands potential users.

And I would like to say that this is a regression problem, too, because the problem is not in Breezy or Hoary.

[Ricardo Pérez López (ricardo)]

Randakar:

> As a temporary workaround, maybe a simple "rm /var/lib/dhcp3/dhclient.eth1.leases" before attempting to bring the network interface up during boot might be an option.

> Or perhaps "touch" ing it to bring it up to speed on the current time.

According to my experience, that workaround doesn't solves nothing. The "Permission denied" error messages in daemon.log appears when dhcp works correctly, so it does not represents a problem symptom (I believe).

[Ricardo Pérez López (ricardo)]

Martin, can I help you in the bug-fixing process? I would like to help, although I don't have the necessary knowledge, but I can send you any information I have (log files, commands output, and so on...)

I ask in the ISC-DHCP's mailing list:

http://marc.theaimsgroup.com/?l=dhcp-users&m=114501729300500&w=2

but I haven't got any responses by now.

[Aurel Schwarzentruber (zed-balcab)]

Ok, I think I found the problem:

The networking initscript in /etc/rcS.d is started *before* hwclock.sh (which sets the correct local time). dhcp3 picks up the wrong time and, depending on the UTC-Offset, thinks its lease is still valid and never sends a DHCP-Request.

I fixed it by starting hwclock.sh earlier (for example renaming it to S09hwclock.sh) and deleting /var/lib/dhcp3/dhclient.eth0.leases .

[Ricardo Pérez López (ricardo)]

> I fixed it by starting hwclock.sh earlier (for example renaming it to S09hwclock.sh) and deleting /var/lib/dhcp3/dhclient.eth0.leases .

IT WORKS FOR ME!!! Zed, thank you very much for the investigation.

Now, please, Martin, can this workaround be applied by default before Dapper Beta release?

Thanks again. This is a very important bug, but at least it has a rather simple solution.

[Scott James Remnant (Canonical) (canonical-scott)]

hwclock.sh must start after /usr has mounted because it uses /etc/localtime which is a symlink to a file under /usr

Therefore the earliest that hwclock.sh can be started is S50, as that's the only point at which /usr is definitely mounted

Physical network devices are started by S10udev, Virtual ones (VPN, etc.) are started by S40networking

[Ricardo Pérez López (ricardo)]

Can S10udev be started after S50hwclock.sh? Maybe S51udev?

[Scott James Remnant (Canonical) (canonical-scott)]

HAHAHAHAHAHAHAHAHA.

No.

Without udev, you have no /dev, so can't do things like check the root filesystem or mount other filesystems.

[Aurel Schwarzentruber (zed-balcab)]

> hwclock.sh must start after /usr has mounted because it uses
> /etc/localtime which is a symlink to a file under /usr

In debian unstable, /etc/localtime is a real file, copied from /usr/share/zoneinfo .

[Scott James Remnant (Canonical) (canonical-scott)]

Interesting; that is the ideal change and has been requested for quite some time.

The reason I understood why it wasn't made was that some things may rely on being able to read the symlink to determine the current timezone.

If we followed suit and made it a real file, we could move hwclock.sh up to somethings like S03 and thus solve the problems.

[Ricardo Pérez López (ricardo)]

> Without udev, you have no /dev, so can't do things like check the root filesystem or mount other filesystems.

Mmmm... It sounds like a circular dependency. I wonder if there's any form of reordering the init scripts in a way that all the dependencies were satisfied.

[Scott James Remnant (Canonical) (canonical-scott)]

/etc/localtime is a symlink to something under /usr
/usr might be an NFS filesystem
NFS filesystem needs network
network might need DHCP
DHCP needs correct hwclock
hwclock needs to read /etc/localtime

No way to reorder the init scripts to solve that; the correct fix is either
a) make /etc/localtime a *copy* of the file under /usr, so /usr doesn't need to be mounted
b) make DHCP not care about what the time is

[Aurel Schwarzentruber (zed-balcab)]

> If we followed suit and made it a real file, we could move
> hwclock.sh up to somethings like S03 and thus solve the
> problems.

The related package in Debian is tzdata, here's the changelog:

http://packages.debian.org/changelogs/pool/main/t/tzdata/tzdata_2006c-2/changelog

[Walther Zwart (wahez)]

I would recommend using option a.
b might give some problems with lease times and so forth.

If there are 'things' that read the symlink, they are probably Ubuntu specific (because in Debian it is not a symlink). We should fix those 'things' so that they read /etc/timezone

[Stevie Beth Mhaol (kormat)]

There is a third option:

c) Make DHCP always use the hardware clock time. I.e. store/renew leases based soley on the hardware clock, not on whatever localtime is in use

That shouldn't be all that hard to do. Maybe i'm missing some fundamental issue with it though.

[Ricardo Pérez López (ricardo)]

> I would recommend using option a.

Me too, and we'll be closer to Debian, as a bonus.

[Scott James Remnant (Canonical) (canonical-scott)]

Actually we couldn't start hwclock before S10udev because it needs access to /dev/rtc which is created by udev.

hwclock would have to be run by a udev rule

[Tormod Volden (tormodvolden)]

I guess the kernel picks up the rtc (and consider it UTC) when it boots? And that's why all timestamps made before hwclock is run are wrong (when rtc is running localtime)?

There should be something like a, for instance, "rtc=UTC+2" kernel option, to get the time correct from the start.

[Ricardo Pérez López (ricardo)]

> hwclock would have to be run by a udev rule

Is this easy to do? It sounds (in my ignorance) like a good solution.

[Scott James Remnant (Canonical) (canonical-scott)]

I've uploaded a partial fix for this:

 util-linux (2.12r-4ubuntu3) dapper; urgency=low
 .
   * Set the hardware clock via a udev rule as soon as /dev/rtc is available.
     This fixes #33968 for people without /usr on a separate partition.

This will run hwclock as early as possible, which should be before dhclient gets run. However because /etc/localtime is still a symlink to a partition under /usr, if you have that mounted separately, this will *not* fix it for you.

[Ricardo Pérez López (ricardo)]

> I've uploaded a partial fix for this:

Thank you very much :)

> However because /etc/localtime is still a symlink to a partition under /usr, if you have that mounted separately, this will *not* fix it for you.

What about making /etc/localtime a *copy* of the file under /usr? Will this be done soon?

[Scott James Remnant (Canonical) (canonical-scott)]

I don't think we can do that for dapper, there was a large number of changes that made that possible including splitting timezone data out into different packages.

[Ricardo Pérez López (ricardo)]

By the way, I've realized that my /etc/localtime IS a regular file, not a symlink:

ricardo@yuggoth:~ $ ls -l /etc/localtime
4 -rw-r--r-- 1 root root 946 2006-04-14 13:20 /etc/localtime
ricardo@yuggoth:~ $ file /etc/localtime
/etc/localtime: timezone data

It's Dapper system, upgraded from Breezy, upgraded from Hoary. Is anything wrong in my system?

[Aurel Schwarzentruber (zed-balcab)]

> I don't think we can do that for dapper

Why not? At least tzconfig could be changed, it's a simple shellscript. But I'm not sure if this is enough. Are there other methods to change timezone configuration?

[Ricardo Pérez López (ricardo)]

The fix uploaded by Scott works for me, but since I use it my /var/lib/dhcp3/dhclient.eth1.leases file is empty.

I don't know if this could be related to the "Permission deined" error messages in daemon.log:

Apr 21 19:23:15 localhost dhclient: DHCPREQUEST on eth1 to 10.175.239.29 port 67Apr 21 19:23:15 localhost dhclient: DHCPACK from 10.175.239.29
Apr 21 19:23:15 localhost dhclient: can't create /var/lib/dhcp3/dhclient.eth1.leases: Permission denied
Apr 21 19:23:15 localhost dhclient: bound to 84.122.157.239 -- renewal in 2994 seconds.

[Martin Pitt (pitti)]

This fix should help a bit, too:

 dhcp3 (3.0.3-6ubuntu7) dapper; urgency=low
 .
   * debian/patches/deroot-client.dpatch: Fixed major thinko in lease file
     handling: dhclient was unable to update the leases file after it
     daemonized, which meant that 'sudo dhclient ethX' worked fine, but
     obtained leases at boot time were never written if the first attempt timed
     out. Now make sure that the lease file is always writable by forked
     instances, too. Closes: LP#39249 (and should also mitigate #33968).
   * Add debian/patches/dhcpd.conf-subnet-examples.dpatch: Add 'option
     subnet-mask' to example dhcpd.conf. Closes: LP#26661

However, the actual solution is highly nontrivial and non-straightforward, please see upstream's reply at
http://marc.theaimsgroup.com/?l=dhcp-users&m=114624286102709&w=2.

[Martin Pitt (pitti)]

(The latest dhcp3 version should fix all the 'permission denied' messages)

[Ricardo Pérez López (ricardo)]

Sorry, Martin, but I still have the 'permission denied' messages:

May 6 11:30:14 localhost dhclient: DHCPREQUEST on eth1 to 10.175.239.29 port 67
May 6 11:30:14 localhost dhclient: DHCPACK from 10.175.239.29
May 6 11:30:14 localhost dhclient: can't create /var/lib/dhcp3/dhclient.eth1.leases: Permission denied
May 6 11:30:14 localhost dhclient: bound to 84.122.157.239 -- renewal in 1781 seconds.

[Ricardo Pérez López (ricardo)]

Mmmm... Curious. Today (May 7) the problem is gone! The patch seems to work.

[Martin Pitt (pitti)]

Does anyone still have huge problems with current dapper? I'm pondering dropping the severity to normal, since with the current fixes, this bug should be mitigated now.

[Ricardo Pérez López (ricardo)]

For me, feel free to do that. The two big problems related with this bug (fail adquyiring IP settings via DHCP, and 'Permission denied' messages) was gone.

[Walther Zwart (wahez)]

I agree. You can drop the severity.

I do remember someone saying that the fix does not work for people who have /usr on a separate partition. I can't verify that though (well .. ok, I could try, but it would take some work :)

[lexual (lexhider)]

Am I missing something?
My internet is still not brought up on reboot until I manually run:
"sudo dhclient"

I'm am running an up to date dapper installed from flight7, kubuntu.

[Steffen Wilberg (steffen-wilberg)]

Doesn't work for me either. There's no trace of dhclient in the logs until I run "sudo ifup --force eth0".
I'm running Ubuntu Dapper with all available updates installed.

[Christian Kirbach (christian-kirbach-e)]

with latest Dapper I cannot see the problem originally described

[Alexander van Loon (avanloon)]

Please don't decrease the severity! I still experience the bug!

My story begins when I did a fresh install of Ubuntu 6.06 about 2 months ago. I noticed the time was displayed incorrectly, so I searched and posted comments at bug #35423. Later I was told that I had the wrong bug, and that I was really affected by #37750 (looks like I installed at a moment when Ubiquity didn't automatically figure out yet whether to set the hardware clock to UTC or not). Because of that bug I was told to edit /etc/default/rcS and change "UTC=yes" to "UTC=no". After that I restarted my PC and booted up Ubuntu again, logged in to GNOME. I noticed the time was displayed correctly now, but that I didn't have a working networking connection anymore (unless I used "sudo dhclient eth0") and that my internal IP address was changing nearly every ten minutes. I posted about my experiences with this in bug #21563 before I was told that I was really affected by this bug.

So after reading this bugreport, I decided to change "UTC=no" back to "UTC=yes" again, I rebooted and noticed that my network connection was now behaving normally again. However, having UTC disabled means that the time is displayed incorrectly.

Conclusion, I'm running 6.06 with the most recent updates installed, and I'm still affected by the bug.

[Alexander van Loon (avanloon)]

*small edit, sorry for double posting*

Please don't decrease the severity! I still experience the bug!

My story begins when I did a fresh install of Ubuntu 6.06 about 2 months ago. I noticed the time was displayed incorrectly, so I searched and posted comments at bug #35423. Later I was told that I had the wrong bug, and that I was really affected by bug #37750 (looks like I installed at a moment when Ubiquity didn't automatically figure out yet whether to set the hardware clock to UTC or not). Because of that bug I was told to edit /etc/default/rcS and change "UTC=yes" to "UTC=no". After that I restarted my PC and booted up Ubuntu again, logged in to GNOME. I noticed the time was displayed correctly now, but that I didn't have a working networking connection anymore (unless I used "sudo dhclient eth0") and that my internal IP address was changing nearly every ten minutes. I posted about my experiences with this in bug #21563 before I was told that I was really affected by this bug.

So after reading this bugreport, I decided to change "UTC=no" back to "UTC=yes" again, I rebooted and noticed that my network connection was now behaving normally again. However, having UTC enabled means that the time is displayed incorrectly.

Conclusion, I'm running 6.06 with the most recent updates installed, and I'm still affected by the bug.

[Ricardo Pérez López (ricardo)]

Sander: what's your timezone?

[Alexander van Loon (avanloon)]

It's Europe/Amsterdam.

[Ricardo Pérez López (ricardo)]

Rather strange... You are in the same timezone as me (Europe/Madrid), so we are in CEST (Central Europe Summer Time), or UTC+2. But, however, the fix works for me and not for you.

[Walther Zwart (wahez)]

Sander do you have /usr on a separate partition? I understood the fix doesn't work in that case.

[Niels Kristian Bech Jensen (nkbjensen)]

I'll just add an observation I think is related:
On my powerpc system I have to load both the RTC driver (genrtc) and the ethernet driver (bmac) from /etc/modules. The network connection is set up by DHCP.

If UTC=no genrtc has to be loaded BEFORE bmac to get a network connection. If UTC=yes the order does not matter.

It seems that the RTC driver has to be loaded before dhclient if UTC=no.

[Alexander van Loon (avanloon)]

Walther Zwart: no, I only have a partition for root and swap.

[Max (max-leopold)]

I just found this bug on my newly installed Dapper (6.06 LTS, with latest updates). My eth0 doesn't get a lease on boot --> no working network. I checked /var/log/messages and it says nothing about DHCP.

When I run
# dhclient eth0
after boot, I get a lease, which works even after two hours (a problem someone had?)

I consider this a very serious bug, if this affects all people, who use DHCP, and use Ubuntu in timezones, which are +-2 UTC (that is the majority of all the timezones).

Hope this gets solved soon.

[Max (max-leopold)]

BTW my timezone is UTC+2 (and UTC+3 in summer).

[Niels Kristian Bech Jensen (nkbjensen)]

Max: Is the rtc module loaded on your system?

[Max (max-leopold)]

@Niels: Yes, rtc-module is loaded.

$ lsmod
Module Size Used by
...
rtc 13492 0
...

I solved the problem temporarily by adding
  /sbin/dhclient eth0
to /etc/rc.local

I'm going on a two week vacation, and can't post any more information about my system & configuration.

[Magnus (koma-lysator)]

I also have this bug.
I'm running dapper 6.06 upgraded from breezy.
I manually do an ifdown/ifup on eth0 on every boot...

[Niels Kristian Bech Jensen (nkbjensen)]

Try adding the line

rtc

to the top of the /etc/modules file to get the module loaded earlier. Does that make any differences?

[Tormod Volden (tormodvolden)]

Note also that rtc is compiled into the 686 kernel, not as a module like for the 386 kernel. So changing to the 686 kernel might help as well.

[Magnus (koma-lysator)]

Adding the line

rtc

to the top of the /etc/modules file didn't do any difference for me.

How come this is broken now, but not in Breezy?

[Alexander van Loon (avanloon)]

I'm worried about the amount of attention this bug receives from the developers. I thought Dapper was supposed to be a long term support release? Martin Pitt's (the assignee for this bug) last reply was two months ago, with the question if there are still people having huge problems with this in Dapper.

Well, Dapper still doesn't display the correct time here, which is a critical problem for me. I would really appreciate it if this could be fixed.

[DarkMageZ (darkmagez)]

this appears to still happen in edgy eft (6.10)

[DarkMageZ (darkmagez)]

i think i've either had too much to drink or i've found a fix. (tho i haven't found regressions yet).
if we were to get rid of dhcp3 and use udhcp (available in universe) then this is fixed ^-^.
udhcpc works in this situation and from my testing... all i think needs to be done is fix ubuntu-minimal's deps to add udhcpc, remove dhcp3 and add a conflict to udhcpc against dhcp3 and then everything will be happy =D

[Alexander van Loon (avanloon)]

I'm currently using the latest Ubuntu 6.10, and the problem seems to be gone for me.

[Alexander van Loon (avanloon)]

It seems this bug is no more, so I took the liberty to close this...

[Martin Pitt (pitti)]

Reopening; I am not convinced at all that this magically fixed itself. Just recently I got a similar report from a friend of mine, so better keep it open.

[DarkMageZ (darkmagez)]

i think some of the magic might result from the changing of daylights savings in some parts of the world. it is the only logical variable i can think of to justify dhcp now working on my system using dhcp3 client...

[Tormod Volden (tormodvolden)]

Yes, see my comment 11 from just after daylight saving started half a year ago...

[Laurent (syrius-no-log)]

this bug is really annoying.
It's not very convenient to change from dynamic ip to static to prevent it to happen.
this BUG IS REPRODUCIBLE WITH using edgy eft (6.10)

[Gerald M (geraldm)]

Any updates? I'm using Edgy server edition and still see the ...dhclients.eth0.leases: Permission Denied message in my logs and the file is never created.

I'm guessing that my periodic connection outages are a result of this.

I experimented by sudo creating the file and giving 666 permissions to it and the file was successfully written to during a reboot and all seemed well. Once i remove write permissions for users then the file is no longer accessible.

From reading above permissions dont seem to be the root cause of the problem though.

[Fredrik (fredrk)]

I still has this problem with 7.04 ...

[Fredrik (fredrk)]

This is a HUGE issue? Why isn't it fixed in 2 releases?

This makes it impossible to run Windows and Ubuntu dual boot ...

[DarkMageZ (darkmagez)]

I propose the removal of dhcp3-client as it appears to be inferior to the windows dhcp client (we can't have that now) and instead have udhcpc (which is available in universe) installed by default instead to resolve this issue which should never happen in software that is released to the public.

Users don't care if it's non-trival to fix... the fact of the matter is that all the adverage user will see is that the network isn't working (as they don't know about such things as dhcp)
If some coder wants to have a look @ the workings of dhcp3-client & udhcpc and figure out why dhcp3-client fails @ life and write up a few patches then that might work as well. but unless some coder is willing do to that then ubuntu should quit shipping dhcp3-client as if it is worthy of being used in home desktop systems.

[Fredrik (fredrk)]

Still no progress on this one?

It forces me to use a router as dhcp-client.

Tyring to remove dhcp3-client will remove other things too so it seems like a bad idea.

[iBix (alaiho)]

"Mar 29 12:55:54 localhost dhclient: can't create /var/lib/dhcp3/dhclient.eth1.leases: Permission denied"

What this means is very straight forward. The dhclient cannot create /var/lib/dhcp3/dhclient.eth1.leases, so you probably need to create one for yor self. For some reason I had a problem with a remote box as here, but touching a file /var/lib/dhcp3/dhclient.eth1.leases seems to have helped... :D

[Fredrik (fredrk)]

I have a /var/lib/dhcp3/dhclient.eth1.leases but it still doesn't work.

[Fredrik (fredrk)]

Any progress on this one?

This is FATAL for me.

If I remove dhcp3-client and replace it with dhcpcd, will anytgin break? Do I need any other config changes to get everything working?

I can't wait for somebody to fix the dhcp3-client...

[Tormod Volden (tormodvolden)]

Are there other people who still have this problem? It seems like it has been fixed for most people (including myself) since the original report.

Can those still affected please give this information:
- software version (release, updates)
- time zone (as in GMT+2)
- ls -la /var/lib/dhcp3
- dhcp-lease-time value from /var/lib/dhcp3/dhclient.eth0.leases or similar
(also dhcp-renewal-time and dhcp-rebinding-time might be of interest)

BTW, I think I only had the problem when my lease (?) time was equal to or shorter than the time zone offset.

[DarkMageZ (darkmagez)]

the problem still exists until the issue mensioned in comment 40 is fixed.

[stefanolodi (slodi)]

I still have this problem.
Currently as a workaround I'm doing ifdown/ifup on eth1 in rc.local.

Some info on my system:

kubuntu 7.04 fully updated
dual boot (the other OS is XP)

ADSL modem on eth1 (3Com PCI 3c905B Cyclone 100baseTx)
local net on eth0 (Intel PRO/100)

> uname -a
Linux ra-sun 2.6.20-15-386 #2 Sun Apr 15 07:34:00 UTC 2007 i686 GNU/Linux

> cat /etc/timezone
Europe/Rome

(i.e. GMT+2)

11:05:38> ls -la /var/lib/dhcp3
total 24
drwxr-xr-x 2 dhcpd dhcpd 4096 2007-05-21 11:04 .
drwxr-xr-x 52 root root 4096 2007-05-16 19:30 ..
-rw-r--r-- 1 dhcp root 0 2007-05-02 01:28 dhclient.ath0.leases
-rw-r--r-- 1 dhcp root 0 2006-07-26 12:28 dhclient.eth0.leases
-rw-r--r-- 1 dhcp root 2005 2007-05-21 11:01 dhclient.eth1.leases
-rw-r--r-- 1 dhcp root 396 2007-05-02 01:28 dhclient.eth2.leases
-rw-r--r-- 1 root root 0 2006-05-31 03:16 dhclient.leases
-rw-r--r-- 1 dhcp root 0 2007-05-02 01:28 dhclient.wlan0.leases
-rw-r--r-- 1 dhcpd dhcpd 1777 2007-05-21 11:04 dhcpd.leases
-rw-r--r-- 1 dhcpd dhcpd 1777 2007-05-21 10:38 dhcpd.leases~

11:08:25> grep dhcp-lease-time /var/lib/dhcp3/dhclient.eth1.leases
  option dhcp-lease-time 300;
  option dhcp-lease-time 300;
  option dhcp-lease-time 300;
  option dhcp-lease-time 300;
  option dhcp-lease-time 300;

11:08:28> grep dhcp-renewal-time /var/lib/dhcp3/dhclient.eth1.leases
<empty output>

11:08:39> grep dhcp-rebinding-time /var/lib/dhcp3/dhclient.eth1.leases
<empty output>

[moret (contato-launchpad)]

This issue is still happening here. Soon after boot eth0 is up but has no IP. If I run "sudo dhclient" the network goes down, up and almost always gets an IP after two or three DHCPDISCOVERs.

Ubuntu 7.04 fully updated
Linux grafite 2.6.20-16-generic #2 SMP Fri Aug 31 00:55:27 UTC 2007 i686 GNU/Linux
America/Sao_Paulo
(GMT-0300)
UTC=no
Cable Modem
Issue non-existent on Windows Dual-Boot

[Erichwtl (erichwtl)]

I too have this error in my /var/log/syslog
I fixed the issue with the following method:

> su -
> touch /var/lib/dhcp3/dhclient.eth0.leases
> chown dhcp /var/lib/dhcp3/dhclient.eth0.leases

I believe the dchpclient didn't have access to create the file in that location, so you needed to create the file, I used the "touch" command, and then gave the file ownership to the user "dhcp" which is trying to write to the file.

[Fredrik (fredrk)]

This should be fixed by now. Does it work in Hardy? If not. his should really be prioritized.

[Fredrik (fredrk)]

Why "Ubuntu Server Team"? It is an desktop issue

[Nicolas Valcarcel (nvalcarcel)]

Actually it is a server issue, Desktop team does not care about network connections, and this bug also affects server users, not only desktop ones.

[Nicolas Valcarcel (nvalcarcel)]

Tested on hardy and it works. Closing this bug. Feel free to reopen if you are still experiencing this bug.

[DarkMageZ (darkmagez)]

i don't recall the dhcp3 component being fixed. the issue "disappeared" around the time network manager was introduced to ubuntu. based on this my theory is that network manager works around this issue.

but this doesn't mean the bug is nessesarily fixed. if my theory is correct then one would just need to remove network manager from the system and the dhcp would be !@#$'ed.

[Fredrik (fredrk)]

As far as I know, the issue is still there. The reason that it began working is that we changed to winter time here in Sweden.

[aceperry (perrychow)]

SOLVED! Or at least it was solved for me. I compared the problem box with another box also running Ubuntu. In the end, what I did was to create the file /var/lib/dhcp3/dhclient.eth0.leases on the problem box. The file was missing and the syslog was complaining that the file couldn't be created, so I created it. Then 'chown dhcp dhclient.eth0.leases' to give it the correct ownership. After that, everything works! Hope that helps someone.