On Fri, Jan 23, 2015 at 01:30:55PM -0500, Vlad Yasevich wrote:
> On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
> > On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
> >> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
> >>> On 01/23/2015 11:25 AM, Sun Paul wrote:
> >>> ...
> I would like to check t
On 01/26/2015 02:17 PM, Sun Paul wrote:
When an ABORT is sent to side-A, side-A INIT a new connection again.
Even if the ABORT is not being sent, the peer (the one who would send
his ABORT) closes the TCB from his side silently then. Any messages that
would afterwards arrive on this dead connec
When an ABORT is sent to side-A, side-A INIT a new connection again.
On Mon, Jan 26, 2015 at 7:46 PM, Marcelo Ricardo Leitner
wrote:
> Hi,
>
> On 25-01-2015 23:27, Sun Paul wrote:
>>
>> Hi
>>
>> sorry for the late reply. I am a bit confused. when side-A sends a
>> request to side-B, and side-B re
Hi,
On 25-01-2015 23:27, Sun Paul wrote:
Hi
sorry for the late reply. I am a bit confused. when side-A sends a
request to side-B, and side-B return the response, but side-A keep
re-transmit the same request to side-B, why side-B needed to send a
ABORT to side-A?
That happens on data transfers
Hi
sorry for the late reply. I am a bit confused. when side-A sends a
request to side-B, and side-B return the response, but side-A keep
re-transmit the same request to side-B, why side-B needed to send a
ABORT to side-A?
If it is used in order to reestablish the connection, shoudn't it
should be
> On 23 Jan 2015, at 18:10, Daniel Borkmann wrote:
>
> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>> ...
I would like to check the behave in LKSCTP.
we are running DIAMETER message ove
> On 23 Jan 2015, at 19:30, Vlad Yasevich wrote:
>
> On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
>> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
On 01/23/2015 11:25 AM, Sun Paul wrote:
...
> I would like to check the behave in L
On 01/23/2015 07:36 PM, Michael Tuexen wrote:
...
Yepp. It might not reach the peer or it might. If it does it helps
to keep the states in sync. If it doesn't it sometimes helps in
analysing tracefiles. In BSD, we also send it. It is not required,
doesn't harm and is useful in some cases...
Ok,
On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>> ...
I would like to check the behave in LKSCTP.
we are running DIAMETER message over SCTP, a
On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
On 01/23/2015 11:25 AM, Sun Paul wrote:
...
I would like to check the behave in LKSCTP.
we are running DIAMETER message over SCTP, and we have set the
parameter "net.sctp.association_max_retrans = 4" in
On 01/23/2015 05:25 AM, Sun Paul wrote:
> Hi
>
> I would like to check the behave in LKSCTP.
>
> we are running DIAMETER message over SCTP, and we have set the
> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>
> We noticed that when remote peer have retry to send the same requ
On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
> Hi,
>
> On 01/23/2015 11:25 AM, Sun Paul wrote:
> ...
>> I would like to check the behave in LKSCTP.
>>
>> we are running DIAMETER message over SCTP, and we have set the
>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>
>> We no
Hi,
On 01/23/2015 11:25 AM, Sun Paul wrote:
...
I would like to check the behave in LKSCTP.
we are running DIAMETER message over SCTP, and we have set the
parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
We noticed that when remote peer have retry to send the same request
for 4
Hi
I would like to check the behave in LKSCTP.
we are running DIAMETER message over SCTP, and we have set the
parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
We noticed that when remote peer have retry to send the same request
for 4 times, the LKSCTP will initiate an ABORT chunk
14 matches
Mail list logo