On 06/03/2013 02:37 PM, Bruce Ashfield wrote:
On 13-06-02 10:06 PM, Xufeng Zhang wrote:
On 06/01/2013 01:29 AM, Bruce Ashfield wrote:
On 13-05-31 05:11 AM, Xufeng Zhang wrote:
commit 9839ff0dead906e85e4d17490aeff87a5859a157 upstream
I assume this is for the 3.4 tree ?
Yes.
Great.
Do
On 13-06-02 10:06 PM, Xufeng Zhang wrote:
On 06/01/2013 01:29 AM, Bruce Ashfield wrote:
On 13-05-31 05:11 AM, Xufeng Zhang wrote:
commit 9839ff0dead906e85e4d17490aeff87a5859a157 upstream
I assume this is for the 3.4 tree ?
Yes.
Great.
Do you know if this same commit has been submitte
On 06/01/2013 01:29 AM, Bruce Ashfield wrote:
On 13-05-31 05:11 AM, Xufeng Zhang wrote:
commit 9839ff0dead906e85e4d17490aeff87a5859a157 upstream
I assume this is for the 3.4 tree ?
Yes.
Do you know if this same commit has been submitted to the korg 3.4
stable tree ?
Check the code in:
ht
On 13-05-31 05:11 AM, Xufeng Zhang wrote:
commit 9839ff0dead906e85e4d17490aeff87a5859a157 upstream
I assume this is for the 3.4 tree ?
Do you know if this same commit has been submitted to the korg 3.4
stable tree ?
The change looks fine, but I'd like to be sure it is also going to
every 3.4
commit 9839ff0dead906e85e4d17490aeff87a5859a157 upstream
While sctp handling a duplicate COOKIE-ECHO and the action is
'Association restart', sctp_sf_do_dupcook_a() will processing
the unexpected COOKIE-ECHO for peer restart, but it does not set
the association state to SCTP_STATE_ESTABLISHED, so
