Hi Nick - I'm also on VirginMedia and noticed a sudden rise. It seems to come and go

dhclient: DHCPREQUEST on eth1 to 62.254.35.12 port 67

...eventually followed by

dhclient: DHCPACK from 10.245.236.1

dhclient: bound to 80.x.x.x -- renewal in 242773 seconds.



[root@server ~]# nslookup 62.254.35.12

Server:         127.0.0.1

Address:        127.0.0.1#53



Non-authoritative answer:

12.35.254.62.in-addr.arpa       name = lang-dhcp-1-2b.server.virginmedia.net.

It appears to be trying to renew it's lease from the VM DHCP server but not getting a return DHCPPACK

You can have a look at the contents of your lease here:-
cat /var/lib/dhclient/dhclient-eth1.leases

Thanks.

I'd had a look in /var/lib/dhclient/dhclient-eth0.leases (and all the other copies from when I'd changed the interfaces round). I have not tried to learn to read the file, but the leases seemed to be for a large number so it was not a rapid expiry of leases. The only thing which struck me as a bit odd was that the file had two sets of lease data, but then again, all the old files were the same.

I'll pop over to the VM forums and see what they have to say. Last time they took days to respond ......

I've been digging and reading the man pages. Apparently the default timeout for dhclient to decide it is not getting a reply is 60s. The default retry time is 5min. dhclient is called from the ifup script with virtually no command line switches (none that are relevant). There is no dhclient.conf, so dhclient should be using the defaults. If they have not been changed at compile time, why am I seeing multiple messages in a minute (or at least lots of messages like "last message repeated 3 times")?

I've also posted in the VM forums.

I'm not getting anywhere with this one. I've tried:
Power cycling the CM
Adding an empty dhclient.conf
Populating a dhclient.conf
Rebooting the server

And it always fails after a day or two.

I have managed to slow the request rate by configuring the dhclient.conf file, but I just don't see any DHCPACK's

@Tim or anyone on VM cable:
Is it correct that in my /var/lib/dhclient/dhclient-eth0.leases file the dhcp-server-identifier is 62.253.131.61 and not the private IP of the server (10.72.136.1)?

Hi Nick, i've never got to the bottom of this one either. I have the same here, the dhcp-server-identifier is different from IP in the returning DHCP-PACK. I've also noticed that sometimes it won't offer until dnsmasq resorts to the broadcast IP. The problem seems to come and go, for many months it was fine - but it seems to have resurfaced again

...snip lots of DHCPREQUESTs...

Jan 19 13:31:51 starlane dhclient: DHCPREQUEST on eth1 to 62.254.35.12 port 67

Jan 19 13:34:57 starlane dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67

Jan 19 13:34:57 starlane dhclient: DHCPACK from 10.245.236.1

Confused :S

I had not noticed the broadcast DHCPREQUEST only succeeding when it went to the broadcast address. It looks like mine is the same but I don't have enough logs to check. Perhaps I'll just put it down to VM, but it fills my logs with rubbish.

It appears you can start dhclient with the -q flag to quieten it down...but doesn't help fix the problem! there must also be a setting for maximum number of attempts to renew from an existing DHCP record. It appears that when I do finally get a DHCPACK, the renewal period is only 2 to 3 days (200,000 to 300,000 seconds)...which is pretty short. Dhclient then persues renewing the lease every minute or so from this time forward until it eventually tries the broadcast address

The trouble is that each time you try a change you have to wait until the renew time before the problem recurs and that is about a day and a half for me. I am currently trying this dhclient.conf:

timeout 60 ;

retry 300 ;

select-timeout 0 ;

backoff-cutoff 60 ;

I am trying to up the retry parameter but I can't work out from the docs if it is in minutes or seconds. It says the default is 5 minutes but I'm not sure I believe that since, without a dhclient.conf, I get multiple retries a minute.

Hmm i'll have a go here too as I seem to be in the renewal period. Might have more luck by increasing the "initial-interval" time?
http://linux.die.net/man/5/dhclient.conf

I can't (easily) see my system from work, but if you look in /var/lib/dhclient/dhclient-eth1.leases you'll see three lines at the bottom of each section the first of which is something like "retry date/time". For some reason there are two similar sections for my DHCP server, but when the first retry time is hit that is when the errors start. Increasing the initial-interval time looks promising but it will be relatively difficult to understand the effect as it is multiplied by a random number and then is capped by the backoff-cutoff.

If we are both hitting this I would suspect a VirginMedia problem, but I've had nothing useful back from them.

Yeah I have

  renew 1 2011/1/31 07:56:54;

  rebind 4 2011/2/3 15:34:07;

  expire 5 2011/2/4 12:21:02;

Apparently from the first line it will attempt to renew the IP using the DHCP Server identifier, until the rebind time, which it will resort to using any DHCP server (i.e the broadbast address).

From my logs here I only ever get an IP once it gets to the rebind stage...so I have 3days of logs with a message every minute or so during the renew cycle period with it attempting to connect to the Virgin IP!

If I kill dhclient, and start it again via (ifup eth1) it will use the broadcast address straight away and get a reply from the 10.x.x.x network...

It appears that you could call dhclient with the -B flag to always use the broadcast address, but i've got to wait a day or so until I know it works

       The -B option instructs dhclient to set the bootp broadcast flag in request packets, so that servers will always broad-

       cast  replies.  This is equivalent to specifying the âbootp-broadcast-alwaysâ option in dhclient.conf, and has the same

       effect as specifying âalways-broadcastâ in the serverâs dhcpd.conf.  This option is provided as a Red Hat extension  to

       enable dhclient to work on IBM zSeries z/OS Linux guests.

I've also considered adding an iptables block rule to the output chain so that it can't attempt to try the dhcp-server-identifier IP and resort to the broadcast address....but it's a hack

The issue here appears to be that the dhcp-server indentifier offered by the Virgin lease is wrong, or at least isn't responding to DHCP requests. We could investigate other means of redirecting the logs but that doesn't fix the "problem". Albeit everything still works, it just filling our logs with rubbish

I was watching my system to see when it would renew correctly and it sorted itself out an hour ago when it hit the rebind time in the second section of dhclient-eth0.leases - and not the first which was earlier. I've now grown a third section so I don't understand how this file is working although the third section probably belongs to the latest lease so it will go wrong again on Sunday at 04:31 and fix itself on Tuesday at 01:57.

I was restarting my eth0 with a mini script otherwise I forget to restart snort which dies when eth0 is taken down.

I believe my "timeout 60" bit in my /etc/dhclient.conf is slowing down the frequency of the errors, but I've stopped testing for the moment to see how the renew cycle behaves.

I'm not sure blocking the output to the dhcp-server-identifier IP will help as you still not get a response, but for a different reason.

I'll have a hunt round VirginMedia's site to see if the problem can be reported other than via their forum which produced no result.

[edit]
It looks like the -B switch can be replaced with the bootp-broadcast-always; switch in the dhclient.conf file. That way you don't have to hack the ifup script which ClearOS could overwrite
[/edit]

I've found to help with testing adding the line "superseded dhcp-renewal-time 30;" forces it to start renewing the IP early saves waiting 50% of the lease time for it to start on it's own

You can then kill dhclient, and reload it by running "ifup ethX". This saves taking the whole interface down and back up again

I've found you can "fix" this by either adding

supersede dhcp-server-identifier 255.255.255.255;

or

supersede dhcp-renewal-time 500000;

which is approx the same time as the rebind period, so it will only have a couple of hours until it tries the broadcase address

The former I think is the neater solution as i'm not sure what happens when VM offer a lease time smaller than the custom renewal time - although they're both hacks

Edit: I didn't have much luck with bootp-broadcast-always

I've managed to find a way to contact VM not by their call center - go through the troubleshooter for no dial-tone and you end up with a web form! The forum is only self help.

Like you I got nowhere with bootp-broadcast-always. I tried your 255.255.255.255 solution and it works. It also works if you put in the IP of your responding dhcp server (mine is 10.72.136.1) which I am running with for the moment. Like you I am reluctant to override the renewal time.

@Tim,

A thread from the past which may avoid a headache. At lunchtime today I lost the internet and I knew VM were doing work in the area so I thought it was down to them. I gave them a ring this evening and they asked me to do a direct connection to the CM. "Ha Ha" I thought, usual call centre stuff who don't acknowledge anything but Windoze. Unfortunately it worked! A lot of playing about reconfiguring the ethernet cards on the server to make my spare one external and nothing. Then I remembered my hack:

supersede dhcp-server-identifier 255.255.255.255;

Removed that and hey presto, up came the connection.

So Tim, just in case you went down this route, if VM do something in your area to rework for the increased speeds, watch out.

[edit]
And the CM then only connected at 10Mbps, half duplex which was fixed with ethtool.
[/edit]