Description of problem: dhclient does not reuse hardware address on (re)start of ppp interface Version-Release number of selected component (if applicable): dhclient-4.2.7-2.fc20.i686 How reproducible: Run dhclient for Prefix Delegation over pppoE connection. Wait for pppd to go down after some time. Stop dhclient. Start dhclient after pppd has connection again. (dhclient -6 -P ppp0) Check messages file. Actual results: xid: warning: no netdev with useable HWADDR found for seed's uniqueness enforcement Expected results: No such warning Additional info:
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.
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.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. 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 '23'. 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 23 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.
It appears that this bug does not get the recognition it needs. Due to the changing HWADDR we get a delay from the ISP before our prefix is delegated to us again. This means that IPv6 is not working during that time which shines a bad light on IPv6.
And it can be easily reproduced: Feb 24 13:56:41 epia dhclient[10699]: xid: warning: no netdev with useable HWADDR found for seed's uniqueness enforcement Feb 24 13:56:41 epia dhclient[10699]: xid: rand init seed (0xf0704f83) built using gethostid Feb 24 13:56:42 epia dhclient[10699]: XMT: Rebind on ppp0, interval 1050ms. Feb 24 13:56:43 epia dhclient[10699]: XMT: Rebind on ppp0, interval 2030ms. Feb 24 13:56:45 epia dhclient[10699]: XMT: Rebind on ppp0, interval 3980ms. Feb 24 13:56:49 epia dhclient[10699]: XMT: Rebind on ppp0, interval 2940ms. Feb 24 14:55:56 epia dhclient[10699]: PRC: Prefix 2001:981:a812::/48 depreferred. Feb 24 14:55:57 epia dhclient[10699]: PRC: Prefix 2001:981:a812::/48 expired. Feb 24 14:55:57 epia dhclient[10699]: PRC: Bound lease is devoid of active addresses. Re-initializing. Feb 24 14:55:57 epia dhclient[10699]: XMT: Solicit on ppp0, interval 1010ms. Feb 24 14:55:58 epia dhclient[10699]: RCV: Advertise message on ppp0 from fe80::2a0:a50f:fc7e:d260. Feb 24 14:55:58 epia dhclient[10699]: XMT: Request on ppp0, interval 910ms. Feb 24 14:55:59 epia dhclient[10699]: RCV: Reply message on ppp0 from fe80::2a0:a50f:fc7e:d260. I.e.: this issue introduces a one hour delay because the ISP does notice that the address has changed. A simple way to borrow the address from an underlying ethernet device or to specify one would help.
FWIW: MACADDR= will not help in case of ppp interfaces. And no pppd option fixes this issue as far as I could find. (including ipv6cp-use-persistent and ipv6cp-use-ipaddr) We can only conclude that dhclient does not really support ipv6 as one config option could fix this.
But... After re-reading the dhclient.conf man page I tried a little dhclient.conf: # cat dhclient.conf interface "ppp0" { hardware ethernet 00:a0:24:ab:fb:9c; prepend domain-name-servers 127.0.0.1; } # Below is some logging output of restarting the dhclient; first without this configuration, (notice the warning) and then twice with the config shown before this: Feb 24 15:17:23 epia dhclient[12744]: xid: warning: no netdev with useable HWADDR found for seed's uniqueness enforcement Feb 24 15:17:23 epia dhclient[12744]: xid: rand init seed (0xf0702279) built using gethostid Feb 24 15:17:24 epia dhclient[12744]: XMT: Rebind on ppp0, interval 980ms. Feb 24 15:17:25 epia dhclient[12744]: XMT: Rebind on ppp0, interval 2030ms. Feb 24 15:17:27 epia dhclient[12744]: XMT: Rebind on ppp0, interval 3940ms. Feb 24 15:17:31 epia dhclient[12744]: XMT: Rebind on ppp0, interval 3050ms. Feb 24 15:40:40 epia dhclient[13567]: xid: rand init seed (0x9cfbab24) built using all available interfaces Feb 24 15:40:40 epia dhclient[13567]: XMT: Rebind on ppp0, interval 1040ms. Feb 24 15:40:41 epia dhclient[13567]: XMT: Rebind on ppp0, interval 2080ms. Feb 24 15:40:43 epia dhclient[13567]: XMT: Rebind on ppp0, interval 3990ms. Feb 24 15:40:47 epia dhclient[13567]: XMT: Rebind on ppp0, interval 2890ms. Feb 24 15:41:06 epia dhclient[13765]: xid: rand init seed (0x9cfbab24) built using all available interfaces Please notice the similar rand init seed values in the latter two lines about this. Please allow for some further testing to confirm if this creates a situation without delays after restarting dhclient.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
(In reply to udo from comment #7) > Please allow for some further testing to confirm if this creates a situation > without delays after restarting dhclient. Hello, How is your testing going? Can you confirm that adding hw address to the configuration fixed the issue? Thank you!
(In reply to Pavel Zhukov from comment #9) > How is your testing going? Can you confirm that adding hw address to the > configuration fixed the issue? It appears that the issue is gone. Together with the hw address I empty the leases file except the duid line: echo 'default-duid "\000\001\000\001\017\214\237y\000@c\346\012\000";' > /var/lib/dhclient/dhclient6.leases This makes for a quicker startup (getting a prefix lease) from the ISP.
(In reply to udo from comment #10) > (In reply to Pavel Zhukov from comment #9) > > How is your testing going? Can you confirm that adding hw address to the > > configuration fixed the issue? > > It appears that the issue is gone. Thank you. Seems like related code is changed upstream as well so hopefully we will see some improvements next release. I'll play with ppp a bit to verify this. P.S. It's better to change "default" hw address from the config with real one :-)
Setting priority to medium as we have workaround in place.
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.
Seems the problem is in interface discovery function. It doesn't scan for hw addresses properly so as the result seed is all zeros
Hello, Can you please verify package [1] (f27) or [2] (f26) and check if it fixes your issue and doesn't have any noticeable regressions. Note: workaround from https://bugzilla.redhat.com/show_bug.cgi?id=1555387#c1 still needed (it's better to allow dhclient to generate duid insead of specify one manually). I've verified it using rawhide and my local reproducer (it's not perfect tbh). # write duid # dhclient -6 -d # First run # dhclient -P -6 -d ppp0 Internet Systems Consortium DHCP Client 4.3.6 Copyright 2004-2017 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on Socket/ppp0 Sending on Socket/ppp0 xid: rand init seed (0x79870900) built using all available interfaces PRC: Soliciting for leases (INIT). XMT: Forming Solicit, 0 ms elapsed. XMT: X-- IA_PD 00:00:00:00 # Second run # dhclient -P -6 -d ppp0 Internet Systems Consortium DHCP Client 4.3.6 Copyright 2004-2017 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on Socket/ppp0 Sending on Socket/ppp0 xid: rand init seed (0x79870900) built using all available interfaces PRC: Soliciting for leases (INIT). XMT: Forming Solicit, 0 ms elapsed. XMT: X-- IA_PD 00:00:00:00 XMT: | X-- Request renew in +3600 XMT: | X-- Request rebind in +5400 XMT: Solicit on ppp0, interval 1010ms. NOTE: Seeds are equal not xid warning Thanks, [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25841343 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=25841345
SELF NOTE: HTYPE_RESERVED should be excluded from the seed generation
Thanks! Sunday I'll have a look.
Copr repo (scratch builds will be deleted soon): https://copr.fedorainfracloud.org/coprs/landgraf/dhcp-bz1163379/
Sorry for the delay. We run Fedora 26 here, so we downloaded from https://koji.fedoraproject.org/koji/taskinfo?taskID=25841376 Initial test confirms behaviour as described by you.
(In reply to udo from comment #19) > Sorry for the delay. We run Fedora 26 here, so we downloaded from > https://koji.fedoraproject.org/koji/taskinfo?taskID=25841376 > Initial test confirms behaviour as described by you. Thank you. I'm pushing fix into rawhide branch. I'm not going to push updates for stable fedora until we have upstream's opinion. If you need F26/F27 builds please use Copr repo https://copr.fedorainfracloud.org/coprs/landgraf/dhcp-bz1163379/
Reopening this, because it's fairly broken: it aborts in case an interface is present that is not ARPHRD_ETHER, ARPHRD_IEEE802, ARPHRD_IEEE802_TR, ARPHRD_FDDI, ARPHRD_INFINIBAND or ARPHRD_PPP: [root@belphegor lkundrak]# dhclient -d -v dummy0 Internet Systems Consortium DHCP Client 4.3.6 Copyright 2004-2017 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ kokotUnsupported device type 803 for "hwsim0" This version of ISC DHCP is based on the release available on ftp.isc.org. Features have been added and other changes have been made to the base software release in order to make it work better with this distribution. Please report issues with this software via: https://bugzilla.redhat.com/ exiting. [root@belphegor lkundrak]# Thanks for not pushing this to F27/F28, but please drop this from F29 also, until a there's a better fix. Thanks!
Hello Ludomir, First of all the original bug report was to support PPPoE and not other device types so please open separate bug if you think dhcp should support radiotap devices (at first glance it doesn't looks so). If you have better fix - you can always submit a patch upstream or using Fedora pagure.