|
|
||
Dual Booting with the DHCPC Daemon© Copyright Darrell Anderson. Many people use both Windows and Slackware and many of those people connect to the internet with a broadband connection using DHCP (Dynamic Host Configuration Protocol). Configuring the DHCP client in Windows is a straightforward process of a couple of mouse clicks. Configuring DHCP in Slackware varies, but most often a few modifications in a text-based configuration file is the means to the end. With either operating system most people experience little or no pain in connecting to the web in this manner. Something interesting happens, however, when trying to use DHCP on a dual boot computer using both Windows and Slackware. Rebooting a computer in Windows often will find the system reconnecting to the previous IP address, yet this is not the immediate case with Slackware, particularly if using the dhcpc daemon. Try as you might, using the dhcpcd likely will result in a different IP address every time. Why does Windows consistently connect to the previous IP address and dhcpcd does not? The answer lies in the way Windows and dhcpcd is configured. Windows systems do not issue a release packet when exiting or shutting down. This tends to leave the DHCP lease open. According to the DHC protocol, however, there is no requirement to issue such a packet. Probably for the very reason being discussed—so people can reboot a box and yet maintain their DHCP lease upon restarting. Therefore there is nothing inherently incorrect with the Windows DHCP client. Using dhcpcd in Slackware, on the other hand, means the DHCP client does issue a release packet upon shutting down, which is why upon rebooting or restarting a Slackware box usually is issued a new IP address. The underlying Slackware script is not configured correctly. The solution is straightforward. Revise the /etc/rc.d/rc.inet1 and /etc/rc.d/rc.6 scripts such that the dhcpcd is sent a SIGTERM signal rather than a SIGHUP signal. With the dhcpcd, a SIGHUP signal forces the daemon to send a release packet. In Windows the MAC address can be “spoofed,” but the dhcpcd easily allows “spoofing” both the MAC address and host name without rebooting. If using a dual boot box as a standalone machine, users can maintain the same host name for each operating system. If used in a network environment, however, using unique host names is a better policy. For example, if in Windows you have assigned a host name of Tweedledee, when using Slackware you might assign a host name of Tweedledum. To truly convince the DHCP server that you have two different boxes, however, requires unique MAC addresses as well. Therefore the better method of convincing a DHCP server that a dual boot box is two different machines is to modify or “spoof” the MAC address. Convincing the DHCP server that two different boxes exist is the first step toward renegotiating the same IP address when rebooting between operating systems. Spoofing the MAC address requires knowing the actual MAC address and then editing /etc/rc.d/rc.inet1.conf. At a command prompt type ifconfig -a and note the MAC address for the affected network card (if using more than one card). The MAC address is identified on the first line with the label HWaddr. In Windows use the ipconfig /all command. Next open rc.inet1.conf with a text editor and for the appropriate network card section, eth0, eth1, etc., add the following variable: HWADDR[0]="" Then insert a MAC address that is different from the actual MAC address. For example: HWADDR[0]="00:04:6A:89:21:D6" At this point you will convince the DHCP server that you are using two different boxes. To add an additional element of privacy, modify the host name that dhcpcd will use with the DHCP server: DHCP_HOSTNAME[0]="MadHatter" Adding this latter parameter does not modify the actual host name of the box used in your local network. This parameter is used only by the dhcpc daemon, but the DHCP server then will not know the actual host name of your box. At this point you have only convinced the DHCP server that you are using two different boxes. You have not resolved the problem of configuring the dhcpc daemon to request the previously used IP address or to maintain the DHCP lease. To do that you must revise the rc.inet1 and rc.6 scripts. With a text editor, open both scripts and notice that upon shutting down, the scripts are hard-coded to pass the -k parameter. Reading the man page for the dhcpcd reveals that the -k parameter sends a SIGHUP signal, which in turn instructs dhcpcd to release the DHCP lease and delete the dhcpcd cache that preserves that information. In other words, the stock Slackware always releases the DHCP lease, which is a primary reason for seldom obtaining the previous IP address from the DHCP server. To successfully renegotiate the same IP address and not release the DHCP lease requires that the dhcpc daemon no longer receive that -k parameter option. A challenge, however, is that strangely, very strangely, there is no option parameter to pass to the dhcpc daemon to perform a SIGTERM shutdown. The dhcpcd is designed only to understand the -k parameter, which performs a SIGHUP shutdown, which sends the release packet to terminate the lease. Therefore, you have to revise the scripts to perform a kill -SIGTERM (kill -15) rather than simply pass a parameter option to dhcpcd. The stock rc.inet1 script looks like this: if [ "${USE_DHCP[$i]}" = "yes" ]; then The stock rc.6 script looks like this: if /bin/ls /etc/dhcpc/*.pid 1> /dev/null 2> /dev/null ; then Merely deleting the -k parameter will have no effect on either script. The dhcpcd must receive a SIGTERM shutdown signal and the only way to accomplish that is with the kill command. Additionally, whether the -k parameter is passed to the dhcpcd should be a configurable end-user option. The best way to provide that option is to add a new parameter to rc.inet1.conf. Modifying the system in this manner allows shutting down dhcpcd in both manners yet requires only modifying one file rather than two. Doing this also means sourcing the rc.inet1.conf file in rc.6. For the affected network card, add the following variable: DHCP_RELEASE[0]="" Later, if you actually want to restore the stock behavior of the dhcpcd shutdown, modify the variable to “yes”: DHCP_RELEASE[0]="yes" The latter option will cause the two modified rc.d scripts to send the -k parameter to the dhcpcd. The former option will not. A revised rc.inet1 script would look something like this: if [ "${USE_DHCP[$i]}" = "yes" ]; then A revised rc.6 script would look something like this: source /etc/rc.d/rc.inet1.conf Restart your network services or reboot your Slackware box. From now on, like Windows, as long as your DHCP lease does not expire (and your ISP does not play games with bumping leases), your Slackware box should be able to maintain the same IP address. If you use the same MAC address for both operating systems, you then also will obtain the same IP address with either system. Note: Spoofing the MAC address in Windows is possible. Surf the web for details. With my NT4 operating system, in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services registry hive, in the Parameters section for the affected network card, I had to add the string key value NetworkAddress. I then entered the MAC address as a 12-digit string, using no colons, dashes, etc. With NT4 I have to reboot to make the change effective. Finis. |
||