ping possible bug ("-I" option)

[Denys Vlasenko]

On Thu, Jul 16, 2009 at 9:39 AM, Javier Viguera<javier.viguera at digi.com> wrote:
> My eth1 is 192.168.105.1
>
> busybox.git$ sudo ./busybox -I eth1 192.168.105.1
> PING 192.168.105.1 (192.168.105.1): 56 data bytes
>
> --- 192.168.105.1 ping statistics ---
> 2 packets transmitted, 0 packets received, 100% packet loss
>
> busybox.git$ ping -I eth1 192.168.105.1
> PING 192.168.105.1 (192.168.105.1) from 192.168.105.1 eth1: 56(84) bytes of
> data.
> 64 bytes from 192.168.105.1: icmp_seq=1 ttl=64 time=0.030 ms
> 64 bytes from 192.168.105.1: icmp_seq=2 ttl=64 time=0.024 ms
> 64 bytes from 192.168.105.1: icmp_seq=3 ttl=64 time=0.024 ms
>
> --- 192.168.105.1 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 1998ms
>
> The funny thing is that in both above cases (ping and busybox's ping) i
> verified with wireshark that the ICMP frames where correctly send and
> received (as you said through the lo interface).
>
>> No.     Time        Source                Destination           Protocol
>> Info
>>      1 0.000000    192.168.105.1         192.168.105.1         ICMP
>> Echo (ping) request
>>      2 0.000025    192.168.105.1         192.168.105.1         ICMP
>> Echo (ping) reply
>>      3 1.000088    192.168.105.1         192.168.105.1         ICMP
>> Echo (ping) request
>>      4 1.000110    192.168.105.1         192.168.105.1         ICMP
>> Echo (ping) reply
>>      5 2.000171    192.168.105.1         192.168.105.1         ICMP
>> Echo (ping) request
>>      6 2.000194    192.168.105.1         192.168.105.1         ICMP
>> Echo (ping) reply
>>      7 3.000259    192.168.105.1         192.168.105.1         ICMP
>> Echo (ping) request
>>      8 3.000281    192.168.105.1         192.168.105.1         ICMP
>> Echo (ping) reply
>>      9 4.000340    192.168.105.1         192.168.105.1         ICMP
>> Echo (ping) request
>>     10 4.000363    192.168.105.1         192.168.105.1         ICMP
>> Echo (ping) reply
>
> It is just busybox's ping not representing the replies while "normal" ping
> does.

Yes, because we really are using a socket which is bound to eth0 (in my case):

socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
getuid32()                              = 0
setuid32(0)                             = 0
setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "eth0\...", 32) = 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ here we bind it
setsockopt(3, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [7280], 4) = 0
rt_sigaction(SIGINT, ...)
clock_gettime(CLOCK_MONOTONIC, {17363, 129898752}) = 0
sendto(3, "\10\0\216ESY\0\0*V\354\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
64, 0, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("10.34.33.157")}, 28) = 64
rt_sigaction(SIGALRM, ....
alarm(1)                                = 0
recvfrom(3, 0xffb11b60, 192, 0, 0xffb11c30, 0xffb11c40) = ?
ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---

and therefore recvfrom does not see the reply. There is no reply on eth0,
it's on lo!

Ubuntu's ping seems to not bind the socket.
--
vda