netinfo.py does not handle all links without hwaddr

[Vitali Fridliand]

Using nocloud
Following output from ip show addr is not processed properly (see can0 link/can), causing failure in other interface setup.

================================
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
    link/can
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether c6:fc:89:b6:a9:23 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.64/16 brd 192.168.255.255 scope global dynamic eth0
       valid_lft 12689sec preferred_lft 12689sec
    inet6 fe80::c4fc:89ff:feb6:a923/64 scope link
       valid_lft forever preferred_lft forever
5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 2a:f3:e3:89:da:bb brd ff:ff:ff:ff:ff:ff
    inet 10.74.90.86/24 brd 10.74.90.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::28f3:e3ff:fe89:dabb/64 scope link
       valid_lft forever preferred_lft forever
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:23:bf:3a:e1 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
================================

Proposal is to add following at https://github.com/canonical/cloud-init/blob/3c551f6ebc12f7729a2755c89b19b9000e27cc88/cloudinit/netinfo.py#L82:

82a82,85
> m = re.match(
> r'\s+link/(?P<link_type>\S+).*', line)
>
> if not m:

[Lucas Albuquerque Medeiros de Moura (lamoura)]

Hello Vitali, thanks for reporting this issue. Is it possible for you to specify the system that you found this bug on ?

[Vitali Fridliand (vitaliq)]

Hello Lucas.

This system is a xilinx soc with arm64 & fpga blocks: vck190, just for our current prototype. But will be used more widely in the future.

With best regards,
Vitali Fridliand

On 17 Aug 2020 15:15, Lucas Albuquerque Medeiros de Moura <email address hidden> wrote:
Hello Vitali, thanks for reporting this issue. Is it possible for you to
specify the system that you found this bug on ?

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1891315

Title:
  netinfo.py does not handle all link formats

Status in cloud-init:
  New

Bug description:
  Using nocloud
  Following output from ip show addr is not processed properly (see can0 link/can), causing failure in other interface setup.

  ================================
  ip addr show
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host
         valid_lft forever preferred_lft forever
  2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
      link/sit 0.0.0.0 brd 0.0.0.0
  3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
      link/can
  4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
      link/ether c6:fc:89:b6:a9:23 brd ff:ff:ff:ff:ff:ff
      inet 192.168.0.64/16 brd 192.168.255.255 scope global dynamic eth0
         valid_lft 12689sec preferred_lft 12689sec
      inet6 fe80::c4fc:89ff:feb6:a923/64 scope link
         valid_lft forever preferred_lft forever
  5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
      link/ether 2a:f3:e3:89:da:bb brd ff:ff:ff:ff:ff:ff
      inet 10.74.90.86/24 brd 10.74.90.255 scope global eth1
         valid_lft forever preferred_lft forever
      inet6 fe80::28f3:e3ff:fe89:dabb/64 scope link
         valid_lft forever preferred_lft forever
  6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
      link/ether 02:42:23:bf:3a:e1 brd ff:ff:ff:ff:ff:ff
      inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
         valid_lft forever preferred_lft forever
  ================================

  Proposal is to add following at https://protect2.fireeye.com/v1/url?k=ce330ef1-9093b49f-ce334e6a-866038973a15-3c3518756974979a&q=1&e=c6636368-4397-4549-a497-34187a98c13b&u=https%3A%2F%2Fgithub.com%2Fcanonical%2Fcloud-
  init/blob/3c551f6ebc12f7729a2755c89b19b9000e27cc88/cloudinit/netinfo.py#L82:

  82a82,85
  > m = re.match(
  > r'\s+link/(?P<link_type>\S+).*', line)
  >
  > if not m:

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1891315/+subscriptions

[Paride Legovini (paride)]

Hi Vitali,

Looks like the root of the problem is netinfo.py not supporting links without a hwaddr. I don't think your patch can be applied as-is, as it will fully disable the detection of the hwaddr, which we need for the Ethernet links. We should do some smarter parsing and make sure the change won't have unwanted side effects, like adding devices we are currently discarding because they lack a hwaddr and that we want to keep discarding for good reasons.

I amended the bug report title and I marked this bug report as Triaged, as I think the problem is well understood. If you want to help driving it forward I encourage you to submit a PR to the cloud-init GitHub project.

(In general it would be way nicer to use `ip --json addr show` instead of parsing stdout meant for humans, but that's not supported in older iproute2 releases, like the one in Xenial. We have to wait.)

[1] https://github.com/canonical/cloud-init

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3771