Your message dated Fri, 24 Nov 2017 18:11:13 -0800
with message-id <[email protected]>
and subject line Re: Bug#882331: mtr: source routing with --address does not
work
has caused the Debian Bug report #882331,
regarding mtr: source routing with --address does not work
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
882331: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882331
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: mtr
Version: 0.92-1
Severity: normal
Hi,
there is a regression in 0.92.
Specifying an interface with --address is broken.
-a, --address ADDRESS bind the outgoing socket to ADDRESS
ie.
mtr -4 --address 213.198.94.174 ic.cz
will not get routed through the interface with the 213.198.94.174
address but instead uses the default route on the system.
This does not happen with mtr_0.87-1~bpo8+1_amd64.deb.
-- System Information:
Debian Release: 8.9
APT prefers oldstable
APT policy: (800, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages mtr depends on:
ii libc6 2.19-18+deb8u10
ii libcap2 1:2.24-8
ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u6
ii libglib2.0-0 2.42.1-1+b1
ii libgtk2.0-0 2.24.25-3+deb8u2
ii libncurses5 6.0+20170902-1
ii libtinfo5 6.0+20170902-1
mtr recommends no packages.
mtr suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
On 11/24/2017 02:03 AM, Tom Hetmer wrote:
> OK, feel free to close this if you don't know how to fix it.
> We'll have to add 0.87 to our repo & pin it as that's the last
> bug-free version.
I already provided a solution for you. Here it is again, a little more
spelled out. This is in the same test VM from my previous email.
Here's the status quo config - IPs configured on ens2 and ens3, default
route out via ens2:
root@test:~# ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
inet 192.168.9.29/24 brd 192.168.9.255 scope global ens2
valid_lft forever preferred_lft forever
3: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
inet 192.168.10.29/24 brd 192.168.10.255 scope global ens3
valid_lft forever preferred_lft forever
root@test:~# ip route
default via 192.168.9.1 dev ens2 onlink
192.168.9.0/24 dev ens2 proto kernel scope link src 192.168.9.29
192.168.10.0/24 dev ens3 proto kernel scope link src 192.168.10.29
We're going to create an alternate routing table with a default route
out via ens3 instead:
root@test:~# ip route add default via 192.168.10.1 dev ens3 table 10
root@test:~# ip route list table 10
default via 192.168.10.1 dev ens3
We're going to create a rule that takes packets with an fwmark of 10 and
sends them to this alternate routing table:
root@test:~# ip rule add fwmark 10 table 10
root@test:~# ip rule show
0: from all lookup local
32765: from all fwmark 0xa lookup 10
32766: from all lookup main
32767: from all lookup default
Now we're going to add an iptables mangle rule to add an fwmark of 10
for packets sent from our IP on ens3:
root@test:~# iptables -A OUTPUT -t mangle -s 192.168.10.29 -j MARK
--set-mark 10
root@test:~# iptables -nvL OUTPUT -t mangle
Chain OUTPUT (policy ACCEPT 55 packets, 6380 bytes)
pkts bytes target prot opt in out source
destination
0 0 MARK all -- * * 192.168.10.29
0.0.0.0/0 MARK set 0xa
Now when we rerun mtr with the -a option:
root@test:~# mtr -c 1 --report -a 192.168.10.29 1.2.3.4
Start: 2017-11-24T18:08:47-0800
HOST: test Loss% Snt Last Avg Best Wrst StDev
We see the packets going out the ens3 interface:
root@test:~# tcpdump -ni ens3 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
18:08:47.985857 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33000, length 44
18:08:48.086187 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33001, length 44
18:08:48.186485 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33002, length 44
18:08:48.286779 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33003, length 44
18:08:48.387028 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33004, length 44
18:08:48.487285 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33005, length 44
18:08:48.587596 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33006, length 44
18:08:48.687729 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33007, length 44
18:08:48.787970 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33008, length 44
18:08:48.888223 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33009, length 44
18:08:48.988467 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33010, length 44
18:08:49.088689 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33011, length 44
18:08:49.189025 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33012, length 44
18:08:49.289370 IP 192.168.10.29 > 1.2.3.4: ICMP echo request, id 1758,
seq 33013, length 44
--- End Message ---
