From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CC69C43334 for ; Sun, 3 Jul 2022 11:36:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231574AbiGCLgQ (ORCPT ); Sun, 3 Jul 2022 07:36:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229993AbiGCLgP (ORCPT ); Sun, 3 Jul 2022 07:36:15 -0400 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1167162DF for ; Sun, 3 Jul 2022 04:36:14 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 74EFE5C0079 for ; Sun, 3 Jul 2022 07:36:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 03 Jul 2022 07:36:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= aaronmdjones.net; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; t=1656848173; x=1656934573; bh=i6/7Pbn+2J 4N/whE1V6LCHkQ3QPwoQlcMbCO7bQuQg4=; b=f2UwEspef6YNJdN8Moz2r78jTb dldCx4roLI+DJNMSn7sCvPKKWoG7r4bCEME9Jjt3VzUg1kKZYQzyhnV6qJAla1Dl jHYK2417YzVsbVZXSxj7E1hEmPp0OogCqRAywuwX3GCdVtUpo57UbTjMPiTdyvXh YUiYqupcZVDllhX1QDo8a5+UIiaaZZw0ijTwpnIBlMoQMrlVWaFpDm7cMRRDVuoC YrAswpYvvrD+8DTCbLn8c6NiWFHfjsxnAXdvYjjBD8btB/FvgPhFpl3a32OwYQqf cs1ZetmWUqAyTVY6XXyGK1dxoT78wKTAC4h+FfcqUP4hhKupmYduUl9tUZtw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1656848173; x= 1656934573; bh=i6/7Pbn+2J4N/whE1V6LCHkQ3QPwoQlcMbCO7bQuQg4=; b=D 4XpUbex2Ue4SzWnEhta6yZ72bV4oZGyNHg/mH8Oqpo91Tgghj5M1P+fSChweNauf J23LH6zbP4OoaI1UEWA2XDPvCzilIHAvYYkTC3eNShyigBNtsnmqJ/MdtDrrnx9x VoC1ybxJZzeLIUgGVPHU6hHxoP2/OzHOsSVTBfU/DlYKtlpIGFoBoj6U6CbgEGWC CUZLNn+VzkDqN/JSmWt34sNI1lYsBz1XdM0rM10SvhZw5N+4gBl1crrW4G3mWxmg Q6EHPhvVisfRh5PREAkwIhDa3pk8LRTEGKpotLbAHsVKxV5zcrrAJUJpcFq4T/DR npI0u18YcnERKIBaedcpA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudehjedggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmne cujfgurheptgfkffggfgfvhffusehmtderredtfeejnecuhfhrohhmpeetrghrohhnucfl ohhnvghsuceomhgvsegrrghrohhnmhgujhhonhgvshdrnhgvtheqnecuggftrfgrthhtvg hrnhepgfekudfhudevkedvkeekgfehfefhjeevieekudejgeffgfeffefhveeggfelkeel necuffhomhgrihhnpeguvggsihgrnhdrnhgvthdpihhmghhurhdrtghomhenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmvgesrggrrhhonhhm ughjohhnvghsrdhnvght X-ME-Proxy: Feedback-ID: idff947e1:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 3 Jul 2022 07:36:12 -0400 (EDT) Content-Type: multipart/mixed; boundary="------------drwzVA6fZyFfSaz5H8LvWVSb" Message-ID: <7e246db6-c78e-4d13-4a38-002ac64e3b41@aaronmdjones.net> Date: Sun, 3 Jul 2022 11:36:12 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 To: linux-sctp@vger.kernel.org Content-Language: en-GB From: Aaron Jones Subject: SCTP INIT chunks do not include multi-homing addresses if IPv6 is used Precedence: bulk List-ID: X-Mailing-List: linux-sctp@vger.kernel.org This is a multi-part message in MIME format. --------------drwzVA6fZyFfSaz5H8LvWVSb Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello. While debugging SCTP multi-homing in an application over the last couple of days, I discovered that the cause is because the application randomly prefers IPv4 or IPv6 (literally; it does the equivalent of a dice roll). If the application passes an IPv4 address first to sctp_bindx() and sctp_connectx(), followed by an IPv6 address, then multi-homing works; the SCTP INIT chunk includes both IP addresses passed to sctp_bindx(), and /proc/net/sctp/assocs contains both. Blocking IPv4 traffic does not break the connection; it falls back to IPv6. However, in the reverse situation (IPv6 address followed by an IPv4 address), it does not; there are no IP addresses in the INIT chunk at all. Thus, /proc/net/sctp/assocs contains only IPv6 addresses, and blocking IPv6 traffic breaks the connection. I have written a minimal reproducer at [0] (which I am attaching to this message), and you can observe the results at [1] (if you do not wish to run it). I have managed to reproduce it on the following software combinations: - lksctp-tools 1.0.18 with Linux kernel 5.4 (Linux Mint 20.3) - lksctp-tools 1.0.19 with Linux kernel 5.10 (Debian 11) - lksctp-tools 1.0.19 with Linux kernel 4.14.278 (Gentoo) I do not know whether this is a bug in libsctp or in the kernel. Regards, Aaron Jones [0]