Bug 1109860 - sending client-identifier in dhclient.conf breaks IPoIB
Summary: sending client-identifier in dhclient.conf breaks IPoIB
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp
Version: 20
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Jiri Popelka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1100485
TreeView+ depends on / blocked
 
Reported: 2014-06-16 13:49 UTC by Jiri Popelka
Modified: 2015-06-30 01:03 UTC (History)
4 users (show)

(edit)
Clone Of: 560361
(edit)
Last Closed: 2015-06-30 01:03:11 UTC


Attachments (Terms of Use)

Description Jiri Popelka 2014-06-16 13:49:48 UTC
+++ 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*."

Comment 1 Jiri Popelka 2014-09-12 10:22:35 UTC
It's a F20 only problem, should be OK (no default dhclient.conf) in F21/rawhide.

Comment 2 Fedora End Of Life 2015-05-29 12:07:42 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Fedora End Of Life 2015-06-30 01:03:11 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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