Bug 10269 - drakx-net: drakconnect, drakhost, our network tools need reworking to match NetworkManager and ifcfg features
Summary: drakx-net: drakconnect, drakhost, our network tools need reworking to match N...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 10590
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-25 02:06 CEST by Pablo Saratxaga
Modified: 2016-06-24 21:42 CEST (History)
5 users (show)

See Also:
Source RPM: drakx-net-1.24-1.mga3.src.rpm
CVE:
Status comment:


Attachments

Description Pablo Saratxaga 2013-05-25 02:06:36 CEST
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
Pablo Saratxaga 2013-05-25 02:07:10 CEST

CC: (none) => pablo
Source RPM: (none) => networkmanager-0.9.8.0-1.mga3

Manuel Hiebel 2013-05-25 19:44:17 CEST

CC: (none) => mageia, olav

Comment 1 Pablo Saratxaga 2013-05-29 14:31:35 CEST
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
Comment 2 Pablo Saratxaga 2013-05-29 14:35:47 CEST
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.
Comment 3 Pablo Saratxaga 2013-06-22 13:11:09 CEST
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) => Triaged
Depends on: (none) => 10590
Summary: networkmanager unable to handle complex interface definitions => drakx-net: drakconnect, drakhost, our network tools need reworking to match NetworkManager and ifcfg features
Source RPM: networkmanager-0.9.8.0-1.mga3 => drakx-net-1.24-1.mga3.src.rpm

Comment 4 Marja Van Waes 2016-06-24 21:25:00 CEST
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, tmb
Assignee: bugsquad => thierry.vignaud

Comment 5 Thierry Vignaud 2016-06-24 21:28:21 CEST
No, we default to let NM handle it.
But we still need drakx-net for detecting & configuring HW.
Especially in installer.
Comment 6 Thomas Backlund 2016-06-24 21:31:47 CEST
well, I explicitly enable NetworkManager and NetworkManager-wait-online services on live medias... maybe we could do the same in classical installs
Comment 7 Thierry Vignaud 2016-06-24 21:33:43 CEST
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
Comment 8 Thomas Backlund 2016-06-24 21:42:40 CEST
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...

Note You need to log in before you can comment on or make changes to this bug.