[Idea] Fix distinct IPv4/IPv6 interface names for LXC

[MiniPierre]

Your idea

When using a LXC container, network configuration sent to GLPI does not link IPv4 and IPv6 addresses to the same interface.

This is due to the following reason:

On LXC server, interfaces names are attached to one of the physical host interfaces, are named {{ interface_name }}@{{ host_interface_name }}, for example eth0@if38.

For inet6 lines, the interface is left as is:

lib/GLPI/Agent/Tools/Linux.pm

} elsif ($line =~ /inet6 (\S+)\/(\d{1,2})/) {
            my $address = $1;
            my $mask    = getNetworkMaskIPv6($2);
            my $subnet  = getSubnetAddressIPv6($address, $mask);

            push @addresses, {
                IPADDRESS6  => $address,
                IPMASK6     => $mask,
                IPSUBNET6   => $subnet,
                STATUS      => $interface->{STATUS},
                DESCRIPTION => $interface->{DESCRIPTION},
                MACADDR     => $interface->{MACADDR}
            };
        }

But for inet lines, the last word is used to replace interface name:

lib/GLPI/Agent/Tools/Linux.pm

} elsif ($line =~ /
            inet \s
            ($ip_address_pattern)(?:\/(\d{1,3}))? \s
            .* \s
            (\S+)$
            /x) {
            my $address = $1;
            my $mask    = getNetworkMask($2);
            my $subnet  = getSubnetAddress($address, $mask);
            my $name    = $3;

            # the name associated with the address differs from the current
            # interface if the address is actually attached to an alias
            push @addresses, {
                IPADDRESS   => $address,
                IPMASK      => $mask,
                IPSUBNET    => $subnet,
                STATUS      => $interface->{STATUS},
                DESCRIPTION => $name,
                MACADDR     => $interface->{MACADDR}
            };

Thus, with the following configuration, IPv4 and IPv6 are not declared on the same interface (eth0 for IPv4, eth0@if10 for IPv6):

2: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether aa:aa:aa:aa:aa:aa brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 1.2.3.4/24 brd 1.2.3.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 a:b:c:d:e:f:a1:a2/64 scope global 
       valid_lft forever preferred_lft forever

I suppose there is a good reason to have done things that way, but it is quite a pain when trying to retrieve an interface IPs from GLPI. Would be nice to have a fix at least for attached interfaces

[g-bougard]

Hi @MiniPierre

interesting. I've myself that case. If I generate a partial network inventory in my glpi 10.0.17 lxc instance with glpi-inventory --partial network command, I have this network section:

      "networks": [
         {
            "description": "lo",
            "ipaddress": "127.0.0.1",
            "ipmask": "255.0.0.0",
            "ipsubnet": "127.0.0.0",
            "mac": "00:00:00:00:00:00",
            "speed": "0",
            "status": "up",
            "type": "loopback",
            "virtualdev": true
         },
         {
            "description": "lo",
            "ipaddress6": "::1",
            "ipmask6": "fff0::",
            "ipsubnet6": "::",
            "mac": "00:00:00:00:00:00",
            "speed": "0",
            "status": "up",
            "type": "loopback",
            "virtualdev": true
         },
         {
            "description": "eth1",
            "ipaddress": "192.168.2.17",
            "ipmask": "255.255.255.0",
            "ipsubnet": "192.168.2.0",
            "mac": "fe:ea:1f:d1:95:c2",
            "speed": "10000",
            "status": "up",
            "virtualdev": true
         },
         {
            "description": "eth1@if11",
            "ipaddress6": "fe80::fcea:1fff:fed1:95c2",
            "ipmask6": "ffff:ffff:ffff:ffff::",
            "ipsubnet6": "fe80::",
            "mac": "fe:ea:1f:d1:95:c2",
            "status": "up",
            "virtualdev": true
         },
         {
            "description": "eth0",
            "ipaddress": "192.168.1.153",
            "ipgateway": "192.168.1.3",
            "ipmask": "255.255.255.0",
            "ipsubnet": "192.168.1.0",
            "mac": "00:16:3e:f0:d4:a6",
            "speed": "1000",
            "status": "up",
            "virtualdev": true
         },
         {
            "description": "eth0@if2",
            "ipaddress6": "2a01:e0a:35c:740:216:3eff:fef0:da46",
            "ipmask6": "ffff:ffff:ffff:ffff::",
            "ipsubnet6": "2a01:e0a:35c:740::",
            "mac": "00:16:3e:f0:da:46",
            "status": "up",
            "virtualdev": true
         },
         {
            "description": "eth0@if2",
            "ipaddress6": "fe80::216:3eff:fef0:d4a6",
            "ipmask6": "ffff:ffff:ffff:ffff::",
            "ipsubnet6": "fe80::",
            "mac": "00:16:3e:f0:da:46",
            "status": "up",
            "virtualdev": true
         }

Imported in glpi, that asset has 5 network interfaces: lo, eth0, eth0@if11, eth1 & eth1@if2

If I edit the inventory to fix "description" with @ extension removed, and import that inventory, the asset has now 3 interfaces: lo, eth0 & eth1, each one with all expected ipv4 & ipv6.

This is probably a bug, I'll check if this is safe to fix it. But my first thinking after a quick check is we can.

[g-bougard]

Hi @MiniPierre

I just pushed a fix here: ab45f01

It will be integrated in next nightly build if you want to test and validate the fix.

I discovered few cases in unittests which involves the same kind of issue but in other cases.

Can you tell me if you now see what you expect in GLPI with that fix ?