[SCTP] transport address unconfirmed instead of inactive

[Michael Tüxen]

On Jan 17, 2011, at 8:11 AM, Schoch Christian wrote:

> I did some test with multihoming and failover. My problem is that if one transport failes it never comes back to active (no heartbeats are sent any more).
> 
> My setup:
> 
> FreeBSD 8.1          Linux 2.6.36
> 172.16.1.4 --------- 172.16.1.3
> 172.17.1.4 --------- 172.17.1.3
> 
> Packets from 16.1.4 to 17.1.3 and 17.1.4 to 16.1.3 are dropped.
> 
> The transfer starts with 172.16.1.4 to 16.1.3 which is working as expected.
Which side is the client, which one is the server? Which side is sending user
data?
> If the transfer on this transport failes, it is switching to 17.1.4 & 17.1.3 as expected. 
How do you fail the connection? Disconnecting the cable? Configuring dummynet?
> 172.16.1.4 gets SCTP_UNCONFIRMED, 172.16.1.3 gets SCTP_INACTIVE
So you mean on the FreeBSD machine you get a SCTP_UNCONFIRMED? For which address? 172.16.1.3?
> Now, if the first connection is available again, the first transport address of FreeBSD stays at unconfirmed with no HB sent to 16.1.3
> Linux sends HB from 16.1.3 to 16.1.4 with ACK coming back from 17.1.4 to 16.1.3 (which is dropped).
> 
> So why are HBs sent from new primary instead of received address ? As specified in RFC it should sent back from address, it receives the HB packet.
Correct. Somethings seems strange. Please answer the above and I will try to reproduce
the problem.

Thanks for the report.
Best regards
Michael
> 
> Regards,
> Christian
> 
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> 
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>