SCTP sendmsgx

[Doug Hardie]

> On 9 March 2020, at 04:11, Michael Tuexen <michael.tuexen at lurchi.franken.de> wrote:
> 
>> On 9. Mar 2020, at 11:55, Doug Hardie <bc979 at lafn.org> wrote:
>> 
>>> 
>>>> On 9. Mar 2020, at 11:01, Doug Hardie <bc979 at lafn.org> wrote:
>>>> 
>>>>> I am trying to get sctp_sendmsgx to work and not having a lot of success.  I have not been able to find any examples on the web of using it.  I have a client using sctp_sendmsg working fine.  I need to make use of the multihoming feature which requires sctp_sendmsgx.    I changed the call to sctp_sendmsgx, and changed the address count to 2.  However, all I get is an EINVAL response.  Looking through the code there are at least 2 different possible causes, but I can't distinguish between them. I do have two address structures in the address field.  Are there any examples of how to build a client with sctp_sendmsgx?
>>>> 
>>>> I am now making some progress.  If you are using the sctp_sendmsg function the sa_len or sin_len field is not used.  However, sctp_sendx does use it.  Leaving it at zero causes
>>> Yepp, filling out the sa_len field is important.
>>>> the problem.  sendx now sends a connection init to the remote host.  There is no server running there yet.  It hangs for quite some time and doesn't try the multihome address.  I seem to recall reading something about that so will investigate that tomorrow. 
>>> What do you see on the wire? I would expect INIT chunks to be sent to the two addresses you provided.
>> 
>> If I have both network connections working, there is an INIT chunk on the primary network followed by a ABORT chunk response.  Then the client sits waiting for a response which 
> When the INIT is received, the association is dead. Are you using a one-to-many style socket (SOCK_SEQPACKET as the second parameter to socket())?
> Then you would need subscribe to notifications to get an indication that the peer is not there. If you would use a one-to-one style
> socket (using SOCK_STREAM as the second argument of socket()), you could use the implicit or explicit connection setup and use
> select() to figure out, that the peer has rejected the association.
>> never comes.  If I disconnect the primary network cable, then after about 5 seconds of starting the client, I get the INIT and ABORT chunks on the secondary network.  I haven't 
> The INIT retransmission timer is 3 seconds in 12.1, I guess. You can change it using
> https://tools.ietf.org/html/rfc6458#section-8.1.1
>> figured out how to control the time, or how to make it switch to the secondary when the network connection is there, but the server is not responding.
> SCTP does failover automatically. Please note that receiving an ABORT is a (final) response from the peer and no retransmissions
> will happen. Retransmissions only happen, when there is no response.
>> 
>>> 
>>> Please note that sctp_sendx() is deprecated (like sctp_sendmsg()). Please consider using sctp_sendv().
>>> See https://tools.ietf.org/html/rfc6458#section-9.12
>> 
>> Thats quite interesting.  This must have occurred after the Steven's book came out.  There is no man entry for sctp_sendv in FBSD 12.1.  However, I do see it in sctp_sys_calls.c 
> Yes, the RFC was finalised after the book chapters were written, I think.
>> so I will have to figure it out from there.  Likewise there is no indication those calls are depreciated in the man pages.
> That is a good point. The man pages need some work. The BSD stack should be pretty much supporting
> the API described in the RFC. If something doesn't work as described in the RFC, I consider it a bug.

Thanks a lot.  This is quite helpful.  I was using a one to many client.  I'll have to rethink that.  

-- Doug