Bug 1329210
Summary: | dhclient fails to assemble DUID while requesting IPv6 prefix delegation using PPP device | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Steven Haigh <netwiz> |
Component: | dhcp | Assignee: | Pavel Zhukov <pzhukov> |
Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 7.4 | CC: | netwiz, pzhukov, thozza, udovdh |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-06-19 11:56:01 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1380362, 1420851, 1534569 |
Description
Steven Haigh
2016-04-21 12:21:53 UTC
I also note that ISC DHCP 4.2.x has been deprecated as of Aug 2015. The current ESV version is 4.3.4. (In reply to Steven Haigh from comment #0) > xid: warning: no netdev with useable HWADDR found for seed's uniqueness > enforcement > Cannot form default DUID from interface ppp0. > Failure assembling a DUID. I know about this and it's a long story (bug #626514). Hi Jiri, I did notice that - but also noticed it was against Fedora (even though it was an OLD version - since updated to rawhide). While I did read a substantial amount of that BZ, I didn't get any impression of a way forward for it... Do you know if this problem still exists when using the 4.3.4 release from ISC? Australia is starting to do a rather large set of IPv6 deployments of recent time - and just about everywhere in this country is PPPoE. (In reply to Steven Haigh from comment #4) > Do you know if this problem still exists when using the 4.3.4 release from ISC? I think so, yes. There are many people watching that BZ and trying to work-around the problem so we would know if it was already fixed upstream. I figured I'd add a quick poke to the above referenced BZ for Fedora - as the last real comment there was nearly 2 years ago now. I might as well add this to the record. My workaround for this issue right now is to add the following to a new file /sbin/ifup-local. This file runs when any interface comes up. I also have /sbin/ifdown-local which runs when any interface goes down. $ cat /sbin/ifup-local #!/bin/bash case "$1" in ppp0) LEASEFILE=/var/lib/dhclient/dhclient6.leases INTERFACE=ppp0 myhwaddr=`ip add | grep link/ether | cut -f 6 -d \ | tail -n 1 | sed s/:/\\\\\\\\x/g` echo "default-duid \"\\x00\\x03\\x00\\x01\\x$myhwaddr\";" > $LEASEFILE dhclient -v -P -lf $LEASEFILE $INTERFACE ;; *) ;; esac exit 0 $ cat /sbin/ifdown-local #!/bin/bash logger "ifdown-local: $1" case "$1" in ppp0) PIDFILE=/var/run/dhclient6.pid if [ -f $PIDFILE ]; then PID=`cat $PIDFILE` kill -9 $PID fi ;; *) esac exit 0 (In reply to Steven Haigh from comment #7) > I might as well add this to the record. > > My workaround for this issue right now is to add the following to a new file > /sbin/ifup-local. This file runs when any interface comes up. I also have > /sbin/ifdown-local which runs when any interface goes down. > > $ cat /sbin/ifup-local > #!/bin/bash > case "$1" in > ppp0) > LEASEFILE=/var/lib/dhclient/dhclient6.leases > INTERFACE=ppp0 > myhwaddr=`ip add | grep link/ether | cut -f 6 -d \ | tail -n > 1 | sed s/:/\\\\\\\\x/g` > echo "default-duid \"\\x00\\x03\\x00\\x01\\x$myhwaddr\";" > > $LEASEFILE > dhclient -v -P -lf $LEASEFILE $INTERFACE > ;; > *) > ;; > esac > exit 0 > > $ cat /sbin/ifdown-local > #!/bin/bash > logger "ifdown-local: $1" > case "$1" in > ppp0) > PIDFILE=/var/run/dhclient6.pid > if [ -f $PIDFILE ]; then > PID=`cat $PIDFILE` > kill -9 $PID > fi > ;; > *) > esac > exit 0 That looks good at least as a starting point. Just thought I'd give this a bit of a poke and see if there is any progress on getting this long lived issue fixed? We're about 6 months since the last update... Just wondering if theres any chance of this getting some love? (In reply to Pavel Šimerda (pavlix) from comment #10) > (In reply to Steven Haigh from comment #7) (....) > That looks good at least as a starting point. The script is only a workaround; the workaround works quite well though. Link please? (In reply to udo from comment #18) > Link please? Hello, Not sure if I understood the question. Can you elaborate? (In reply to Steven Haigh from comment #16) > We're about 6 months since the last update... Just wondering if theres any > chance of this getting some love? Hello Steven, I'd like to ask you to contact your Support Representative for SLA related questions. Red Hat does NOT guarantee any response time or Service Level Agreement (SLA) for Bugzilla entries. - A review might happen immediately or after a time span of any length. The SLAs for Red Hat Enterprise Linux provided by Red Hat Support can be found at: https://www.redhat.com/support/policy/sla/production/ Issues coming through the regular support process, will always be prioritized higher than issues of similar impact and severity that are being filed directly through Bugzilla (unless the later get linked to customer support tickets, like this issue was). This means that they are more likely to be addressed and they are more likely to meet inclusion criteria consistent with the Red Hat Enterprise Linux life cycle policy: http://www.redhat.com/security/updates/errata/ Yep - its probably (at least) my support ticket that is linked to this BZ report - as I provided the links to both this ticket, and the identical one on Fedora in my support case. (In reply to Pavel Zhukov from comment #19) > (In reply to udo from comment #18) > > Link please? > > Hello, > Not sure if I understood the question. Can you elaborate? The link question is clear enough. It appears that Redhat (RH) thinks this 'knowledge' needs to be monetized, i.e.: I cannot see it. That means it is of no help to me. The link is here: https://access.redhat.com/solutions/3129591 The article is incorrect anyhow. The issue title states: "IPv6 address cannot be obtained via Point-to-Point connection." The problem is not that you can't get an IPv6 address via PPP - as you can. That is what the ipv6 option is for to pppd. This part works fine. dhclient is used to get a Prefix Delegation (PD) from your ISP (if this is supported). https://en.wikipedia.org/wiki/Prefix_delegation The dhclient man page states: "-P Enable IPv6 prefix delegation. This implies -6 and also disables the normal address query. See -N to restore it. Note only one requested interface is allowed." The article uses an inferior version of my script above that was put together over several iterations. Even my script above is inferior to the version I included in the Fedora version of this ticket (which is almost at its 7th birthday): https://bugzilla.redhat.com/show_bug.cgi?id=626514 The method here can be directly integrated into NetworkManager's dispatcher: https://bugzilla.redhat.com/show_bug.cgi?id=626514#c161 (In reply to Steven Haigh from comment #23) > The link is here: https://access.redhat.com/solutions/3129591 Thanks but no thanks, It says: Subscriber exclusive content And withholds info. I do think a NetworkManager-less solution is better. Can someone explain PLEASE that to the Fedora people? (please see their 'solution' for VNC) faking a DUID is the ultimate solution. The non-NetworkManager solution is to use pretty much the same script as either /sbin/ifup-local and /sbin/ifdown-local - or in /etc/ppp/ip-up.local or /etc/ppp/ip-down.local I now hook into NetworkManager via the following: /etc/ppp/ip-up.local and /etc/ppp/ip-down.local (you can hardlink these together): #!/bin/sh if [[ $0 == *"ip-up.local" ]]; then STATUS=up; fi if [[ $0 == *"ip-down.local" ]]; then STATUS=down; fi for i in `run-parts --list /etc/NetworkManager/dispatcher.d`; do echo "Running $i" $i $1 $STATUS done Then in /etc/NetworkManager/dispatcher.d/50-network-functions: #!/bin/bash INTERFACE=$1 # The interface which is brought up or down STATUS=$2 # The new state of the interface logger "$0 called with: 1 = $1 2 = $2" ## Reset selinux tags in /run - this screws up a lot. restorecon -R /run/ || true case "$INTERFACE" in ppp0) if [ "$STATUS" = "up" ]; then dhclient -x -pf /var/run/dhclient6.pid || true LEASEFILE=/var/lib/dhclient/dhclient6.leases myhwaddr=`ip add | grep link/ether | cut -f 6 -d \ | tail -n 1 | sed s/:/\\\\\\\\x/g` echo "default-duid \"\\x00\\x03\\x00\\x01\\x$myhwaddr\";" > $LEASEFILE dhclient -6 -P -v -nw -lf $LEASEFILE -pf /var/run/dhclient6.pid $INTERFACE fi if [ "$STATUS" = "down" ]; then dhclient -x -pf /var/run/dhclient6.pid || true fi ;; esac exit 0 Mainly because NetworkManager doesn't seem to fire dispatcher events / scripts on ppp links. *sigh* Or something like: # cat sbin/adsl-start #!/bin/bash # Source function library. . /etc/init.d/functions iface=ppp0 route del default rm -f /var/run/$iface".pid" /usr/sbin/pppd call vdsl #echo pppd gestart... num=0 while [[ ! -f /var/run/$iface".pid" && (($num -lt 35 )) ]]; do echo -n . sleep 1 ((num++)) done echo $num [[ $num -gt 34 && ! -f /var/run/$iface".pid" ]] && exit 1 pid=`cat /var/run/$iface".pid"` echo $pid while $(checkpid $pid); do if /sbin/ifconfig|grep $iface > /dev/null ; then echo $iface break else echo -n . sleep 1 fi done echo route add default dev ppp0 route add default dev ppp0 echo ip -6 route add default dev ppp0 ip -6 route add default dev ppp0 /usr/local/sbin/wshaper start # echo '----' #dhclient -6 -r ppp0 killall -9 dhclient 2> /dev/null echo 'default-duid "\000\001\000\201\017\214\117y\00@@c\366\002\000";' > /var/lib/dhclient/dhclient6.leases echo '----' dhclient -6 -P ppp0 & echo ip -6 addr add 20XX:X81:aXX2:0:2X0:XXXf:feXX:XXX/64 dev eth0 ip -6 addr add 20XX:X81:aXX2:0:2X0:XXXf:feXX:XXX/64 dev eth0 # if pidof radvd > /dev/null ; then echo . # bla else service radvd start fi sleep 1 (In reply to udo from comment #24) > I do think a NetworkManager-less solution is better. > Can someone explain PLEASE that to the Fedora people? Sure. You can For fedora people https://fedoraproject.org/wiki/How_to_contribute_to_Docs. For even more dhcp users: https://lists.isc.org/mailman/listinfo/dhcp-users I appreciate your feedback but this bug is not Fedora related. Using uppercasing is not helpful in bug resolution nor productive in any sense. > > (please see their 'solution' for VNC) > > faking a DUID is the ultimate solution. Bugzilla is not right place for such kind of discussion nor support/documentation tool. I'd like to ask you to contact upstream if you think it should have wider evidence / attention and remind you the "Upstream first" rule [1] [1] https://fedoraproject.org/wiki/Staying_close_to_upstream_projects Hi all, It would be great if we could see the two blocker bugs linked to this. They are currently both set to private. (In reply to Steven Haigh from comment #28) > Hi all, > > It would be great if we could see the two blocker bugs linked to this. They > are currently both set to private. Id would not. Linked bugs are part of internal tracking/prioritization process so they contain nothing related to the subject of this bug report. Thank you for understanding Simple workaround: run dhclient on any interface which is constantly connected to the server: dhclient -P -6 -d <iface> wait for first Solicity message Interrupt dhclient process (Ctrl-C) run dhclient on ppp0 interface. duid will be generated, stored in leases file and used for ppp interface Simple workaround for the problem is run dhclient on any interface with hw address (ethernet, bridge etc) and abort the process after few seconds. Since that uuid is generated and written in leases file and used for ppp connection. So this bug was not considered as a priority for the release, so it's being closed now as WONTFIX. Feel free to re-open the bug if there is a business reason to deliver a fix for this issue. |