Difference in address selection between ICMP and TCP

[Andre Oppermann]

On 31.01.2012 21:27, Guido van Rooij wrote:
>
> Consider the following:
> ifconfig em0 inet 1.2.3.4/24
> ping 1.2.3.4
>
> Then a tcpdump on lo0 shows:
> 21:15:56.641571 IP 127.0.0.1>  1.2.3.4: ICMP echo request, id 36105, seq 10, length 64
> 21:15:56.641582 IP 1.2.3.4>  127.0.0.1: ICMP echo reply, id 36105, seq 10, length 64
>
> I think that the address used should have been 1.2.3.4 and not 127.0.0.1.
>
> Now when I do a telnet 1.2.3.4 22, I see:
> 21:17:55.955475 IP 1.2.3.4.38534>  1.2.3.4.22: Flags [S], seq 904951907, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 1850412 ecr 0], length 0
> 21:17:55.955487 IP 1.2.3.4.22>  1.2.3.4.38534: Flags [R.], seq 0, ack 904951908, win 0, length 0
>
> So in this case we actually do use 1.2.3.4!
>
> This is on a 8.1 system. A 8.2 system shows the same behaviour and a 7.4
> system behaves correctly (i.e.: uses the same address for icmp as for
> tcp).
>
> I tried to investigate the souce code, but my knwoledge about it is a
> bit rusty :-(

The way the source address is determined is different between ping-icmp
and TCP. For ping-icmp the source address is filled in ip_output() based
on the outgoing interface. For all local addresses, including those on
real interfaces the loopback interface is used. You can see that by doing
a "netstat -ran".

> -Guido
>
> NB: perhaps related: When I do the ping in a vimage on a different
> VIMAGE-kernel, the ping fails because the source address is never
> filled in (i.e. is 0.0.0.0)

The loopback interface is inaccessible from a jail and thus the source
address is never filled in and stays at INADDR_ANY.

A fix for either issue is not entirely trivial and fraught with other
potential undesired side effects.

-- 
Andre