From owner-freebsd-net@freebsd.org Mon Mar 9 10:57:44 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4F14025EFFB for ; Mon, 9 Mar 2020 10:57:44 +0000 (UTC) (envelope-from SRS0=tAdi=42=mail.sermon-archive.info=doug@sermon-archive.info) Received: from mail.sermon-archive.info (sermon-archive.info [71.177.216.148]) by mx1.freebsd.org (Postfix) with ESMTP id 48bZtt64Lxz4XxL for ; Mon, 9 Mar 2020 10:57:42 +0000 (UTC) (envelope-from SRS0=tAdi=42=mail.sermon-archive.info=doug@sermon-archive.info) Received: from [10.0.1.251] (mini [10.0.1.251]) by mail.sermon-archive.info (Postfix) with ESMTPSA id 48bZtt0ws8z2fjQV for ; Mon, 9 Mar 2020 03:57:42 -0700 (PDT) From: Doug Hardie Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: SCTP sendmsgx Date: Mon, 9 Mar 2020 03:57:41 -0700 References: <1C234055-9CDD-4A72-A027-1BD4F8A2FC71@mail.sermon-archive.info> To: freebsd-net@freebsd.org In-Reply-To: Message-Id: <3A0F2F1C-EB50-45A1-B0AB-8914535ED35F@mail.sermon-archive.info> X-Mailer: Apple Mail (2.3445.104.11) X-Virus-Scanned: clamav-milter 0.101.4 at mail X-Virus-Status: Clean X-Rspamd-Queue-Id: 48bZtt64Lxz4XxL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of SRS0=tAdi=42=mail.sermon-archive.info=doug@sermon-archive.info designates 71.177.216.148 as permitted sender) smtp.mailfrom=SRS0=tAdi=42=mail.sermon-archive.info=doug@sermon-archive.info X-Spamd-Result: default: False [0.69 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:71.177.216.148:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; NEURAL_SPAM_MEDIUM(0.98)[0.982,0]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.92)[-0.918,0]; IP_SCORE(0.03)[asn: 5650(0.20), country: US(-0.05)]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_NONE(0.00)[148.216.177.71.list.dnswl.org : 127.0.10.0]; FORGED_SENDER(0.30)[bc979@lafn.org,SRS0=tAdi=42=mail.sermon-archive.info=doug@sermon-archive.info]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5650, ipnet:71.177.216.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[bc979@lafn.org,SRS0=tAdi=42=mail.sermon-archive.info=doug@sermon-archive.info]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 10:57:44 -0000 >=20 >> On 9. Mar 2020, at 11:01, Doug Hardie 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. 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 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 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. >=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 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 so I will have to figure it out = from there. Likewise there is no indication those calls are depreciated = in the man pages. -- Doug