Bug 1657848
| Summary: | dhclient ignores given interface | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jari Turkia <redhat-bugzilla> | ||||
| Component: | dhcp | Assignee: | Pavel Zhukov <pzhukov> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 29 | CC: | dcantrell, jpopelka, pemensik, pzhukov, redhat-bugzilla, thozza | ||||
| Target Milestone: | --- | ||||||
| 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-02-13 20:00:59 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: | |||||||
| Attachments: |
|
||||||
This is weird. I use dhclient with interface specified on daily basis for testing and on some machines and never seen this behavior. # dhcp-client-4.3.6-32.fc30.x86_64 1: lo 2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 4: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 7: dh1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 8: dh2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 # sudo /sbin/dhclient -1 -d -lf /var/lib/dhclient/dhclient--eno1.lease -pf /run/dhclient-eno1.pid -H myPCame dh1 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 LPF/dh1/7a:7b:a8:ba:2f:06 Sending on LPF/dh1/7a:7b:a8:ba:2f:06 Sending on Socket/fallback DHCPDISCOVER on dh1 to 255.255.255.255 port 67 interval 8 (xid=0xf3cbb83e) Actually nobody else reported this before. Can you please provide reproducer? Do you have some special setup? My setup has really nothing special, besides having multiple physical network interfaces. I've been running similar ones since Fedora Core 1 and first one not working for me is Fedora 29. Looking at your list of interfaces: 1: lo 2: enp0s25 3: wlp3s0 4: br0 5: virbr0 6: virbr0-nic 7: dh1 8: dh2 The ones looking physical ones are: 2: enp0s25 3: wlp3s0 all other ones are local, bridged or alias. Feel free to point out the actual physical devices in case I'm reading the list wrong. In my original bug report I wrote: "All suitable interfaces are flagged as INTERFACE_AUTOMATIC and DISCOVER_REQUESTED." Definition of word "suitable" is critical here. By looking at client/dhclient.c the detection logic knows about different types of network interfaces. The code completely ignores network inteface command-line argument at that point. As my patch suggest, it should discover _only_ that given interface. I should be able to produce a Fedora 29 KVM QCow2 -image having this issue. My suggestion to reproduce: Run a system with two physical NICs both using DHCP and see how it fails. (In reply to Jari Turkia from comment #2) > I should be able to produce a Fedora 29 KVM QCow2 -image having this issue. > My suggestion to reproduce: > Run a system with two physical NICs both using DHCP and see how it fails. I've created qemu VM with 3 NICs: # dhcp-client-4.3.6-29.fc30.x86_64 00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) 00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) First one is able to get IP address without any problems # dhclient -d ens3 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 LPF/ens3/52:54:00:12:34:56 Sending on LPF/ens3/52:54:00:12:34:56 Sending on Socket/fallback DHCPREQUEST on ens3 to 255.255.255.255 port 67 (xid=0x78c70a71) DHCPACK from 192.168.122.1 (xid=0x78c70a71) bound to 192.168.122.76 -- renewal in 1479 seconds. Second one as well: ]# dhclient -d ens4 -pf /var/run/dhclient4.pid 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 LPF/ens4/52:54:00:12:34:57 Sending on LPF/ens4/52:54:00:12:34:57 Sending on Socket/fallback DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 3 (xid=0x6ec2d953) DHCPREQUEST on ens4 to 255.255.255.255 port 67 (xid=0x6ec2d953) DHCPOFFER from 192.168.122.1 DHCPACK from 192.168.122.1 (xid=0x6ec2d953) bound to 192.168.122.77 -- renewal in 1372 seconds. As you can see it use correct interface to send the request. qemu connect all nics to same hub. So (qemu) set_link hub0port3 off (qemu) set_link hub0port2 off # dhclient -d ens4 -pf /var/run/dhclient4.pid 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 LPF/ens4/52:54:00:12:34:57 Sending on LPF/ens4/52:54:00:12:34:57 Sending on Socket/fallback DHCPREQUEST on ens4 to 255.255.255.255 port 67 (xid=0xf645e07) DHCPREQUEST on ens4 to 255.255.255.255 port 67 (xid=0xf645e07) Or using exact command you provided with: # /sbin/dhclient -1 -d -lf /var/lib/dhclient/dhclient--eno1.lease -pf /run/dhclient-eno1.pid -H myPCame ens4 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 LPF/ens4/52:54:00:12:34:57 Sending on LPF/ens4/52:54:00:12:34:57 Sending on Socket/fallback DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 5 (xid=0x6ace8815) DHCPDISCOVER on ens4 to 255.255.255.255 port 67 interval 7 (xid=0x6ace8815) /sbin/dhclient -1 -d -lf /var/lib/dhclient/dhclient--eno1.lease -pf /run/dhclient-eno1.pid -H myPCame ens5 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 LPF/ens5/52:54:00:12:34:58 Sending on LPF/ens5/52:54:00:12:34:58 Sending on Socket/fallback DHCPDISCOVER on ens5 to 255.255.255.255 port 67 interval 7 (xid=0x53f9e070) DHCPDISCOVER on ens5 to 255.255.255.255 port 67 interval 7 (xid=0x53f9e070) Given the unavailability of Fedora 30 binaries, I downloaded dhcp-4.3.6-32.fc30.src.rpm and built it in my F29. # rpm -q dhcp-client dhcp-client-4.3.6-32.fc29.x86_64 The issue is gone. Apparently somebody picked it up and fixed it in one of those three versions after 4.3.6-28.fc29. I'm resolving the bug. |
Created attachment 1513100 [details] Fix to enable functionality on dhclient to run on a given interface Description of problem: When networking is using classic interface management (network-scripts.rpm) and when an interface is configured to use DHCP as bootproto, it will execute dhclient with a command-line similar to this: /sbin/dhclient -1 -q -lf /var/lib/dhclient/dhclient--eno1.lease -pf /run/dhclient-eno1.pid -H myPCame eno1 When same command-line is run without -q and -d added, output will contain: Listening on LPF/enp3s0f1/90:e2:ba:00:00:01 Sending on LPF/enp3s0f1/90:e2:ba:00:00:01 Listening on LPF/eno1/60:a4:4c:00:00:01 Sending on LPF/eno1/60:a4:4c:00:00:01 Listening on LPF/enp3s0f0/90:e2:ba:00:00:02 Sending on LPF/enp3s0f0/90:e2:ba:00:00:02 Sending on Socket/fallback This list is obviously not what was intended. There should be a single network interface listed (eno1). As an expected fallout of this issue, following happens: DHCPDISCOVER on enp3s0f1 to 255.255.255.255 port 67 interval 3 DHCPREQUEST on eno1 to 255.255.255.255 port 67 DHCPDISCOVER on enp3s0f0 to 255.255.255.255 port 67 interval 5 DHCPACK from 62.248.219.2 DHCPREQUEST on enp3s0f0 to 255.255.255.255 port 67 DHCPOFFER from 84.249.192.3 DHCPACK from 84.249.192.3 DHCPDISCOVER on enp3s0f1 to 255.255.255.255 port 67 interval All detected interfaces start DHCP negotiation. Since command similar to this is run for each configured interface, a complete disaster happens. Ultimately no interface will retain a negotiated IP-address, if they succeed in negotiating one. Version-Release number of selected component (if applicable): Name : dhcp-client Epoch : 12 Version : 4.3.6 Release : 28.fc29 Arch : x86_64 How reproducible: Easily, run dhclient on an machine having more than one network interface. Steps to Reproduce: 1. Remove NetworkManager, install network-scripts 2. ifup <an interface> 3. Observe no IP-address available Actual results: No working network. Expected results: Fully functional network. Additional info: A patch exists. In client/dhclient.c code discover_interfaces() is called to detect available interfaces. All suitable interfaces are flagged as INTERFACE_AUTOMATIC and DISCOVER_REQUESTED. Later send/receive code is run for all interfaces flagged as DISCOVER_REQUESTED. The below patch breaks user input logic of running DHCP-client on all interfaces if none is specified. However, it fixes the logic on specified interface making network-scripts work again.