networkmanager is unable to handle complex interface definitions. for those cases it would be better to stick with current sysv init scripts. what triggers it: * network sub interfaces (eg: "eth0" and "eth0:1"), which btw is needed to have several IPv4 adresses on a same physical card * more than one IPv6 adress (eg IPV6ADDR_SECONDARIES present in the ifcfg file) if NM_CONTROLLED=no is present in an /etc/sysconfig/network-scripts/ifcfg-* file, it isn't managed by netwrokmanager. so, the proposed action is to add "NM_CONTROLLED=no" in the ifcfg-* files if: 1. DEVICE has ":" on it (and add NM_CONTROLLED=n to the main device too!) 2. there is IPV6ADDR or IPV6ADDR_SECONDARIES (maybe "NM_CONTROLLED=no" would be needed for some wireless cards too?) I'll look at nm internals when I have a bit of time
CC: (none) => pabloSource RPM: (none) => networkmanager-0.9.8.0-1.mga3
CC: (none) => mageia, olav
ok; so after some search on it it seems it is not networmanager itself which is at fault; but the conversion from ifcfg-* configuration files to the networmanager configuration. the converter (ifcfg-rh plugin) doesn't handle device aliases. On the other hand, the ifcfg-* Red Hat files have the ability to define several IPv4 addresses per interface, thus avoiding the need for device aliases. That functionality is not available trough the draktools GUI however; if it is still to be used it would be nice to add it. The networkanager-applet does have it (for both ipv6 and ipv4 you can add as many ip adresses as you want) In the ifcfg-* files it work by using numbered varaibles: eg: IPADDR, IPADDR0, IPADDR1, ... IPADDR255 that is the case for: IPADDR, PREFIX, NETMASK, BROADCAST, ARPCHECK all dealing with IPv4; for IPv6 it is different: IP6_ADDR for first address, and IPV6ADDR_SECONDARIES can give a space separated list of extra adresses; the ipv6 adresses can specify (in fact it is better imho to always put it) the prefix length. So; a check could be done for existing /etc/sysconfig/network-scripts/ifcfg-*:* files: - if at least one exist, then check if the only difference between then and base device file are only the IPADDR, PREFIX, NETMASK, BROADCAST, ARPCHECK variables (alias config files can have less variables defined, but for all those defined, other than the 5 listed above, they have to hold the same value; with only exception being "DEVICE" of course. - if that's true, then the alias files can be deleted, and their info put in the main file; the imported variable names postfixed with the device alias number. it will then be properly managed by network manager. having multiple ipv6 is not a problem for network manager (the problem I had identified was due to the device aliases only) multiple IPv4 addresses on a same interface won't be seen on comand line with ipconfig, but if will with "ip addr show" (maybe ipconfig should be fixed?). Nor will it be seen with current draknet tool (it has to be fixed). - if alises exist, but the above condition is not met; then thet should be kept, and "NM_CONTROLLED=no" added to the main device and its aliases. eg: ____ file ifcfg-eth0 with: DEVICE=eth0 ONBOOT=yes BOOTPROTO=static IPADDR=192.168.1.2 NETMASK=255.255.255.0 NETWORK=192.168.1.0 (...) ____ file ifcfg-eth0:3 with: DEVICE=eth0:3 ONBOOT=yes BOOTPROTO=static IPADDR=192.168.100.42 NETMASK=255.255.255.0 NETWORK=192.168.100.0 then ifcfg-eth0:3 can be deleted and ifcfg-eth0 added those extra lines: IPADDR3=192.168.100.42 NETMASK3=255.255.255.0 NETWORK3=192.168.100.0
a possible problem with IPv6 is that the old script method allowed manul configuration (eg IPV6_ADDR, IPV6ADDR_SECONDARIES) to work even if IPV6_AUTOCONF=yes The new networkmanager system needs IPV6_AUTOCONF=no to read the IPV6_ADDR, IPV6ADDR_SECONDARIES variables. Maybe simple update notes will be an acceptable "fix" for those two problems.
changed this as a bug of drakx-net; planed work to improve the situation, see: https://wiki.mageia.org/en/Feature:NetworkDrakToolsImprovements add dependency on bug #10269, as a proper text2bool function will help on the work added Triaged keyword
Keywords: (none) => TriagedDepends on: (none) => 10590Summary: networkmanager unable to handle complex interface definitions => drakx-net: drakconnect, drakhost, our network tools need reworking to match NetworkManager and ifcfg featuresSource RPM: networkmanager-0.9.8.0-1.mga3 => drakx-net-1.24-1.mga3.src.rpm
IINM, drakx-net now uses NetworkManager in the 6sta1 Live isos CC'ing tmb I don't know about the traditional isos, though. Assigning to drakx-net maintainer
Keywords: Triaged => (none)CC: (none) => marja11, tmbAssignee: bugsquad => thierry.vignaud
No, we default to let NM handle it. But we still need drakx-net for detecting & configuring HW. Especially in installer.
well, I explicitly enable NetworkManager and NetworkManager-wait-online services on live medias... maybe we could do the same in classical installs
we don't have NM in stage1 or stage2. We would then need glue code in order to poke in NM for being able to start/stop network, ... drakx-net cannot be replaced until someone steps in to do the job
yeah, I was more thinking of doing "systemctl disable network && systemctl enable NetworkManager && systemctl enable NetworkManageer-wait-online" in post-install in case user did not change any network settings during install... that way they would be up and running on first bootup after new install... with no user intervention at all... NM is happily handling any nic found after boot... But yes, we also need to do proper NM integration...