ICMP reply uses wrong source address as destinatio

ICMP reply uses wrong source address as destinatio

[Anders Nilsson Plymoth]

Dear linux kernel enthusiasts,

I came upon an issue where ICMP reply packets were issued towards the
IP address of the receiving interface, rather than the source IP
address.
Looking at the kernel code, I saw that this is caused by the following
line in net/ipv4/icmp.c function icmp_reply:

daddr = ipc.addr = rt->rt_src;

For most cases the original line of code is ok, but in some situations
doesn't arrive to the kernel from the network device, but through some
other mechanism such as a userspace application. In these cases the
receiving device in the skb appears to be the loopback interface, not
a physical device. icmp_reply will thus issue the reply to the
loopback IP address, rather than the source IP address as it should.

While googling to see if this issue have been submitted, I found this
two posts that address the same problem:
h**p://www.mail-archive.com/linux-kernel@vger.kernel.org/msg209746.html
h**p://www.mail-archive.com/linux-kernel@vger.kernel.org/msg208272.html
Some of the questions there are easy to answer; such as this doesn't
affect DNAT, and if source address is not set then you can' reply
anyway.

As to the statement:
"... which IP address should be used as the source

1. the destination address of the packet that generated the message

or.

2. the IP address that the machine would use by default if the machine
were to generate a new connection to the destination."

These may be relevant questions, but the ICMP RFC clearly states the
answer is 1. 2. may seem relevant to multi-homing, but its not the
role of the ICMP reply to resolve multi-homing issues.

The following code will correct the issue.

{
   struct iphdr *ip = ip_hdr(skb);
   daddr = ipc.addr = ip->saddr;
}

The only functions that use icmp_reply are icmp_echo and
icmp_timestamp, and this change do not modify their behavior. After
extensive testing, in regular setups and DNATed situations, I can
verify this change works as intended.

Thanks,
Anders

Re: ICMP reply uses wrong source address as destinatio

[Eric Dumazet]

Le mardi 01 mars 2011 à 09:49 +0100, Anders Nilsson Plymoth a écrit :
> Dear linux kernel enthusiasts,
> 
> I came upon an issue where ICMP reply packets were issued towards the
> IP address of the receiving interface, rather than the source IP
> address.
> Looking at the kernel code, I saw that this is caused by the following
> line in net/ipv4/icmp.c function icmp_reply:
> 
> daddr = ipc.addr = rt->rt_src;
> 
> For most cases the original line of code is ok, but in some situations
> doesn't arrive to the kernel from the network device, but through some
> other mechanism such as a userspace application. In these cases the
> receiving device in the skb appears to be the loopback interface, not
> a physical device. icmp_reply will thus issue the reply to the
> loopback IP address, rather than the source IP address as it should.
> 
> While googling to see if this issue have been submitted, I found this
> two posts that address the same problem:
> h**p://www.mail-archive.com/linux-kernel@vger.kernel.org/msg209746.html
> h**p://www.mail-archive.com/linux-kernel@vger.kernel.org/msg208272.html
> Some of the questions there are easy to answer; such as this doesn't
> affect DNAT, and if source address is not set then you can' reply
> anyway.
> 
> As to the statement:
> "... which IP address should be used as the source
> 
> 1. the destination address of the packet that generated the message
> 
> or.
> 
> 2. the IP address that the machine would use by default if the machine
> were to generate a new connection to the destination."
> 
> These may be relevant questions, but the ICMP RFC clearly states the
> answer is 1. 2. may seem relevant to multi-homing, but its not the
> role of the ICMP reply to resolve multi-homing issues.
> 
> The following code will correct the issue.
> 
> {
>    struct iphdr *ip = ip_hdr(skb);
>    daddr = ipc.addr = ip->saddr;
> }
> 
> The only functions that use icmp_reply are icmp_echo and
> icmp_timestamp, and this change do not modify their behavior. After
> extensive testing, in regular setups and DNATed situations, I can
> verify this change works as intended.

I suspect you could respin Lepton Wu patch (from msg209746.html) on top
of net-next-2.6 and add your "Acked-by or Tested-by"

Keep in mind changelog should be very very detailed because patch was
delayed because of this.