Bug 1109860

+++ This bug was initially created as a clone of Bug #560361 +++

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

--- Additional comment from Doug Ledford on 2014-02-12 15:50:08 CET ---

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

--- Additional comment from Doug Ledford on 2014-02-12 15:56:14 CET ---

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

--- Additional comment from Doug Ledford on 2014-02-12 15:59:15 CET ---

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.

--- Additional comment from Doug Ledford on 2014-02-12 16:00:24 CET ---



--- Additional comment from Jiri Popelka on 2014-02-13 14:14:29 CET ---

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

--- Additional comment from Jiri Popelka on 2014-02-14 16:15:09 CET ---

(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

--- Additional comment from Jiri Popelka on 2014-02-14 16:17:25 CET ---

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

--- Additional comment from Jiri Popelka on 2014-02-17 13:59:21 CET ---

(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*."