Bug 560361 - Dhclient doesn't use client-identifier; may cause issues in certain bridged environments
Summary: Dhclient doesn't use client-identifier; may cause issues in certain bridged e...
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp
Version: 19
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Jiri Popelka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
: 1064029 1065675 (view as bug list)
Depends On:
Blocks: 1100485
TreeView+ depends on / blocked
 
Reported: 2010-01-31 08:45 UTC by Philip Prindeville
Modified: 2015-12-23 10:09 UTC (History)
14 users (show)

(edit)
Clone Of:
: 1109860 (view as bug list)
(edit)
Last Closed: 2014-06-16 13:50:10 UTC


Attachments (Terms of Use)

Description Philip Prindeville 2010-01-31 08:45:56 UTC
Description of problem:

There are certain layer 2-1/2 bridges that are known to scribble on DHCP packets, in particular replacing the source MAC address with their own.  This is common in--but not limited to--Wifi, Docsis, and ADSL bridged environments.

To disambiguate multiple clients behind the same bridge, the client-identifier (which won't be modified) should be used instead.

Version-Release number of selected component (if applicable):

4.1.0p1-17

How reproducible:

Put a Fedora workstation on Ethernet behind a Windows 7 workstation, with the latter's Ethernet and Wifi connections joined in an NDIS miniport bridge.

The bridge will send forwarded Ethernet packets with the original MAC source address having been replaced with the Win7 bridge's own Wifi MAC address.

This will cause the Fedora workstation to not receive the DHCP responses.

Steps to Reproduce:
1. As above.
2.
3.
  
Actual results:

Dhclient never receives response.

Expected results:

Dhclient receives response (lease).

Additional info:

Comment 1 Philip Prindeville 2010-01-31 08:48:59 UTC
Recommend the package (or an optional subpackage) include the following as the file /etc/dhcp/dhclient.conf:

# required in environments where a bridge might be clobbering the forwarded
# packet's MAC address (common in Wifi, Docsis, or ADSL bridging scenarios)
send dhcp-client-identifier = hardware;

Comment 2 Jiri Popelka 2010-01-31 20:39:28 UTC
At this moment I think this is doable (it shouldn't break anything).
Although probably the best solution is to send client identifier as defined in RFC 4361.

Additional info:
see `man 5 dhcp-options` for setting option values using expressions

see `man 5 dhcp-eval` for hardware data expression

section 2 of RFC 2131, page 9 says:
... the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field ...

section 4.2 of RFC 2131, page 26 says:
If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client. It is crucial for a DHCP client to use an identifier unique within the subnet to which the client is attached in the 'client identifier' option.

section 9.14 of RFC 2132 says:
The client identifier MAY consist of type-value pairs similar to the   'htype'/'chaddr' fields. For instance, it MAY consist of a hardware type and hardware address.
For correct identification of clients, each client's client-identifier MUST be unique among the client-identifiers used on the subnet to which the client is attached. Vendors and system administrators are responsible for choosing client-identifiers that meet this requirement for uniqueness.

section 5 of RFC 4361 says:
In order to satisfy all but the last of these requirements, we need to construct a DHCPv4 client identifier out of two parts. One part must be unique to the host on which the client is running.  The other must be unique to the network identity being presented.  The DHCP Unique Identifier (DUID) and Identity Association Identifier (IAID) specified in RFC 3315 satisfy these requirements.
In order to satisfy the last requirement, we must use the DUID to
identify the DHCPv4 client.  So, taking all the requirements
together, the DUID and IAID described in RFC 3315 are the only
possible solution.

Comment 3 Philip Prindeville 2010-01-31 22:17:24 UTC
So...

send dhcp-client-identifier = concat(03:00:01, suffix(hardware, 6));

then in the case of Ethernet.

We probably need a new function in the data-expr eval that returns the RFC-826 ar$hrd value (ARP-hardware type) for an Interface as an enum (which we could then manipulate as encode-int(XXX, 2) to turn it into a 16-bit field.

Comment 4 Philip Prindeville 2010-02-02 23:40:25 UTC
(In reply to comment #3)
> So...
> 
> send dhcp-client-identifier = concat(03:00:01, suffix(hardware, 6));
> 
> then in the case of Ethernet.
> 
> We probably need a new function in the data-expr eval that returns the RFC-826
> ar$hrd value (ARP-hardware type) for an Interface as an enum (which we could
> then manipulate as encode-int(XXX, 2) to turn it into a 16-bit field.    

Actually, you could also use:

send dhcp-client-identifier = concat(03:00, substring(hardware, 0, 1), suffix(hardware, 6));

although I wonder: given how long RFC-3315 has been out (6.5 years, as of today) no one really seems to be using it.

Do we want to "go it alone" and adopt a standard that no one else has?

Won't that cause interoperability issues?

Comment 5 Jiri Popelka 2010-02-03 16:32:50 UTC
RFC 3315 defines DHCP for IPv6 (DHCPv6).
When you run 'dhclient -6' and 'dhcpd -6' you are running DHCPv6, which is implemented according to RFC 3315.
'dhclient -6' and 'dhcpd -6' uses for identifying each other DUID_LLT.

'dhcpd (-4)' uses for client identification dhcp-client-identifier (if it's defined) or chaddr (client's link-layer address) field in DHCP message.

RFC 4361 specifies how to encode DHCPv4 client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol.
And I think such defined identifiers would solve your problem.
But implementation of RFC 4361 is task for upstream.

Comment 6 Philip Prindeville 2010-04-24 16:57:22 UTC
Well, I still think catching up from RFC-826 to RFC-3315 is worthwhile, while we're waiting for upstream to get around to RFC-4361.

Comment 7 Philip Prindeville 2010-12-20 06:57:41 UTC
So... how about going with the original proposal then:

send dhcp-client-identifier = hardware;

Just trying to get an additional config file into the BOM, so it shouldn't take too much effort I'm hoping...

Comment 8 Jiri Popelka 2010-12-21 13:47:24 UTC
(In reply to comment #7)
> So... how about going with the original proposal then:
> send dhcp-client-identifier = hardware;

Yes, I think we should try the simplest way first.
There's now default /etc/dhcp/dhclient.conf shipped with dhclient in Rawhide (dhcp-4.2.0-24.P2.fc15).
And sorry for not taking action so long.

Comment 9 Jiri Popelka 2011-07-20 09:48:57 UTC
Actually, I don't like the "default /etc/dhcp/dhclient.conf" solution.
- It's there only because of this bug.
- It's used only by network service. Most of the people use NetworkManager nowadays (which creates its own conf file for dhclient).
- Somebody can become confused when editing /etc/dhcp/dhclient.conf while using NM. See bug #723374. So I'm probably going to remove it again.


Reassigning this BZ to NM.
Jirka, Dan: would it be possible to add the

send dhcp-client-identifier = hardware;

line to /var/run/nm-dhclient-<iface>.conf ?
See the description of this BZ.

Comment 10 Philip Prindeville 2011-11-19 08:08:38 UTC
(In reply to comment #9)
> Actually, I don't like the "default /etc/dhcp/dhclient.conf" solution.
> - It's there only because of this bug.
> - It's used only by network service. Most of the people use NetworkManager
> nowadays (which creates its own conf file for dhclient).
> - Somebody can become confused when editing /etc/dhcp/dhclient.conf while using
> NM. See bug #723374. So I'm probably going to remove it again.
> 
> 
> Reassigning this BZ to NM.
> Jirka, Dan: would it be possible to add the
> 
> send dhcp-client-identifier = hardware;
> 
> line to /var/run/nm-dhclient-<iface>.conf ?
> See the description of this BZ.

Not everyone uses NetworkManager: I have a bunch of headless servers that don't have a way to run a GUI.

I'd really like to have this bug wrapped up in less than 2 years if we could...

Comment 11 Philip Prindeville 2011-11-23 03:12:33 UTC
On an unrelated note, I noticed that after I updated from F15 to F16, the file:

/etc/dhcp/dhclient-p6p1.conf

contains the contents of "uname -r" but from F15, not from F16.

Comment 12 Kjetil T. Homme 2012-01-17 15:25:20 UTC
The lack of a dhcp-client-identifier causes problems when Kickstarting, too.  In that case, it is impossible (without building your own initrd) to change the parameters before NetworkManager/dhclient runs.

The issue is that ISC dhcpd will grant a dynamic IP address to the BIOS and PXE client which is coupled to the client-id.  When Anaconda/NM/dhclient later asks for an IP address, ISC dhcpd will *not* reuse the lease, since it considers a non-existent client-id a different value from a given client-id, even if the hardware address is the same.

The consequence of this is that each kickstarting server will consume 2 IP addresses from the pool, and it is slightly inconvenient to find out which one is actually active since both IP addresses are valid as far as the DHCP server is concerned.

Ideally I would like to see dhclient changed (upstream) to behave better by default, but failing that, please change the default configuration shipped with RedHat.

Comment 13 Philip Prindeville 2012-04-18 01:50:15 UTC
Anyone? This bug is 2+ years old...

Comment 14 Dan Williams 2012-04-19 23:09:34 UTC
(In reply to comment #9)
> Actually, I don't like the "default /etc/dhcp/dhclient.conf" solution.
> - It's there only because of this bug.
> - It's used only by network service. Most of the people use NetworkManager
> nowadays (which creates its own conf file for dhclient).
> - Somebody can become confused when editing /etc/dhcp/dhclient.conf while using
> NM. See bug #723374. So I'm probably going to remove it again.
> 
> 
> Reassigning this BZ to NM.
> Jirka, Dan: would it be possible to add the
> 
> send dhcp-client-identifier = hardware;
> 
> line to /var/run/nm-dhclient-<iface>.conf ?
> See the description of this BZ.

NM will send whatever the user wants it to send if the "DHCP Client ID" field is populated in nm-connection-editor.  That GUI field pulls directly from DHCP_CLIENT_ID in the ifcfg file, so if you're not using a GUI, adding that key to the ifcfg file for that interface should cause NM to write the ID to /var/run/nm-dhclient-<iface>.conf as well.

Comment 15 Pavel Šimerda (pavlix) 2012-09-13 12:13:38 UTC
Is there any reason to use UUID_LLT when UUID_LL is available through the first embedded interface?

Comment 16 Jiri Popelka 2012-09-17 13:22:08 UTC
From dhclient(8):

By default, DHCPv6 dhclient creates an identifier based on the link-layer address (DUID-LL) if it is running in stateless mode (with -S, not requesting an address), or it creates an identifier based on the link-layer address plus a timestamp (DUID-LLT) if it is running in stateful mode (without -S, requesting  an address).

Comment 17 Pavel Šimerda (pavlix) 2012-09-18 13:57:20 UTC
What's the reason not to use DUID-LL all the time?

Comment 18 Philip Prindeville 2012-09-18 16:34:03 UTC
(In reply to comment #17)
> What's the reason not to use DUID-LL all the time?

I agree.

There are low-end devices that don't have persistent (battery backed up) RTC's (like printers, scanners, NAS, etc) that won't have a reliable time-of-day until after they've acquired an address and synchronized via NTP.

Having a mixed network of DUID-LL and DUID-LLT seems onerous.

Comment 19 Pavel Šimerda (pavlix) 2012-09-21 16:03:43 UTC
> There are low-end devices that don't have persistent (battery backed up)
> RTC's (like printers, scanners, NAS, etc) that won't have a reliable
> time-of-day until after they've acquired an address and synchronized via NTP.

The time thing is there only to get some more unique bits.

> Having a mixed network of DUID-LL and DUID-LLT seems onerous.

It's not a problem per se. But DUID-LL has the great property of stability
accross reboots and reinstalls without the need to actually save it on the
disk.

Comment 20 Philip Prindeville 2012-09-26 23:26:20 UTC
(In reply to comment #19) 
> It's not a problem per se. But DUID-LL has the great property of stability
> accross reboots and reinstalls without the need to actually save it on the
> disk.

So it seems like we all agree that DUID-LL is the way to go...

Comment 21 Pavel Šimerda (pavlix) 2012-09-27 10:34:42 UTC
> So it seems like we all agree that DUID-LL is the way to go...

AFAIK even the RFC agrees :).

Comment 22 Fedora End Of Life 2013-04-03 20:01:29 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 23 Brian J. Murrell 2013-10-25 15:27:08 UTC
I would like to add my support for an option that works equally well with NM as well as with the more traditional ifup/ifdown mechanisms since our headless servers tend to not use NM.

Comment !4 seems to indicate that DHCP_CLIENT_ID in the ifcfg-$iface file already works for NM.  I couldn't find any evidence that it works for traditional ifup/ifdown though.  Maybe I'm wrong.  Somebody please correct me if I am.

Comment 24 Dan Williams 2013-10-25 20:41:31 UTC
If we're talking IPv4 only, does the following make it work with initscripts?

--- /etc/sysconfig/network-scripts/ifup-eth.bak	2013-10-25 15:37:30.086338774 -0500
+++ /etc/sysconfig/network-scripts/ifup-eth	2013-10-25 15:38:10.694831098 -0500
@@ -160,7 +160,7 @@
     fi;
     generate_config_file_name
     generate_lease_file_name
-    DHCLIENTARGS="${DHCLIENTARGS} -H ${DHCP_HOSTNAME:-${HOSTNAME%%.*}} ${ONESHOT} -q ${DHCLIENTCONF} -lf ${LEASEFILE} -pf /var/run/dhclient-${DEVICE}.pid"
+    DHCLIENTARGS="${DHCLIENTARGS} -H ${DHCP_HOSTNAME:-${HOSTNAME%%.*}} ${ONESHOT} ${DHCP_CLIENT_ID:+-I $DHCP_CLIENT_ID} -q ${DHCLIENTCONF} -lf ${LEASEFILE} -pf /var/run/dhclient-${DEVICE}.pid"
     echo
     echo -n $"Determining IP information for ${DEVICE}..."
     if [[ "${PERSISTENT_DHCLIENT}" !=  [yY1]* ]] && check_link_down ${DEVICE}; then

(my shell-fu is weak, so I'm not quite sure that's the right notation for "print nothing if $DHCP_CLIENT_ID is not defined")

Comment 25 Philip Prindeville 2013-10-26 00:38:54 UTC
(In reply to Dan Williams from comment #24)

> (my shell-fu is weak, so I'm not quite sure that's the right notation for
> "print nothing if $DHCP_CLIENT_ID is not defined")

from bash(1):

       ${parameter:+word}
              Use Alternate Value.  If parameter is null or unset, nothing is sub‐
              stituted, otherwise the expansion of word is substituted.

Comment 26 Philip Prindeville 2013-10-26 00:45:21 UTC
Hard to believe I opened this bug almost 4 years ago.

Can we please move this to closure?

Comment 27 Philip Prindeville 2013-10-30 16:22:00 UTC
(In reply to Dan Williams from comment #24)
> If we're talking IPv4 only, does the following make it work with initscripts?
> [...]

That would require each user manually configuring DHCP_CLIENT_ID when not using NM. It also means that it would work differently for plug-n-play devices.

For instance, if I have a laptop and 2 docking stations, the MAC address will come from the docking station itself.

Similarly, if I have a laptop with both Wifi and Ethernet, it would use the same client-id for both devices. This may or may not be desirable.

There's much less convenience and a lot more unintended consequences from this patch.

Comment 28 Philip Prindeville 2013-10-30 16:26:56 UTC
Changing the component as this needs to work whether NM is being used or not.

Comment 29 Jiri Popelka 2013-10-31 12:27:51 UTC
OK, /etc/dhcp/dhclient.conf (send dhcp-client-identifier = hardware;) strikes back.

Comment 30 Fedora Update System 2013-10-31 12:28:34 UTC
dhcp-4.2.5-26.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dhcp-4.2.5-26.fc20

Comment 31 Fedora Update System 2013-10-31 17:40:29 UTC
Package dhcp-4.2.5-26.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dhcp-4.2.5-26.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20396/dhcp-4.2.5-26.fc20
then log in and leave karma (feedback).

Comment 32 Fedora Update System 2013-11-10 06:28:13 UTC
dhcp-4.2.5-26.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 33 Doug Ledford 2014-02-12 14:45:42 UTC
(In reply to Philip Prindeville from comment #1)
> Recommend the package (or an optional subpackage) include the following as
> the file /etc/dhcp/dhclient.conf:
> 
> # required in environments where a bridge might be clobbering the forwarded
> # packet's MAC address (common in Wifi, Docsis, or ADSL bridging scenarios)
> send dhcp-client-identifier = hardware;

This is broken.  In dhcp config file parlance, hardware == the single byte value of the hardware type.  For Ethernet, this is 10.  For InfiniBand IPoIB, this is 32.  That's *all* that this config line causes to get put into the client identifier field.  This means that *every* computer behind the windows Ethernet/wifi bridge will all have the exact same client id of 10.  That obviously violates the requirements as listed in comment #3 that this value must be unique.

For reference though, there is a long standing history that InfiniBand IPoIB interfaces already send 0xff:<GUID> as their client id, so when you fix this bug properly, it needs to differentiation what hardware you are on, and on hardware type 32, we need to replace 32 with 255 and then append the GUID.  For Ethernet, hardware type 10 with an append of the MAC address should work.

Comment 34 Doug Ledford 2014-02-12 14:50:08 UTC
(In reply to Doug Ledford from comment #33)
> For reference though, there is a long standing history that InfiniBand IPoIB
> interfaces already send 0xff:<GUID> as their client id, so when you fix this
> bug properly, it needs to differentiation what hardware you are on, and on
> hardware type 32, we need to replace 32 with 255 and then append the GUID. 
> For Ethernet, hardware type 10 with an append of the MAC address should work.

This is an over simplification of what we do with InfiniBand at the moment.  And I should point out that there are quite a lot of InfiniBand dhcp clients that will break if we change this.  I would look in the source code to see what we do here.  And it may require that this bug be fixed in the source code as I'm not sure the config file will present you with a suitable programming construct to differentiate between IPoIB and Ethernet and program the client id differently between the two.

Comment 35 Doug Ledford 2014-02-12 14:56:14 UTC
Further clarification, the problem here is that the hardware keyword only works properly on certain hardware types.  IPoIB is not one of those types.  It should work as expected on Ethernet.  I'm trying this now to see if it solves my problem:

if not hardware = 32 {
        send dhcp-client-identifier = hardware;
}

Comment 36 Doug Ledford 2014-02-12 14:59:15 UTC
The config file change in my previous comment fixes infiniband IPoIB interfaces by causing us to fall back to the internal client ID that dhclient already produces on those interfaces.  I'm not sure if this change is really right though in that the hardware option only works on certain hardware, it seems we should limit this config file option to hardware where it works, not just exclude IPoIB from the list.  But I'll leave that up to the dhclient maintainer to sort out.

Comment 37 Doug Ledford 2014-02-12 15:00:24 UTC
*** Bug 1064029 has been marked as a duplicate of this bug. ***

Comment 38 Jiri Popelka 2014-02-13 13:14:29 UTC
(In reply to Doug Ledford from comment #33)
> For reference though, there is a long standing history that InfiniBand IPoIB
> interfaces already send 0xff:<GUID> as their client id

Correct, that's RFC 4390 (DHCP over IPoIB).

> so when you fix this
> bug properly, it needs to differentiation what hardware you are on, and on
> hardware type 32, we need to replace 32 with 255 and then append the GUID. 
> For Ethernet, hardware type 10 with an append of the MAC address should work.

I'm not sure the 'hardware' expression needs any change,
it behaves per RFC4390, which says that (for IPoIB):
- hw type must be 32
- hw len must be 0
- hw add must be zeroed

(In reply to Doug Ledford from comment #35)
> if not hardware = 32 {
>         send dhcp-client-identifier = hardware;
> }

Thank you !

(In reply to Doug Ledford from comment #36)
> it seems we should limit this config file option to hardware where
> it works, not just exclude IPoIB from the list.

I actually like this solution.
I'm fine with excluding IPoIB, because it's a special case.
I don't know about any other similar case, if you do, let me know so I can change my mind.

Comment 39 Jiri Popelka 2014-02-14 15:15:09 UTC
(In reply to Doug Ledford from comment #35)
> if not hardware = 32 {
>         send dhcp-client-identifier = hardware;
> }

Added in dhcp-4.2.6-2.fc20
http://koji.fedoraproject.org/koji/taskinfo?taskID=6530814

Comment 40 Jiri Popelka 2014-02-14 15:17:25 UTC
(In reply to Jiri Popelka from comment #2)
> Although probably the best solution would be to send client identifier as defined in RFC 4361.

This starts to becoming reality with dhcp-4.3 in rawhide/F21.

dhclient(8):
"  -i  Use a DUID with DHCPv4 clients.  If no DUID is available in the lease file one will be constructed and saved.  The DUID will be used to construct a RFC4361 style client id that will be included in the client's messages."

This DUID should have the same format as DUID used by DHCPv6 or the one we already create for IPoIB.

The only problem I see is in using the '-i' options to turn this on.
I'm thinking about turning this on in code by default, because it seems it's possible to redefine or turn it off in dhclient.conf with
send dhcp-client-identifier = "better identifier" or send dhcp-client-identifier = ""

And I also need to make sure IPoIB still works with it ;)

Comment 41 Jiri Popelka 2014-02-17 12:44:25 UTC
*** Bug 1065675 has been marked as a duplicate of this bug. ***

Comment 42 Jiri Popelka 2014-02-17 12:59:21 UTC
(In reply to Doug Ledford from comment #35)
> if not hardware = 32 {
>         send dhcp-client-identifier = hardware;
> }
(In reply to Doug Ledford from comment #36)
> The config file change in my previous comment fixes infiniband IPoIB
> interfaces by causing us to fall back to the internal client ID that
> dhclient already produces on those interfaces.

Actually it "fixes" the problem on IPoIB because the conditional behaviour seems to not work as expected. I've tried to make it work somehow but with no luck so far - the only explanation I have is from dhcp-eval(5):
"... provide the ability to perform conditional behavior depending on the contents of packets they *receive*."

So for now I tend to remove the sending of dhcp-client-identifier at all from F20 so we don't break IPoIB and will hopefully fix it in F21 as described in comment #40.

Comment 43 Jiri Popelka 2014-02-17 18:10:22 UTC
(In reply to Jiri Popelka from comment #42)
> So for now I tend to remove the sending of dhcp-client-identifier at all
> from F20 so we don't break IPoIB

done, dhcp-4.2.6-3.fc20
https://koji.fedoraproject.org/koji/buildinfo?buildID=498806

> and will hopefully fix it in F21 as described in comment #40.

done, dhcp-4.3.0-3.fc21
https://koji.fedoraproject.org/koji/buildinfo?buildID=498829
(tested with IB hw and looks good)

Comment 44 Jiri Popelka 2014-06-16 13:50:10 UTC
(In reply to Jiri Popelka from comment #42)
> So for now I tend to remove the sending of dhcp-client-identifier at all
> from F20 so we don't break IPoIB and will hopefully fix it in F21 as
> described in comment #40.

I think, I've changed my mind. I probably don't want to do such changes in already released Fedora. I'm sure sending of dhcp-client-identifier breaks IPoIB, but hey, how many machines out there with IPoIB is running Fedora ? 

I'm closing this bug as the original problem should be fixed in F20/F21 and we can continue with the IPoIB problem in newly created bug #1109860

Comment 45 Jiri Popelka 2014-11-19 09:33:06 UTC
Even sending client identifier as defined in RFC 4361 isn't without problems, see bug #1154200 - it seems that some DHCP servers (e.g. Cisco RV320 Router) when configured to do static allocation (assign IP according to MAC) search client's MAC address in client identifier (when specified) instead of in chaddr field of DHCP packet. The problem does not appear when there's no client identifier or the client identifier is equal to client's MAC.

So what now ?
Not sending client identifier causes this bug.
Sending client identifier = MAC causes bug #1109860.
Sending client identifier per RFC 4361 causes bug #1154200.

Comment 46 Philip Prindeville 2014-11-19 18:52:21 UTC
(In reply to Jiri Popelka from comment #45)
> Even sending client identifier as defined in RFC 4361 isn't without
> problems, see bug #1154200 - it seems that some DHCP servers (e.g. Cisco
> RV320 Router) when configured to do static allocation (assign IP according
> to MAC) search client's MAC address in client identifier (when specified)
> instead of in chaddr field of DHCP packet. The problem does not appear when
> there's no client identifier or the client identifier is equal to client's
> MAC.
> 
> So what now ?
> Not sending client identifier causes this bug.
> Sending client identifier = MAC causes bug #1109860.
> Sending client identifier per RFC 4361 causes bug #1154200.

I wouldn't let the fact that someone doesn't handle it correctly: it will get fixed eventually by "the other guy" (as someone who spent 5 years at Cisco fixing IOS bugs and being "the other guy").

Do what you think is the truest/most correct interpretation of the RFCs.

IPoIB is a bit of a corner case. For IB, setting the client-identifier to "" seems to be a viable workaround.

Comment 47 Philip Prindeville 2014-11-19 18:53:19 UTC
Oh, an for what it's worth I'm not a fan of "implicit" configurations nor of changing the way a package behaves in a distro from how it behaves upstream.

Comment 48 Doug Ledford 2014-11-19 19:11:26 UTC
I would follow the RFC.  As pointed out, if something else breaks when we are RFC compliant, it's the other thing's time to be fixed.

Comment 49 Philip Prindeville 2014-11-19 19:44:53 UTC
(In reply to Doug Ledford from comment #48)
> I would follow the RFC.  As pointed out, if something else breaks when we
> are RFC compliant, it's the other thing's time to be fixed.

Agreed.

If everyone refused to fix anything because they were "blocking" on someone else's bug, then nothing would ever get fixed because we'd be in a permanent Mexican standoff.

Comment 50 Jiri Popelka 2014-11-20 06:50:15 UTC
Thank you guys !
Let's keep sending DUID (per RFC 4361) as client-id then.

(In reply to Philip Prindeville from comment #46)
> IPoIB is a bit of a corner case. For IB, setting the client-identifier to ""
> seems to be a viable workaround.

This is fortunately needed only in F20 (bug #1109860), where we send client-id = MAC. Since F21 we send DUID (per RFC 4361) as client-id and even RFC 4390 (DHCP over IB) says that client-id must conform to RFC 4361 - I tested it back then and it worked nicely.

Comment 51 Jiri Popelka 2015-10-29 14:39:46 UTC
Now I see I've never replied to the following question:

(In reply to Pavel Šimerda (pavlix) from comment #17)
> What's the reason not to use DUID-LL all the time?

Because 6.1. of RFC 4361 [1] says, that:
"DHCPv4 clients MUST NOT use client identifiers based solely on layer two
 addresses that are hard-wired to the layer two device (e.g., the
 ethernet MAC address) as suggested in RFC 2131, except as allowed in
 section 9.2 of RFC 3315."

Section 9.2 of RFC 3315, refers [2] to DUID-LLT

[1] https://tools.ietf.org/html/rfc4361#section-6.1
[2] https://tools.ietf.org/html/rfc3315#section-9.2

Comment 52 Philip Prindeville 2015-10-29 18:16:30 UTC
(In reply to Jiri Popelka from comment #51)

> Because 6.1. of RFC 4361 [1] says, that:
> "DHCPv4 clients MUST NOT use client identifiers based solely on layer two
>  addresses that are hard-wired to the layer two device (e.g., the
>  ethernet MAC address) as suggested in RFC 2131, except as allowed in
>  section 9.2 of RFC 3315."

And quoting RFC 3315, section 9.2:

"Clients and servers that use this DUID SHOULD attempt to configure
the time prior to generating the DUID, if that is possible, and MUST
use some sort of time source (for example, a real-time clock) in
generating the DUID, even if that time source could not be configured
prior to generating the DUID.  The use of a time source makes it
unlikely that two identical DUID-LLTs will be generated if the
network interface is removed from the client and another client then
uses the same network interface to generate a DUID-LLT."

A lot of embedded devices (like my pcEngines Alix-2c firewall, or my Sipura 942 desk phone) are SBC's where the NIC is onboard, same as everything else. There's no chance of the network interface being put anywhere else.

Also, many of those same devices don't have battery backed up (CMOS) Time-of-day clocks, so they don't know the time on boot... and need to DHCP and acquire an IP address before they can learn the time via (S)NTP.

Thus creating a circular dependency that this RFC doesn't acknowledge exists.

Comment 53 Philip Prindeville 2015-10-29 18:33:31 UTC
Actually, RFC-3315 is all kinds of confused.  For instance, section 9.4:

"This type of DUID consists of two octets containing the DUID type 3,
a two octet network hardware type code, followed by the link-layer
address of any one network interface that is permanently connected to
the client or server device.  For example, a host that has a network
interface implemented in a chip that is unlikely to be removed and
used elsewhere could use a DUID-LL.  [...]

"The choice of network interface can be completely arbitrary, as long
as that interface provides a unique link-layer address and is
permanently attached to the device on which the DUID-LL is being
generated.  The same DUID-LL SHOULD be used in configuring all
network interfaces connected to the device, regardless of which
interface's link-layer address was used to generate the DUID."

That last sentence is particularly problematic if all of the routers are using dhcp-relays because then the DHCP server will be presented with the same DUID regardless of which interface on a multi-homed device (router or host) is requesting the assignment. In that case additional attributes would be required to further disambiguate the request (such as the IP address of the interface that the dhcp-relay received the request on).

Comment 54 Pavel Šimerda (pavlix) 2015-10-29 23:15:23 UTC
(In reply to Philip Prindeville from comment #53)
> That last sentence is particularly problematic if all of the routers are
> using dhcp-relays because then the DHCP server will be presented with the
> same DUID regardless of which interface on a multi-homed device (router or
> host) is requesting the assignment.

No matter how exactly DUID is generated and stored, it identifies a single node. Any expectations regarding interface identification in DUID are misguided.

Comment 55 Doug Ledford 2015-12-02 17:55:52 UTC
(In reply to Jiri Popelka from comment #50)
> Thank you guys !
> Let's keep sending DUID (per RFC 4361) as client-id then.
> 
> (In reply to Philip Prindeville from comment #46)
> > IPoIB is a bit of a corner case. For IB, setting the client-identifier to ""
> > seems to be a viable workaround.
> 
> This is fortunately needed only in F20 (bug #1109860), where we send
> client-id = MAC. Since F21 we send DUID (per RFC 4361) as client-id and even
> RFC 4390 (DHCP over IB) says that client-id must conform to RFC 4361 - I
> tested it back then and it worked nicely.

Is this intended to interoperate at all with DHCP servers that aren't configured for this?  I ask because the recent Fedora installs won't get an IP address from a DHCP server over InfiniBand.  Not a static, nor a dynamic address.  In fact, a rhel7 DHCP server considers the Fedora 23/rawhide DHCP request to be malformed and simply ignores it.

Comment 56 Jiri Popelka 2015-12-02 18:20:59 UTC
Yes, and I'm sure I tested it with IB. Need to take another look then.

Comment 57 Doug Ledford 2015-12-02 20:13:25 UTC
Let me know if you need machines to test on.  I have server/client machines already to go that I can get you a login too.

Comment 58 Jiri Popelka 2015-12-11 16:36:43 UTC
(In reply to Doug Ledford from comment #55)
> (In reply to Jiri Popelka from comment #50)
> > Since F21 we send DUID (per RFC 4361) as client-id and even
> > RFC 4390 (DHCP over IB) says that client-id must conform to RFC 4361 - I
> > tested it back then and it worked nicely.
> 
> Is this intended to interoperate at all with DHCP servers that aren't
> configured for this?

Well, the fixed-address allocation using client-identifier (cid) needs to be amended as the cid has been different since F21.
The original (prior to F21) implementation (from Mellanox) of RFC4390 (DHCP over IB) was sending cid in form of 0xff + default_prefix (00:00:00:00:00:02:00:00:02:c9:00:00) + low 8B of iface LL address => for example:
ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:6f:33:71

While since F21 it's had a form (per RFC4361) of 0xff + IAID (low 4B of LL addr) + UUID (2B duid_type + 2B htype (+ 4B current_time in case of DUID_LLT type)) + low 8B of iface LL addr => fox example:
ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:6f:33:71

> I ask because the recent Fedora installs won't get an
> IP address from a DHCP server over InfiniBand. Not a static, nor a dynamic
> address. In fact, a rhel7 DHCP server considers the Fedora 23/rawhide DHCP
> request to be malformed and simply ignores it.

There's actually no dynamic allocation (no range statement) in your config and fixed-address allocations use the old (pre F21) cid. I can see
DHCPDISCOVER from ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:6f:33:71 via <iface>: network <subnet>.0/24: no free leases
in log, so it's not considered malformed - the server just doesn't have any dynamic/fixed address to offer.

I tested it again and dynamic allocation works out-of-the-box and for fixed-address allocation something like the following works for me on RHEL7 server as well:

host name {
 fixed-address <address>;
 hardware infiniband 00:11:75:00:00:6f:33:71;
 option dhcp-client-identifier=ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:6f:33:71;
}

Comment 59 Doug Ledford 2015-12-11 17:27:37 UTC
(In reply to Jiri Popelka from comment #58)
> (In reply to Doug Ledford from comment #55)
> > (In reply to Jiri Popelka from comment #50)
> > > Since F21 we send DUID (per RFC 4361) as client-id and even
> > > RFC 4390 (DHCP over IB) says that client-id must conform to RFC 4361 - I
> > > tested it back then and it worked nicely.
> > 
> > Is this intended to interoperate at all with DHCP servers that aren't
> > configured for this?
> 
> Well, the fixed-address allocation using client-identifier (cid) needs to be
> amended as the cid has been different since F21.
> The original (prior to F21) implementation (from Mellanox) of RFC4390 (DHCP
> over IB) was sending cid in form of 0xff + default_prefix
> (00:00:00:00:00:02:00:00:02:c9:00:00) + low 8B of iface LL address => for
> example:
> ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:6f:33:71
> 
> While since F21 it's had a form (per RFC4361) of 0xff + IAID (low 4B of LL
> addr) + UUID (2B duid_type + 2B htype (+ 4B current_time in case of DUID_LLT
> type)) + low 8B of iface LL addr => fox example:
> ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:6f:33:71

My question is this: since f21 does the new cid work out to be static?  If not, it's very hard to use it as a client identifier.  The whole "may use current_time" is worrisome.

> > I ask because the recent Fedora installs won't get an
> > IP address from a DHCP server over InfiniBand. Not a static, nor a dynamic
> > address. In fact, a rhel7 DHCP server considers the Fedora 23/rawhide DHCP
> > request to be malformed and simply ignores it.
> 
> There's actually no dynamic allocation (no range statement) in your config

Sorry, that's an oversight introduced by commit c5b16d0 dated Mon Oct 19 23:29:46 2015 in my internal config script git repo.  Thanks for pointing it out, it's been fixed.

> and fixed-address allocations use the old (pre F21) cid. I can see
> DHCPDISCOVER from
> ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:6f:33:71 via <iface>:
> network <subnet>.0/24: no free leases
> in log, so it's not considered malformed - the server just doesn't have any
> dynamic/fixed address to offer.
> 
> I tested it again and dynamic allocation works out-of-the-box and for
> fixed-address allocation something like the following works for me on RHEL7
> server as well:
> 
> host name {
>  fixed-address <address>;
>  hardware infiniband 00:11:75:00:00:6f:33:71;

Does this option even do anything?

>  option
> dhcp-client-identifier=ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:
> 6f:33:71;
> }

I'll have to create different stanzas, one for the old cid format and one for the new, in order to support both f21+ and rhel7- installs with static dhcp addresses.

Comment 60 Jiri Popelka 2015-12-14 12:23:21 UTC
(In reply to Doug Ledford from comment #59)
> (In reply to Jiri Popelka from comment #58)
> My question is this: since f21 does the new cid work out to be static?

It must me "static" once generated.

> If not, it's very hard to use it as a client identifier.  The whole "may use
> current_time" is worrisome.

I see your point. Then we might go one step further and implement RFC 6355 (DUID-UUID) [1]. That one is supposed to be "really static" - I mean, even when you delete the dhclient's leases file and let it generate new DUID - it should be the same as previously. It also addresses comment #51 (DUID-LL), because it's not based *solely* on LL address.

Since dhcp-4.3.3-9.fc24 I've been using [2] /etc/machine-id (man machine-id) to generate RFC 4122 compliant UUID to be used in DUID-UUID.
The DUID-UUID has form of: 0xff + IAID (low 4B of MAC) + 2B duid_type (4) + 16B UUID.
For example in my case where
(ethernet) MAC = xx:xx:28:c2:d7:11
/etc/machine-id = 9942ebb9c4a8495fbb51e98cb2b481d7
results in DUID-UUID (client-identifier):
ff:28:c2:d7:11:00:04:99:42:eb:b9:c4:a8:49:5f:bb:51:e9:8c:b2:b4:81:d7

[1] https://tools.ietf.org/html/rfc6355
[2] http://pkgs.fedoraproject.org/cgit/dhcp.git/tree/dhcp-duid_uuid.patch

> > I tested it again and dynamic allocation works out-of-the-box and for
> > fixed-address allocation something like the following works for me on RHEL7
> > server as well:
> > 
> > host name {
> >  fixed-address <address>;
> >  hardware infiniband 00:11:75:00:00:6f:33:71;
> 
> Does this option even do anything?

Not sure what you are actually asking as I've seen it in your config too.
I had tried whether it works (when I commented the line below) and it does so I wanted to point out that you can use either 'hardware infiniband ...' or 'option dhcp-client-identifier=...' to identify the IB clients.

> >  option
> > dhcp-client-identifier=ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:
> > 6f:33:71;
> > }
> 
> I'll have to create different stanzas, one for the old cid format and one
> for the new, in order to support both f21+ and rhel7- installs with static
> dhcp addresses.

I see, but I hope we are now RFCs compliant.

Comment 61 Doug Ledford 2015-12-17 20:57:06 UTC
(In reply to Jiri Popelka from comment #60)
> (In reply to Doug Ledford from comment #59)
> > (In reply to Jiri Popelka from comment #58)
> > My question is this: since f21 does the new cid work out to be static?
> 
> It must me "static" once generated.

For f21 through the most recent change, how can I generate the proper entry for a host entry in the dhcpd.conf file?  Here's the list I have so far based upon the comments in this bug:

I need an RFC4390 entry for all releases through rhel7/f20
I need an RFC4361 entry for f21+ until dhcp-4.3.3-9.fc24
I need an RFC4122 entry for f24+
I need an RFC6355 entry possibly in the future.

My install scripts in the test lab generate the necessary dhcpd.conf host entries needed to satisfy all possible requests from a machine no matter what OS the machine is installed with.  So, I now have to generate all of those IDs on each install.  I know how to generate the first (static element plus GID of device) and third (machine ID plus part of GID), but how do I generate the second or fourth?


> > > host name {
> > >  fixed-address <address>;
> > >  hardware infiniband 00:11:75:00:00:6f:33:71;
> > 
> > Does this option even do anything?
> 
> Not sure what you are actually asking as I've seen it in your config too.

No, I don't have any hardware infiniband entries.  Last I knew, they weren't supported on rhel7 dhcpd and just fail.  No, what you saw was host stanzas that have a complete list of possible IP addresses that are valid for this host across all of its Ethernet and InfiniBand devices combined with one hardware Ethernet and one client identifier element per host.  It would make my life easier if dhcpd would accept more than one hardware ethernet and one client identifier entry per host stanza as I could consolidate things then.  Instead,  because I have machines with things like two different InfiniBand devices plus two different Ethernet devices, I have to split things up like this:

host rdma-storage-02.0 {
	fixed-address 172.31.0.102,172.31.2.102,172.31.4.102,172.31.6.102,172.31.1.102,172.31.3.102,172.31.5.102,172.31.7.102,172.31.40.102,172.31.43.102,172.31.45.102,172.31.50.102;
	hardware ethernet 00:90:fa:88:5b:56;
	option dhcp-client-identifier=ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:6f:33:70;
}

host rdma-storage-02.1 {
	fixed-address 172.31.0.102,172.31.2.102,172.31.4.102,172.31.6.102,172.31.1.102,172.31.3.102,172.31.5.102,172.31.7.102,172.31.40.102,172.31.43.102,172.31.45.102,172.31.50.102;
	hardware ethernet 00:07:43:2e:c4:90;
	option dhcp-client-identifier=ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:6f:33:71;
}

If I split my ethernet entries and IB entries into different stanzas, I would have sometimes exactly twice as many host stanzas to deal with.

Of course, now, because of all of the different client identifiers I might have to support, my number of stanzas is going to blow up anyway ;-)

> I had tried whether it works (when I commented the line below) and it does
> so I wanted to point out that you can use either 'hardware infiniband ...'
> or 'option dhcp-client-identifier=...' to identify the IB clients.

As mentioned above, I believe you are mistaken in that I've never used hardware infiniband (it wasn't supported when I tried).  On rdma-master where I keep all of the individual host stanzas for generating the dhcpd.conf file:

[root@rdma-master hosts.d]$ ls
rdma-dev-00.dhcp.0  rdma-dev-12.dhcp.0   rdma-qe-13.dhcp.0
rdma-dev-00.dhcp.1  rdma-dev-13.dhcp.0   rdma-qe-14.dhcp.0
rdma-dev-01.dhcp.0  rdma-dev-16.dhcp.0   rdma-qe-15.dhcp.0
rdma-dev-01.dhcp.1  rdma-perf-00.dhcp.0  rdma-storage-01.dhcp.0
rdma-dev-02.dhcp.0  rdma-perf-01.dhcp.0  rdma-storage-01.dhcp.1
rdma-dev-02.dhcp.1  rdma-perf-02.dhcp.0  rdma-storage-02.dhcp.0
rdma-dev-03.dhcp.0  rdma-perf-02.dhcp.1  rdma-storage-02.dhcp.1
rdma-dev-03.dhcp.1  rdma-perf-03.dhcp.0  rdma-storage-03.dhcp.0
rdma-dev-04.dhcp.0  rdma-perf-03.dhcp.1  rdma-storage-03.dhcp.1
rdma-dev-04.dhcp.1  rdma-qe-04.dhcp.0    rdma-storage-04.dhcp.0
rdma-dev-05.dhcp.0  rdma-qe-05.dhcp.0    rdma-storage-04.dhcp.1
rdma-dev-05.dhcp.1  rdma-qe-06.dhcp.0    rdma-virt-00.dhcp.0
rdma-dev-06.dhcp.0  rdma-qe-06.dhcp.1    rdma-virt-00.dhcp.1
rdma-dev-06.dhcp.1  rdma-qe-07.dhcp.0    rdma-virt-01.dhcp.0
rdma-dev-07.dhcp.0  rdma-qe-07.dhcp.1    rdma-virt-01.dhcp.1
rdma-dev-07.dhcp.1  rdma-qe-08.dhcp.0    rdma-virt-02.dhcp.0
rdma-dev-08.dhcp.0  rdma-qe-08.dhcp.1    rdma-virt-02.dhcp.1
rdma-dev-09.dhcp.0  rdma-qe-09.dhcp.0    rdma-virt-03.dhcp.0
rdma-dev-10.dhcp.0  rdma-qe-09.dhcp.1    rdma-virt-03.dhcp.1
rdma-dev-10.dhcp.1  rdma-qe-10.dhcp.0    rdma-vr5-master.dhcp.0
rdma-dev-11.dhcp.0  rdma-qe-11.dhcp.0    rdma-vr6-master.dhcp.0
rdma-dev-11.dhcp.1  rdma-qe-12.dhcp.0    rdma-vr7-master.dhcp.0
[root@rdma-master hosts.d]$ grep infiniband *
[root@rdma-master hosts.d]$ 


> > >  option
> > > dhcp-client-identifier=ff:00:6f:33:71:00:01:00:20:1d:fd:a3:5e:00:11:75:00:00:
> > > 6f:33:71;
> > > }
> > 
> > I'll have to create different stanzas, one for the old cid format and one
> > for the new, in order to support both f21+ and rhel7- installs with static
> > dhcp addresses.
> 
> I see, but I hope we are now RFCs compliant.

Comment 62 Jiri Popelka 2015-12-18 12:24:45 UTC
(In reply to Doug Ledford from comment #61)
> (In reply to Jiri Popelka from comment #60)
> > (In reply to Doug Ledford from comment #59)
> > > (In reply to Jiri Popelka from comment #58)
> > > My question is this: since f21 does the new cid work out to be static?
> > 
> > It must me "static" once generated.
> 
> For f21 through the most recent change, how can I generate the proper entry
> for a host entry in the dhcpd.conf file?  Here's the list I have so far
> based upon the comments in this bug:
> 
> I need an RFC4390 entry for all releases through rhel7/f20

It's not RFC4390, but some Mellanox created UID type AFAIK not specified in any RFC and even contradicting RFC4361 (because the variable part is based solely on LL address).

> I need an RFC4361 entry for f21+ until dhcp-4.3.3-9.fc24

Yes, DUID-LLT to be specific.

> I need an RFC4122 entry for f24+
> I need an RFC6355 entry possibly in the future.

These two are the same. RFC6355 specifies DUID-UUID, which embeds UUID as defined in RFC4122.
 
> My install scripts in the test lab generate the necessary dhcpd.conf host
> entries needed to satisfy all possible requests from a machine no matter
> what OS the machine is installed with.  So, I now have to generate all of
> those IDs on each install.  I know how to generate the first (static element
> plus GID of device) and third (machine ID plus part of GID), but how do I
> generate the second or fourth?

Fourth and third are the same (DUID-UUID) and regarding the second (DUID-LLT) - that's why I've implemented RFC6355 (DUID-UUID) - because one cannot predict the DUID-LLT before the client generates it for the first time.
After the client sends it (DUID-LLT), you can find it either in dhcpd log or in /var/lib/dhcpd/dhcpd.leases (if the client got a lease).
It's a terrible idea, but I don't have any better.

> > > > host name {
> > > >  fixed-address <address>;
> > > >  hardware infiniband 00:11:75:00:00:6f:33:71;
> > > 
> > > Does this option even do anything?
> > 
> > Not sure what you are actually asking as I've seen it in your config too.
> 
> No, I don't have any hardware infiniband entries.  Last I knew, they weren't
> supported on rhel7 dhcpd and just fail.

I meant I had seen 'hardware' statement in you config so I didn't understood what you meant with 'does it do anything ?'.
It seemed to work for me, but it might had been some specific case - I hadn't tested it thoroughly.

Comment 63 Doug Ledford 2015-12-21 00:28:56 UTC
(In reply to Jiri Popelka from comment #62)
> (In reply to Doug Ledford from comment #61)
>
> > I need an RFC4390 entry for all releases through rhel7/f20
> 
> It's not RFC4390, but some Mellanox created UID type AFAIK not specified in
> any RFC and even contradicting RFC4361 (because the variable part is based
> solely on LL address).

Fair enough, it's not an RFC compliant UID, but it is what I need for those releases ;-)
 
> > I need an RFC4361 entry for f21+ until dhcp-4.3.3-9.fc24
> 
> Yes, DUID-LLT to be specific.

Got that working.

> > I need an RFC4122 entry for f24+
> > I need an RFC6355 entry possibly in the future.
> 
> These two are the same. RFC6355 specifies DUID-UUID, which embeds UUID as
> defined in RFC4122.

OK.
 
> > My install scripts in the test lab generate the necessary dhcpd.conf host
> > entries needed to satisfy all possible requests from a machine no matter
> > what OS the machine is installed with.  So, I now have to generate all of
> > those IDs on each install.  I know how to generate the first (static element
> > plus GID of device) and third (machine ID plus part of GID), but how do I
> > generate the second or fourth?
> 
> Fourth and third are the same (DUID-UUID) and regarding the second
> (DUID-LLT) - that's why I've implemented RFC6355 (DUID-UUID) - because one
> cannot predict the DUID-LLT before the client generates it for the first
> time.
> After the client sends it (DUID-LLT), you can find it either in dhcpd log or
> in /var/lib/dhcpd/dhcpd.leases (if the client got a lease).
> It's a terrible idea, but I don't have any better.

OK, this presents a problem.  Most often, the InfiniBand interfaces are not brought up during the install, so my %post scripts have no means of working this out.  That means the interfaces can't come up with a predictable address after the install completes and the admin must take manual action to get the interfaces to a predictable address.  Would it be possible to update the f21-f23 dhcp client to switch them to the DUID-LLT for new interfaces but preserve the existing value for known interfaces?

> > > > > host name {
> > > > >  fixed-address <address>;
> > > > >  hardware infiniband 00:11:75:00:00:6f:33:71;
> > > > 
> > > > Does this option even do anything?
> > > 
> > > Not sure what you are actually asking as I've seen it in your config too.
> > 
> > No, I don't have any hardware infiniband entries.  Last I knew, they weren't
> > supported on rhel7 dhcpd and just fail.
> 
> I meant I had seen 'hardware' statement in you config so I didn't understood
> what you meant with 'does it do anything ?'.

Well, back in the rhel6/rhel7 days, the dhclient did not ever pass a hardware infiniband to the server, so it was a wasted option.  It seems the latest dhclient passes both the hardware infiniband as well as the client-id.  So even in some cases where the client-id can't be figured out, it's possible that a hardware infiniband entry can work.  So, I've added hardware infiniband entries into the matrix of ids I create for each host.

Comment 64 Jiri Popelka 2015-12-22 18:24:33 UTC
(In reply to Doug Ledford from comment #63)
> Would it be possible to update
> the f21-f23 dhcp client to switch them to the DUID-LLT for new interfaces

not sure what 'switch to' means as they already send it

> but preserve the existing value for known interfaces?

no idea what do you have in mind with this

Comment 65 Doug Ledford 2015-12-22 18:53:20 UTC
(In reply to Jiri Popelka from comment #64)
> (In reply to Doug Ledford from comment #63)
> > Would it be possible to update
> > the f21-f23 dhcp client to switch them to the DUID-LLT for new interfaces
> 
> not sure what 'switch to' means as they already send it

Sorry, too many acronyms.  f21-f23 use DUID-LLT, which, as you said before, can't be predicted until the first attempt to get an IP address.  The DUID-UUID was added in f24.  My comment was meant to be: Would it be possible to switch the f21-f23 distros to a dhcp client that, if a device is previously unknown, uses DUID-UUID, but if a leases file exists with a previously used DUID-LLT then continue to use it?  That would keep the update from breaking working systems, but allow new systems/interfaces to have a reliable ID.

> > but preserve the existing value for known interfaces?
> 
> no idea what do you have in mind with this

Comment 66 Jiri Popelka 2015-12-23 10:09:33 UTC
(In reply to Doug Ledford from comment #65)
> Would it be
> possible to switch the f21-f23 distros to a dhcp client that, if a device is
> previously unknown, uses DUID-UUID, but if a leases file exists with a
> previously used DUID-LLT then continue to use it?

Got it. That's how F24 works now actually. I can't do anything with f21 as that one has already reached End-Of-Life. And regarding f22+f23: I'm afraid my answer would be no as I've learned not to do any such changes in already released versions, even I think it shouldn't break anything - let me think about it some more.


Note You need to log in before you can comment on or make changes to this bug.