Date: Mon, 9 Mar 2020 04:15:08 -0700 From: Doug Hardie <bc979@lafn.org> To: Michael Tuexen <michael.tuexen@lurchi.franken.de> Cc: freebsd-net@freebsd.org Subject: Re: SCTP sendmsgx Message-ID: <446BD4C8-4FAA-4FE6-850A-02450C8E2658@mail.sermon-archive.info> In-Reply-To: <FC6EF354-9536-460F-92F3-0F8D4F9D538F@lurchi.franken.de> References: <1C234055-9CDD-4A72-A027-1BD4F8A2FC71@mail.sermon-archive.info> <BF6123E9-89CB-4E67-9B8A-7927EFF2D7A0@lurchi.franken.de> <67FA10E2-9EB7-4BCC-8E1D-9F82C10447B8@mail.sermon-archive.info> <FC6EF354-9536-460F-92F3-0F8D4F9D538F@lurchi.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 9 March 2020, at 04:11, Michael Tuexen = <michael.tuexen@lurchi.franken.de> wrote: >=20 >> On 9. Mar 2020, at 11:55, Doug Hardie <bc979@lafn.org> wrote: >>=20 >>>=20 >>>> On 9. Mar 2020, at 11:01, Doug Hardie <bc979@lafn.org> wrote: >>>>=20 >>>>> 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? >>>>=20 >>>> 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.=20 >>> What do you see on the wire? I would expect INIT chunks to be sent = to the two addresses you provided. >>=20 >> 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=20 > 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=20 > 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. >>=20 >>>=20 >>> 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 >>=20 >> 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=20 > 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. =20 -- Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?446BD4C8-4FAA-4FE6-850A-02450C8E2658>