From: Nils Fuhler <nils@nilsfuhler.de>
To: Paolo Abeni <pabeni@redhat.com>,
davem@davemloft.net, dsahern@kernel.org, edumazet@google.com,
kuba@kernel.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, nils@nilsfuhler.de
Subject: Re: [PATCH v2] net: ip6: ndisc: fix incorrect forwarding of proxied ns packets
Date: Wed, 21 Aug 2024 19:57:55 +0200 [thread overview]
Message-ID: <fcb4b7d9-08e1-4a8b-8218-a7301e6930f5@nilsfuhler.de> (raw)
In-Reply-To: <a95f1211-0f1b-4957-8e31-1b53af888cb5@redhat.com>
On 20/08/2024 15:13, Paolo Abeni wrote:
>
>
> On 8/15/24 17:18, Nils Fuhler wrote:
>> When enabling proxy_ndp per interface instead of globally, neighbor
>> solicitation packets sent to proxied global unicast addresses are
>> forwarded instead of generating a neighbor advertisement. When
>> proxy_ndp is enabled globally, these packets generate na responses as
>> expected.
>>
>> This patch fixes this behaviour. When an ns packet is sent to a
>> proxied unicast address, it generates an na response regardless
>> whether proxy_ndp is enabled per interface or globally.
>>
>> Signed-off-by: Nils Fuhler <nils@nilsfuhler.de>
>
> I have mixed feeling WRT this patch. It looks like a fix, but it's changing an established behaviour that is there since a lot of time.
>
> I think it could go via the net-next tree, without fixes
> tag to avoid stable backports. As such I guess it deserves a self-test script validating the new behavior.
>
That is probably the best option.
Although I'm not sure whether it would really break something. The
forwarded packets have a hoplimit of 254 and are therefore not valid
ndisc packets anymore.
>> ---
>> v1 -> v2: ensure that idev is not NULL
>>
>> net/ipv6/ip6_output.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>> index ab504d31f0cd..0356c8189e21 100644
>> --- a/net/ipv6/ip6_output.c
>> +++ b/net/ipv6/ip6_output.c
>> @@ -551,8 +551,8 @@ int ip6_forward(struct sk_buff *skb)
>> return -ETIMEDOUT;
>> }
>> - /* XXX: idev->cnf.proxy_ndp? */
>> - if (READ_ONCE(net->ipv6.devconf_all->proxy_ndp) &&
>> + if ((READ_ONCE(net->ipv6.devconf_all->proxy_ndp) ||
>> + (idev && READ_ONCE(idev->cnf.proxy_ndp))) &&
>> pneigh_lookup(&nd_tbl, net, &hdr->daddr, skb->dev, 0)) {
>> int proxied = ip6_forward_proxy_check(skb);
>> if (proxied > 0) {
>
> Note that there is similar chunk in ndisc_recv_na() that also ignores idev->cnf.proxy_ndp, why don't you need to such function, too?
I have noticed the chunk in ndisc_recv_na() and did some quick testing
but I was not able to get an obviously wrong behavior out of it.
I have to admit, though, that I am not sure if I understand the
condition correctly. At the start, it checks that the lladdr of the
received na packet is equal to the lladdr of the reciving interface.
That can only happen, when the interface receives its own packet, right?
Is there a valid case where that can happen? Or am I missing something?
Greetings,
Nils
next prev parent reply other threads:[~2024-08-21 17:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-15 15:18 Nils Fuhler
2024-08-20 13:13 ` Paolo Abeni
2024-08-21 17:57 ` Nils Fuhler [this message]
2024-12-16 17:01 ` Florian Rommel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fcb4b7d9-08e1-4a8b-8218-a7301e6930f5@nilsfuhler.de \
--to=nils@nilsfuhler.de \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®