netdev - Re: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 05 Feb 2007 11:39:19 -0500
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Steve Hill <steve.hill@...logic.com>
Cc:	netdev@...r.kernel.org, lksctp-developers@...ts.sourceforge.net,
	Sridhar Samudrala <sri@...ibm.com>
Subject: Re: [Lksctp-developers] Fw: Intermittent SCTP multihoming breakage

Steve Hill wrote:
> Vlad Yasevich wrote on 25 January 2007 16:33:
> 
>> Can you try the attached patch and let me know if the problem is
>> fixed.  You can try reducing rto_max or path_max_retrans to get the
>> failover to happen a little faster. 
> 
> Sorry for the delay - I've been on vacation for the past week.
> 
> I've tried applying the patch.  However, the failure still seems to
> happen in the original test system with a patched kernel.  A look at the
> network traffic shows that the receiving side is still returning a
> gap-ack, the chunks in the gap are never resent and I don't see a
> FORWARD TSN for them.

Once you start simulating the network failure, how long do you wait?

If you have not changed rto_max and path_max_retrans, you can end up
waiting quite a while for the full path switchover.  This will also
severely slow down your retransmissions...

Try reducing /proc/sys/net/sctp/rto_max to say 6000ms (6 seconds).  It
defaults to (60000 ms or 1 minute).  That reduction means that the
retransmit timeout will max out at 6 seconds.

The problem is that you will not see the FORWARD TSN on the alternate
path until the original path is marked down.  That requires us to
exceed the path_max_retrans counter
(/proc/sys/net/sctp/path_max_retrans).  This means that you will see
the gap grow until a time when the rto exceeds the data expiry time.
At this pint, you will not see any new data sent, since it will expire
before being sent.  So, it will look to you like nothing is happening.

The gap will be closed once the FWD-TSN is transmitted over the
alternate transport.

-vlad

> 
>  - Steve Hill
>    Software Engineer
>    Dialogic
>    Fordingbridge, Hampshire, UK
>    +44-1425-651392
>    steve.hill@...logic.com
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
> 

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html