v0.5.12 TypeError: Unsupported link layer address length 0

[mkorkalo]

Upgrading from 0.5.11 to 0.5.12 gives this warning on my Ubuntu 18.04 test VM:

>>> i = pyroute2.IPDB()
2020-06-18 09:47:46,543 - pyroute2.ipdb.main - WARNING - Deprecation warning https://docs.pyroute2.org/ipdb_toc.html
>>> i.ipaddr
2020-06-18 09:47:49,900 - pyroute2.netlink - WARNING - decoding NDA_LLADDR
2020-06-18 09:47:49,901 - pyroute2.netlink - WARNING - Traceback (most recent call last):
  File "/opt/fleet/sensor-orchestrator/virtualenv/lib/python3.8/site-packages/pyroute2/netlink/__init__.py", line 1520, in try_to_decode
    cell.decode()
  File "/opt/fleet/sensor-orchestrator/virtualenv/lib/python3.8/site-packages/pyroute2/netlink/__init__.py", line 1901, in decode
    raise TypeError('Unsupported link layer address length {}'
TypeError: Unsupported link layer address length 0

{1: (('::1', 128), ('169.254.255.255', 32), ('127.0.0.1', 8)), 2: (('fe80::a00:27ff:fed2:d382', 64), ('192.168.56.101', 24)), 3: (('fe80::a00:27ff:fe97:4aa9', 64), ('10.0.3.15', 24)), 4: (('169.254.255.255', 32), ('fe80::4871:fe4:ff79:1b05', 64)), 5: (('fe80::b820:efff:feed:4196', 64),), 11: (('fe80::34d6:daff:fe5f:b139', 64),)}

my lladdr object holds the following data:
{'value': b'', 'attrs': [], 'header': {'length': 4, 'type': 2}}

[svinota]

Length 4 it's a bit strange for an lladdr NLA, it's an empty address… May I ask you to compare the result of 0.5.11 and 0.5.12 on the same system and tell me the difference in addresses listed, if it's not a secret? (the difference just not to disclosure other address info)

[ssalenik]

I see the same thing since upgrading. I'm not sure, but it seems like it possibly happens just when an iface is being added, so maybe something is not complete?

The change happened in this commit though which got added in 0.5.12, so I think that explains the change in behaviour:
fa2e934

Before it was using l2addr class which wasn't performing a check on the len:

pyroute2/pyroute2/netlink/__init__.py

Lines 1885 to 1888 in 9b2af31

	def decode(self):
	nla_base.decode(self)
	self.value = ':'.join('%02x' % (i) for i in
	struct.unpack('BBBBBB', self['value']))

[jonwaland]

Suspect a lot of downstream users with same issue. I'm running HomeAssistant 2021.4.1 (as above) which calls pyroute 0.5.17:

2021-04-09 14:48:21 WARNING (MainThread) [pyroute2.netlink] decoding NDA_LLADDR
2021-04-09 14:48:21 WARNING (MainThread) [pyroute2.netlink] Traceback (most recent call last):
  File "/srv/homeassistant/lib/python3.8/site-packages/pyroute2/netlink/__init__.py", line 1503, in try_to_decode
    cell.decode()
  File "/srv/homeassistant/lib/python3.8/site-packages/pyroute2/netlink/__init__.py", line 1929, in decode
    raise TypeError('Unsupported link layer address length {}'
TypeError: Unsupported link layer address length 0

[svinota]

@jonwaland I prepare a workaround and tag a release within a day.

But would be cool to find out the reason for these messages and exact data. If someone would volunteer, I can prepare a script to save raw netlink and thereafter we would have something to analyze and prepare a proper fix, not a workaround.

[makob]

@svinota I would be happy to try and help with that (if I can make the script work within the home-assistant docker image)

[svinota]

@jonwaland pls take a look at 8db8a6b — if it helps, then:

1. you'll see in the logs hexdumps of messages with zero-sized lladdr — please paste them here or mail me
2. I'll tag a release so the fix gets deployed

[sreknob]

Hi @svinota, thanks for working on this!
This the data I get with your applied patch.

packet data: 44:00:00:00:1c:00:02:00:00:01:00:00:d5:00:00:00:02:00:00:00:0a:00:00:00:40:00:00:03:08:00:01:00:00:00:00:00:04:00:02:00:08:00:04:00:00:00:00:00:14:00:03:00:40:69:00:00:d0:51:00:00:d0:51:00:00:00:00:00:00

Let me know if I can get you any other info!

[svinota]

{'__pad': (),
 'attrs': [('NDA_DST', '0.0.0.0'),
           ('NDA_LLADDR', ''),
           ('NDA_PROBES', 0),
           ('NDA_CACHEINFO', {'ndm_confirmed': 26944, 'ndm_used': 20944, 'ndm_updated': 20944, 'ndm_refcnt': 0})],
 'family': 2,
 'flags': 0,
 'header': {'flags': 2,
            'length': 68,
            'pid': 213,
            'sequence_number': 256,
            'type': 28},
 'ifindex': 10,
 'ndm_type': 3,
 'state': 64}

Ridiculous message, but it has to be supported, ok.

Adding to the code, the next release will be tagged tomorrow after all the tests.

[jonwaland]

apologies for lack of response - weekend, etc.

my log:

(3 instances at same time if relevant)

packet data: 44:00:00:00:1c:00:02:00:00:01:00:00:97:51:00:00:02:00:00:00:0d:00:00:00:40:00:00:03:08:00:01:00:00:00:00:00:04:00:02:00:08:00:04:00:00:00:00:00:14:00:03:00:8a:a9:5a:09:1a:92:5a:09:1a:92:5a:09:00:00:00:00