From nobody Sun Jan 08 18:52:12 2023 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NqmQt2Jt3z2qrrJ for ; Sun, 8 Jan 2023 18:52:22 +0000 (UTC) (envelope-from mail@s14u.de) Received: from s14u.de (s14u.de [IPv6:2a02:c206:3007:9110::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NqmQs3r42z4M9L for ; Sun, 8 Jan 2023 18:52:21 +0000 (UTC) (envelope-from mail@s14u.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=s14u.de header.s=dkim20210825 header.b=ex2JwHGo; spf=pass (mx1.freebsd.org: domain of mail@s14u.de designates 2a02:c206:3007:9110::1 as permitted sender) smtp.mailfrom=mail@s14u.de; dmarc=pass (policy=none) header.from=s14u.de DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=s14u.de; s=dkim20210825; h=Content-Transfer-Encoding:Content-Type:Subject:From:To: MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3ncumDziut+XeZuKxEDOhEDfjWs4fAWbZhTIbWmBl4c=; b=ex2JwHGodZu/DEFRlydbFhR1/Q IWZxmcRHPNEls6jOn2wwLZ7PweQaPx5PWYZ5kIXK1iDdFLWitiFzFS5oQxH5uJRLhJJSMt8QjQ/g+ vLxo34wqzb1sb1rd8ARJsBdyGKRGLzIuwaOtIzaFbOoZdV3gXfi9CLlav6pq7T7PkKH4fZ8jIwFqU grWg19A0bH0xAxjD1TBkLV1dkO8F1oLsN+7ubkbvMSY7c3fmpRaYKA/PnRBqmCsqXQSHATBWbics1 /dYUR8KSsTB+P6IShvkFbc5tqFD09DSBj1wuQTJ0ga7WCHIv/DfhfwaMBTBkKC6QvjREsJzMKBo+r +GXszp4Q==; Received: from p200300fb5f01c200dc6b3109cf35922b.dip0.t-ipconnect.de ([2003:fb:5f01:c200:dc6b:3109:cf35:922b]) by s14u.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pEamC-007RvV-VS for freebsd-net@freebsd.org; Sun, 08 Jan 2023 19:52:13 +0100 Message-ID: <68c52405-1071-db04-0874-f6dac2bacceb@s14u.de> Date: Sun, 8 Jan 2023 19:52:12 +0100 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 To: freebsd-net@freebsd.org Content-Language: en-US From: Steffen Christgau Subject: Bind fails in jail with assigned IP address Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[s14u.de,none]; R_DKIM_ALLOW(-0.20)[s14u.de:s=dkim20210825]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; ASN(0.00)[asn:51167, ipnet:2a02:c206::/32, country:DE]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[s14u.de:+]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4NqmQs3r42z4M9L X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi folks, (The whole discussion is for legacy IP (v4) only, IPv6 might be affected as well, but I haven't tested yet.) I've implemented a daemon in Python for the Web Services on Devices (WSD) discovery protocol [1]. The protocol requires the "host" side to receive multicast packets addressed to a specific port (i.e. 3702). On the other hand, unicast traffic must be sent from that very same port as well [2]. I realize this by using separate sockets for multicast reception (recv_socket), unicast transmission (uc_send_socket) and a third one for multicast transmission, but the third one is not of concern here. So, essentially I have a multicast-enabled socket and a "conventional" unicast socket that need to be bound to the same port. On Linux, I can bind the the multicast socket to the legacy IP multicast address, but for FreeBSD this does not work (EADDRNOTAVAIL) and I fall back to bind to the port only and a wildcard IP address [3]. Although I found a hint on this in Stevens' book and it actually works, I maybe doing it wrong. So if there is a better way to do so, I'd be happy to know about it. After the receiving multicast socket is bound, I bind the unicast sending socket to the IP address of the intended network interface and the required protocol-specific port. As said, this works fine under FreeBSD in general. But if the script/daemon is executed in a jail with an IP addresses assigned to the jail, binding the sending socket fails with EADDRINUSE. This appears to be caused by what is described in jail(8) for jails with provided IP addresses: > ip4.addr > A list of IPv4 addresses assigned to the jail. If this is set, the > jail is restricted to using only these addresses. [...] Attempts to > use wildcard addresses silently use the jailed address instead. For > IPv4 the first address given will be used as the source address when > source address selection on unbound sockets cannot find a better > match. The effect of the silently changed wildcard address in my case is that the changed address prevents the required binding of the second/sending socket. This is inconsistent with the behavior outside a jail. Is this actually intended? If so, what can be done to bind both sockets to their required ports? I also tried to set ip4.saddrsel = 1 in the jail config, but it appeared that nothing changed. If the IP address configuration is omitted for the jail, the service does not encounter the error of an address that is already in use. If there is a solution to have the daemon run in a jail, I would be happy to discuss this. If jails are not suitable for this use case, let me know as well. 😉 Looking forward to your replies. Regards, Steffen [1] https://github.com/christgau/wsdd [2] https://learn.microsoft.com/en-us/windows/win32/wsdapi/discovery-and-metadata-exchange-message-patterns [3] https://github.com/christgau/wsdd/blob/0aef2d7/src/wsdd.py#L281-L287