Bug 1154200 - not getting a dhcp address assigned
not getting a dhcp address assigned
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
24
x86_64 Linux
high Severity urgent
: ---
: ---
Assigned To: Pavel Zhukov
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs, Reopened
: 1158838 1276073 1381594 (view as bug list)
Depends On:
Blocks: dualstack
  Show dependency treegraph
 
Reported: 2014-10-17 16:59 EDT by David Krovich
Modified: 2017-05-02 02:56 EDT (History)
33 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-01 23:21:31 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tcpdump while dhclient is running (2.12 KB, application/octet-stream)
2014-10-20 16:02 EDT, David Krovich
no flags Details
dhclient with an identifier (2.47 KB, application/octet-stream)
2014-10-23 15:26 EDT, Barry Martin
no flags Details
dhclient with no identifier (988 bytes, application/octet-stream)
2014-10-23 15:26 EDT, Barry Martin
no flags Details
packet.dump packet_dhclient-4.3.1-12.dump (10.52 KB, application/octet-stream)
2014-12-17 09:11 EST, Arthur Clement
no flags Details
new dump with build 8358933 (7.37 KB, application/octet-stream)
2014-12-17 10:41 EST, Arthur Clement
no flags Details
dhclient from NM applet (7.38 KB, application/octet-stream)
2014-12-17 12:15 EST, Arthur Clement
no flags Details

  None (edit)
Description David Krovich 2014-10-17 16:59:13 EDT
Description of problem:

When I install Fedora 21 Workstation I am unable to get a dhcp response. If I manually configure the network everything works as expected.  After manually configuring the network I did a yum update to get all updates and rebooted and still get the same result. 

Using the same hardware I wiped the installation and then installed Fedora 20 and it has no problems getting a dhcp response.

This problem only seems to be happening on my University network.  If I install Fedora 21 on a machine on my home network it has no problems getting a dhcp response.

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


How reproducible:  Always.


Steps to Reproduce:
1. Install Fedora 21 Workstartion using live media.
2. Reboot machine.
3. 

Actual results:

Machine will reboot and not have a dhcp assigned address.

Expected results:

Machine will reboot and have an IP address assigned to it via DHCP.


Additional info:
Comment 1 Jiri Popelka 2014-10-20 07:01:49 EDT
There might of course be something wrong with dhclient in F21 as it contains version 4.3.1 while F20 has 4.2.7.

We need to see some network traffic to see what's going on.
- install tcpdump package and run (as root)
# tcpdump -i em1 -vvv '(port 67 or port 68)' -U -w packet.dump
(replace em1 with you network interface name)
- in another terminal run (as root) dhclient by hand like 'dhclient -d em1' (again replace em1), let it run for 10sec and press Ctrl+c
- return to the terminal with running tcpdump and press Ctrl+c

Now please attach the packet.dump file and also the output of dhclient.
Thanks.
Comment 2 David Krovich 2014-10-20 16:01:26 EDT
Here is the output from dhclient

[root@localhost ~]# dhclient -d enp0s25
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp0s25/00:1c:c0:e9:88:c9
Sending on   LPF/enp0s25/00:1c:c0:e9:88:c9
Sending on   Socket/fallback
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 5 (xid=0xdd1aa79)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 5 (xid=0xdd1aa79)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 13 (xid=0xdd1aa79)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 10 (xid=0xdd1aa79)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 17 (xid=0xdd1aa79)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 11 (xid=0xdd1aa79)
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
Comment 3 David Krovich 2014-10-20 16:02:48 EDT
Created attachment 948677 [details]
tcpdump while dhclient is running

Generated with the following command

tcpdump -i enp0s25 -vvv '(port 67 or port 68)' -U -w packet.dump
Comment 4 Jiri Popelka 2014-10-21 06:22:19 EDT
(In reply to David Krovich from comment #2)
> DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 11
> No DHCPOFFERS received.

Strange, the only relevant change that comes to my mind is
http://pkgs.fedoraproject.org/cgit/dhcp.git/commit/?h=f21&id=30308a134f5321841426e39ac089a90841655bde

i.e. we now send client-identifier in different format than on F20.

Please try to add a
send dhcp-client-identifier = "Davids identifier";
into /etc/dhcp/dhclient.conf (create it if there's no one)
and run 'dhclient -d enp0s25'
Then change it to
send dhcp-client-identifier = "";
and run 'dhclient -d enp0s25' once more.

Let me know if you see any difference. Thanks.
Comment 5 David Krovich 2014-10-21 14:03:35 EDT
Definitely noticed a difference.  Made the first suggested change, ran it, same result.  Made the second suggested change, and then it gets a dhcp response and throws an error.  Here is the output of the first run followed by the second run.

[root@localhost dhcp]# emacs -nw dhclient.conf
[root@localhost dhcp]# dhclient -d enp0s25
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp0s25/00:1c:c0:e9:88:c9
Sending on   LPF/enp0s25/00:1c:c0:e9:88:c9
Sending on   Socket/fallback
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 8 (xid=0x223981b1)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 13 (xid=0x223981b1)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 14 (xid=0x223981b1)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 15 (xid=0x223981b1)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 11 (xid=0x223981b1)
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
^C
[root@localhost dhcp]# emacs -nw dhclient.conf
[root@localhost dhcp]# dhclient -d enp0s25
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp0s25/00:1c:c0:e9:88:c9
Sending on   LPF/enp0s25/00:1c:c0:e9:88:c9
Sending on   Socket/fallback
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 4 (xid=0x1e380443)
DHCPREQUEST on enp0s25 to 255.255.255.255 port 67 (xid=0x1e380443)
DHCPOFFER from 157.182.195.129
DHCPACK from 157.182.195.129 (xid=0x1e380443)
Invalid domain list.
suspect value in domain_search option - discarded
Invalid domain list.
bound to 157.182.195.138 -- renewal in 178113 seconds.
Comment 6 Jiri Popelka 2014-10-22 04:13:35 EDT
(In reply to David Krovich from comment #5)
> Definitely noticed a difference.  Made the first suggested change, ran it,
> same result. Made the second suggested change, and then it gets a dhcp response ...

Well, if the server ignores clients messages *because* they contain client-identifier (DHCP option 61) then there's IMHO something really wrong with the server.

> ... and throws an error.
> Invalid domain list.
> suspect value in domain_search option - discarded

This only confirms my suspicion.
Please use tcpdump (per comment #1) to catch the network traffic, I'll see if there's anything I can do.
Comment 7 David Krovich 2014-10-22 15:59:51 EDT
(In reply to Jiri Popelka from comment #6)
> Well, if the server ignores clients messages *because* they contain
> client-identifier (DHCP option 61) then there's IMHO something really wrong
> with the server.

Thats entirely possible.  The dhcp server is not something I maintain.  Unfortunately, I don't have the friendliest network staff here at my University but I'll alert them to this issue and see if they will do anything.

> 
> > ... and throws an error.
> > Invalid domain list.
> > suspect value in domain_search option - discarded
> 
> This only confirms my suspicion.
> Please use tcpdump (per comment #1) to catch the network traffic, I'll see
> if there's anything I can do.

I'll get you a tcpdump shortly.  If not today then definitely before the end of the week.  Thanks for your assistance.

-Dave
Comment 8 Barry Martin 2014-10-23 15:26:29 EDT
Created attachment 950052 [details]
dhclient with an identifier
Comment 9 Barry Martin 2014-10-23 15:26:57 EDT
Created attachment 950053 [details]
dhclient with no identifier
Comment 10 Barry Martin 2014-10-23 15:29:37 EDT
Hello, I've been working with Dave on the machine in question.

I've attached two dump files, one with an identifier of "Test Identifier" and another with it blanked out.Additionally, here's the output from running the two test.


Output with identifier:
[ledora@localhost ~]$ sudo dhclient -d enp0s25
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp0s25/00:1c:c0:e9:88:c9
Sending on   LPF/enp0s25/00:1c:c0:e9:88:c9
Sending on   Socket/fallback
DHCPREQUEST on enp0s25 to 255.255.255.255 port 67 (xid=0x224854b1)
DHCPREQUEST on enp0s25 to 255.255.255.255 port 67 (xid=0x224854b1)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 5 (xid=0x1f574123)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 6 (xid=0x1f574123)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 12 (xid=0x1f574123)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 18 (xid=0x1f574123)
DHCPDISCOVER on enp0s25 to 255.255.255.255 port 67 interval 20 (xid=0x1f574123)
No DHCPOFFERS received.



Output with a blank identifier:

[ledora@localhost ~]$ sudo dhclient -d enp0s25
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/enp0s25/00:1c:c0:e9:88:c9
Sending on   LPF/enp0s25/00:1c:c0:e9:88:c9
Sending on   Socket/fallback
DHCPREQUEST on enp0s25 to 255.255.255.255 port 67 (xid=0x20cc9e8f)
DHCPACK from 157.182.195.129 (xid=0x20cc9e8f)
Invalid domain list.
suspect value in domain_search option - discarded
Invalid domain list.
bound to 157.182.195.138 -- renewal in 170087 seconds.


-Barry
Comment 11 Barry Martin 2014-10-23 15:41:57 EDT
Additionally, I noticed the default value for send dhcp-client-identifier in fedora 20 is
send dhcp-client-identifier = hardware;

Using this same value in 21 also worked and behaved exactly the same as setting it to an empty string.
Comment 12 David Krovich 2014-10-27 16:17:32 EDT
Got more information.  I don't think this is a bug anymore.  The dhcp server in question is only assigning addresses to known MAC address in a static fashion.

From my research, if a client identifier is set, the dhcp server has to use it.

In F20, it sends a client identifier, and that client identifier is equal to the MAC address of the interface.  This is recognized by the DHCP server's static configuration and the F20 client gets an IP address.

F21 now sends a different client identifier that is not equal to the MAC address of the identifier.  This new string format for client identifier doesn't match anything in the static configuration of the DHCP server so it fails to get an IP address assigned.

In this case it sounds like I either need to reconfigure F21 clients to use client identifier=hardware or update the server configuration to recognize the new format.
Comment 13 Jiri Popelka 2014-10-29 05:55:40 EDT
(In reply to David Krovich from comment #12)
> F21 now sends a different client identifier that is not equal to the MAC
> address of the identifier.  This new string format for client identifier
> doesn't match anything in the static configuration of the DHCP server so it
> fails to get an IP address assigned.

Well, I have F21 here on my machine (in office) and the address I get is also statically assigned based on my MAC address. And everything still works.
Server can get the MAC address also from chaddr field of DHCP packet.
Comment 14 David Krovich 2014-10-29 13:12:43 EDT
(In reply to Jiri Popelka from comment #13)
> (In reply to David Krovich from comment #12)
> > F21 now sends a different client identifier that is not equal to the MAC
> > address of the identifier.  This new string format for client identifier
> > doesn't match anything in the static configuration of the DHCP server so it
> > fails to get an IP address assigned.
> 
> Well, I have F21 here on my machine (in office) and the address I get is
> also statically assigned based on my MAC address. And everything still works.
> Server can get the MAC address also from chaddr field of DHCP packet.

I did more research and came to the same conclusion.  On a dhcp server that I maintain it works fine even with assigning static addresses.  This isn't a bug in Fedora.  The problem is in the way the dhcp server at my university is configured.  Unfortunately I don't think I'll be able to get them to change it so I'm going to have to go back to send client identifier=hardware for now.  :(  

Thanks for your assistance.  I learned a lot about option 61 and some new RFCs along the way.
Comment 15 Alexander Lindqvist 2014-11-14 14:10:49 EST
I had the same issue after a clean install of fc21 beta 4 from fc20.

creating /etc/dhcp/dhclient.conf and adding the following line solved the issue:

send dhcp-client-identifier = hardware;

DHCP server in this case was a Cisco RV320 Router.
Comment 16 Alexander Lindqvist 2014-11-14 14:12:47 EST
Forgot to mention that I do not assign static addresses on this router.
Comment 17 Jirka Klimes 2014-11-18 04:55:41 EST
*** Bug 1158838 has been marked as a duplicate of this bug. ***
Comment 21 Dams 2014-11-20 09:30:50 EST
Same issue here. I can confirm "send dhcp-client-identifier = hardware;" fixes the issue. DHCP server is a microsoft windows server and there's nothing I can do to change its configuration.
Comment 22 Arthur Clement 2014-12-05 06:20:31 EST
Thanks to these comments. I had this problem with the RV320 as well and it's solved with an empty string.
Comment 23 Aniruddha 2014-12-09 12:33:57 EST
I had the same problem with the Cisco RV320, the dhclient.conf  is removed during the upgrade causing dhcp to fail. I solved this by backing up and restoring dhclient.conf:

sudo cp /etc/dhcp/dhclient.conf  /etc/dhcp/fedora20_dhclient.conf
sudo cp /etc/dhcp/fedora20_dhclient.conf /etc/dhcp/dhclient.conf  

What is the reason dhclient.conf  is removed? I think it would be better to keep it in the default installation media and preserve it with fedup.
Comment 24 gerrit.boesebeck 2014-12-11 07:26:42 EST
Same here. We got a microsoft windows server infrastructure. Please change the default mechanism back to 'hardware'
Comment 25 Jiri Popelka 2014-12-11 09:23:28 EST
(In reply to Aniruddha from comment #23)
> What is the reason dhclient.conf is removed?

Up to F19 there's been no dhclient.conf and dhclient does not send any client-identifier by default on F19. Dhcp server takes the client's hw address from chaddr field of DHCP packet.

Because of bug #560361, in F20 we added default dhclient.conf, which tells dhclient to send client-identifier equal hardware address.
In bug #560361, comment #2 you can also see that I think it'd be best to send client-identifier per RFC 4361 [1]. But at that time RFC 4361 was not implemented in ISC dhcp.

Since dhcp-4.3 (F21) ISC dhcp finally implements RFC 4361 so we can use it.
We've removed the default dhclient.conf again in F21 and dhclient sends RFC 4361 compliant client-identifier by default. It fixes bug #560361 and bug #1109860.

I'm sorry that some routers/dhcp servers does not handle RFC 4361 compliant client-identifier and expect it to be equal to client's hardware address, but AFAIK no RFC specifies that.
In bug #560361, comment #45 I asked for others' opinions on this bug and we agreed that we should follow RFCs, which I think we do.

[1] http://www.ietf.org/rfc/rfc4361.txt
Comment 27 Jiri Popelka 2014-12-11 15:12:03 EST
Anyone seeing this bug, can you please try
http://koji.fedoraproject.org/koji/taskinfo?taskID=8351945

Download the rpms into a directory and run
# dnf update *.rpm

Then move away your /etc/dhcp/dhclient.conf
and run
# > /var/lib/dhclient/dhclient.leases
# dhclient -d <interface>

You should see something like:

DHCPDISCOVER on ... (5x)
No DHCPOFFERS received.
You might have hit https://bugzilla.redhat.com/show_bug.cgi?id=1154200
Try to put 'send dhcp-client-identifier = hardware;' into /etc/dhcp/dhclient.conf
DHCPDISCOVER on ...
DHCPREQUEST on ...
DHCPOFFER from ...
DHCPACK from ...

--
Thanks to Adam Williamson for the idea.
Comment 28 Adam Williamson 2014-12-11 15:44:51 EST
jiri: maybe print the "you might have hit" message *after* the fallback succeeds (if it does), not before? presumably there are other situations in which you get no DHCPOFFERS. logically speaking, it seems more accurate to print the message in the case where we get no offers without the fallback but we do get offers after the fallback. Or are there possibly cases where even the fallback won't work, but this is still the bug and adding the 'hardware' workaround will help?
Comment 29 Jiri Popelka 2014-12-12 04:51:35 EST
(In reply to Adam Williamson (Red Hat) from comment #28)
> jiri: maybe print the "you might have hit" message *after* the fallback
> succeeds (if it does), not before?

Right, new scratch-build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=8358931
Comment 30 Arthur Clement 2014-12-12 12:25:58 EST
Jiri,

It's not working with 4.3.1-12.fc21 and the RV320.

rmps from koji :
dhclient                  12:4.3.1-12.fc21  
dhcp-common               12:4.3.1-12.fc21 
dhcp-libs                 12:4.3.1-12.fc21  


It's working with the custum dhclient.conf though.
Comment 31 Jiri Popelka 2014-12-13 23:17:58 EST
(In reply to Arthur Clement from comment #30)
> It's not working with 4.3.1-12.fc21 and the RV320.

(In reply to Arthur Clement from comment #22)
> it's solved with an empty string.

Strange, cause this is what we do when we fail to obtain any offer.
Could you run
# sudo tcpdump -i <interface> -w client-id.pcap
in another terminal and retry it ?
Then please attach the client-id.pcap here. Thanks
Comment 32 Boris Glawe 2014-12-15 09:11:42 EST
I can confirm the same behavior as originally described by David Krovich.

I use a Fritzbox 7270 v2 as my dhcp server.

You mentioned, that you're going to contact server providers, if their solution are affected by the RFC compliance failure.

http://fedoraproject.org/wiki/Common_F21_bugs#IP_address_discovery_via_DHCP_does_not_work

The provider in this case is http://avm.de/

I have no idea, whether other AVM/Fritz routers are also affected. AVM recently released version 6.20 of their firmware/operating system. It will however not be released for old hardware like mine. Any idea, whether AVM fixed this problem?
Comment 33 Jiri Popelka 2014-12-15 10:24:53 EST
Boris, could you try with
http://koji.fedoraproject.org/koji/taskinfo?taskID=8358931
(see also comment #27)
Comment 34 Boris Glawe 2014-12-15 15:04:55 EST
Hi Jiri,

I've installed the version "-12" rpms that I found via your link above and rebootet. Dhcp did not work. Thus I rolled back to the "-8" version.
However the trick with the dhclient.conf works for me for the current -8 version and the -12 version.

In addition I've issued an informal bug report at AVM via the AVM support contact form. I'll post the response, if I get an answer.
Comment 35 Jiri Popelka 2014-12-16 05:01:55 EST
Can *somebody* with the installed testing package(s) show me the actual output from dhclient when running
# > /var/lib/dhclient/dhclient.leases; dhclient -d <interface>

and/or attach packet dump obtained with
# tcpdump -i <interface> -vvv '(port 67 or port 68)' -U -w packet.dump

I don't have the HW so "it doesn't work" isn't enough to debug that. Thank you.
Comment 36 Arthur Clement 2014-12-16 17:25:12 EST
Hi Jiri,

"It doesn't work" is the best IT answer EVER :)

I'll do the capture tomorrow as soon as reach my work network.
Comment 37 Arthur Clement 2014-12-17 09:09:51 EST
Ok, so I got patient and I got this message :

dhclient -d em1
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/em1/
Sending on   LPF/em1/
Sending on   Socket/fallback
Created duid \000\001\000\001\034$HG(\322DG(@.

DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 4 (xid=0x5e6f410)
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 9 (xid=0x5e6f410)
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 19 (xid=0x5e6f410)
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 15 (xid=0x5e6f410)
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 14 (xid=0x5e6f410)
No DHCPOFFERS received.
You might have hit https://bugzilla.redhat.com/show_bug.cgi?id=1154200
Try to put 'send dhcp-client-identifier = hardware;' into /etc/dhcp/dhclient.conf
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 4 (xid=0x8fa6165)
DHCPREQUEST on em1 to 255.255.255.255 port 67 (xid=0x8fa6165)
DHCPOFFER from 192.168.1.1
DHCPACK from 192.168.1.1 (xid=0x8fa6165)
bound to 192.168.1.53 -- renewal in 34436 seconds.


but dhclient hung and I lost network few seconds after bounding (maybe because I also have NetworkManager). Anyway, it's too long to get an ip with this workaround, it's better to keep the client identifier by default.
Comment 38 Arthur Clement 2014-12-17 09:11:33 EST
Created attachment 970138 [details]
packet.dump packet_dhclient-4.3.1-12.dump
Comment 39 Jiri Popelka 2014-12-17 10:17:39 EST
(In reply to Arthur Clement from comment #37)
> Ok, so I got patient and I got this message :

Thank you. It seems you're using the scratch-build from comment #27, could you also try the one from comment #29, i.e.
http://koji.fedoraproject.org/koji/taskinfo?taskID=8358931

> but dhclient hung and I lost network few seconds after bounding

I can see it sent a Request (with client-id) 2s after bounding,
which I have no idea how to explain.

>(maybe because I also have NetworkManager).

I don't think it's related, but who knows.

> Anyway, it's too long to get an ip with
> this workaround, it's better to keep the client identifier by default.

I know, this is intended for those who don't know the work-around,
so they get some address even after long time and let them know that
there is a work-around available to avoid the long waiting next time.
Comment 40 Jiri Popelka 2014-12-17 10:20:33 EST
(In reply to Jiri Popelka from comment #39)
> Thank you. It seems you're using the scratch-build from comment #27, could
> you also try the one from comment #29, i.e.
> http://koji.fedoraproject.org/koji/taskinfo?taskID=8358931

They have the same version so you'll probably need to install it like:
# rpm -Uvh --force *.rpm
(I'll bump the version next time)
Comment 41 Arthur Clement 2014-12-17 10:41:15 EST
Created attachment 970174 [details]
new dump with build 8358933
Comment 42 Arthur Clement 2014-12-17 10:44:52 EST
Same as first time, it's working after a while -  without NetworkManager and without disconnection (the first disconnection might be my fault)

dump attached



dhclient -d em1                 
Internet Systems Consortium DHCP Client 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/em1/xxx
Sending on   LPF/em1/xxx
Sending on   Socket/fallback
Created duid \000\001\000\001\034$_G(\322DG(@.
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 5 (xid=0x35cf714f)
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 9 (xid=0x35cf714f)
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 10 (xid=0x35cf714f)
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 9 (xid=0x35cf714f)
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 14 (xid=0x35cf714f)
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 12 (xid=0x35cf714f)
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 2 (xid=0x35cf714f)
No DHCPOFFERS received.
Re-trying with empty client-identifier (RHBZ#1154200).
DHCPDISCOVER on em1 to 255.255.255.255 port 67 interval 4 (xid=0x147bbe05)
DHCPREQUEST on em1 to 255.255.255.255 port 67 (xid=0x147bbe05)
DHCPOFFER from 192.168.1.1
DHCPACK from 192.168.1.1 (xid=0x147bbe05)
bound to 192.168.1.53 -- renewal in 35597 seconds.
You might have hit https://bugzilla.redhat.com/show_bug.cgi?id=1154200
Try to put 'send dhcp-client-identifier = hardware;' into /etc/dhcp/dhclient.conf
Comment 43 Jiri Popelka 2014-12-17 11:42:12 EST
(In reply to Arthur Clement from comment #42)
> Same as first time, it's working after a while -  without NetworkManager and
> without disconnection (the first disconnection might be my fault)

Thanks. Not sure how to understand it now.
So it doesn't work with NM but works without it?
Comment 44 Arthur Clement 2014-12-17 12:15:00 EST
Ok, here a more precise test.

●  NM is running :

Last dhclient rpms from koji are installed and the custom dhclient.conf is removed.


If if try to connect with the graphical NetworkManager (KDE Applet), it doesn't work, it displays "setting up address.." then "em1 disconnected" (dump attached)

When I try with the cli dhclient, I got my ip with the workaround, then I lost the connection after ~1 minute. I think it's NM related because the NM applet displays a spinning arrow.



●  Without NM : dhclient workaround works fine. No disconnection after few minutes.
Comment 45 Arthur Clement 2014-12-17 12:15:50 EST
Created attachment 970201 [details]
dhclient from NM applet
Comment 46 W. Michael Petullo 2015-01-05 11:42:23 EST
I have another data point that might be of interest. I ran into this issue after returning to work from Christmas leave. Upon returning, I could not connect to our WiFi network (although I had been able to connect to a number of other networks). I worked with some engineers to figure out the problem.

Our case was slightly different. We run a DHCP server on UNIX, separate from our router. That DHCP server implements a MAC-address-based whitelist. In practice, the DHCP server seems to consider DHCP option 61 when enforcing its access controls. 

Setting "send dhcp-client-identifier = hardware;" allows me to connect again.

I thought this was worth bringing up because it seems not to be the case of a broken router/server, but instead the case of a bad---yet common---assumption. If DHCP option 61 has historically been set to a host's MAC address, then it is likely that administrators will assume this to be the case. Put another way: Fedora 21 users, when asked "what is your MAC address" before adding their computer to a new network need to be cognizant enough to ask "do you mean, what will my host send as DHCP option 61?"

At least this is my understanding after considering this issue. Thus proposal to fall back on the previous behavior proposed above probably makes sense.
Comment 47 Gabriel Somlo 2015-01-09 20:59:56 EST
I'm also dealing with a "hostile" dhcp server on one of the networks I need to be on, and the

  echo 'send dhcp-client-identifier = hardware;' >> /etc/dhcp/dhclient.conf

workaround helps on an already installed F21 machine.

However, I find myself needing to kickstart a F21 network install (both the
kickstart file and the repositories are only reachable over the network, through a proxy -- long story). Problem being, I can't get to the kickstart file because the F21 install image (which I'm booting from a USB stick) never gets a DHCP lease on this network.

Is there any way to apply the "dhcp-client-identifier = hardware" workaround to Anaconda/Kickstart, e.g. via some kernel boot arguments ? I didn't see anything promising in the anaconda manuals, but maybe someone on the cc list for this bug has more recent knowledge ?
Comment 48 Adam Williamson 2015-01-17 12:21:33 EST
It'd be good if some of the more recent reporters could test the builds from #c29? I believe Jiri is still looking for feedback on them.
Comment 49 Bruce Petrie 2015-01-28 16:48:46 EST
Running F20 on a system that has not had issues with dhcp assigned addresses for quite some time. fedup'ed to F21 and now has the problem. Nothing has been done to the netgear router running DD-WRT firmware during this F20 to F21 aftermath.

ifconfig shows the MAC as lower case alpha characters as usual. The dd-wrt router/AP had the MAC as upper case alpha. I changed the router DHCP MAC entry for this machine to lower case alpha, shut the machine down, expired the DHCP entry in the router and now the correct address is assigned on machine boot. 

1. I did not put the dhcp-client-identifier entry into the machine.
2. There is no explicit IP entry in hosts file.
3. ifcfg-em1 contains HWADDR= MAC address using upper case alpha characters and has not been changed.

new kernel-3.18.3-201.fc21.x86_64  dhclient-4.3.1-8.fc21.x86_64
old kernel-3.17.7-200.fc20.x86_64  not sure but had just done yum update

forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64
00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)
        Subsystem: Acer Incorporated [ALI] Device 0153

DD-WRT v24-sp2 (04/18/14) std - build 23919
Comment 50 Adam Williamson 2015-01-28 17:00:24 EST
Bruce: the thing that changed was the 'dhclient' package. Fedora 21 contains version 4.3. Fedora 20 contains version 4.2. Upstream changed to send an RFC 4631-compliant DHCP client identifier by default in version 4.3. This is explained in comment #25.

However, you're the first person (AFAICS) to say dd-wrt is affected by this. Can you check whether the workaround does work for you, as you said you haven't tried yet? If it doesn't, you might be running into something else. Thanks!
Comment 51 Bruce Petrie 2015-01-28 22:45:08 EST
Adam: Understand about comment #25. My initial test triggered the thought was that the router was not handling MAC addresses with case insensitivity. This is significant since there are web site comments stating that more than one router vendor contracts with that firm for customized firmware. This could account for some of the observed behavior.

Wanted to eliminate as many variables has possible by first reverting the router DHCP MAC back to the upper case hex characters and making sure the F21 machine has issues again. This has proven hard to do perhaps due to caching in the F21 machine/router or cockpit error.

Removing NetworkManager*.lease in single user mode, clearing arp cache, deleting router nvram entries, changing the DHCP lease IP and shortening the lease time are some of the areas I am working on.

Will update after more attempts. Take care.
Comment 52 Rudi Middel 2015-06-11 08:14:38 EDT
Today I tried to get my new USB WiFi dongle to work on F22. At first I was not able to receive a DHCP assign IP Number. A fixed address however did work. Therefore I tried the solution with added information in the dhclient.conf. This solved my issue. So it seems to be persistent in F22 as well

My laptop:
HP Pavilion g7
Fedora Dekstop 22 (64-bit; Gnome Version 3.16.2)
Wireless: WLA-2100
dhcpclient: isc-dhclient-4.3.2
NetworkManager: 1.0.2-1.fc22

My Server:
Raspberry Pi 2
Raspbian Wheezy (latest update)
dhcpserver: isc-dhcpd-4.2.2

My network: 
AccessPoint: Sitecom 300N (DHCP disabled)
Switch: ProCurve 1800-24G (J9028B)
Comment 53 Ryan O'Hara 2015-06-15 12:55:06 EDT
On a related note, I've noticed that that the client identifier generated during a kickstart install does not match the client identified that is used post-install (ie. first boot). The DHCP server is configured for static leases. During install I get the correct IP address from DHCP, but after reboot I get a different, incorrect IP address from DHCP because 1) the correct IP address is leased and 2) the client-identifier does not match. This seems like a bug. Can someone shed some light on how the client identifier is generated and why it is not consistent?

If I set dhcp-client-identifier = hardware in /etc/dhcp/dhclient, it helps. But as stated in comment #47 there is no way to set this in anaconda/kickstart. By the time you hit the %pre script it is too late.
Comment 56 Pavel Šimerda (pavlix) 2015-10-29 10:26:54 EDT
(In reply to Ryan O'Hara from comment #53)
> On a related note, I've noticed that that the client identifier generated
> during a kickstart install does not match the client identified that is used
> post-install (ie. first boot).

That reminds me of:

https://fedoraproject.org/wiki/QA/Networking/Configuration#DUID_assignment_and_stability
Comment 57 Ryan O'Hara 2015-10-30 04:21:53 EDT
(In reply to Pavel Šimerda (pavlix) from comment #56)
> (In reply to Ryan O'Hara from comment #53)
> > On a related note, I've noticed that that the client identifier generated
> > during a kickstart install does not match the client identified that is used
> > post-install (ie. first boot).
> 
> That reminds me of:
> 
> https://fedoraproject.org/wiki/QA/Networking/
> Configuration#DUID_assignment_and_stability

Absolutely.

To be clear, what is really annoying (to me) here is that I used static DHCP and it just does not work as expected because the DUID is changing.
Comment 58 Fedora End Of Life 2015-11-04 10:18:27 EST
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 '21'.

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 21 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 59 Fedora End Of Life 2015-12-01 23:21:59 EST
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.
Comment 60 Gergo 2016-04-04 13:11:58 EDT
*** Bug 1276073 has been marked as a duplicate of this bug. ***
Comment 61 Alex 2016-09-16 01:13:50 EDT
Hi,

I am using fedora24 and this error is still happening. Only "fixed" by adding 
"send dhcp-client-identifier = hardware;" to /etc/dhcp/dhclient.conf
Comment 62 Jonh Wendell 2016-10-01 17:21:44 EDT
exactly same this as Alex. F24, got a new router and dhcp client stopped get an address until I added this line to dhclient.conf
Comment 63 Jiri Popelka 2016-10-04 10:02:21 EDT
*** Bug 1381594 has been marked as a duplicate of this bug. ***
Comment 64 Fedora Admin XMLRPC Client 2017-04-04 08:32:40 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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