From: Zhu Yanjun
Date: Wed, 20 Aug 2014 17:31:43 +0800
> Since the transport has always been in state SCTP_UNCONFIRMED, it
> therefore wasn't active before and hasn't been used before, and it
> always has been, so it is unnecessary to bug the user with a
> notification.
>
> Reported-by: Deepak
On 08/20/2014 11:31 AM, Zhu Yanjun wrote:
Since the transport has always been in state SCTP_UNCONFIRMED, it
therefore wasn't active before and hasn't been used before, and it
always has been, so it is unnecessary to bug the user with a
notification.
Reported-by: Deepak Khandelwal
Suggested-by:
On 08/20/2014 05:31 AM, Zhu Yanjun wrote:
> Since the transport has always been in state SCTP_UNCONFIRMED, it
> therefore wasn't active before and hasn't been used before, and it
> always has been, so it is unnecessary to bug the user with a
> notification.
>
> Reported-by: Deepak Khandelwal
>
Since the transport has always been in state SCTP_UNCONFIRMED, it
therefore wasn't active before and hasn't been used before, and it
always has been, so it is unnecessary to bug the user with a
notification.
Reported-by: Deepak Khandelwal
Suggested-by: Vlad Yasevich
Suggested-by: Michael Tue
On 08/15/2014 11:27 AM, Zhu Yanjun wrote:
When a failed probe comes along UNCONFIRMED path, it is not necessary
to send SCTP_PEER_ADDR_CHANGE notification.
I do not find this in the RFC, but it seems reasonable - at least, I would
have liked to see a more elaborate commit message from you expla
When a failed probe comes along UNCONFIRMED path, it is not necessary
to send SCTP_PEER_ADDR_CHANGE notification.
Reported-by: DEEPAK KHANDELWAL
Suggested-by: Vlad Yasevich
Suggested-by: Michael Tuexen
Signed-off-by: Zhu Yanjun
---
net/sctp/associola.c | 1 +
1 file changed, 1 insertion(+)
6 matches
Mail list logo