Zero block in IPv6 route prefix misinterpreted

[0xb35c]

Hi,
if you have a zero block in one of your route prefixes scapy will die with a "Illegal syntax for IP address" exception.

$ route -6n
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
fd00:2001:0:c020::/64          ::                         U    600 1     3 wlp4s0

In arch/linux.py:263 the route is read and d is set to fd0020010000c0200000000000000000.
This parsed in the function inet_pton from pton_ntop.py and incorrectly truncated to fd00:2001::c020:: (the correct value for that example would be fd00:2001:0:c020::), which again is validated from the same function at a later point and causes the exception.

I installed scapy in a virtualenv and with pacman. Running sudo scapy and from scapy.all import * in ipython causes the exception.

[0xb35c]

Actually it seems that the return value from inet_pton from pton_ntop.py is fed into inet_ntop, which causes the issue.

[guedou]

For sure fd00:2001::c020:: is a weird IPv6 address ! On Linux, Scapy uses the output of /proc/net/ipv6_route. Would you mind sharing it with us ? This will help us mock and debug the issue easily.

Thanks.

[guedou]

@p-l- that's a nasty nasty bug =)

[0xb35c]

Hi,
here it is:

fd0020010000c0200000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000258 00000000 00000000 00000001   wlp4s0
fe800000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000258 00000000 00000000 00000001   wlp4s0
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001 vboxnet0
fe800000000000000000000000000000 40 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000000 00000000 00000001   wlp4s0
00000000000000000000000000000000 00 00000000000000000000000000000000 00 fe800000000000000000000000000001 00000258 00000002 00000004 00000003   wlp4s0
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00007031 00200200       lo
00000000000000000000000000000001 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000005 00000121 80200001       lo
fd0020010000c020d9f1952d72aa052d 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000001 00000000 80200001       lo
fe80000000000000080027fffe000000 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000005 00000011 80200001       lo
fe800000000000000ed67a68be4e52f2 80 00000000000000000000000000000000 00 00000000000000000000000000000000 00000000 00000002 00000001 80200001       lo
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000004 00000060 00000001 vboxnet0
ff000000000000000000000000000000 08 00000000000000000000000000000000 00 00000000000000000000000000000000 00000100 00000004 0000001b 00000001   wlp4s0
00000000000000000000000000000000 00 00000000000000000000000000000000 00 00000000000000000000000000000000 ffffffff 00000001 00007031 00200200       lo

The issue here is the first line though.

[guedou]

Thanks a lot. I was able to reproduce the issue.

[guedou]

@0xb35c I can confirm that PR #363 was not a correct fix for Windows. Will you mind submitting your fix that use regexp ?

[0xb35c]

@guedou I will do so. I need to find some time to create a according PR.