Re: Dhcp client issue

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

 



On 01/28/2010 06:00 PM, Marko Vojinovic wrote:
> 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... :-) ).

Not really.  A bridge can and sometimes does replace the MAC address with its own.

It will not scribble on the inside of the packet (the IP payload), however.


>> 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;

Damnation!  Thank you.  I was missing the '='.

It wasn't clear from the documentation that the 'send' required the '=' as well.

> 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. ;-)

Fortunately the share a lot of common code.


> 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.

Right, but I didn't want to hand edit hundreds of machines.


> HTH, :-)
> Marko
> 


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


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux