Tonight I updated from net-misc/networkmanager-0.8-r1 to net-misc/networkmanager-0.8.1. After restarting NetworkManager, the new version fails to acquire an IP. It seems to be related to a dhcp client issue -- I have the "dhcpcd" USE flag selected, but it appears to be trying to use dhclient instead (and providing invalid syntax). Reproducible: Always Steps to Reproduce: 1. # emerge net-misc/networkmanager-0.8.1 2. # /etc/init.d/NetworkManager restart Actual Results: NetworkManager restarts and fails to acquire an IP; I'm then prompted to check my WEP/WPA password and try again. Expected Results: NetworkManager restarts and acquires an IP. I downgraded to back to net-misc/networkmanager-0.8-r1, restarted NetworkManager and my problem went away (I get an IP again), so I'm certain it's not an issue with WEP or WPA. I will attach logs of it working with 0.8-r1 and failing with 0.8.1. My USE flags are: [ebuild U ] net-misc/networkmanager-0.8.1 [0.8-r1] USE="avahi bluetooth dhcpcd gnutls -connection-sharing -dhclient -doc -nss -resolvconf" 0 kB
Created attachment 240555 [details] Log of NetworkManager 0.8.1 Failing to Get IP Attached is what I see in the syslog with 0.8.1 (when it fails to get an IP).
Created attachment 240557 [details] Log of NetworkManager 0.8-r1 Working Properly Attached is what I see in the syslog after I reverted back to 0.8-r1 and restart it; NetworkManager works as expects and gets an IP without any issues.
This seems to be a dependency of Networkmanager-0.8.1 to dhcp-4.x (because of some parameters) (when you have dhclient as use flag) Unmasking and emerging dhcp-4.1.0 allows you to get an IP.
I can confirm the dependency, unmasking and emerging dhcp 4.1 solves the problem. However, dhcp >= 4.* is hard-masked. Please either unmask dhcp or mask networkmanager 0.8.1 in order to prevent more users running into this. Kind regards Christian
Also noticed this: [snip] * QA Notice: Unrecognized configure options: * * configure: WARNING: unrecognized options: --with-dhcp-client [/snip]
(In reply to comment #5) > Also noticed this: > [snip] > * QA Notice: Unrecognized configure options: > * > * configure: WARNING: unrecognized options: --with-dhcp-client > [/snip] > Yes, the new options are: --with-dhclient=yes|no|path Enable dhclient 4.x support --with-dhcpcd=yes|no|path Enable dhcpcd 4.x support
Created attachment 240693 [details, diff] networkmanager-0.8.1-dhcp-configure.patch Worse then that, the config variables are a bit screwed up (two typos), and even if you manage to get it to configure properly, it appears to build both dhcp managers, and defaults to dhclient, meaning if you've got dhclient installed, it'll try and use it, whether you've told it to disable support or not... 5:\ Unfortunately, I haven't figured out where this choosing of the client happens, but here's a patch that should sort out the configure.ac at least. The options passed in the ebuild need to be fixed also, as noted above.
(In reply to comment #7) > Worse then that, the config variables are a bit screwed up (two typos), and > even if you manage to get it to configure properly, it appears to build both > dhcp managers, and defaults to dhclient, meaning if you've got dhclient > installed, it'll try and use it, whether you've told it to disable support or > not... I removed net-misc/dhcp (afaik I don't need a dhcp-server on a netbook ...) and this made it work again as well with 0.8.1 ... quick and dirty ...
Created attachment 240697 [details, diff] networkmanager-0.8.1-dhcp-configure.patch Right... It appears that setting DHCLIENT_PATH to "" isn't enough to actually disable dhclient support, because they've handily hardcoded in some paths it might exist at, and if they find one, they use it: const char * nm_dhcp_dhclient_get_path (const char *try_first) { static const char *dhclient_paths[] = { "/sbin/dhclient", "/usr/sbin/dhclient", "/usr/pkg/sbin/dhclient", "/usr/local/sbin/dhclient", NULL }; const char **path = dhclient_paths; if (strlen (try_first) && g_file_test (try_first, G_FILE_TEST_EXISTS)) return try_first; while (*path != NULL) { if (g_file_test (*path, G_FILE_TEST_EXISTS)) break; path++; } return *path; } So as a work around, I've simply emptied that hardcoded list, and now it actually uses dhcpcd and everything seems to be fine again. I'm not sure if that's the most elegant fix, but this really needs to go upstream given how many mistakes block use of dhcpcd...
Created attachment 241033 [details] networkmanager-0.8.1.ebuild Ok, here it goes: Updated ebuild that seems to be working on my machine. Utilizes networkmanager-0.8.1-dhcp-configure.patch (Thanks Mike!) and fixes configure options for dhcp client. It would be nice if someone with developer access would put it in because it seems that real maintainer is AWOL :S
There's another issue: the minimum required version for net-misc/dhcp must be raised to 4.0.
According to Fedora's source rpm file, it's even 4.1.0. I can also confirm networkmanager running flawlessly again with =net-misc/dhcp-4.1.10. Has anyone linked the author for this bug yet to have those changes included upstream?
WHY would you like to disable dhclient in hackish - totally wrong way, when you can specify -dhclient +dhcpcd? I will have a chat with NM maintainer and upgrade dependency. Thanks for your report.
Sorry, not sure who that's aimed at, but USE="-dhclient +dhcpcd" will still make use of dhclient if /usr/bin/dhclient exists. It will do this even if --with-dhclient=no is passed to configure, and that's why the patch is necessary. There's autofinding code which will still look for dhclient even with --with-dhclient=no, and it will use that *over* dhcpcd, even if that's been specified during configure. So to allow people to keep an older version of dhclient and use dhcpcd, the autofinding code has to be removed/disabled/altered in some way. If the user does specify --with-dhclient=yes everything will work as expected, because the configure script will attempt to locate the dhclient binary, and that will get passed in as the first guess to the finding function, and so will be used. I didn't think this patch was particularly hackish, save for leaving the code that runs through an empty list in place, but it at least will respect all the various --with-dh* options, which the current code doesn't do for a number of reasons (not least typos in the configure script). That seems to keep everybody happy, with a minimum of fuss, but if you know of another way to ensure that --with-dhclient=no is respected, I'm fine with that... The submitted ebuild doesn't specify --with-dhclient=no when it specifies --with-dhcpcd=yes, which it should do. There's a 0.8.1-r1 ebuild in my overlay that has the correct dhclient requirements, and which correctly specifies the --with-dh* flags to favour dhcpcd (as has been the way in previous ebuilds). If you're not intending to use any kind of patch, then you'll have to make >=dhcp-4 a hard dependency of networkmanager (which you shouldn't do until it's unmasked), and which isn't necessary if dhcp isn't installed.
I'm really sorry, but it seems I was too quick in judging it. I should have read it more carefully. Sorry again Mike! Mike's patch seems like a good option. I'm currently discussing with upstream if that's acceptable solution or we need to find more elegant way.
I've now committed version based on Mike's patch. If upstream decide about different solution - I'll backport it.
Just had a chat with Dan. He pushed part of Mike's patch: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=91e90d9d5412223e0252ccff0e3732afae201af6 and http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c050e036c3d748970945195ed0fe6c914c439481 I'll backport it with some other fixes as 0.8.1-r2
