Skip to contentSkip to conversation

iputils: ping -I <iface>

DISCUSSION Jan Synacek 3 participants 5 messages Nov 29, 2012 – Nov 30, 2012

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

Jan Synacek

author
#0 lore raw

Hello,

There seems to be a bug(?) when calling ping with -I lo:

$ ping -I lo kernel.org

PING kernel.org (149.20.4.69) from 192.168.1.10 lo: 56(84) bytes of data. ^C

Note that 192.168.1.10 is my primary interface's address (em1). However, no replies are coming back.

$ ping -I em1 kernel.org

PING kernel.org (149.20.4.69) from 192.168.1.10 em1: 56(84) bytes of data. 64 bytes from pub2.kernel.org (149.20.4.69): icmp_seq=1 ttl=42 time=202 ms 64 bytes from pub2.kernel.org (149.20.4.69): icmp_seq=2 ttl=42 time=187 ms ^C

Works as expected.

I know that binding to loopback probably doesn't make much sense, but I think that ping should be able to cope with that.

Also, it would be nice to mention the difference between -I <ip> and -I <iface> in the manpage.

I don't understand the problem clearly enough to write a patch.

Regards,

Signature · 2 lines
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
#1 lore raw
Quoted 19 lines · Jan Synacek

Hello,

There seems to be a bug(?) when calling ping with -I lo:

$ ping -I lo kernel.org

PING kernel.org (149.20.4.69) from 192.168.1.10 lo: 56(84) bytes of data. ^C

Note that 192.168.1.10 is my primary interface's address (em1). However, no replies are coming back.

$ ping -I em1 kernel.org

PING kernel.org (149.20.4.69) from 192.168.1.10 em1: 56(84) bytes of data. 64 bytes from pub2.kernel.org (149.20.4.69): icmp_seq=1 ttl=42 time=202 ms 64 bytes from pub2.kernel.org (149.20.4.69): icmp_seq=2 ttl=42 time=187 ms ^C

Quoted 4 lines

Works as expected.

I know that binding to loopback probably doesn't make much sense, but I think that ping should be able to cope with that.

I think it would be wrong if ping worked as you suggest. Binding to an interface means use that interface as the source of your packets, and having it bind hard helps when using systems with multiple NICs on same subnet (or possibly, same IP).

Quoted 2 lines

Also, it would be nice to mention the difference between -I <ip> and -I <iface> in the manpage.

In my opinion, -I <iface> should use SO_BINDTODEVICE, but at least in older versions of ping it did not.

Thanks,
Ben

Quoted 5 lines

I don't understand the problem clearly enough to write a patch.

Regards,

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
author
#2 lore raw
Quoted 22 lines · Ben Greear
Quoted 21 lines · Jan Synacek

Hello,

There seems to be a bug(?) when calling ping with -I lo:

$ ping -I lo kernel.org

PING kernel.org (149.20.4.69) from 192.168.1.10 lo: 56(84) bytes of data. ^C

Note that 192.168.1.10 is my primary interface's address (em1). However, no replies are coming back.

$ ping -I em1 kernel.org

PING kernel.org (149.20.4.69) from 192.168.1.10 em1: 56(84) bytes of data. 64 bytes from pub2.kernel.org (149.20.4.69): icmp_seq=1 ttl=42 time=202 ms 64 bytes from pub2.kernel.org (149.20.4.69): icmp_seq=2 ttl=42 time=187 ms ^C

Works as expected.

Quoted 7 lines
Quoted 2 lines

I know that binding to loopback probably doesn't make much sense, but I think that ping should be able to cope with that.

I think it would be wrong if ping worked as you suggest. Binding to an interface means use that interface as the source of your packets, and having it bind hard helps when using systems with multiple NICs on same subnet (or possibly, same IP).

I just wanted to point out that if I call ping with -I lo, its 'from' address is wrong (in my case 192.168.1.10) and nothing happens (that's, I guess, expected if it really bound to loopback). If I call ping with the -I <the same address> or -I em1 (the same address again), it works as expected. I'm sorry if I wasn't clear enough.

Quoted 6 lines
Quoted 3 lines

Also, it would be nice to mention the difference between -I <ip> and -I <iface> in the manpage.

In my opinion, -I <iface> should use SO_BINDTODEVICE, but at least in older versions of ping it did not.

Ping does use SO_BINDTODEVICE.

Quoted 4 lines

Thanks,
Ben

Regards,

Signature · 2 lines
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
#3 lore raw
Quoted 38 lines · Jan Synacek
Quoted 22 lines · Ben Greear
Quoted 21 lines · Jan Synacek

Hello,

There seems to be a bug(?) when calling ping with -I lo:

$ ping -I lo kernel.org

PING kernel.org (149.20.4.69) from 192.168.1.10 lo: 56(84) bytes of data. ^C

Note that 192.168.1.10 is my primary interface's address (em1). However, no replies are coming back.

$ ping -I em1 kernel.org

PING kernel.org (149.20.4.69) from 192.168.1.10 em1: 56(84) bytes of data. 64 bytes from pub2.kernel.org (149.20.4.69): icmp_seq=1 ttl=42 time=202 ms 64 bytes from pub2.kernel.org (149.20.4.69): icmp_seq=2 ttl=42 time=187 ms ^C

Works as expected.

Quoted 7 lines
Quoted 2 lines

I know that binding to loopback probably doesn't make much sense, but I think that ping should be able to cope with that.

I think it would be wrong if ping worked as you suggest. Binding to an interface means use that interface as the source of your packets, and having it bind hard helps when using systems with multiple NICs on same subnet (or possibly, same IP).

I just wanted to point out that if I call ping with -I lo, its 'from' address is wrong (in my case 192.168.1.10) and nothing happens (that's, I guess, expected if it really bound to loopback). If I call ping with the -I <the same address> or -I em1 (the same address again), it works as expected. I'm sorry if I wasn't clear enough.

Quoted 1 line
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Also, it would be nice to mention the difference between -I <ip> and -I <iface> in the manpage.

In my opinion, -I <iface> should use SO_BINDTODEVICE, but at least in older versions of ping it did not.

Ping does use SO_BINDTODEVICE.

So far, -I device is related to source address selection (using SO_BINDTODEVICE) and outgoing device (using in_pktinfo). On the other hand, -I addr is, in fact, related to source address selection (and it is enfoced by bind), only.

Something like this:

-I interface
interface is either an address, or an interface name. If interface is an address, it sets source address to
specified interface address. If interface
in an interface name, it tells the command to use that interface. For ping6, when doing ping to a link-local scope address, link specification (by the '%'-notation in destination, or by this option) is required.

BUT, even with -I device, net/ipv4/dev_inet.c:inet_select_addr() may select an address from other interfaces, AFAIK).

Should we check if the selected source address blongs to the actual device?

--yoshfuji

#4 lore raw
Quoted 64 lines · YOSHIFUJI Hideaki
Quoted 38 lines · Jan Synacek
Quoted 22 lines · Ben Greear
Quoted 21 lines · Jan Synacek

Hello,

There seems to be a bug(?) when calling ping with -I lo:

$ ping -I lo kernel.org

PING kernel.org (149.20.4.69) from 192.168.1.10 lo: 56(84) bytes of data. ^C

Note that 192.168.1.10 is my primary interface's address (em1). However, no replies are coming back.

$ ping -I em1 kernel.org

PING kernel.org (149.20.4.69) from 192.168.1.10 em1: 56(84) bytes of data. 64 bytes from pub2.kernel.org (149.20.4.69): icmp_seq=1 ttl=42 time=202 ms 64 bytes from pub2.kernel.org (149.20.4.69): icmp_seq=2 ttl=42 time=187 ms ^C

Works as expected.

Quoted 7 lines
Quoted 2 lines

I know that binding to loopback probably doesn't make much sense, but I think that ping should be able to cope with that.

I think it would be wrong if ping worked as you suggest. Binding to an interface means use that interface as the source of your packets, and having it bind hard helps when using systems with multiple NICs on same subnet (or possibly, same IP).

I just wanted to point out that if I call ping with -I lo, its 'from' address is wrong (in my case 192.168.1.10) and nothing happens (that's, I guess, expected if it really bound to loopback). If I call ping with the -I <the same address> or -I em1 (the same address again), it works as expected. I'm sorry if I wasn't clear enough.

Quoted 1 line
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Also, it would be nice to mention the difference between -I <ip> and -I <iface> in the manpage.

In my opinion, -I <iface> should use SO_BINDTODEVICE, but at least in older versions of ping it did not.

Ping does use SO_BINDTODEVICE.

So far, -I device is related to source address selection (using SO_BINDTODEVICE) and outgoing device (using in_pktinfo). On the other hand, -I addr is, in fact, related to source address selection (and it is enfoced by bind), only.

Something like this:

-I interface
interface is either an address, or an interface name. If interface is an address, it sets source address to
specified interface address. If interface
in an interface name, it tells the command to use that interface. For ping6, when doing ping to a link-local scope address, link specification (by the '%'-notation in destination, or by this option) is required.

Quoted 5 lines

BUT, even with -I device, net/ipv4/dev_inet.c:inet_select_addr() may select an address from other interfaces, AFAIK).

Should we check if the selected source address blongs to the actual device?

Maybe have -D <iface-name> and -P <source-address> options?

Where -D uses SO_BINDTODEVICE, and -P binds to a source IP?

Would have to keep the -I logic similar to what it does now for backwards compatibility...

Thanks,
Ben

Quoted 3 lines

--yoshfuji

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com