* iputils: ping -I <iface> @ 2012-11-29 14:12 Jan Synacek 2012-11-29 19:48 ` Ben Greear 0 siblings, 1 reply; 5+ messages in thread From: Jan Synacek @ 2012-11-29 14:12 UTC (permalink / raw) To: YOSHIFUJI Hideaki; +Cc: netdev 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, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: iputils: ping -I <iface> 2012-11-29 14:12 iputils: ping -I <iface> Jan Synacek @ 2012-11-29 19:48 ` Ben Greear 2012-11-30 6:06 ` Jan Synacek 0 siblings, 1 reply; 5+ messages in thread From: Ben Greear @ 2012-11-29 19:48 UTC (permalink / raw) To: Jan Synacek; +Cc: YOSHIFUJI Hideaki, netdev On 11/29/2012 06:12 AM, Jan Synacek wrote: > 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. 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). > 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 > > I don't understand the problem clearly enough to write a patch. > > Regards, > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: iputils: ping -I <iface> 2012-11-29 19:48 ` Ben Greear @ 2012-11-30 6:06 ` Jan Synacek 2012-11-30 19:04 ` YOSHIFUJI Hideaki 0 siblings, 1 reply; 5+ messages in thread From: Jan Synacek @ 2012-11-30 6:06 UTC (permalink / raw) To: Ben Greear; +Cc: YOSHIFUJI Hideaki, netdev On 11/29/2012 08:48 PM, Ben Greear wrote: > On 11/29/2012 06:12 AM, Jan Synacek wrote: >> 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. > > 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. > >> 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. > > Thanks, > Ben > Regards, -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: iputils: ping -I <iface> 2012-11-30 6:06 ` Jan Synacek @ 2012-11-30 19:04 ` YOSHIFUJI Hideaki 2012-11-30 19:11 ` Ben Greear 0 siblings, 1 reply; 5+ messages in thread From: YOSHIFUJI Hideaki @ 2012-11-30 19:04 UTC (permalink / raw) To: Jan Synacek; +Cc: Ben Greear, netdev, YOSHIFUJI Hideaki (2012年11月30日 15:06), Jan Synacek wrote: > On 11/29/2012 08:48 PM, Ben Greear wrote: >> On 11/29/2012 06:12 AM, Jan Synacek wrote: >>> 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. >> >> 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. > >> >>> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: iputils: ping -I <iface> 2012-11-30 19:04 ` YOSHIFUJI Hideaki @ 2012-11-30 19:11 ` Ben Greear 0 siblings, 0 replies; 5+ messages in thread From: Ben Greear @ 2012-11-30 19:11 UTC (permalink / raw) To: YOSHIFUJI Hideaki; +Cc: Jan Synacek, netdev On 11/30/2012 11:04 AM, YOSHIFUJI Hideaki wrote: > (2012年11月30日 15:06), Jan Synacek wrote: >> On 11/29/2012 08:48 PM, Ben Greear wrote: >>> On 11/29/2012 06:12 AM, Jan Synacek wrote: >>>> 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. >>> >>> 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. >> >>> >>>> 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? 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 > > --yoshfuji > -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-11-30 19:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-29 14:12 iputils: ping -I <iface> Jan Synacek 2012-11-29 19:48 ` Ben Greear 2012-11-30 6:06 ` Jan Synacek 2012-11-30 19:04 ` YOSHIFUJI Hideaki 2012-11-30 19:11 ` Ben Greear
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).