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:
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.
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.
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
(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.
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.
(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.
(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
Created attachment 950052 [details] dhclient with an identifier
Created attachment 950053 [details] dhclient with no identifier
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
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.
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.
(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.
(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.
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.
Forgot to mention that I do not assign static addresses on this router.
*** Bug 1158838 has been marked as a duplicate of this bug. ***
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.
Thanks to these comments. I had this problem with the RV320 as well and it's solved with an empty string.
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.
Same here. We got a microsoft windows server infrastructure. Please change the default mechanism back to 'hardware'
(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
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.
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?
(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
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.
(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
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?
Boris, could you try with http://koji.fedoraproject.org/koji/taskinfo?taskID=8358931 (see also comment #27)
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.
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.
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.
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.
Created attachment 970138 [details] packet.dump packet_dhclient-4.3.1-12.dump
(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.
(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)
Created attachment 970174 [details] new dump with build 8358933
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
(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?
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.
Created attachment 970201 [details] dhclient from NM applet
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.
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 ?
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.
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
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!
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.
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)
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.
(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
(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.
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.
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.
*** Bug 1276073 has been marked as a duplicate of this bug. ***
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
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
*** Bug 1381594 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Lowering the priority once we have workaround in place
*** Bug 1471900 has been marked as a duplicate of this bug. ***
Small update. I've submitted patch to dracut once it's released in Fedora installer should use HW address as client-identifier. https://github.com/dracutdevs/dracut/commit/4011b48c4261426c0cc51e5e063c4ac929153956
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. 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 '24'. 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 24 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.
still happening on freshly installed fedora26. Using my own previous post to fix it.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 '26'. 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 26 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.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 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.