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?
>
> AFAIK, usually the client broadcasts a dhcp request packet to the LAN, and the
> dhcp server catches this packet (which already has a MAC address of the source
> inside), sets up a lease for this MAC and answers back with an IP and other
> data. Why do you need to explicitly send a dhcp-client-identifier?
>
> Are you trying to get a lease for some other value of MAC, not the one that
> eth card uses to actually send the request? (You are not trying to hack into
> someone's MAC-filtered network or something, right? :-) )
>
> Or is there something else going on?
>
> If you are trying to achieve some highly non-default setup, it would be a good
> idea to tell us as much as possible about what is customized and why.
>
> HTH, :-)
> Marko
>
There are a variety of conditions where you can't rely on the MAC source address being correct.
One is with broken DOCSIS Ethernet-to-CATV bridges that try to be secure and prevent spoofing.
Another is when you've got routers (such as Cisco IOS routers) that use DHCP relaying (i.e. ip helper-address x.x.x.x on an "interface" in IOS).
Another is in a Wifi environment when you're using a Win7 PC with a bridge NDIS adapter set up over an Ethernet and Wifi adapter. The PC will always forward packets with its own source address, because doing promiscuous mode at 100Mb/s or 1Gb/s is too expensive (and you don't have the Content-Addressable-Memory to do fast cache lookups for Spanning Tree).
There are other scenarios as well.
The bottom line is that you can't trust the MAC address, especially when the client and server aren't physically adjacent.
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.
Quoting RFC 1533
======
9.12. Client-identifier
This option is used by DHCP clients to specify their unique
identifier. DHCP servers use this value to index their database of
address bindings. This value is expected to be unique for all
clients in an administrative domain.
Identifiers consist of a type-value pair, similar to the
It is expected that this field will typically contain a hardware type
and hardware address, but this is not required. Current legal values
for hardware types are defined in [22].
The code for this option is 61, and its minimum length is 2.
Code Len Type Client-Identifier
+-----+-----+-----+-----+-----+---
| 61 | n | t1 | i1 | i2 | ...
+-----+-----+-----+-----+-----+---
======
t1 is the same as the bootp htype (i.e. 1 for Ethernet).
i1..i6 as the same as bootp chaddr field (i.e. MAC address).
--
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
