"Cloned MAC address" parameter is not saved in /etc/conf.d/net. Consequently, this parameter is not preserved between daemon restarts. Also, some field entries in nm-applet and nm-connection-editor are duplicated. Steps to reproduce: 1. Connect to any new unprotected wireless network. 2. Change cloned MAC address parameter with nm-connection-editor. 3. Set "Available to all users" checkbox. 4. Save. 5. /etc/init.d/NetworkManager restart As a workaround, I removed "ifnet" plugin entries from /etc/NetworkManager/NetworkManager.conf Tested with networkmanager-0.9.4.0-r6 and networkmanager-0.9.6.4.
I suffer a very similar experience. There are duplicated entries for a new created wifi connections appears. if one of them is removed manually, the connection password is not getting saved after a computer restart. Moreover, after a restart the connection settings can not be edited anymore as the "save..." button is disabled!!! "Available for all users" checkbox is also disabled. using the latest stable release - 0.9.4.0-r6.
still the same with 0.9.8.2?
Created attachment 369350 [details, diff] This patch fixes the ifnet plugin to save a cloned mac address 0.9.8.8 still suffered from the problem of not saving the cloned mac address. In this patch I fixed it by saving the cloned mac address in mac_eth0 and the actual hardware address (which network manager requires apparently) in hwaddr_eth0. The latter is not something that openrc knows, but it seems to ignore it if it's present so that's good enough.
Due to stress with my router i rely on a cloned mac adress for my cable connection. Problem can be confirmed with net-misc/networkmanager-0.9.8.8 and kde 4.11.5 I can't wait to test it in ~amd64 or even in masked!
I wasn't able to wait, so I found out, that the ebuild of networkmanager has the epatch_user functionality. I also found out that this enables me to apply your patch by simply move the .patch file in /etc/patches/net-misc/networkmanager-0.9.8.8/ and reemerge networkmanager. The behaviour without the patch: clone mac in linux. restart linux cloned mac is lost, original mac is used again. The behaviour with the patch: clone mac in linux restart linux cloned mac is still used But there is one unexpected additional behaviour: clone mac in linux restart in Windows 7 (grub-dualboot) cloned mac is used in Windows 7! (This wasn't before. But I don't know if this is caused by the patch, so I apologize if this leads to misunderstandings or wrong accusations) Workaround is easy, just set the original mac in Windows 7 manually. I just had a few hours and some restarts to test it this evening. If you want I'll report in some days if anything new occured. Hardware: Dell Alienware Atheros AR8151 PCI-E Gigabit Ethernet Controller (NDIS 6.20)
Not sure if qiaomuf will still be around for reviewing this
Thank you for your patch!!! It would bring us much much further if you could open an upstream bug report about this plugin component and extend your patch with tests incorparating new changes, according to http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifnet/tests/test_all.c as there is no maintainer currently working on it. (In reply to Maurice van der Pot from comment #3) > Created attachment 369350 [details, diff] [details, diff]http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifnet/tests/test_all.c > This patch fixes the ifnet plugin to save a cloned mac address > > 0.9.8.8 still suffered from the problem of not saving the cloned mac address. > > In this patch I fixed it by saving the cloned mac address in mac_eth0 and > the actual hardware address (which network manager requires apparently) in > hwaddr_eth0. The latter is not something that openrc knows, but it seems to > ignore it if it's present so that's good enough.
(In reply to Stephan Karacson from comment #5) > But there is one unexpected additional behaviour: > clone mac in linux > restart in Windows 7 (grub-dualboot) > cloned mac is used in Windows 7! I don't see this issue on my dual boot system with Windows 7. I don't understand why this would be different without the patch. (In reply to Evgeny Bobkin from comment #7) > Thank you for your patch!!! > > It would bring us much much further if you could open an upstream bug report > about this plugin component and extend your patch with tests incorparating > new changes, according to > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/ > plugins/ifnet/tests/test_all.c as there is no maintainer currently working > on it. Before I do this could someone from openrc please comment on whether or not the hwaddr_eth0 is an acceptable thing to them?
CCing openrc team to check previous comment then
Instead of fixing libnm-settings-plugin-ifnet.so why not just use native NM format of configs? net-misc/netifrc is now optional in openrc, NM works fine without it.
@openrc, any thoughts about the patch? OK to try to upstream it? (if we pretend to support ifnet plugin in any way :S)
+*networkmanager-0.9.10.0-r1 (13 Oct 2014) + + 13 Oct 2014; Pacho Ramos <pacho@gentoo.org> + +files/networkmanager-0.9.10.0-arpingpath.patch, + +networkmanager-0.9.10.0-r1.ebuild: + Ifnet plugin is now disabled because of it being unattended and unmaintained + for a long time, leading to some unfixed bugs and new problems appearing + (#443596, #458274, #493370, #498372, #523700). If some day somebody volunteers + for fixing/maintaining that plugin and forwarding all that fixes to upstream + it could be re-enabled of course. Append configure option regarding systemd + unit files install path only when systemd support is enabled to prevent + HAVE_SYSTEMD to be true (#524534 by Konstantin Ivanov). Ensure arping is found + (#523632 by Kobboi). +
