> On 9 March 2020, at 04:11, Michael Tuexen <michael.tue...@lurchi.franken.de> > wrote: > >> On 9. Mar 2020, at 11:55, Doug Hardie <bc...@lafn.org> wrote: >> >>> >>>> On 9. Mar 2020, at 11:01, Doug Hardie <bc...@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 _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
