Re: Dhcp client issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux