Cannot run hping3 against a host on remote VPN link - Issue with too many interfaces - VPN link on my laptop is #48 - hping3 stops searching after 16 interfaces

[ak2766]

It appears that I cannot get hping3 to ping a host in a remote network when connected via VPN tunnel. I'm not sure whether the issue is that I have too many interfaces (I do lots of virtualization on my laptop and currently have 48 interfaces - mainly due to LXD containers).

I've tried forcing which interface to use via the -I tun0 flag but no joy - hping3 always binds to lo for hosts on the remote subnet.

List of interfaces (too many to list here - unless explicitly requested):

$ ip l l | awk '/^[0-9]*:/ {print}'| wc -l
48

Routing info (relevant route listed):

$ ip r l | egrep 10.2.20
10.2.20.0/24 via 10.64.192.14 dev tun0 

Route to remote host:

[Fri Jul 27 17:33:31 - 4.15.0-29-generic - /dev/pts/26]
[akk@akk-m6700 10.0.0.13: ~/source/hping (master)]
$ ip r g 10.2.20.74
10.2.20.74 via 10.64.192.14 dev tun0  src 10.64.192.13 
    cache 

Attempt to hping:

[Fri Jul 27 17:29:06 - 4.15.0-29-generic - /dev/pts/26]
[akk@akk-m6700 10.0.0.13: ~/source/hping (master)]
$ sudo ./hping3 -I tun0 -S -p 443 10.2.20.74
HPING 10.2.20.74 (lo 10.2.20.74): S set, 40 headers + 0 data bytes
^C
--- 10.2.20.74 hping statistic ---
5 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

A simple ping:

[Fri Jul 27 17:31:32 - 4.15.0-29-generic - /dev/pts/26]
[akk@akk-m6700 10.0.0.13: ~/source/hping (master)]
$ ping -c4 10.2.20.74
PING 10.2.20.74 (10.2.20.74) 56(84) bytes of data.
From 10.64.192.222: icmp_seq=1 Redirect Network(New nexthop: 10.64.192.211)
64 bytes from 10.2.20.74: icmp_seq=1 ttl=62 time=12.1 ms
From 10.64.192.222: icmp_seq=2 Redirect Network(New nexthop: 10.64.192.211)
64 bytes from 10.2.20.74: icmp_seq=2 ttl=62 time=12.5 ms
From 10.64.192.222: icmp_seq=3 Redirect Network(New nexthop: 10.64.192.211)
64 bytes from 10.2.20.74: icmp_seq=3 ttl=62 time=13.0 ms
From 10.64.192.222: icmp_seq=4 Redirect Network(New nexthop: 10.64.192.211)
64 bytes from 10.2.20.74: icmp_seq=4 ttl=62 time=11.6 ms

--- 10.2.20.74 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 11.670/12.542/13.082/0.436 ms

Let me know what else to provide to help narrow the problem.

[njombart]

You may run with -D (debug) to try to see more details about interface selection

[ak2766]

@njombart I've tried as you suggested - looks like it gives up after trying a few interfaces.

Below is the result:

$ sudo ./hping3 -D -I tun0 -S -p 443 10.2.20.74
DEBUG: if lo: Don't Match (but seems to be UP)
DEBUG: if eth0:avahi: Don't Match (but seems to be UP)
DEBUG: if wlan0: Don't Match (but seems to be UP)
DEBUG: if br0: Don't Match (but seems to be UP)
DEBUG: if vmbridge: Don't Match (but seems to be UP)
DEBUG: if lxdbr0: Don't Match (but seems to be UP)
DEBUG: if vmwarews12br0: Don't Match (but seems to be UP)
DEBUG: if vmwarews12br1: Don't Match (but seems to be UP)
DEBUG: if vmwarews12br2: Don't Match (but seems to be UP)
DEBUG: if vmwarews12br3: Don't Match (but seems to be UP)
DEBUG: if vmwarews12br4: Don't Match (but seems to be UP)
DEBUG: if br-0039e1852ce5: Don't Match (but seems to be UP)
DEBUG: if docker0: Don't Match (but seems to be UP)
DEBUG: if br-37a9a1f3ebc0: Don't Match (but seems to be UP)
DEBUG: if docker_gwbridge: Don't Match (but seems to be UP)
DEBUG: if virbr1: Don't Match (but seems to be UP)
using lo, addr: 127.0.0.1, MTU: 1500
DEBUG: pcap_open_live(lo, 99999, 0, 1, 0x626820)
DEBUG: dltype is 1
HPING 10.2.20.74 (lo 10.2.20.74): S set, 40 headers + 0 data bytes
45 00 00 28 BE E8 00 00 40 06 00 00 7F 00 00 01 0A 02 14 4A 09 7B 01 BB 2D 8F 02 EF 34 9D AA C4 50 02 02 00 F5 7F 00 00 
DEBUG: under pcap_recv()
DEBUG: [pcap_recv] p = NULL
DEBUG: [pcap_recv] p = NULL
DEBUG: [pcap_recv] p = NULL
DEBUG: [pcap_recv] p = NULL
DEBUG: [pcap_recv] p = NULL
DEBUG: [pcap_recv] p = NULL

That DEBUG: [pcap_recv] p = NULL continuously floods my screen and intermittently tossing a line similar to the one below every ~930 lines: 45 00 00 28 BE E8 00 00 40 06 00 00 7F 00 00 01 0A 02 14 4A 09 7B 01 BB 2D 8F 02 EF 34 9D AA C4 50 02 02 00 F5 7F 00 00

[ak2766]

Unfortunately for me, since I make the VPN link after all other links have come up (or much later in the day or when the link drops and recreated), the VPN interface (tun0) is normally at the bottom of the list.

So it seems that maybe a flag could be provided that instructs HPING to keep trying to the end of the list or maybe give it a regexp of interfaces to exclude. For instance, if I remove the interfaces with noqueue and those in a DOWN state, I end up with a much smaller list of interfaces to try:

$ ip l l | perl -l -0777 -ne 'for (m{^[0-9].*?(?=^[0-9]|\Z)}gsm) {print if !/noqueue|DOWN/}'
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 3c:a9:f4:39:9c:d0 brd ff:ff:ff:ff:ff:ff

61: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100
    link/none 

62: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 90:f6:52:17:e1:81 brd ff:ff:ff:ff:ff:ff

And as you can see, today I have 46 interfaces:

$ ip l l | awk '/^[0-9]*:/ {print}'| wc -l
46

[njombart]

Yep there is a limit to 16 interface which was enough before container times ... I would suggest increase this limit in getifname.c as a workaround

[ak2766]

@njombart thanks for the suggestion. I'll use it as a workaround for now.

If this is not something planned for a future update, then please close this issue.

[ak2766]

For completeness sake, here's what I had to modify to get it to work in my environment of numerous interfaces.

Modify file getifname.c line 47 on commit 3547c7691742c6eaa31f8402e0ccbb81387c1b99 of master branch:

From:

struct ifreq    ibuf[16],

To:

struct ifreq    ibuf[80],

[zhangyoufu]

I ran into this issue today. My environment has a lot of VLAN interfaces.

Just a note, for Docker containers, you can make use of macvlan network driver to get rid of extra veth interfaces in init netns.

Don't forget to change memset(ibuf, 0, sizeof(struct ifreq)*16); line as well.