From: Daniel Borkmann <dborkman@redhat.com>
To: vyasevic@redhat.com
Cc: Duan Jiong <duanj.fnst@cn.fujitsu.com>,
davem@davemloft.net, netdev@vger.kernel.org, vyasevich@gmail.com
Subject: Re: [PATCH] ipv6: Do route updating for redirect in ndisc layer
Date: Thu, 12 Sep 2013 14:07:05 +0200 [thread overview]
Message-ID: <5231AE69.4050704@redhat.com> (raw)
In-Reply-To: <52311604.6080507@redhat.com>
On 09/12/2013 03:16 AM, Vlad Yasevich wrote:
> On 09/11/2013 07:17 PM, Hannes Frederic Sowa wrote:
>> [added Cc to Daniel and Vlad because of ipv6/sctp/redirect problem]
>>
>> On Wed, Sep 11, 2013 at 03:04:35PM +0800, Duan Jiong wrote:
>>> 于 2013年09月11日 06:50, Hannes Frederic Sowa 写道:
>>>> On Mon, Sep 09, 2013 at 03:09:56PM +0800, Duan Jiong wrote:
>>>>> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
>>>>> index 5c71501..61fe8e5 100644
>>>>> --- a/net/ipv6/tcp_ipv6.c
>>>>> +++ b/net/ipv6/tcp_ipv6.c
>>>>> @@ -382,14 +382,6 @@ static void tcp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
>>>>>
>>>>> np = inet6_sk(sk);
>>>>>
>>>>> - if (type == NDISC_REDIRECT) {
>>>>> - struct dst_entry *dst = __sk_dst_check(sk, np->dst_cookie);
>>>>> -
>>>>> - if (dst)
>>>>> - dst->ops->redirect(dst, sk, skb);
>>>>> - goto out;
>>>>> - }
>>>>> -
>>>>
>>>> You dropped the "goto out" here in case of an NDISC_REDIRECT, so this sends an
>>>> EPROTO further up the socket layer. Was this intended?
>>>>
>>>
>>> I'm sorry, i didn't notice the variable err was assigned to EPROTO.
>>> I only thought that message should be sent to the socket layer, because
>>> i found that in function sctp_v6_err().
>>>
>>> In addition, the rfc 4443 said the Redirect Message is not the ICMPv6 Error
>>> Message, so i think we shouldn't call those err_handler function, in other
>>> words we shouldn't call the icmpv6_notify().
>>>
>>> How do you think of this?
>>
>> Hm, thats hard.
>>
>> First of, when the kernel started publishing these errors it had a
>> contract with user-space we cannot break now. This includes all error
>> handling functions which call ipv6_icmp_error. So we only have to care
>> about INET6_PROTO_FINAL protocols, bbecause they mostly operate in socket
>> space (in this case these are the raw and the udp protocol and currently
>> sctp). Especially I do think it is important to report the redirects
>> to raw sockets. The other non-final protocols only need to be notified
>> for mtu reduction currently. Maybe we could stop notifying non-final
>> protocols for redirects, but I don't think this will improve things.
>>
>> Also we cannot know if the router sending the redirect discarded the
>> original packet or if it forwarded it just notifying us of a better route,
>> so we don't know if an actual error happend. So I would do the same thing
>> as IPv4 sockets, set sk_err to zero and queue up the icmp packet on the
>> socket's error queue (for udp and raw).
>>
>> Regarding notifying tcp sockets about the redirect seems wrong. It would
>> generate a poll notification and I do think it could even tear down
>> the whole connection. I guess sctp should also stop updating sk_err
>> on redirects. But let's Cc Daniel and Vlad about this. My guess is that
>> sctp could go into some error recovery mode because of this which would
>> be wrong.
>
> You are right. SCTP shouldn't be setting sk_err on redirects as it
> isn't an error condition. it should be doing exactly what tcp is doing and leaving the error handler without touching the socket.
Yep, probably something like ...
diff --git a/net/sctp/input.c b/net/sctp/input.c
index 5f20686..98b69bb 100644
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -634,8 +634,7 @@ void sctp_v4_err(struct sk_buff *skb, __u32 info)
break;
case ICMP_REDIRECT:
sctp_icmp_redirect(sk, transport, skb);
- err = 0;
- break;
+ /* Fall through to out_unlock. */
default:
goto out_unlock;
}
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index 4f52e2c..e7b2d4f 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -183,7 +183,7 @@ static void sctp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
break;
case NDISC_REDIRECT:
sctp_icmp_redirect(sk, transport, skb);
- break;
+ goto out_unlock;
default:
break;
}
> Thanks
> -vlad
>
>>
>> So, for this patch I would leave the logic as is and not change anything
>> at the error reporting. Maybe Daniel and Vlad could check if we should
>> suppress redirect information for ipv6 in sctp, too? But this should
>> go into another patch. Regarding the EPROTO problem in raw and udp,
>> let's see if all the problems go away if we update icmpv6_err_convert
>> to set *err to 0.
>>
>> Greetings,
>>
>> Hannes
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
prev parent reply other threads:[~2013-09-12 12:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-09 7:09 [PATCH] ipv6: Do route updating for redirect in ndisc layer Duan Jiong
2013-09-10 22:50 ` Hannes Frederic Sowa
2013-09-11 7:04 ` Duan Jiong
2013-09-11 23:17 ` Hannes Frederic Sowa
2013-09-12 1:16 ` Vlad Yasevich
2013-09-12 12:07 ` Daniel Borkmann [this message]
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=5231AE69.4050704@redhat.com \
--to=dborkman@redhat.com \
--cc=davem@davemloft.net \
--cc=duanj.fnst@cn.fujitsu.com \
--cc=netdev@vger.kernel.org \
--cc=vyasevic@redhat.com \
--cc=vyasevich@gmail.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;
as well as URLs for NNTP newsgroup(s).