forum.excito.org

Hi,

My ISP, comhem in Sweden, is giving me an IP address that lasts between 1.5 to 3 hours. The B3 however performs a DHCPREQUEST to my ISP with an interval between 5 minutes to 20 minutes.

I am trying to reduce the disk access on my B3 and would like the B3 to only request a IP address just before it expires. Does anyone know how to modify the B3 to more accurately comply with the DHCP renewal time?

A part of my syslog showing this issue can be found below.

/Morgan

Aug 25 11:39:21 MorganB3 dhclient: DHCPREQUEST on eth0 to 10.125.1.11 port 67
Aug 25 11:39:21 MorganB3 dhclient: DHCPACK from 10.125.1.11
Aug 25 11:39:23 MorganB3 dhclient: bound to 83.251.130.102 -- renewal in 4678 seconds.
Aug 25 11:39:33 MorganB3 dnsmasq[27149]: reading /etc/resolv.conf
Aug 25 11:39:33 MorganB3 dnsmasq[27149]: using nameserver 193.150.193.150#53
Aug 25 11:39:33 MorganB3 dnsmasq[27149]: using nameserver 83.255.245.11#53

Aug 25 11:51:08 MorganB3 dhclient: DHCPREQUEST on eth0 to 10.125.1.11 port 67
Aug 25 11:51:08 MorganB3 dhclient: DHCPACK from 10.125.1.11
Aug 25 11:51:10 MorganB3 dhclient: bound to 83.251.130.102 -- renewal in 5279 seconds.
Aug 25 11:52:05 MorganB3 dnsmasq[27149]: reading /etc/resolv.conf
Aug 25 11:52:05 MorganB3 dnsmasq[27149]: using nameserver 193.150.193.150#53
Aug 25 11:52:05 MorganB3 dnsmasq[27149]: using nameserver 83.255.245.11#53

Aug 25 11:55:09 MorganB3 dhclient: DHCPREQUEST on eth0 to 10.125.1.11 port 67
Aug 25 11:55:09 MorganB3 dhclient: DHCPACK from 10.125.1.11
Aug 25 11:55:11 MorganB3 dhclient: bound to 83.251.130.102 -- renewal in 10010 seconds.
Aug 25 11:55:12 MorganB3 dnsmasq[27149]: reading /etc/resolv.conf
Aug 25 11:55:12 MorganB3 dnsmasq[27149]: using nameserver 193.150.193.150#53
Aug 25 11:55:12 MorganB3 dnsmasq[27149]: using nameserver 83.255.245.11#53

Aug 25 12:16:33 MorganB3 dhclient: DHCPREQUEST on eth0 to 10.125.1.11 port 67
Aug 25 12:16:33 MorganB3 dhclient: DHCPACK from 10.125.1.11
Aug 25 12:16:35 MorganB3 dhclient: bound to 83.251.130.102 -- renewal in 9444 seconds.
Aug 25 12:17:11 MorganB3 dnsmasq[27149]: reading /etc/resolv.conf
Aug 25 12:17:11 MorganB3 dnsmasq[27149]: using nameserver 193.150.193.150#53
Aug 25 12:17:11 MorganB3 dnsmasq[27149]: using nameserver 83.255.245.11#53

Aug 25 12:23:38 MorganB3 dhclient: DHCPREQUEST on eth0 to 10.125.1.11 port 67
Aug 25 12:23:38 MorganB3 dhclient: DHCPACK from 10.125.1.11
Aug 25 12:23:40 MorganB3 dhclient: bound to 83.251.130.102 -- renewal in 9283 seconds.
Aug 25 12:23:48 MorganB3 dnsmasq[27149]: reading /etc/resolv.conf
Aug 25 12:23:48 MorganB3 dnsmasq[27149]: using nameserver 193.150.193.150#53
Aug 25 12:23:48 MorganB3 dnsmasq[27149]: using nameserver 83.255.245.11#53

Are you sure their dhcp lease time really is that long? From my ISP I only get 20 minute leases. Check /var/lib/dhcp/dhclient.eth0.leases just to be sure.

Anyways, it's standard to renew the lease when half the time has passed. On my B3 this works good, it renews the lease every 10th minute. I don't know if this is settable or if it's just the way it works.

/Daniel

Hi Daniel,

Looking at the /var/lib/dhcp/dhclient.eth0.leases the leases are that long. What I however discovered was that the file was corrupt. It contained a lot of strange characters and it did not comply with the syntax described in the manual.

I also noticed that there were five dhclients running and all pointing to the same pid file and lease file. My guess is that it is this that resulted in the corrupt lease file, or did the corrupt leases file result in multiple dhclients?

Anyone that have experienced this?

I cleaned up the lease file and rebooted the B3 and then I only had one dhclient process running.

I will report back if the refresh still have a low value when this have been running for a while.

/Morgan

Hi Daniel and all,

I have now configured the dhclient to request an IP lease for 2 days. This will result in that a possible default value on the server is not used but insted the maximum interval (or a two day interval) is used. For my ISP this requlted in that a lease was granted for 6 hours.

The issue that I discovered then was that the DHCP server my ISP is using do not create a new lease if the current lease is still valid and no need for renewal is required (according to the server).

Since the B3 always requests a new IP lease before the lease is scheduled for renewal (according to the server), every second lease is for about 3 hours and the other ones are for 6 hours.

My thinking was then to trigger the local dhcp client to renew the lease according to the server settings. Adding to the /etc/dhcp/dhclinet.conf file resulted in the my ISP included the renewal and rebinding times.

The issue I have now is however the the local dhclient ignores these values it receives from the server and keeps using the local values (with the too short expire values).

Does anyone know how to get the dhclient to actually use the options it receives in the DHCP ACK message?

I have attached the wireshark log showing the DHCP messages, including the interval between the requests and the content of the DHCP Request and Ack messages)

Best Regards,
Morgan

Hi all,

I have now managed to get the DHCP requests to occur with as long interval as the DHCP server and the specification allows them to happen. Below is a draft wiki text that I would like your feedback on. One needed to modify the dhclient source code to always use as long intervals as possible.

Increase DHCP request interval
Background
The B3 when running in “router, firewall and server” mode asks, in most cases, the ISP (Internet Service Provider) for an IP address using the DHCP protocol and when running in “server only” mode it asks, in most cases, the local DHCP server for an IP address. The responses to the DHCP requests will update a large number of files on the file system and hence wake up the harddisk.

If you would like to have the harddisk in sleep as often as possible the DHCP request intervals should be as long as possible.

Configuration Information
You need to save the command and options that is used to start the DHCP server since we need to restart it when the modifications are complete. Login to the B3 and execute the following commands.
On my B3 this results in the following result

root 698 1 0 Aug27 ? 00:00:00 dhclient -v -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
morgan 29147 639 0 06:08 pts/1 00:00:00 grep dhclient

and it is the first line that we are interested in. 698 is the process id of the dhclient, this we will need later. We will also need the whole command for starting the dhclient.

Packages
To make all the improvements we need to modify the source code for the dhclient and hence we need to fetch it and the packages needed to compile it and verify the changes. Login to the B3 and execute the following commands
Setup
Since a DHCP server in some cases have a default lease time that is significantly shorter than the maximum allowed one we need to explicitly request the DHCP server for a long lease time. This is done by enhancing the dhclient configuration file

Login to the B3 and become the root user
Go to the dhclient configuration folder, make a backup and open the file
Add the following text into the file

interface "eth0" {
send dhcp-lease-time 172800;
}

If there already is a interface “eth0” block defined add the “send dh...” row to the existing block. 172800 is the requested lease time in seconds and corresponds to 48 hours.

To ensure that the client and the server have the same understanding on the renewal and rebinding timers we also add “ dhcp-rebinding-time, dhcp-renewal-time” to the request statement in the same file. On my B3 this results in that the request statement have the following content.

request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name,
netbios-name-servers, netbios-scope,
dhcp-rebinding-time, dhcp-renewal-time;

Modifying the dhclient

For some DHCP servers the above changes is enough and the modification of the dhclient source code is not necessary. Since it depends on your ISPs DHCP settings you could first try without modifying the dhclient and do it later if required by your ISP to get the optimal performance.

First exit the root user and perform the modifications as a “normal” user.
fetch the source code of dhclient in a new folder.
go into the client folder
modify the dhclient.c file so that the function dhcpack have the new syntax when it comes to renewal logic.

Original code

/* Now introduce some randomness to the renewal time: */
if (client->new->renewal <= ((TIME_MAX / 3) - 3))
client->new->renewal = (((client->new->renewal * 3) + 3) / 4) +
(((random() % client->new->renewal) + 3) / 4);

New code

/* Now introduce some randomness to the renewal time: */
if (client->new->renewal <= ((TIME_MAX / 3) - 3))
client->new->renewal = client->new->renewal +
(random() % client->new->renewal) / 10);

This will “move” the randomness from 75-100% of the renewal time to 100-110% of the renewal time, e.g. we do not ask for a new IP address until the server renewal time have expired. The reason for this is that some DHCP servers to not update the renewal time if requests comes before it have expired.

Now we need to configure the build environment and build the binaries
To install the new client we simply copy it to the correct location (as root user)
Restart dhclient

To stop the dhclient we must know its process id. As seen above my process id was 698, yours will be different. It is vital that you use the correct process id, if you use a wrong one you might in worst case stop a vital process on B3 and be forced to pull the power cord (which is not good) to get it usable again. To stop the dhclient execute the command below and replace NNN with the process id of dhclient.
Now we need to start the process again. To allow the process to continue to live after we have closed the shell we used to start it we must use the “nohup” command to start it and we should also divert output to /dev/null to avoid having a file with the output of the command. NOTE: If your dhclient have other options than in this example it is vital that you start dhclient with your parameters and not the ones below.
Do not forget “nohup” and “>/dev/null”

Test

To test the updates we capture the relevant traffic on the eth0 interface. This log can be viewed later with the Wireshark application (Available for Win, Mac, Ubuntu, …)
This command will capture all traffic that have a source or destination port of 67, which all DHCP traffic have.

The tcpdump command should be running for at least 24 hours so that you get a capture of an update. To get a log from the initial DHCP request the tcpdump command could be started in a separate command window before the dhclient is restarted.

When 24 hours have passed stop the tcpdump application by pressing Ctrl-C. The DHCP.pcap file can now be opened by Wireshark. To filter out DHCP broadcast traffic add a filter in wireshark that have the following syntax ip.addr=<your eth0 IP address>

Your eth0 IP address can be found by the following commands
In the DHCP ACK packets you can expand the “bootstrap protocol” and the option “IP Address Lease Time” will tell you the time your ISP is allowing you to lease an IP address. If everything is working as it should this time should be the same in all DHCP ACK packets. If you have not updated the dhclient the value can be smaller in every second packet. If this is the case and you would like to squeeze the harddisk sleep times you need to modify the dhclient application as described above.

NOTE: It is a good idea to perform the test before any changes so that you know the initial status of you DHCP traffic. Maybe you already have really good performance, e.g. long intervals.

eramoli wrote:Below is a draft wiki text that I would like your feedback on.

Excellent work! I have one question though. My /etc/dhcp/dhclient.conf is just a symbolic link to /etc/bubba/dhclient.conf which is owned by bubba-backend package. Won't changes to it be lost next time bubba-backend is updated?

/Daniel

Hi Daniel,

Hmm, on my B3 there is no link to that file. Maybe I by misstake have removed the link and rcreated the file again. Need to pay more attention.

And yes, this fix, as many other will have to be redone if/when one updates the system. I will add this information to the wiki. Thanks for pointing this out.

Best Regards,
Morgan

Hi,

The wiki is now updated, http://wiki.excito.org/wiki/index.php/R ... sts_to_ISP

/Morgan