Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752487AbcL0Irr (ORCPT ); Tue, 27 Dec 2016 03:47:47 -0500 Received: from m50-155.163.com ([123.125.50.155]:9617 "EHLO m50-155.163.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751256AbcL0Irp (ORCPT ); Tue, 27 Dec 2016 03:47:45 -0500 X-Greylist: delayed 940 seconds by postgrey-1.27 at vger.kernel.org; Tue, 27 Dec 2016 03:47:44 EST X-Originating-IP: [221.237.152.67] Date: Tue, 27 Dec 2016 16:29:05 +0800 (CST) From: "wei zhang" To: kuznet@ms2.inr.ac.ru, davem@davemloft.net, jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@trash.net Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re:[PATCH] net: fix incorrect original ingress device index in PKTINFO X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20160729(86883.8884) Copyright (c) 2002-2016 www.mailtech.cn 163com In-Reply-To: <1482825138-2125-1-git-send-email-asuka.com@163.com> References: <1482825138-2125-1-git-send-email-asuka.com@163.com> Content-Type: text/plain; charset=GBK MIME-Version: 1.0 Message-ID: <64f198a9.a52b.1593f65ad7e.Coremail.asuka.com@163.com> X-Coremail-Locale: zh_CN X-CM-TRANSID: j8GowEA5X0JRJmJY1cECAA--.20549W X-CM-SenderInfo: 5dvxytoofrzqqrwthudrp/1tbiDw9N1lUL-CzMRgABse X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id uBR8m25c008685 Content-Length: 2073 Lines: 48 At 2016-12-27 15:52:18, "Wei Zhang" wrote: >When we send a packet for our own local address on a non-loopback interface >(e.g. eth0), due to the change had been introduced from commit 0b922b7a829c >("net: original ingress device index in PKTINFO"), the original ingress >device index would be set as the loopback interface. However, the packet >should be considered as if it is being arrived via the sending interface >(eth0), otherwise it would break the expectation of the userspace >application (e.g. the DHCPRELEASE message from dhcp_release binary would >be ignored by the dnsmasq daemon) > >Signed-off-by: Wei Zhang >--- > net/ipv4/ip_sockglue.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > >diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c >index b8a2d63..b6a6d35 100644 >--- a/net/ipv4/ip_sockglue.c >+++ b/net/ipv4/ip_sockglue.c >@@ -1202,8 +1202,13 @@ void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb) > * which has interface index (iif) as the first member of the > * underlying inet{6}_skb_parm struct. This code then overlays > * PKTINFO_SKB_CB and in_pktinfo also has iif as the first >- * element so the iif is picked up from the prior IPCB >+ * element so the iif is picked up from the prior IPCB except >+ * iif is loopback interface which the packet should be >+ * considered as if it is being arrived via the sending interface > */ >+ if (pktinfo->ipi_ifindex == LOOPBACK_IFINDEX) { >+ pktinfo->ipi_ifindex = inet_iif(skb); >+ } > pktinfo->ipi_spec_dst.s_addr = fib_compute_spec_dst(skb); > } else { > pktinfo->ipi_ifindex = 0; >-- >1.8.3.1 > When I upgrade to the 4.9, the dhcp_release could not release the dhcp lease, the dnsmasq ignored all the DHCPRELEASE message which it think come from lo. I think this is due to the commit 0b922b7a829c, which set the IPCB(skb)->iif = skb->skb_iif in the ip_rcv()! And I'm very sorry about forgetting checkpatch, I will resend the patch, hope I'm not bothering you! Thanks, Wei Zhang