netdev - Re: iputils: ping -I <iface>

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 30 Nov 2012 11:11:14 -0800
From:	Ben Greear <greearb@...delatech.com>
To:	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
CC:	Jan Synacek <jsynacek@...hat.com>, netdev@...r.kernel.org
Subject: Re: iputils: ping -I <iface>

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@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html