Bug 1657848 - dhclient ignores given interface
Summary: dhclient ignores given interface
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp
Version: 29
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Pavel Zhukov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-10 15:11 UTC by Jari Turkia
Modified: 2019-02-13 20:00 UTC (History)
6 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2019-02-13 20:00:59 UTC


Attachments (Terms of Use)
Fix to enable functionality on dhclient to run on a given interface (421 bytes, patch)
2018-12-10 15:11 UTC, Jari Turkia
no flags Details | Diff

Description Jari Turkia 2018-12-10 15:11:34 UTC
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.

Comment 1 Pavel Zhukov 2019-02-12 21:05:45 UTC
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?

Comment 2 Jari Turkia 2019-02-13 07:32:25 UTC
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.

Comment 3 Pavel Zhukov 2019-02-13 08:51:46 UTC
(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)

Comment 4 Jari Turkia 2019-02-13 20:00:59 UTC
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.


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