Ever run a long operation in a terminal on Linux? You don't want to have to keep checking back to see if the operation has completed, but you don't want to waste time letting the session sit idle after completion. To make Linux ring the terminal bell, thus alerting you when your job is complete, you can use the echo command.

echo -e "\a"

In context, you would most likely do something like this:

tar cvj /homes.tbz /home && echo -e "\a"

So you have a network merrily rolling along with a Linux Server providing DNS, DHCP, Samba File Sharing, OpenVPN Access, BackupPC for client backups, Asterisk providing VoIP Services, maybe a Joomla based Intranet. Everyone is happy . . . until . . . someone brings in their shiny new Laptop running Windows Vista. Try as you might, you can't get Vista to pick up an IP Address from your DHCP Server. You could set a static IP address, but remember, this is a laptop and it needs to work from home and the local coffee shop. Where do you go from here?

The first troubleshooting step was to google it and you found out about the Vista DHCP Broadcast Flag change. You have made the registry hacks and nothing has helped. Nevermind the fact that Vista SP1 enables the Broadcast Flag toggle automatically, it still doesn't work.

So, you stop your dhcp server and run it in foreground debugging mode:

# /etc/init.d/dhcpd stop
# dhcpd -f -d

You watch as Vista does a DHCP Discover, your server provides a DHCPOffer and Vista never accepts the offer. What is wrong?

Turns out that while rewriting a perfectly good TCP/IP stack borrowed from BSD, Microsoft made the DHCP Client extra-picky. The first thing they did was to require the Broadcast flag, which the RFCs state SHOULD be supported, not MUST be supported. The next thing they did was to require the DHCPOffer flags to be set just so, in the name of security, of course.

So, why are we running foul of Vista, and more importantly, how can we appease it?

Our first mistake it seems was running Linux instead of Windows Server. Of course we have a stable and productive machine happily providing services for just the cost of the hardware. All would be well if we plunked down the coin for the Windows Server Licenses, applied our monthly patches, installed AntiVirus Software, etc.

But no, we can make it work. Lets take a look at our dhcpd.conf file:

#
# Default LTSP dhcpd.conf config file.
#
server-identifier           localhost;
ignore client-updates;

authoritative;

subnet 10.1.1.0 netmask 255.255.255.0 {
    range 10.1.1.200 10.1.1.252;
    option broadcast-address 10.1.1.255;
    option routers 10.1.1.1;
    option domain-name "example.com";
    option domain-name-servers 10.1.1.1;
    option netbios-name-servers 10.1.1.1;
    option subnet-mask 255.255.255.0;
}

As you can see from the comments, this dhcpd.conf file was based on the LTSP configuration that ships with Ubuntu. By simply moving a few things around, we can get our server to send out packets that are not too hot, not too cold and vista will happily accept them:

option domain-name "example.com";
option domain-name-servers 10.1.1.1;
option netbios-name-servers 10.1.1.1;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;

subnet 10.1.1.0 netmask 255.255.255.0 {
    range 10.1.1.200 10.1.1.252;
    option broadcast-address 10.1.1.255;
    option routers 10.1.1.1;
}

Fire up the dhcp server using the new setup:

# dhcpd -f -d

And thats it. By moving domain-name, domain-name-servers, netbios-name-servers and subnet-mask out of the subnet section and into the global section, we have a configuration that works with Vista. What if you have multiple subnet sections that need different values? I'll leave that as an exercise for the reader. Just don't forget to restart the dhcp service:

# /etc/init.d/dhcpd restart