In VPP 20.05, when I invoke the lisp_eid_table_dump API, PAPI throws an error and causes the networking-vpp agent to die. It’s easy to reproduce:

1. Run the attached API trace file (lisp_eid_table_dump.api) to re-create the LISP config in VPP
2. Execute the lisp_eid_table_dump API from Python CLI

root@gtw01:~# python3
Python 3.6.9 (default, Apr 18 2020, 01:56:04)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> from vpp_papi import VPPApiClient as VPP
>>> log=logging.getLogger("test")
>>> log.setLevel(logging.DEBUG)
>>> logging.basicConfig()
>>> 
>>> c=VPP(logger=log)
>>> c.connect("test")

DEBUG:test:No such message type or failed CRC checksum: oddbuf_enable_disable_3865946c

DEBUG:test:No such message type or failed CRC checksum: oddbuf_enable_disable_reply_e8d4e804

0

>>> 
>>> func=getattr(c.api, "lisp_eid_table_dump")
>>> 
>>> func()
DEBUG:test:Calling lisp_eid_table_dump('context':1,'_vl_msg_id':373)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 113, in _call_
    return self._func(**kwargs)
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 452, in f
    return self._call_vpp(i, msg, multipart, **kwargs)
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 697, in _call_vpp
    r = self.read_blocking(no_type_conversion, timeout)
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 779, in read_blocking
    return self.decode_incoming_msg(msg, no_type_conversion)
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_papi.py", line 600, in decode_incoming_msg
    r, size = msgobj.unpack(msg, ntc=no_type_conversion)
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_serializer.py", line 644, in unpack
    x, size = p.unpack(data, offset, result, ntc)
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_serializer.py", line 644, in unpack
    x, size = p.unpack(data, offset, result, ntc)
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_serializer.py", line 467, in unpack
    x, size = p.unpack(data, offset, ntc=ntc)
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_serializer.py", line 654, in unpack
    t = conversion_unpacker(t, self.name)
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_serializer.py", line 66, in conversion_unpacker
    return vpp_format.conversion_unpacker_table[field_type](data)
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_format.py", line 220, in <lambda>
    'vl_api_prefix_t': lambda o: unformat_api_prefix_t(o),
  File "/usr/lib/python3/dist-packages/vpp_papi/vpp_format.py", line 193, in unformat_api_prefix_t
    raise ValueError('Unknown address family {}'.format(o))
ValueError: Unknown address family vl_api_prefix_t(address=vl_api_address_t(af=<vl_api_address_family_t.128|64|32|16|8|2: 250>, un=vl_api_address_union_t(ip4=b'\x16<\xa0\xe9',)
>>> 

IMO this looks like a bug in the serializer/de-serializer – it does not recognize the fact that the lisp_eid_table_dump*call now returns the new *vl_api_eid_t type which goes as follows:

/* endpoint identifier */

typedef eid

{         
vl_api_eid_type_t type;         
vl_api_eid_address_t address;
};

 enum eid_type : u8

{         
EID_TYPE_API_PREFIX = 0,         
EID_TYPE_API_MAC = 1,         
EID_TYPE_API_NSH = 2,
};

union eid_address

{         
vl_api_prefix_t prefix;        
vl_api_mac_address_t mac;         
vl_api_nsh_t nsh;
};
 

I could be wrong, of course.