[SCTP] transport address unconfirmed instead of inactive

[Schoch Christian]

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.

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.

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"
>>
>
>