Dotaz: rozdíl mezi 'ping -I adresa' a 'ping -I interface' ?

[Franta Hanzlík]

Žil jsem zřejmě v bludu (a man stránka ping u přepínače "-I" to i navozuje:
Set source address to specified interface address. Argument may be numeric IP address or name of device.
) mysle si, že výsledek je stejný. Ale není:

# ping -I 90.182.150.74 -n -c 1 90.179.172.17
PING 90.179.172.17 (90.179.172.17) from 90.182.150.74 : 56(84) bytes of data.
64 bytes from 90.179.172.17: icmp_seq=1 ttl=58 time=28.2 ms

--- 90.179.172.17 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 28ms
rtt min/avg/max/mdev = 28.220/28.220/28.220/0.000 ms
# 
# ping -I eth2 -n -c 1 90.179.172.17
PING 90.179.172.17 (90.179.172.17) from 90.182.150.74 eth2: 56(84) bytes of data.
From 90.182.150.74 icmp_seq=1 Destination Host Unreachable

--- 90.179.172.17 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 3000ms

# 
# ip addr sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:e0:4c:15:b4:15 brd ff:ff:ff:ff:ff:ff
    inet 90.182.150.74/29 brd 90.182.150.79 scope global eth2
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:21:27:c7:98:84 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 00:19:e0:14:67:9f brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp 
    inet 90.176.219.147 peer 88.103.200.3/32 scope global ppp0

Tohle je na jádře 2.6.32, ping z iputils v20071127.
Když to zkouším na jiném stroji s jádrem 3.6.2 / ping z iputils v20101006 / capabilities na /bin/ping = cap_net_raw+ep, je to také divné (ale jinak, ping -I IFACE hlásí "Warning: cannot bind to specified iface, falling back: Operation not permitted"):

# ping -I 80.92.224.140 -n -c 1 90.179.172.17
PING 90.179.172.17 (90.179.172.17) from 80.92.224.140 : 56(84) bytes of data.
64 bytes from 90.179.172.17: icmp_req=1 ttl=58 time=21.4 ms

--- 90.179.172.17 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 21.426/21.426/21.426/0.000 ms
#
# ping -I eth1 -n -c 1 90.179.172.17
Warning: cannot bind to specified iface, falling back: Operace není povolena
PING 90.179.172.17 (90.179.172.17) from 80.92.224.140 eth1: 56(84) bytes of data.
64 bytes from 90.179.172.17: icmp_req=1 ttl=58 time=38.6 ms

--- 90.179.172.17 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 38.641/38.641/38.641/0.000 ms
# 
# ip addr sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 50:e5:49:5a:92:66 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:08:c7:19:47:f0 brd ff:ff:ff:ff:ff:ff
    inet 80.92.224.140/24 brd 80.92.224.255 scope global eth1

SELinux je v obou případech vypnutý, ping je spuštěný root-em.
Dokáže tahle chování prosím někdo vysvětlit?

Odpovědi

[NN]

Asi bych si to jeste overil pres tcpdump, ale na debianu iputils-ping 3:20100418-3 nemam zadny problem..

[pavlix]

tcpdump ti nepomůže.

[NN]

Mozna by se poznalo jestli to vubec odejde do stacku..

[pavlix]

To se pozná už podle toho permission denied.

[pavlix]

Mám za to, že to dělá přecně to, co se tam píše. Váže to socket na konkrétní interface voláním setsockopt nebo tak něco. To v případě pingání na adresu nedělá. O zbytek se postará kernel.

[Franta Hanzlík]

Jak 'pingání na adresu'? To se pingá v obou případech, ne? Jde asi o zdrojovou adresu; já si právě myslel, že ten přepínač "-I" určí interface z něhož ICMP pakety budou odcházet, A ZÁROVEŇ zdrojovou IP adresu. Tedy že ať použiji kterýkoliv tvar, tak bude výsledek stejný. A tady mám na dvou různých sestavách tři odlišné výsledky:
1) oba stroje, 'ping -I SrcAddress':
funguje; tcpdump ukazuje, že pakety odcházejí z rozhraní s adresou 'SrcAddress'

2) 2.6.32 + iputils v20071127, 'ping -I IfaceName':
Destination Host Unreachable, dle tcpdump je aktivní jen rozhraní lo (!), ale zdrojová adresa je adresa rozhraní 'IfaceName' (eth2) (?cojetozazvrhlost?):

22:07:25.158125 IP 90.182.150.74 > 90.182.150.74: ICMP host 90.179.172.17 unreachable, length 92

3) 3.6.2 + iputils v20101006, 'ping -I IfaceName':
hlásí "Warning: cannot bind to specified iface, falling back: Operation not permitted"

[pavlix]

Jak 'pingání na adresu'? To se pingá v obou případech, ne?

Jo, sorry.

já si právě myslel, že ten přepínač "-I" určí interface z něhož ICMP pakety budou odcházet

Ano, pokud zadáš interface.

zdrojovou IP adresu.

Ano, pokud zadáš adresu a pravděpodobně i pokud zadáš interface, ale tam si nejsem na 100% jistý.

Tedy že ať použiji kterýkoliv tvar, tak bude výsledek stejný.

Jak sám vidíš, není tomu tak.

A tady mám na dvou různých sestavách tři odlišné výsledky:

Pokud chceš vědět, co ping skutečně dělá, použij strace. Ale upozorňuju tě, že to není moc hezké čtení.

[NN]

Neblokujes to firewallem ?

[Michal Kubeček]

Už se to tu řešilo, ta manuálová stránka je bohužel špatně.

[Franta Hanzlík]

Skleroza :). OK, v případě 'ping -I interface' ping použije socket option "SO_BINDTODEVICE". Ale je potom normální, že se to chová tak, že cílovou adresu předpokládá na segmentu tohoto interface? Ačkoliv podle IP adresy interface a masky to tak být nemůže? tcpdump totiž ukazuje jen ARP dotazy:

# tcpdump -i eth2 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
06:52:59.951966 ARP, Request who-has 90.179.170.17 tell 90.182.150.74, length 28
06:53:00.951965 ARP, Request who-has 90.179.170.17 tell 90.182.150.74, length 28
06:53:01.951964 ARP, Request who-has 90.179.170.17 tell 90.182.150.74, length 28

PS: To chování iputils-v20101006 ping-u je nejspíš způsobené tím, že ping zahodí CAP_NET_RAW capability před voláním "setsockopt(..,SO_BINDTODEVICE, IfName,..)", takže to vždy končí EPERM. Asi Fedora-specific patch podle zdrojáků (těm jsem se chtěl vyhnout;).

[Ondrej 'SanTiago' Zajicek]

Nevim, zda by tohle melo delat samotne SO_BINDTODEVICE, ale urcite by tomu tak bylo, pokud by k tomu ping prihodil jeste SO_DONTROUTE (nezkousel jsem, co presne ping pouziva za socket options).