[SCTP] transport address unconfirmed instead of inactive

[Michael Tüxen]

On Jan 19, 2011, at 11:02 PM, Schoch Christian wrote:

> Dear Michael,
> 
> as I could figure out, the problem with UNCONFIRMED is solved. My test tools is based on lksctp-tools and written for linux testing. Now the problem here is that there is a inconsistency between linux and FreeBSD of the return value of spinfo_state. Perhaps these return values could be standardized in the sctp socket-api. Leaving a note on the linux dev mailing list on this topic.
Hi Christian,

the actual values are not standardized, only the names of the constants. If you use
the names and recompile the code when moving from Linux to FreeBSD, it should work.
> 
> The other problem may depend on the fact, that i did the test with vmware and a remote machine using only one network interface with 2 different Addresses assigned. Furthermore, both addresses had a netmask of 255.255.0.0 so both addresses were located in the same subnet. Did the same test with 2 Vmware machines and other addresses which was successful.
Yes, that mask may result in problems.

Thanks for reporting.

Best regards
Michael
> 
> Regards,
> Christian
> 
>> 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"
>>> 
>> 
>> 
> 
> 
>