From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=UTzN1FeL; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id A1F125A0625 for ; Tue, 13 Jan 2026 01:12:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768263131; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZodQbKVM5awH0fvB4QwagMvhRWaSKEXQWKmafvbWCPo=; b=UTzN1FeLv2H+7IuV4v97kioDLjPOCg5rw1VioP833ffBmt0hGO4yPeCTKWUT/GY6MlQisv v9rUGoat6fp+gc9OsNMzkz5e34Zz17wwMul1887+JQ0FDvAKqg2CeTx/rQHUd0CG3RFa5h DI8UenbOlRvaCPLZ/0xr1WoUVZ+qmIY= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-158-PV-4yeqTOi69KLS8y62tPw-1; Mon, 12 Jan 2026 19:12:10 -0500 X-MC-Unique: PV-4yeqTOi69KLS8y62tPw-1 X-Mimecast-MFC-AGG-ID: PV-4yeqTOi69KLS8y62tPw_1768263129 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-430fd96b440so3511588f8f.1 for ; Mon, 12 Jan 2026 16:12:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768263129; x=1768867929; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZodQbKVM5awH0fvB4QwagMvhRWaSKEXQWKmafvbWCPo=; b=qgN/XElV+trHrk1Mtg912RuWDhfWpyDRz9PVUOWM/pbghpDt2tRR0LsSqDO2U1hzF1 dExhBRlbRxxOjtDJw21pVdxhAxpJ0WYVniFhC1FWOvpsVP1LKTH/sn9wFQn1DnmHshoF W/EIHUXwuLpSnOtnrsgxbwkS0Uznc2RAxZKV1hBzaw5dYTDebSgNUMvGFfLx2GZ91OFW 0AxmrMrV7TeEwSAffuSETp2J7+GLdz+9xxZyTOHSIz/MaOZzdDegP9bWG012tA7O+zIE k1K+/7lWp2QQsu1LS9cWY8icSPRUzv+N6DyscThLaDcvzPXLGSargAaty+josXorcWH6 kqhA== X-Gm-Message-State: AOJu0YzQ6LxLyo1Rh3IZSMHcXoXKXhMoeU7aWrHyIznoF8CAxBNbp/4a chVJkJ3yb+wCU9THEGGMXC0QG2btqLc3S63Z6NySpiopMWwtqD0yQ56QHGuH1vie4ooSinTpbEE Cc5qMv+kdKQqDqURZGCnb2FkGtPASdHryGUj6XhG8BJmWWio+TmLHsA== X-Gm-Gg: AY/fxX72JA+Fr+d4COTCeBcxaOA5P0GMHJVzjH99AzQP1V/V+3zsopQedUEyeak0jbL MMq+kLdzFVRVWEE3YGdI5E3VdVEH424t0zCmhsHrvbA7PATMpfCmVLx+IxCFfbfYya5FYCq3G5Z JuuDfLd7zOIpZ8n3/c8B6LwtSHk39lyWHiP5yPNgJ4swe7/n/JV6F2oBDZ9MMEZB01XJypV7KEU dURSSzAQEEOP4+5CJyDLRcCjDZT/VCwApCT4N8GPkp3dRyZHXBgRNE7hP/TEeseubilZak4tK/O nSCZhGdf4sre5/9YxzO8l1gPLRXSdygoO3j+HsdgB7IpBfV71qB1mGkUTATmc1SdqbfdL8ST729 9VxYHJOVQqmS8r9AogAY4eEueBflBQz/6xOwpHQ== X-Received: by 2002:a05:6000:1449:b0:431:488:b9a8 with SMTP id ffacd0b85a97d-432c375b4eamr23483276f8f.33.1768263129086; Mon, 12 Jan 2026 16:12:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IFLtBQ3aRTBbbZ3D8iyPXhhceTMvIYUqZMOW4ubiQxgSpUVYeNxeiE/IrlMPrmp1vIRbIsS2g== X-Received: by 2002:a05:6000:1449:b0:431:488:b9a8 with SMTP id ffacd0b85a97d-432c375b4eamr23483256f8f.33.1768263128619; Mon, 12 Jan 2026 16:12:08 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ee870sm41324165f8f.36.2026.01.12.16.12.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 16:12:07 -0800 (PST) Date: Tue, 13 Jan 2026 01:12:06 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 2/3] tcp, udp, conf: Don't silently ignore listens on unsupported IP versions Message-ID: <20260113011206.67b52012@elisabeth> In-Reply-To: References: <20260105082850.1985300-1-david@gibson.dropbear.id.au> <20260105082850.1985300-3-david@gibson.dropbear.id.au> <20260111003328.7e5f22ec@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: v4cy9KRa-CLQy7LpRWITucNLCUX7B6t-6Di0lNs-9qo_1768263129 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: RUQPK2QUBQ3UYGQKLGCTSCMNZUDL2GHB X-Message-ID-Hash: RUQPK2QUBQ3UYGQKLGCTSCMNZUDL2GHB X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon, 12 Jan 2026 14:48:54 +1100 David Gibson wrote: > On Sun, Jan 11, 2026 at 12:33:28AM +0100, Stefano Brivio wrote: > > On Mon, 5 Jan 2026 19:28:49 +1100 > > David Gibson wrote: > > > > > Currently, it's possible to explicitly ask for forwarding from an IPv4 > > > address, while disabling IPv4: > > > $ pasta -t 192.0.2.1/12345 -6 > > > or vice versa: > > > $ pasta -t 2001:db8::1/12345 -4 > > > > > > Currently, the impossible to implement forwarding option will be silently > > > ignored. That's potentially confusing since in a complex setup, it might > > > not be obvious why the requested forward isn't taking effect. > > > > > > Specifically, it's ignored at a fairly low level: tcp_listen() and > > > udp_listen() ignore it and return 0. Those run kind of late to give a > > > good error message. Change the low-level functions to return -EACCES > > > (chosen because that's what the kernel will return if you request IPv6 > > > when it's disabled by sysctl). > > > > I couldn't quite find out in which case EACCES is returned by the > > kernel. If I set /proc/sys/net/ipv6/conf/all/disable_ipv6 to 1 and then > > bind() an IPv6 address, after setting IPV6_FREEBIND, I get 0. > > Huh. EAFNOSUPPORT seems like it makes more sense, but oddly didn't > spot it. I was looking at: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/addrconf.c#n1098 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/addrconf.c#n2565 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv6/route.c#n3664 Weird, I guess it eventually gets translated to EOPNOTSUPP later (perhaps in netlink code), because: # strace ip addr add db8::1 dev ens3 [...] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{nlmsg_len=84, nlmsg_type=NLMSG_ERROR, nlmsg_flags=0, nlmsg_seq=1768262003, nlmsg_pid=1598}, {error=-EOPNOTSUPP, msg=[{nlmsg_len=64, nlmsg_type=RTM_NEWADDR, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK|NLM_F_EXCL|NLM_F_CREATE, nlmsg_seq=1768262003, nlmsg_pid=0}, {ifa_family=AF_INET6, ifa_prefixlen=128, ifa_flags=0, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("ens3")}, [[{nla_len=20, nla_type=IFA_LOCAL}, inet_pton(AF_INET6, "db8::1")], [{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "db8::1")]]]}], iov_len=32768}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 84 write(2, "RTNETLINK answers: Operation not"..., 43RTNETLINK answers: Operation not supported it's EOPNOTSUPP in the NLMSG_ERROR message. > Happy enough to change it to EAFNOSUPPORT if you'd prefer. I think it would make a lot more sense, EACCES would confuse pretty much anybody (and I can't get the kernel to return that over netlink anyway). > > If I disable IPv6 via command line (ipv6.disable=1) I get EAFNOSUPPORT > > on bind(), and EOPNOTSUPP on setting addresses and routes. EACCES, I > > couldn't quite spot it yet. > > Huh. Kind of weird it only fails on bind(), not on socket(). Oops, I was fooled by the error message we print in that case. It actually fails on socket(): socket(AF_INET6, SOCK_STREAM|SOCK_NONBLOCK, IPPROTO_TCP) = -1 EAFNOSUPPORT (Address family not supported by protocol) but we print: L4 socket: Address family not supported by protocol Failed to bind port 2548 (Address family not supported by protocol) for option '-t 2b8::1/2548' which makes sense because that's what we're doing with that port (just not with that socket). -- Stefano