Let's say I've got a Windows box on a LAN and it's set to use DHCP.

The DHCP server has a long lease time and a rather large address space (the netmask is 255.255.0.0). So when I do IPCONFIG /RELEASE followed by IPCONFIG /RENEW, this box always gets the same IP address as before.

Suppose, for whatever reason, I want this box to remain set for DHCP, yet I want it to request a new address from the DHCP server (i.e., I want the resulting address to be a different one than the one it keeps granting me right now).

Is there an easy way I can force this to happen on the client's end without needing to touch the DHCP server itself?

Fake the MAC address before connecting?

Nifty idea. And it would work for what I want to do for this immediate thing that I need it for. That will be my work-around for now.

A more general curiosity question for the future, then, would be, is there some kind of command I can type at the shell to do the thing I wanted? Some way to tell the DHCP server, "can I please have a different IP address?"

No. Its not part of the spec. The best you can do is release your DHCP lease and ask for another one whilst hoping its different.

Okay, understood. Thanks!

DHCPDECLINE. Quite how you fake it, I don't know.

The side effect of doing a DHCPDECLINE is what Tony wants but there are other parts to it which won't be good.



He'll just progressively use up more and more addresses. Potentially also annoying whoever runs the DHCP server if it does log a warning or error.

Instructions for changing the MAC address in the registry here

SMAC command line

Thanks, Andrew. I've done MAC address spoofing before, so I know how to do that part, and I was aware of SMAC. But that's a good reference and link to have, right here in this thread discussing the topic. Very useful if anyone else is ever curious how to do it.

One thing that can help, is to remove or change the client's record of the old IP address.

Normally, the client saves the DHCP address (or "lease") granted, and requests the exact same address on subsequent registrations.

If you can find the file where this is stored and change it, then the client should request whatever you put there in place of the original value.

Whether or not the server honours the request is another matter, but that would depend upon the individual server.

I thought that was handled on the DHCP server side; i.e., it was the DHCP server that did the remembering, not the client. Am I wrong?

Both sides can usefully implement remembering. The protocol allows the client to say either "I've no idea what my address is, give me any free one" or "I had this particular address last time, is it still available?". In the first case, the server will probably remember what address it last gave that MAC, and hand it back again. In the second case, it's up to the server what to do, but it's at least reasonable that it'll confirm the suggested address if it's available, whether or not it matches the last one it handed out to that MAC.

If the client were Linux, I'd suggest setting up an IP alias of the interface, which would be guaranteed to get a new address, then downing the non-aliased version -- but I've no idea whether Windows has those same features.

Peter

Exactly.

On my Linux client notebook here, the file is called /var/lib/dhcp3/dhclient.eth0.leases, and contains this data:

Code:

lease {
  interface "eth0";
  fixed-address 10.0.0.6;
  option subnet-mask 255.255.255.0;
  option time-offset -18000;
  option dhcp-lease-time 86400;
  option routers 10.0.0.2;
  option dhcp-message-type 5;
  option dhcp-server-identifier 10.0.0.2;
  option domain-name-servers 10.0.0.2;
  option broadcast-address 10.0.0.255;
  option host-name "corey";
  option netbios-name-servers 10.0.0.2;
  option domain-name "localnet.";
  renew 3 2008/8/6 23:56:34;
  rebind 4 2008/8/7 11:15:43;
  expire 4 2008/8/7 14:15:43;
}

Using Wireshark (aka. "Ethereal"), I can monitor the entire DHCP exchange, and see the client first request the original 10.0.0.6 address, and get ACK'd by the server for it.

Cheers

For my WinXP VMware guest, the data appears to be stuffed into that massive blight called the "registry", in several places including:
My Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters


Cheers

That isn't going to fly on Windows, you can have the equivalent of aliases, but only one DHCP setup per interface and the rest static IPs.

Thinking about it, can it really work the way on Linux you claim it does ? The DHCP server only has the MAC address to identify the interface by, so surely adding DHCP'd alias is just going to get you the same IP address that has already been allocated to the interface by the server ?

I suppose one would also have to change the MAC address then, before bringing up the new alias.

Haven't tried it, though .. dunno if dhcp methods work on aliases or not.

Cheers

In theory the DHCP server is meant to identify clients by the "client identifier" field, not by MAC address. But now you mention it, I've never tried DHCPing off aliased interfaces, so I don't actually know whether it works in practice with any particular server. (Although the recently-discovered bug in Receiver Edition, where using the same xid and ciaddr from different MAC addresses makes the server think it's just one client, suggests that it sort-of might.)

Peter

Do typical DHCP client implementations actually attempt to use a unique client identifier value or do they just stick the MAC address in there ?

On thinking about it a bit more, that's an unwarranted slur on the server. The server is doing the Right Thing, and the client is misinterpreting someone else's replies as its own because it omits to check the ciaddr. Still my fault

Peter

Speaking of which -- the regular empeg load (v3alpha11, at least) has this exact same problem.

I cannot use DHCP for my empegs when more than one of them is powered on, as otherwise they *all* end up with identical IP addresses.

Cheers

Presumably you could fix it hijack by intercepting the DHCP packets and putting in a properly unique client id ?

I think the bug is that the client doesn't check the chaddr in replies, only the xid. If so, the Hijack fix might be just to drop on the floor incoming DHCP packets whose chaddr doesn't match our MAC. (Though I'm a bit doubtful about that, as, if such frames are unicast to the right MAC, how come anyone else's IP stack even receives them? Or are they broadcast?)

Probably, Mark, stage one of the process is going to be using Hijack or Wireshark to capture the DHCP traffic and see at what point it all goes wrong.

And it's embarrassing but also a teensy bit surprising that the normal v3a11 gets it wrong -- I'd have thought that at one stage we had a whole office-full of v3a11 players DHCPing at the same time.

Peter

I didn't notice it here until I actually had HTTP connections going to two empegs simultaneously.

Cheers

I'm posting a wireshark trace in the original bug thread.