DHCPCD 6.2.1

[Armin K]

​http://roy.marples.name/downloads/dhcpcd/

[rt]

Fernando, can you test if this works with NetworkManager? dhcpcd hasn't worked with NM on my system since version 6.1.

[Fernando de Oliveira]

I remember your problem. Will try to see what happens.

[Fernando de Oliveira]

Sorry. I always use manual ip. At first, I thought that I could do somwthing. Then trying out, I realized that as I am using fixed ip, NetworkManger is not calling DHCPCD. I always use manual ip as in LFS. When updating Network Manager, I used it with manual ip. With DHCPCD, the same.

In summary: tried to get the two working together, failed to connect. Do not know if it is due to the filter in the router (I remember spending some time to configure the router to filter ip, but think it was only for wifi) or if is the same problem as yours.

Hope you get a solution, now for the two of us.

[Fernando de Oliveira]

Fixed at r12616.

[Fernando de Oliveira]

Ragnar, how could we reach the conclusion that we both have the same problem? Some log file that would look similar, for example. This way, a ticket could be created, and a solution would be easier to find. I only used not fixed ip long ago (years), so I cannot remember many things about this. I wish I could help more, but this suggestion/question is all what I can do at the moment.

[Fernando de Oliveira]

It is a coincidence, Fedora has just release a git as default:

NetworkManager.i686                    1:0.9.9.0-25.git20131003.fc20     updates
NetworkManager-glib.i686               1:0.9.9.0-25.git20131003.fc20     updates

May be it is related to the problem?

[Fernando de Oliveira]

Ragnar, I can confirm the bug. Installed dhcpcd-6.0.5 and it worked with NetworkManager-0.9.8.8, but dhcpcd-6.2.1 did not. Would you like to open a ticket for this, please?

[rt]

Thanks for testing, Fernando. Good to know it's not a misconfiguration on my system that's causing this. I've found that the routing table doesn't get properly configured with the newer dhcpcd versions. It seems odd that no information on this issue could be found on the web. I would've thought if the issue was general, that it would have been picked up by other distros by now. I will open a new ticket when I get home later today.

[Fernando de Oliveira]

Ragnar, it is working fine now, apparently. I verified that /lib/dhcpcd/dhcpcd-run-hooks are very different, between versions 6.0.5 and 6.2.1 (will attach the diff), where I read:

# With the advent of alternative init systems, it's possible to have
# more than one installed. So we need to try and guess what one we're
# using unless overriden by configure.

Bruce will certainly blame systemd's advent :-)

Tried many things, including an sed to modify dhcpcd-run-hooks.in.

Finally, found:

​https://bbs.archlinux.org/viewtopic.php?id=165793

where it is stated

Make sure you don't have a dhcp-daemon, dhclient or similiar running.

In my case, I do not have systemd, but they have, there.

I stopped then network, and then, network-manager worked, when I tried.

I modified the /etc/sysconfig/ifconfig.enp2s1 (your interfaces may have different names) to:

$ cat /etc/sysconfig/ifconfig.enp2s1
ONBOOT=no
IFACE=enp2s1
SERVICE=dhcpcd
DHCP_START="-b -q <customized, in my case>"
DHCP_STOP="-k"

so that the configuration is skipped, and will be done by NM.

Then rebooted, and there was the interface configured and up running.

Please, try this, if it works, we probably will have to modify dhcpcd and NM pages (perhaps dhcp, too, but I never touched the page nor built the package).

[Fernando de Oliveira]

Very different, many init systems to consider, now.

[rt]

The issue in the Arch-thread was that both dhcpcd and NM services were enabled, i.e. that systemd was starting both dhcpcd and NM at boot. When using NM, dhcpcd should not be started by the init system because NM automatically starts it. I'm using systemd, but the dhcpcd service is not enabled on my system, so this is not the cause of the problem.

Something in the update from the 6.0 dhcpcd series to the 6.1 series broke NM. Unfortunately, there were quite a bit of changes introduced, so it won't be trivial to find the cause. I will take a look at the difference in the hooks to see if this could be causing it.

[Fernando de Oliveira]

Yes. Adding some more info, perhaps useful.

But curiously, that did not matter for 6.0.5.

Another curiosity, is that NM apparently used dhcpcd for the connection, but did not demonize (i mean:, dhcpcd was not running, afterwards).

[Fernando de Oliveira]

Forgot to tell about another difference that, I guess, could be the responsible for our problems, or may be only mine:

--- a/DEST-dhcpcd-6.0.5/etc/dhcpcd.conf	2014-01-23 18:38:05.258905056 -0300
+++ b/DEST-dhcpcd-6.2.1/etc/dhcpcd.conf	2014-01-23 18:39:18.318906188 -0300
@@ -10,6 +10,9 @@
 # Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
 duid
 
+# Persist interface configuration when dhcpcd exits.
+persistent
+
 # Rapid commit support.
 # Safe to enable by default because it requires the equivalent option set
 # on the server to actually work.

As I said, a guess. This persistent could prevent a proper execution of NM, when I had it running and tried to change from one connection (fixed ip, earlier set by dhcpcd) to the other one (not fixed, to be negotiated by dhcpcd).

I know very little about these matters, just trying to help and learn a little more.

[bdubbs@…]

Milestone current deleted