I am having a similar problem with NM's internal dhcp client on Fedora 27. I don't have the problem on various Macbook Pros or other servers. The Fedora client is a desktop machine that implements a bridged config - br0 is the interface, eth0 is the slave - I don't know if that matters, but NM handles the bridge just fine.
Some other specifics are: My home router is a small Linux server running Fedora Server, does DHCP service via dnsmasq, configured as the authoritative DHCP server. Every once in a while, NM on the client fails to renew an expired lease, so that NM ends up taking the connection down. 'nmcli con up br0' gets the lease again, just fine. Something seems to affect the renewal, sometimes.
I will do a TRACE log, and when the problem happens again, I will share the info.
Anything else I should look at to diagnose this?
David
-----Original Message-----
From: "Mleman" <mleman1217 posteo org>
Sent: Tuesday, January 2, 2018 11:57am
To: "Thomas Haller" <thaller redhat com>, networkmanager-list gnome org
Subject: Re: Internal dhcp unable to acquire IP from certain routers, breaking network connection for many users
Thomas,
thank you for your reply. I will report to the distro maintainers
regarding their compilation defaults.
As for the non-working DHCP handshake, I did as advised and generated a
log with level=TRACE and pasted it on https://pastebin.com/qTbDWJb1
Some details:
Log was generated on Manjaro 17.1 Xfce Edition on a VirtualBox VM after
a fresh reboot with LAN adapter in bridge mode to my internal network.
System: Host: ManjaroXfceVirt Kernel: 4.9.72-1-MANJARO x86_64 bits:
64 Desktop: N/A Distro: Manjaro Linux
Machine: Device: oracle System: innotek product: VirtualBox v: 1.2
serial: N/A
Mobo: Oracle model: VirtualBox v: 1.2 serial: N/A BIOS:
innotek v: VirtualBox date: 12/01/2006
CPU: Quad core Intel Core i7-7700K (-MCP-) cache: 8192 KB
clock speeds: max: 4200 MHz 1: 4200 MHz 2: 4200 MHz 3: 4200
MHz 4: 4200 MHz
Graphics: Card: InnoTek Systemberatung VirtualBox Graphics Adapter
Display Server: x11 (X.Org 1.19.5 ) driver: modesetting
Resolution: 1544x962@59.94hz
OpenGL: renderer: llvmpipe (LLVM 5.0, 256 bits) version: 3.3
Mesa 17.3.1
Audio: Card Intel 82801AA AC'97 Audio Controller driver:
snd_intel8x0 Sound: ALSA v: k4.9.72-1-MANJARO
Network: Card: Intel 82540EM Gigabit Ethernet Controller driver: e1000
IF: enp0s3 state: up speed: 1000 Mbps duplex: full mac:
08:00:27:79:3d:e8
Drives: HDD Total Size: 32.2GB (50.5% used)
ID-1: /dev/sda model: VBOX_HARDDISK size: 32.2GB
Partition: ID-1: / size: 21G used: 6.8G (35%) fs: ext4 dev: /dev/sda1
ID-2: swap-1 size: 9.45GB used: 0.00GB (0%) fs: swap dev:
/dev/sda2
Sensors: None detected - is lm-sensors installed and configured?
Info: Processes: 148 Uptime: 23 min Memory: 387.4/5972.2MB Client:
Shell (fish) inxi: 2.3.53
NetworkManager is the distro package networkmanager 1.10.2-1,
NetworkManager.conf is
[main]
dhcp=internal
[logging]
level=TRACE
domains=ALL
DHCP is a Linksys LRT224 Router, Firmware v1.0.4.03 and it is configured
for IPv4 Only, providing IPs in subnet 10.1.0.0/24.
dhcp=dhclient is able to obtain IP immediately on all my devices (LAN
and Wifi) and I do not have any issues on other systems (Win, Android,
iOS).
Hope this helps.
Regards,
mleman
Am 02.01.2018 09:55 schrieb Thomas Haller:
> Hi,
>
> On Sat, 2017-12-30 at 17:27 +0100, Mleman wrote:
>> NetworkManager 1.10 introduced a breaking change by making
>> dhcp=internal
>> the default instead of dhclient. Many distros pushed out NM 1.10
>> obviously without being aware of that change. Lots of users are
>> reporting issues with their wifi connection etc. in support forums
>> and
>> lots of guesswork is happening about what is the cause.
>
> The default plugin is decided by your distribution when building
> NetworkManager. That didn't change in 1.10 release. If such a change
> was done by your distribution and is unwanted, report a downstream bug.
>
> For example, Fedora didn't move away from dhclient, nor is it likely to
> do that any time soon. Because dhclient supports additional
> configuration from various locations like /etc/dhcp/dhclient.conf, and
> changing the default might break working installations on upgrade. Of
> course, that makes it problematic to ever change the default, which is
> a problem... On the other hand, if somebody relies on a particular DHCP
> plugin to be used, it might be resonable to require the user to
> explicitly configure it in NetworkManager.conf. This decision has to be
> made by your distribution.
>
>> As for the general issue of not properly working internal DHCP
>> client:
>> for me the only notable symptom is simple a timeout after 45sec when
>> waiting for an IP. This happens on different machines with different
>> network hardware and on wifi as well as on LAN. I have put my logs
>> on
>> pastebin here: https://pastebin.com/rQQbUrkv
>
> The internal DHCP client is supposed to work well. Hence, your report
> is relevant (thanks). But there is not enough information in the
> logfile. Please consider providing a logfile with level=TRACE debug
> logging. See the hints at
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf
>
>
> best,
> Thomas
_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
https://mail.gnome.org/mailman/listinfo/networkmanager-list