Dhcp client issue
Marko Vojinovic
vvmarko at gmail.com
Fri Jan 29 02:00:10 UTC 2010
On Friday 29 January 2010 00:40:27 Philip A. Prindeville wrote:
> On 01/28/2010 04:32 PM, Marko Vojinovic wrote:
> > On Thursday 28 January 2010 17:30:23 Philip A. Prindeville wrote:
> >> On 01/28/2010 12:40 AM, Ed Greshko wrote:
> >>> Philip A. Prindeville wrote:
> >>>> My dhcp server is expecting my client (the FC12 box) to send a request
> >>>> with:
> >>>>
> >>>> option dhcp-client-identifier 01:XX:XX:XX:XX:XX
> >>>>
> >>>> where XX:XX:XX:XX:XX:XX is the MAC address, and 01 is the type-code
> >>>> for Ethernet.
> >>>>
> >>>> Unfortunately, by default Fedora omits this option in the request.
> >>>>
> >>>> Is there an easy way to do this? Like:
> >>>>
> >>>> interface "eth0" {
> >>>> send dhcp-client-identifier hardware;
> >>>> }
> >
> > Dhclient settings aside, I'm afraid I don't understand the original
> > issue. Would you care to elaborate why is the server expecting some
> > non-default behavior? What is the error message on the server side?
>
> There are a variety of conditions where you can't rely on the MAC source
> address being correct.
[snip]
> The bottom line is that you can't trust the MAC address, especially when
> the client and server aren't physically adjacent.
Well, AFAIK both dhcp-client-identifier and MAC address are usually assumed to
be equally unique (at least theoretically), for example when matching to a
host declaration on the server side. So I guess they are basically equally
trusted (while equally spoofable... :-) ).
> As for "highly non-default", actually *MOST* DHCP clients (HP printers,
> iPhones, Windows, Symbian phones, etc) ALL use a client-id with
> 01:xx:xx:xx:xx:xx:xx.
>
> I was surprised to see that Linux/BSD *doesn't* do this.
Maybe this is normal behavior for such systems, but for a typical *computer*
network I've never seen this to be a requirement. Besides, the dhcpd server
can easily be configured to prefer dhcp-client-identifier and fallback to MAC if
the identifier isn't available. At least in Linux version of dhcpd. :-)
Philosophy aside, if your server forces you to use identifiers rather than
MACs, then you can try this syntax in dhclient.conf:
send dhcp-client-identifier = hardware;
I haven't tried it (and I really can't set up a virtual dhcpd just to try it
out), but man dhcp-options says the following:
<quote>
SETTING OPTION VALUES USING EXPRESSIONS
Sometimes it’s helpful to be able to set the value of a DHCP option
based on some value that the client has sent. To do this, you can use
expression evaluation. The dhcp-eval(5) manual page describes how to write
expressions. To assign the result of an evaluation to an option, define the
option as follows:
option my-option = expression ;
For example:
option hostname = binary-to-ascii (16, 8, "-", substring (hardware, 1, 6));
</quote>
Now, I know these instructions are for setting options on the server side, but
the same syntax just might work also in the client context. Not sure, but
worth a try. ;-)
OTOH, man dhcp-eval says
<quote>
hardware
The hardware operator returns a data string whose first element is the type of
network interface indicated in packet being considered, and whose...
</quote>
Note the "packet being considered" phrase. What you are trying to do is to
have the "hardware" keyword evaluate to the MAC of your network card, which
doesn't involve any particular packet, but rather local hardware data. So in
this sense this whole approach just might not work at all, design-wise. If
that is the case, I can only suggest to create a bash script which will read
up the actual MAC from, say, output of ifconfig and modify each particular
dhclient.conf to hard-code this MAC at the appropriate place. Then run this
script on your whole farm of machines. This is just a workaround that avoids
having yourself to manually configure dhclient for each particular machine, but
it's better than nothing. ;-) The syntax
send dhcp-client-identifier 01:aa:bb:cc:dd:ee:ff;
should definitely work, so this kind of workaround should also definitely work.
HTH, :-)
Marko
More information about the users
mailing list