You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Linux 5.7.19 / Debian Sid I created a pair of veth interfaces and disabled IPv6 on them:
ip link add vethx type veth peer name vethy
ip link set up dev vethx
ip link set up dev vethy
echo 1 > /proc/sys/net/ipv6/conf/vethx/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/vethy/disable_ipv6
I then run into the issue that the icmp6 listener installs the pcap handle on the wrong interface, on "lo"/loopback, instead of the given $IFACE. And that the listener then is not able to receive any of the packets from the icmp6 sender.
Which is similar to how mldq6.c, rd6.c, rs6.c, tcp6.c and udp6.c do it.
The issue seems to be caused by load_dst_and_pcap() changing the idata.iface two times. Once here (changes it from vethy to wlp61s0). And once here (changes it from wlp61s0 to lo).
Before submitting a patch like adding the idata.dstaddr_f check to icmp6.c, as present in other tools, I do not quite understand why the listening interface should be changed in the first place when --interface is given. Seems counter intuitive and confusing? And potentially annoying because it's done without informing the user. Am I missing a specific use-case?
My ultimate goal is to use the ipv6toolkit to exchange icmp6 echo requests/replies without depending on the kernel IPv6 stack. And without performing any neighbor discovery.
The text was updated successfully, but these errors were encountered:
T-X
changed the title
Interface selection on interface without IPv6 support / next hop lookup
Interface selection on interface without IPv6 support / next hop lookup broken
Jan 12, 2021
Hi,
On Linux 5.7.19 / Debian Sid I created a pair of veth interfaces and disabled IPv6 on them:
I then run icmp6 sender as follows:
And the icmp6 listener as follows:
I then run into the issue that the icmp6 listener installs the pcap handle on the wrong interface, on "lo"/loopback, instead of the given $IFACE. And that the listener then is not able to receive any of the packets from the icmp6 sender.
Changing this line here as follows helps:
Before:
After:
Which is similar to how mldq6.c, rd6.c, rs6.c, tcp6.c and udp6.c do it.
The issue seems to be caused by load_dst_and_pcap() changing the idata.iface two times. Once here (changes it from vethy to wlp61s0). And once here (changes it from wlp61s0 to lo).
Before submitting a patch like adding the idata.dstaddr_f check to icmp6.c, as present in other tools, I do not quite understand why the listening interface should be changed in the first place when --interface is given. Seems counter intuitive and confusing? And potentially annoying because it's done without informing the user. Am I missing a specific use-case?
My ultimate goal is to use the ipv6toolkit to exchange icmp6 echo requests/replies without depending on the kernel IPv6 stack. And without performing any neighbor discovery.
The text was updated successfully, but these errors were encountered: