All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
To: Vlad Yasevich <vladislav.yasevich@hp.com>
Cc: David Miller <davem@davemloft.net>,
	linux-sctp@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] SCTP: enable cookie-echo retransmission transport switch
Date: Fri, 13 Jun 2008 00:47:41 +0000	[thread overview]
Message-ID: <4851C3AD.9030600@cn.fujitsu.com> (raw)
In-Reply-To: <48513BA4.9030403@hp.com>

Vlad,

  Thanks for your comments.

Vlad Yasevich wrote:
> Gui Jianfeng wrote:
>> Vlad,
>> This patch enables cookie-echo retransmission transport switch
>> feature. If COOKIE-ECHO retransmission happens, it will be sent to the
>> address other than the one last sent to.
>>
> 
> NAK.
> 
> You can't blindly choose a different transport since they could
> be unconfirmed and can't really be used until we confirm them
> with HBs.  So, you can only do this when the user issued an
> sctp_connectx() and we have multiple confirmed transports.
> 
> In this case only confirmed transports are allowed, otherwise
> there is a possibility of hijacking associations.
> 
  Choosing a transport here just gives a suggestion for sctp_outq_flush(),
  sctp_outq_flush() will judge again. If the selected transport is in 
  INACTIVE or UNCONFIRMED, active_path will be used.
  So COOKIE-ECHO won't be sent to a unconfirmed address.

> 
> Also, looking at this, the same problem exists in current
> code for selection INIT transports.
> 
> We don't correctly treat peers passed to connectx() as confirmed
> and don't select the correct transport.
> 
> Once you fix that above, you can just re-use the function and
> re-use init_last_sent_to.

  Will do.

> 
> -vlad
> 



> 
> 

-- 
Regards
Gui Jianfeng

WARNING: multiple messages have this Message-ID (diff)
From: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
To: Vlad Yasevich <vladislav.yasevich@hp.com>
Cc: David Miller <davem@davemloft.net>,
	linux-sctp@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH] SCTP: enable cookie-echo retransmission transport switch
Date: Fri, 13 Jun 2008 08:47:41 +0800	[thread overview]
Message-ID: <4851C3AD.9030600@cn.fujitsu.com> (raw)
In-Reply-To: <48513BA4.9030403@hp.com>

Vlad,

  Thanks for your comments.

Vlad Yasevich wrote:
> Gui Jianfeng wrote:
>> Vlad,
>> This patch enables cookie-echo retransmission transport switch
>> feature. If COOKIE-ECHO retransmission happens, it will be sent to the
>> address other than the one last sent to.
>>
> 
> NAK.
> 
> You can't blindly choose a different transport since they could
> be unconfirmed and can't really be used until we confirm them
> with HBs.  So, you can only do this when the user issued an
> sctp_connectx() and we have multiple confirmed transports.
> 
> In this case only confirmed transports are allowed, otherwise
> there is a possibility of hijacking associations.
> 
  Choosing a transport here just gives a suggestion for sctp_outq_flush(),
  sctp_outq_flush() will judge again. If the selected transport is in 
  INACTIVE or UNCONFIRMED, active_path will be used.
  So COOKIE-ECHO won't be sent to a unconfirmed address.

> 
> Also, looking at this, the same problem exists in current
> code for selection INIT transports.
> 
> We don't correctly treat peers passed to connectx() as confirmed
> and don't select the correct transport.
> 
> Once you fix that above, you can just re-use the function and
> re-use init_last_sent_to.

  Will do.

> 
> -vlad
> 



> 
> 

-- 
Regards
Gui Jianfeng

  reply	other threads:[~2008-06-13  0:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-12  4:37 [PATCH] SCTP: enable cookie-echo retransmission transport switch Gui Jianfeng
2008-06-12  4:37 ` Gui Jianfeng
2008-06-12 15:07 ` Vlad Yasevich
2008-06-12 15:07   ` Vlad Yasevich
2008-06-13  0:47   ` Gui Jianfeng [this message]
2008-06-13  0:47     ` Gui Jianfeng
2008-06-13 12:57     ` Vlad Yasevich
2008-06-13 12:57       ` Vlad Yasevich

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=4851C3AD.9030600@cn.fujitsu.com \
    --to=guijianfeng@cn.fujitsu.com \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vladislav.yasevich@hp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.