This is done by traceroute and other tools as well. It requires CAP_NET_RAW, but without it the -I option doesn't seem to have any effect.
I could only test with IPv4, but it worked fine for ICMP, TCP and UDP. Not sure if additional handling is required for the case where CAP_NET_RAW isn't available it shows "Unexpected mtr-packet error" like it does for -M. Before this change there was no error, but it didn't take the interface into account.
Could be relevant for #379, #250, #232, although it doesn't handle the -a option. This is comparable to traceroute though. traceroute -s <IP> shows the same (wrong?) hops as mtr -a <IP> after this change, while traceroute -i <NAME> shows the same (correct) hops as mtr -I <NAME>. So I'd argue that this is the correct behavior.
This is done by traceroute and other tools as well. It requires CAP_NET_RAW, but without it the
-Ioption doesn't seem to have any effect.I could only test with IPv4, but it worked fine for ICMP, TCP and UDP. Not sure if additional handling is required for the case where CAP_NET_RAW isn't available it shows "Unexpected mtr-packet error" like it does for
-M. Before this change there was no error, but it didn't take the interface into account.Could be relevant for #379, #250, #232, although it doesn't handle the
-aoption. This is comparable totraceroutethough.traceroute -s <IP>shows the same (wrong?) hops asmtr -a <IP>after this change, whiletraceroute -i <NAME>shows the same (correct) hops asmtr -I <NAME>. So I'd argue that this is the correct behavior.