ipdb: IPv6 MP fix breaks handling of tables > 255

[PaulSD]

8278ecb has broken handling of IPv6 routes in route tables above 255:

# ip -6 route add table 256 1234::/64 dev eth0
# ip route add table 256 1.2.3.0/24 dev eth0
# python
>>> from pyroute2 import IPDB
>>> ipdb = IPDB()
>>> ipdb.routes.tables[256]
[{'metrics': {}, 'oif': 2, 'dst_len': 64, 'family': 10, 'proto': 3, 'tos': 0, 'dst': '1234::/64', 'pref': '00', 'flags': 0, 'ipdb_priority': 0, 'priority': 1024, 'header': {'pid': 3844071573, 'length': 116, 'flags': 2, 'error': None, 'type': 24, 'sequence_number': 257}, 'scope': 0, 'attrs': [('RTA_TABLE', 256), ('RTA_DST', '1234::'), ('RTA_PRIORITY', 1024), ('RTA_OIF', 2), ('RTA_CACHEINFO', {'rta_error': 0, 'rta_id': 0, 'rta_expires': 0, 'rta_ts': 0, 'rta_lastuse': 2159, 'rta_tsage': 0, 'rta_used': 0, 'rta_clntref': 1}), ('RTA_PREF', '00')], 'encap': {}, 'src_len': 0, 'table': 0, 'multipath': (), 'type': 1, 'event': 'RTM_NEWROUTE', 'ipdb_scope': 'system'}, {'oif': 2, 'dst_len': 24, 'family': 2, 'proto': 4, 'tos': 0, 'dst': '1.2.3.0/24', 'ipdb_priority': 0, 'metrics': {}, 'flags': 0, 'encap': {}, 'src_len': 0, 'table': 256, 'multipath': (), 'type': 1, 'scope': 0, 'ipdb_scope': 'system'}]
>>> ipdb.routes.tables[256][0].remove().commit()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/pyroute2/ipdb/routes.py", line 584, in commit
    raise error
pyroute2.netlink.exceptions.NetlinkError: (3, 'No such process')

Notice that the IPv6 Route object hasn't been cleaned up properly (it still has 'header' and 'attrs' fields, the 'table' field hasn't been overwritten by the RTA_TABLE attr, etc), although the IPv4 Route object has been cleaned up.
Because of this, the remove() call on the IPv6 route fails because the incorrect 'table' value ends up being sent in RTA_TABLE in the netlink message requesting route deletion.

[svinota]

Didn't make a proper test yet (so not closing the ticket), but it should help if I understood the issue.

[PaulSD]

Sorry, forgot to follow up on this. Yes, it appears fixed now.