From nobody Mon Apr 22 19:47:04 2024 X-Original-To: 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 4VNbP43n9wz5HmHB for ; Mon, 22 Apr 2024 19:47:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VNbP41x6qz4qwB for ; Mon, 22 Apr 2024 19:47:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713815224; a=rsa-sha256; cv=none; b=dlWRpezQLZ2RqIeGMWNFjonuwfM88GWrO4dkoTXDYYkJPkimZWD6mDRUTEO2vgjShnVEvI ll9UJ8JpPSlT2+8IPMea2y5R3a7Sfs9glhqqwmG15X9CiXzrWMRPB9scY4cGEvLJQ0unGG jTH9NBJRcStSdd/4N8KxEgLRpy5WYtWa23RqSEaPj0W6+6u3PJmMGW8BdoZE3zqN985NPf Mmk5V2m63b1fbHcHGy7c7MHySUGKRRC0FxWTn+UDwRCb1N59j0UDhOIYXHGKy+2+RnnCBw /lJn1/9YGHJwQrI1883mB63yVkLWRqU3L3vLwyhsoSl5ZHt6E9BgWDWna8Y46g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713815224; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p5aY6S5PrwZYeE5+ZQP1VknGlho+Au0HyYMzXZeZq6E=; b=FZlOYiQ6KNYSbocI5yihoJBVG4K02jKwOSlRJVxX+ex9M6GJIDGeYO3x1PLjzgueHqh7YI rmtLiNPGaqmtRiywcRU644Lfuf4yV345uEI8lb/1U2qaOdg4JfGXdPSqs4Es3aO4LDDiVv OEHTnlo0IdaFl8DQePrXu/2PQcT5PAfCK8bjt3N8ePQMkjWL3Y1Hvr9PeRldSt/MbWgdL1 lrmhKWLnRHBXT12SSeuP00FGrbpk2Q/mlIid5UdsPkJBN+IxIsD6h39iS22q5VSqoIQVo5 LJnwi/1FNDkToUp/8U3uuKfcCDCTA+0Bqx/GSwmDJWoXwVr5WTE8sE6pDaAlVA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4VNbP41VqSz11x2 for ; Mon, 22 Apr 2024 19:47:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 43MJl42L070774 for ; Mon, 22 Apr 2024 19:47:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43MJl4cg070773 for net@FreeBSD.org; Mon, 22 Apr 2024 19:47:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 253888] exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r = 0 (0xfffff800035d4780) locked Date: Mon, 22 Apr 2024 19:47:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: lexi.freebsd@le-fay.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D253888 Lexi Winter changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lexi.freebsd@le-fay.org --- Comment #5 from Lexi Winter --- also seeing this on a fresh current (7a7063cc54) on bhyve amd64, seems triv= ial to reproduce, just boot with IPv6 enabled. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Apr 23 04:53:51 2024 X-Original-To: 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 4VNqX02xZbz5JQgl for ; Tue, 23 Apr 2024 04:53:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VNqX01vjvz4cCR for ; Tue, 23 Apr 2024 04:53:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713848032; a=rsa-sha256; cv=none; b=PXoStRQGvl3hvnixuft8lwIpGokhtcJnYffKimC6eNRze9nbhkEAbRI/8GoIlCps/9a/N9 4C9OtFnV8uA/U983fGvYPHERjz/M/9SiRfYFLCDKBMYKWzCAC1kjGjPcKyYY8F6rdIHW2q NBUqorvZvtP5ihQHCEj5tA1mLWRRva9KVd8NZNBYJcv41dhpjwSrT6CckIYiT5N89yek3V Umky/L5fUDyHn3b1rdmz7bG03++uYMf7tzuN36ftE7izWoSnTYKJJDdxJpNWo29Ey5VABn GeIeWSoSVnAYBfLd2X8JIP1bVw7p410+xu7RKnNfzoiiySv+6MRpVHYRSS6YXQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713848032; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+HLXIjPDUfwJYzz1T6umNlRK1IIF7B4jDteG4HU/Hsk=; b=S1oOaRbdWQKrUIbacGnQrTAjY5FN3iA9OtsRQ7Y44GDSHPy7aw7vlXTWfTEEQTLrokDsAk 73XJYYuG6i79aD2lsbmzbPXslu6H8MrMZbqVyTu9W8V57ccQk/QNHLG6BGqJSVsoDzAI0W vPLsJDSzVZcCyMyAhp/2/o8Wa1v1kwmVFfaJfOF7KgjWLAobWmY4CMuzGcI35LC+z1CJm5 uq3Bp7Li2AvFTIp1VZY8HLYxkUmSIQoGiViAiyZnznxUEluLOOtLa1GC8TEovaZVgZUEAj W7ZT8PK7D1jdtP7J1FwEU7SHXtwBDPdfRNeT38yBG4wCECnm2h225j2ZyfMHXQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4VNqX01RRTzHfp for ; Tue, 23 Apr 2024 04:53:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 43N4rqKa029967 for ; Tue, 23 Apr 2024 04:53:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43N4rqSK029960 for net@FreeBSD.org; Tue, 23 Apr 2024 04:53:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 230807] if_alc(4): Driver not working for Killer Networking E2200 Date: Tue, 23 Apr 2024 04:53:51 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? mfc-stable12? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230807 --- Comment #27 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D05a95d19cb248203acdd4e069d3eedfe5= 97c3b49 commit 05a95d19cb248203acdd4e069d3eedfe597c3b49 Author: Lexi Winter AuthorDate: 2024-04-22 22:09:26 +0000 Commit: Warner Losh CommitDate: 2024-04-23 04:36:35 +0000 alc(4): disable MSI-X by default on Killer cards Several users with alc(4)-based "Killer" Ethernet cards have reported issues with this driver not passing traffic, which are solved by disabling MSI-X using the provided tunable. To work around this issue, disable MSI-X by default on this card. This is done by having msix_disable default to 2, which means "auto-detect". The user can still override this to either 0 or 1 as desired. Since these are slow (1Gbps) Ethernet ICs used in low-end systems, it's unlikely this will cause any practical performance issues; on the other hand, the card not working by default likely causes issues for many new FreeBSD users who find their network port doesn't work and have no idea why. PR: 230807 MFC after: 1 week Reviewed by: imp Pull Request: https://github.com/freebsd/freebsd-src/pull/1185 share/man/man4/alc.4 | 6 +++++- sys/dev/alc/if_alc.c | 24 +++++++++++++++++++++++- 2 files changed, 28 insertions(+), 2 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From nobody Tue Apr 23 05:20:57 2024 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 4VNr7K5ZJvz5JSt3 for ; Tue, 23 Apr 2024 05:21:01 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from sfo.monkeybrains.net (sfo.monkeybrains.net [208.69.40.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "sfo.monkeybrains.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VNr7K176Bz4gYY for ; Tue, 23 Apr 2024 05:21:01 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=monkeybrains.net header.s=dkim header.b=kMVovied; dmarc=pass (policy=none) header.from=monkeybrains.net; spf=pass (mx1.freebsd.org: domain of crapsh@monkeybrains.net designates 208.69.40.9 as permitted sender) smtp.mailfrom=crapsh@monkeybrains.net Received: from [192.168.118.204] (148-64-102-167.PUBLIC.monkeybrains.net [148.64.102.167]) (authenticated bits=0) by sfo.monkeybrains.net (8.16.1/8.16.1) with ESMTPSA id 43N5KxdM088137 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 22 Apr 2024 22:20:59 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=monkeybrains.net; s=dkim; t=1713849659; bh=wjunn4+x2QEs4HRrQcozT7INn2DM0lGSHIZkmkDz3T0=; h=Date:To:From:Subject; b=kMVoviedDkcdtVsS4bIjN8MJ2kJdxvRK/DASn5k3wAHd/hk5e4B6kOOvif3KcXuMy 2oRViJF0iVqXRcdc8CID8Kc5WOkx0WXbkKUV1Rxr0nSswCFqRch2/0FYfTcmmq9c76 hhsHT6fz44Twc44e20ij7vrooo48yqezqbsc1qeU= X-Authentication-Warning: mail.monkeybrains.net: Host 148-64-102-167.PUBLIC.monkeybrains.net [148.64.102.167] claimed to be [192.168.118.204] Message-ID: <9439dc37-bd39-44ce-bc1e-47374f12d10b@monkeybrains.net> Date: Mon, 22 Apr 2024 22:20:57 -0700 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 Thunderbird To: freebsd-net@freebsd.org Content-Language: en-US From: Rudy Subject: unsubscribe Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.103.3 at mail.monkeybrains.net X-Virus-Status: Clean X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.89 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[monkeybrains.net,none]; R_SPF_ALLOW(-0.20)[+ptr]; R_DKIM_ALLOW(-0.20)[monkeybrains.net:s=dkim]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; DKIM_TRACE(0.00)[monkeybrains.net:+]; HAS_XAW(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:32329, ipnet:208.69.40.0/22, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; SINGLE_SHORT_PART(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4VNr7K176Bz4gYY unsubscribe From nobody Wed Apr 24 02:12:15 2024 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 4VPMv76WSNz5JXKF for ; Wed, 24 Apr 2024 02:12:19 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPMv74sh6z49rD for ; Wed, 24 Apr 2024 02:12:19 +0000 (UTC) (envelope-from gshapiro@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713924739; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ktFLd2624I7QLofJ3VEu/avLu9DzTmrguC5V/6H/VZ0=; b=Y7hTwm1DAJxeUnVZv33xvxv8SJ4OAXQ/YtyaPmchzE1C8fK6MHd1NarO8i+82v7GnmrR5z PeQdSCigcVFciN3XdnBSz0et4oEI5SlLBKCw6dUaQPKznwlgX3+3REs5f9Rai4ZhjlgoMg P0Anlqt7ds8WBvgwi1X19W3aS6SYgXFw94GCYZRDYe77OQ6uW1gD7ZWyAZ5F7HFPjuCpsb LBkGrU+BeJaJ80ljeAPE06H5Md6+doiL4J0piyo2dLZs0JxFxWkM72VREGiLO+olKZXHQY 25P04l1Ga2LuFdRcplgtUJsUiJ93QScB5fwupQ31v3hwT2pFNod6GLtV6BBW2g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713924739; a=rsa-sha256; cv=none; b=abCLBoYTQAbg0kla+k/ryAQ7YMEdCZoqQqD+MILryMHqAENcjdcKPoDUdk1vdxu8ze64PF 67o49AXJ2SbS2qui93CeLRBos0UShfR9mMO9bvOanDM+ZPsdPNLdeOfZ/GKRzne6mH7uIe nXjtrNW5vxwtrvDm+W/jSoe2JpcWobx8f5NwRk3LDOkCOSY2kY9BVYWnJlaMTAnj438ibk 3jglNfGyaHOJ4q5vPqqnepsDPslSC8/UTUAbu806yNN9NAiqxkrfBLX8m9UtWkBbc5lwAt lFJvrgNxFZQ1n/cp8xe66RfZ+S8osktx/fgHu8dAnCaT5nslz4cCShUekfnVkg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713924739; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=ktFLd2624I7QLofJ3VEu/avLu9DzTmrguC5V/6H/VZ0=; b=OyH/LnjJb3xc8L2ZVps2WwDyMH5dbhszj+yPNgjDAZMDOhrc8GzMhi77QrtBwPptBXsRxN RZy/ArcyD4nDm06iEHS9bGvrypI4UUnuUGIqQymn+10nzOXclKERJTFogFTUC9FJvqm+7a rLQZWLK4DXlrC3tRVvycIMd681e2Nn0BZVBZ5LdrH6FGvJ0+BRMhhGxEa2VQ9prjWQvb4H ZvQ6XOUriymGe0bAj6HY6oj7pdkTDtB0v6r8wJLNzoeu2uORuwMRcZ7Hp+NfPNly1KIIPj RpHe91/RuQ+8ZtAdnCHfV3ibDnQHZ25XMW+roM+ZMlWCRJj3o0D3GlfXRzSlXg== Received: from thornystick.local (thornystick.gshapiro.net [IPv6:2a0a:280:2357:5506::2ee5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: gshapiro) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VPMv64k2Jz15vl for ; Wed, 24 Apr 2024 02:12:18 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Date: Tue, 23 Apr 2024 19:12:15 -0700 From: Gregory Shapiro To: freebsd-net@freebsd.org Subject: Source IPv4 address selection vs BGP IX connection Message-ID: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Short version: Using FreeBSD as a BGP router has network issues caused by suboptimal default IPv4 source address selection when connected to Internet Exchanges (which are required to use IPs that aren't routable on the Internet). I was hoping to find more elegant workarounds or encourage FreeBSD to add source IPv4 selection akin to the existing IPv6 source address selection (no_prefer_iface and prefer_source). Long version: Unless I'm mistaken, today, there is no way to set the default IPv4 source address for connections like there is with IPv6 (using no_prefer_iface and prefer_source). It appears the default source IP is chosen based on IP address of the outbound interface for the packet. This presents a problem on FreeBSD systems acting as BGP routers that have connections to Internet exchanges (IX). One of the rules of IX IP addresses is that they are must not be routable on the Internet. As a simple example, a system with two Ethernet interfaces, one to the transit provider and one to an IX would look like this: vtnet0: flags=1008843 metric 0 mtu 1500 description: Uplink inet 193.148.250.141 netmask 0xffffff00 broadcast 193.148.250.255 vtnet1: flags=1008843 metric 0 mtu 1500 description: IX inet 185.1.147.211 netmask 0xffffff00 broadcast 185.1.147.255 Then if /etc/resolv.conf contains 8.8.8.8 and BGP selects a route for 8.8.8.0/24 over the IX, you end up with: # route -n get 8.8.8.8 route to: 8.8.8.8 destination: 8.8.8.0 mask: 255.255.255.0 gateway: 185.1.147.22 fib: 0 interface: vtnet1 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 And DNS on the system doesn't work as all DNS requests go out with a source address of 185.1.147.211 (the IX endpoint) which isn't exported as an Internet route. While I can set a static route for 8.8.8.8 for this particular case, it would be messy to have to set up static routes for every possible local connection (other DNS servers, outbound SMTP for periodic/cron mail, etc.). I assume that there is a group of BGP enthusiasts using FreeBSD lurking on freebsd-net. What have you done to solve this problem? I'd also love to hear other tips for running BGP on FreeBSD. From nobody Wed Apr 24 05:10:51 2024 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 4VPRsQ1pLPz5Jnpc for ; Wed, 24 Apr 2024 05:11:06 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPRsP74KQz4VJJ for ; Wed, 24 Apr 2024 05:11:05 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; none Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 43O5Ardp064273 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 24 Apr 2024 07:10:54 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1713935454; bh=5IL81Sn7a+1/9ITyOF0lc5f2oDTBVo4NZBNSsWOTfEQ=; h=Date:Subject:To:References:From:In-Reply-To; b=hByYrFjuwaeXVZz17ibC0mEqXL+zpP5wWcdTapsMBZ9u2wizC9jDli00rssD0cNZ+ hSg6kugdL3djEIe5AI+e4Lo1S87WHj/NMndDIy+WhL4eIXHrcDW5KJRx/X8G5GQ5z0 sO1ELBZO1at/4zBhRhi9N9TDAt434uSJ5nc6kZnyfCQrBhgIDJUmXhv9Qpz8sn5yss s7FWto1fGuAAgvxaOS4LEM+PJGUPLjiEFMbY7n9u8drJCb8DByCTcROhalfeb2ZjvB Py+NYtizSxc23M9HLKgUGLYzSYZIeGomi7zirFg4lYN97QevFmWUSGT6rh2odNtpfQ QAb5B4RLRtcxg== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Message-ID: <8895bb37-ccf3-48fd-877c-74c659045b23@plan-b.pwste.edu.pl> Date: Wed, 24 Apr 2024 07:10:51 +0200 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 Thunderbird Subject: Re: Source IPv4 address selection vs BGP IX connection To: Gregory Shapiro , freebsd-net@freebsd.org References: Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL] X-Rspamd-Queue-Id: 4VPRsP74KQz4VJJ W dniu 24.04.2024 o 04:12, Gregory Shapiro pisze: > Short version: > > Using FreeBSD as a BGP router has network issues caused by suboptimal > default IPv4 source address selection when connected to Internet > Exchanges (which are required to use IPs that aren't routable on the > Internet). I was hoping to find more elegant workarounds or encourage > FreeBSD to add source IPv4 selection akin to the existing IPv6 source > address selection (no_prefer_iface and prefer_source). > > > Long version: > > Unless I'm mistaken, today, there is no way to set the default > IPv4 source address for connections like there is with IPv6 (using > no_prefer_iface and prefer_source). > > It appears the default source IP is chosen based on IP address of > the outbound interface for the packet. This presents a problem on > FreeBSD systems acting as BGP routers that have connections to Internet > exchanges (IX). One of the rules of IX IP addresses is that they are > must not be routable on the Internet. > > As a simple example, a system with two Ethernet interfaces, one to the > transit provider and one to an IX would look like this: > > vtnet0: flags=1008843 metric 0 mtu 1500 > description: Uplink > inet 193.148.250.141 netmask 0xffffff00 broadcast 193.148.250.255 > vtnet1: flags=1008843 metric 0 mtu 1500 > description: IX > inet 185.1.147.211 netmask 0xffffff00 broadcast 185.1.147.255 > > Then if /etc/resolv.conf contains 8.8.8.8 and BGP selects a route for > 8.8.8.0/24 over the IX, you end up with: > > # route -n get 8.8.8.8 > route to: 8.8.8.8 > destination: 8.8.8.0 > mask: 255.255.255.0 > gateway: 185.1.147.22 > fib: 0 > interface: vtnet1 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0 > > And DNS on the system doesn't work as all DNS requests go out with a > source address of 185.1.147.211 (the IX endpoint) which isn't exported > as an Internet route. > > While I can set a static route for 8.8.8.8 for this particular case, it > would be messy to have to set up static routes for every possible local > connection (other DNS servers, outbound SMTP for periodic/cron mail, > etc.). > > I assume that there is a group of BGP enthusiasts using FreeBSD lurking > on freebsd-net. What have you done to solve this problem? > > I'd also love to hear other tips for running BGP on FreeBSD. > In this case, probably best solution will probably be using multiple FIBs. Running a BGP routing daemon under not default FIB after assigning its interface to this FIB should solve the problem but it might create eventually new problems to solve (for example in which FIB should imported routes be stored). It's also possible to set and use non-default FIB for DNS lookups and maintenance tasks like pkg upgrade (setfib -1 pkg ....). This approach is probably more straightforward to conduct. -- Marek Zarychta From nobody Wed Apr 24 17:42:43 2024 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 4VPmXv6x6rz5J33P for ; Wed, 24 Apr 2024 17:42:55 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPmXv3YbJz4tqx; Wed, 24 Apr 2024 17:42:55 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 43OHghuG055178; Wed, 24 Apr 2024 10:42:43 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 43OHghWB055177; Wed, 24 Apr 2024 10:42:43 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202404241742.43OHghWB055177@gndrsh.dnsmgr.net> Subject: Re: Source IPv4 address selection vs BGP IX connection In-Reply-To: To: Gregory Shapiro Date: Wed, 24 Apr 2024 10:42:43 -0700 (PDT) CC: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] 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 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4VPmXv3YbJz4tqx > Short version: > > Using FreeBSD as a BGP router has network issues caused by suboptimal > default IPv4 source address selection when connected to Internet > Exchanges (which are required to use IPs that aren't routable on the > Internet). I was hoping to find more elegant workarounds or encourage > FreeBSD to add source IPv4 selection akin to the existing IPv6 source > address selection (no_prefer_iface and prefer_source). > > > Long version: > > Unless I'm mistaken, today, there is no way to set the default > IPv4 source address for connections like there is with IPv6 (using > no_prefer_iface and prefer_source). > > It appears the default source IP is chosen based on IP address of > the outbound interface for the packet. This presents a problem on > FreeBSD systems acting as BGP routers that have connections to Internet > exchanges (IX). One of the rules of IX IP addresses is that they are > must not be routable on the Internet. > > As a simple example, a system with two Ethernet interfaces, one to the > transit provider and one to an IX would look like this: > > vtnet0: flags=1008843 metric 0 mtu 1500 > description: Uplink > inet 193.148.250.141 netmask 0xffffff00 broadcast 193.148.250.255 > vtnet1: flags=1008843 metric 0 mtu 1500 > description: IX > inet 185.1.147.211 netmask 0xffffff00 broadcast 185.1.147.255 > > Then if /etc/resolv.conf contains 8.8.8.8 and BGP selects a route for > 8.8.8.0/24 over the IX, you end up with: > > # route -n get 8.8.8.8 > route to: 8.8.8.8 > destination: 8.8.8.0 > mask: 255.255.255.0 > gateway: 185.1.147.22 > fib: 0 > interface: vtnet1 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0 > > And DNS on the system doesn't work as all DNS requests go out with a > source address of 185.1.147.211 (the IX endpoint) which isn't exported > as an Internet route. > > While I can set a static route for 8.8.8.8 for this particular case, it > would be messy to have to set up static routes for every possible local > connection (other DNS servers, outbound SMTP for periodic/cron mail, > etc.). The mistake your making, IMHO, is that an IX connected eBGP FreeBSD router _SHOULD NOT_ be doing ANYTHING other than BGP on the IX connected interface, and anything like DNS and outbound SMTP should be going inward on the AS, not outward to the internet. I must ask why your using 8.8.8.8 and not your own nameservers? Why would you want or even allow outbound SMTP from such a critical infustructure point go out over the unwashed internet? One of the reasons for using the non-routable IP on IX connected eBGP routers is to minimize the exposure footprint, and what you seem to be doing is defeating that minimization by wanting to expose another IP on that very box to the public internet. > > I assume that there is a group of BGP enthusiasts using FreeBSD lurking > on freebsd-net. What have you done to solve this problem? I only trust AS internal objects from my eBGP routers, they have no need to speak to the unwashed internet other than to IX peers. > I'd also love to hear other tips for running BGP on FreeBSD. Lock it down as tight as you can if your IX connected. I dont even allow inbound BGP connection setup, all eBGP sessions have to be initiated by my router. ipfw -a list 20179 20179 23854 1131316 deny log tcp from any to any 179 This is at an ISP peer, not an IX, so not a private IX IP range, but 23854 attempts to connect to my bgp. -- Rod Grimes rgrimes@freebsd.org From nobody Wed Apr 24 17:45:13 2024 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 4VPmbf1P4sz5J2xW for ; Wed, 24 Apr 2024 17:45:18 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPmbd60Vyz4vgl; Wed, 24 Apr 2024 17:45:17 +0000 (UTC) (envelope-from gshapiro@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713980717; 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=pgomdU57CMe1y6zUUU3nLdZLHEIlrmUBrWe4pFt0m4w=; b=hPMcq1B2DPPFZFvUXfd33GxLpEegVvq68zfpmWpiTjqMIZrDXfw+BkvpwTy3zsEl9nN63E J5ZBgkAb43VVT/8erxU96d0tyF73TXO7h6Yxm0hChfWEsCMQYV38NM48m8ABlGKhzSHyLB YYeucx2ucq03gns0hPgFvxdi1JZpvmzJ6rdHSVqUBztTpXatMNevZKwXr+CLCpuflD+0RJ JPZxA4FNfzqxXvAQ/rxeC1/B8AlEsNjV5HEYTKY1euvKlreTv5DDcuf8pdKik2coJmrQSd NuqyUeYodePya5KKkTSIolEarPLnSka0dr6ZsJB/nYTEgyVVzd7jJX/aIydf/A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713980717; a=rsa-sha256; cv=none; b=bgyPPVqu68rH7C9mvNcrngTk205eETRxHj1ndwNHcaaWuYYDerMF2c8TY86ulXqCutj0xV 1ZEVOThsqiH0v9KLNxUbGrsxkSgBOWrKVu8s9hlXaZKmasX1tmRnMqj41Aqww9Igl84oaO viW/glQaL0V4rtJib2UgjqqGcLPbqj9gclgo6rbkMZsCdf9Je7TN25lZInAzOekD2o6aQS emhmnW1DH6LUjeowyQdwN+u/3YLuzsvAFtNpNJo11icHLGf1g8rSzlUa7XOKVy0fiAdytc 97wug/p45EUT9Y++tLjB2h9OxQWbxEN85mbYrknHeaZaeN/FdAetO23TZSmosw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713980717; 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=pgomdU57CMe1y6zUUU3nLdZLHEIlrmUBrWe4pFt0m4w=; b=lr9Vtt5nLv+oUzkMr50qathf1sQ4iV/XcwWe3e0iJ+ZqwD0+WUl2SbL0R6Albol6JIyZBD elawjaisbSmPYHXtUpTYJoHjtEeu0RYBcG2zVDwh4U8msn14lfRfuGTU1SIFL/LLB5MBlX JRw4fsHy84ejYbd2WQslpk7+9L2Qqu2rbeb4YNWZltgpjb0tj8mXdsetNAnOzDO8/ZS7uY IqEZiMAYODQjuf7QYZByPFDU4W4CO9Uc2VYVTUrEBsFtc1a0Wx3h/C6VLXPlfOEw5l0Rz4 mYv05CPkD6NReSPXAZPkgqV44nydCCKdVcr50EGEfgZQzNjGwJyaVfI/L6i2Cw== Received: from thornystick.local (thornystick.gshapiro.net [IPv6:2a0a:280:2357:5506::2ee5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: gshapiro) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VPmbc5G8Sz1PXd; Wed, 24 Apr 2024 17:45:16 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Date: Wed, 24 Apr 2024 10:45:13 -0700 From: Gregory Shapiro To: Marek Zarychta Cc: freebsd-net@freebsd.org Subject: Re: Source IPv4 address selection vs BGP IX connection Message-ID: References: <8895bb37-ccf3-48fd-877c-74c659045b23@plan-b.pwste.edu.pl> 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 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8895bb37-ccf3-48fd-877c-74c659045b23@plan-b.pwste.edu.pl> On Wed, Apr 24, 2024 at 07:10:51AM +0200, Marek Zarychta wrote: > W dniu 24.04.2024 o 04:12, Gregory Shapiro pisze: > > Short version: > > > > Using FreeBSD as a BGP router has network issues caused by suboptimal > > default IPv4 source address selection when connected to Internet > > Exchanges (which are required to use IPs that aren't routable on the > > Internet). I was hoping to find more elegant workarounds or encourage > > FreeBSD to add source IPv4 selection akin to the existing IPv6 source > > address selection (no_prefer_iface and prefer_source). > In this case, probably best solution will probably be using multiple FIBs. > Running a BGP routing daemon under not default FIB after assigning its > interface to this FIB should solve the problem but it might create > eventually new problems to solve (for example in which FIB should imported > routes be stored). Thank you for sharing the ideas. This first idea seems to negate the positive impact of multihoming and connecting to the IX for peering and additional transit. If the routes aren't usable in the default routing RIB (for downstream/LAN hosts or the router itself), then there doesn't seem to be a purpose of having multiple routes. > It's also possible to set and use non-default FIB for DNS lookups and > maintenance tasks like pkg upgrade (setfib -1 pkg ....). This approach is > probably more straightforward to conduct. Until you consider that not all work is done from the command line such that 'setfib' can proceed every command. What if cron wants to send a message with output from a cron job? What if a system service needs to connect to another host (e.g., ntpd)? Even to ssh into the system, sshd needs DNS for PTR lookups. I really think this isn't an issue with routing (and therefore can't be fixed elegantly by changing routing). It is an issue with source IP selection (one that has been addressed for IPv6, just not IPv4). I'll try to dig into how FreeBSD does source IP selection and see if I can add code to tune that process. From nobody Wed Apr 24 18:00:57 2024 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 4VPmxn0qs5z5J44r for ; Wed, 24 Apr 2024 18:01:01 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPmxn0BmDz3xc5; Wed, 24 Apr 2024 18:01:01 +0000 (UTC) (envelope-from gshapiro@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713981661; 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: in-reply-to:in-reply-to:references:references; bh=84doZlQx2jEr8yE/PN8UPr98OvXMS8in7LgoEKCx2es=; b=Pju9zGF3B/KqFHePpOPAIQIRT7i+dl8pMFywBicNuIGxIIR9W/tDqlHWprwBoJ13854fhI x7vs55Ny+FZ1RbFzhXwAFR8rm6H7jDthR0XFYBM7X7hcGjAN9vLaPDWoWxAPUbx8Tl7i8K e2zItClanWSmi5fA40+2lDuyST4NiJbP1B9oEq9u+bDo7qc8g2pP5PhNqUXnK5dtTnseUb 5ZslRXcldni3iquSNGgnAyFNOfwHoKoXY2CN0qg4VjyO8tB4HesLflA/TvxG3mNxSiPnQM 88b8grsvGSrE1knJgHzDjnbTPzs+8HJjJbiWGVzm5fnMmLo9NmzrW7vSYM0duw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713981661; a=rsa-sha256; cv=none; b=i78Lm5YM2uCf3m6r+WfJZN2mEftDNKRQ5u3C1BljDQQARkoKI+5ie//uP29d2GRZKx0j3r 4er5pdynMSYXSJ3tvw4G1hLCN9cpSIDS955J/Ii5OQg+K+LwXFl91UlSfEsXcTsttVA83F /IrLfKfVp1MBViIiIiWEoqrIm5O4qDJGnS0MyTk83gjl8xLVVyAfThvon2hzb6ZE3d4B7X 2wMEGIbCUGn30enDmuiK0PPSID2n32I5jughD9cZWa3MpXf/nSFJBreKhRJbBY7gkNNcx3 K2LPYGF1LUZrWHxsWd9W/RRYA8ILNpu4B8AJisiVO4jCJDaDJtxA9LgZU02flA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713981661; 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: in-reply-to:in-reply-to:references:references; bh=84doZlQx2jEr8yE/PN8UPr98OvXMS8in7LgoEKCx2es=; b=i6hmk+EwgRMjgHb84EaVHUE4QxeHHTjPajNEac7y9ldowFPGce1uGsmU5U5kZ37X2Oka+9 k5gJuScnRjoDaCkvj9oQQdR1E560zB03vsgdTiEVwa9yojQOFExUgs55rkJK68Zci7syO9 QoTQcqqzxwub09kJycydfhGL1CiE4n61LrLnwU/UTGgac2saU2zkklQGWxi3KtuMxchBUS 5w7TUiVnlbnrpAquu3L2VjF1VfAS0nWYD9CparsifbL8IVvoEnImKIgb5SYwiFD3Cioj7n w9ogV6q2eJRiAhiLP3l7KoQLz+p1Zrc2fX/sdS29xq3bC8QaPxHQMcCkcuSofw== Received: from thornystick.local (thornystick.gshapiro.net [IPv6:2a0a:280:2357:5506::2ee5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: gshapiro) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VPmxl3CNNz1QMZ; Wed, 24 Apr 2024 18:00:59 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Date: Wed, 24 Apr 2024 11:00:57 -0700 From: Gregory Shapiro To: "Rodney W. Grimes" Cc: freebsd-net@freebsd.org Subject: Re: Source IPv4 address selection vs BGP IX connection Message-ID: <3exr7zmcxnfxuofbyf57gdbzxxrgntprydeesbjsparq3xgeri@p4irynwruq7f> References: <202404241742.43OHghWB055177@gndrsh.dnsmgr.net> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202404241742.43OHghWB055177@gndrsh.dnsmgr.net> > The mistake your making, IMHO, is that an IX connected eBGP FreeBSD > router _SHOULD NOT_ be doing ANYTHING other than BGP on the IX > connected interface, and anything like DNS and outbound SMTP should be > going inward on the AS, not outward to the internet. Fair point and thank you for the advice. I am locking it down to an extent (denying all inbound ports except 22, 179 from an ipfw table list of trusted hosts/peers/upstreams/downstreams) but not as tightly as you suggest as I do use some on-Internet services. Specifically, port 25 to my own mail server (not unwashed Internet service, but sitting off of a different network) for system generated mail (cron, /etc/periodic/ script output), 53 to admittedly "unwashed" Google DNS, and 123 to FreeBSD's NTP pool (again "unwashed" to an extent). I will look at using local instances for the latter two. I still see value in source IP selection, even outside of the IX use case. From nobody Wed Apr 24 18:05:33 2024 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 4VPn396zJ0z5J4Sb for ; Wed, 24 Apr 2024 18:05:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPn395K7Yz40jP; Wed, 24 Apr 2024 18:05:41 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; none Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.17.1/8.16.1) with ESMTPS id 43OI5XKw014124 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Wed, 24 Apr 2024 14:05:33 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:50c:96ad:c667:424f] ([IPv6:2607:f3e0:0:4:50c:96ad:c667:424f]) by pyroxene2a.sentex.ca (8.17.1/8.15.2) with ESMTPS id 43OI5Wsj061333 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 24 Apr 2024 14:05:32 -0400 (EDT) (envelope-from mike@sentex.net) Content-Type: multipart/alternative; boundary="------------yyOEuZIT3LtYQpKGACz0B0z1" Message-ID: <42ac4479-53bc-4576-a81a-f71ce4e03986@sentex.net> Date: Wed, 24 Apr 2024 14:05:33 -0400 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 Thunderbird Subject: Re: Source IPv4 address selection vs BGP IX connection To: Gregory Shapiro , freebsd-net@freebsd.org References: Content-Language: en-US From: mike tancsa Autocrypt: addr=mike@sentex.net; keydata= xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg== In-Reply-To: X-Scanned-By: MIMEDefang 2.86 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA] X-Rspamd-Queue-Id: 4VPn395K7Yz40jP This is a multi-part message in MIME format. --------------yyOEuZIT3LtYQpKGACz0B0z1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/23/2024 10:12 PM, Gregory Shapiro wrote: > Short version: > > Using FreeBSD as a BGP router has network issues caused by suboptimal > default IPv4 source address selection when connected to Internet > Exchanges (which are required to use IPs that aren't routable on the > Internet). I was hoping to find more elegant workarounds or encourage > FreeBSD to add source IPv4 selection akin to the existing IPv6 source > address selection (no_prefer_iface and prefer_source). > > I assume that there is a group of BGP enthusiasts using FreeBSD lurking > on freebsd-net. What have you done to solve this problem? > For DNS in such situations I start unbound locally and bind it to an internal interface or an IP on lo0 and then tell unbound to just use that IP only  (outgoing-interface IIRC) that is advertised out as a work around.  Its not a proper solution, but will get your resolver working at least. I run into this problem in layered networks where the next hop is often RFC 1918 addrs. I bind applications to internal NICs that have addresses that have routing to/from.     ---Mike --------------yyOEuZIT3LtYQpKGACz0B0z1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 4/23/2024 10:12 PM, Gregory Shapiro wrote:
Short version:

Using FreeBSD as a BGP router has network issues caused by suboptimal
default IPv4 source address selection when connected to Internet
Exchanges (which are required to use IPs that aren't routable on the
Internet).  I was hoping to find more elegant workarounds or encourage
FreeBSD to add source IPv4 selection akin to the existing IPv6 source
address selection (no_prefer_iface and prefer_source).

I assume that there is a group of BGP enthusiasts using FreeBSD lurking
on freebsd-net.  What have you done to solve this problem?

For DNS in such situations I start unbound locally and bind it to an internal interface or an IP on lo0 and then tell unbound to just use that IP only  (outgoing-interface IIRC) that is advertised out as a work around.  Its not a proper solution, but will get your resolver working at least. I run into this problem in layered networks where the next hop is often RFC 1918 addrs. I bind applications to internal NICs that have addresses that have routing to/from.

    ---Mike

--------------yyOEuZIT3LtYQpKGACz0B0z1-- From nobody Wed Apr 24 20:55:37 2024 X-Original-To: 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 4VPrqG1Mpxz5J59x for ; Wed, 24 Apr 2024 20:55:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPrqG0KSXz4Ngg for ; Wed, 24 Apr 2024 20:55:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713992138; a=rsa-sha256; cv=none; b=FC2YXTiXnUF13yE6m37QdLL08aM1okevwtAe04vBKSnjR3mZMjCuX24mg/S13xMtW5Mn8k fCdxVzDzYHx+S/8uJRuJna7ufF4joXMssfHaErBRb3/AHb9QXTHT48qS9HuUlC0ya7WWoL mmiPE1y0mH4EkBpWNS9uAG3aJPMRLvYh700bxOCTF6OsaDuxa1ArHzVVTgq4D/3UzwMF3n bcVW3vKDL25YXv79THOw9VltyZnnyB7XHnndmfcZQ5v0LA4wty6T9EVOgna7/EHVwKp2Sv 04zTdT/ALAJ/DSf4GaeLb3bCqyrr85YShKbCQentVY22+mWBu4nsr9pBFUhPmQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713992138; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Tk7tvSMKp25fmW9v7nX3B8hRreRnyTtjOo+3Wmi7Nzw=; b=WOpZuUhz/bCzUp9iwQjDG8540AiIzhJpo5veGHvVr8DfCySQXmbtYg6hmxn2q97Vz+F4Sm dz9ubAC2m1RfqbWXKZS9xsegriakB0+6xue+f2tq10afcJaBt9snDws35Nk+N1vf+W0jEu L9hUJpp2f87cfF4evL9+abEhQ6l15bmgkP7X9M5y2ANcWpFIOED79kilZRvF58XdnpcS6v tCe9GBUPcVlt9mXGp08RkmYIZfKI7kgBWbMAX+i6CHzKxLDPMN+CMQ1ED29v1WHHaj1Zfb UvqP7c9zp2LI9HB2WQFvRpIK0vfWOLRtE4PArxWCQy86felZN2Wbj7rm03SbBQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4VPrqF6XMWzWSH for ; Wed, 24 Apr 2024 20:55:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 43OKtbjl002517 for ; Wed, 24 Apr 2024 20:55:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43OKtb9h002516 for net@FreeBSD.org; Wed, 24 Apr 2024 20:55:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 263982] IPv6 Router Advertisement - Route Information Option Date: Wed, 24 Apr 2024 20:55:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: freebsd@centromere.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263982 --- Comment #3 from Alex Wied --- Is there any plan to fix this? It's strange to me that a pfSense router (wh= ich runs FreeBSD) would cause issues for a FreeBSD machine. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Apr 24 22:31:08 2024 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 4VPtxf6K3xz5JFwb for ; Wed, 24 Apr 2024 22:31:18 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from util.redbarn.org (util.redbarn.org [24.104.150.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.redbarn.org", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VPtxf4RcNz4gfj; Wed, 24 Apr 2024 22:31:18 +0000 (UTC) (envelope-from paul@redbarn.org) Authentication-Results: mx1.freebsd.org; none Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.redbarn.org", Issuer "RapidSSL TLS RSA CA G1" (not verified)) by util.redbarn.org (Postfix) with ESMTPS id 5A0D819CCAE; Wed, 24 Apr 2024 22:31:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1713997870; bh=WYrhS+grCnTv9K/KYB4mTUudToqi1gsqd+dKZjsk+KE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=hxz+V443nwkWpcJq4Aw+j7+SBvO0c4ifLcejlV+Q3f7eqU0elhn78aLod6DhW2jRu ArZW3ZhaqEXHNj4PQ31UZcfLA84dXzakm7yZp6AQte7UfLwm0dySrkau4t9Jwcc6US toorNWbRWqL+0sp1rW6zWo/JEl63Zi/7SEDbk8R0= Received: from [24.104.150.175] (dhcp-175.access.rits.tisf.net [24.104.150.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 161AFC3F21; Wed, 24 Apr 2024 22:31:10 +0000 (UTC) Subject: Re: Source IPv4 address selection vs BGP IX connection To: Gregory Shapiro Cc: "Rodney W. Grimes" , freebsd-net@freebsd.org References: <202404241742.43OHghWB055177@gndrsh.dnsmgr.net> <3exr7zmcxnfxuofbyf57gdbzxxrgntprydeesbjsparq3xgeri@p4irynwruq7f> From: Paul Vixie Message-ID: <9d8cbd3e-6531-5c2b-ce02-0ff056cc946b@redbarn.org> Date: Wed, 24 Apr 2024 15:31:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.60 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 In-Reply-To: <3exr7zmcxnfxuofbyf57gdbzxxrgntprydeesbjsparq3xgeri@p4irynwruq7f> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:33651, ipnet:24.104.150.0/24, country:US] X-Rspamd-Queue-Id: 4VPtxf4RcNz4gfj agreed. and one of my mods to the ultrix (~4.3bsd) kernel for gatekeeper.dec.com back in ~1990 was to use the result of gethostid(3) if that result was nonzero and if a socket was not already bound. so named(8) and ntpd(8) and anything else that used explicit binding got what they expected, but the vast majority who just used INADDR_ANY (or more often just bzero(3)'d the sockaddr) would get what the sysadmin wanted. multihoming wasn't well understood and has gotten worse since. of course, gethostid(3) is now deprecated in favour of sysctl(3), and the hostid(8) command is gone, and there's now more than one flavour of Internet-capable UNIX in the world, and there's more than one Internet address family now. so what i did in 1990 is a guide only inasmuch as some way should exist to change the default local address of a socket so that it isn't the address of the interface used for the destination. if that happens i hope we coordinate with Linux and with the other BSD's. Gregory Shapiro wrote on 2024-04-24 11:00: > I still see value in source IP selection, even outside of the IX use > case. -- P Vixie From nobody Thu Apr 25 20:56:12 2024 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 4VQSnY1gCwz5JXd0 for ; Thu, 25 Apr 2024 20:56:17 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VQSnX6xs6z4sQ6; Thu, 25 Apr 2024 20:56:16 +0000 (UTC) (envelope-from gshapiro@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714078577; 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: in-reply-to:in-reply-to:references:references; bh=/MHXXEo1ZfwVOPk2ZflWBUV3wlY5s+6iLd54B0bHry4=; b=bLad2pUsMyGe99JqNCFLtEbiBiWAxX0KTRhDPg+oICWFX/HnxDqGtJuvXjPDOZ3Qzf/ZGD Bh9luMwiN9EUbES3f5xKtpXSTb9kiGFhTFBsoj8D19LuCCMDYVa9nePY/6GS1J+I4j7zVX 06z7PMBIsgK6myMCdpamu8UctNUOWk1TssXKyY5Tr5DHqoi2e4vT7/7F7SWqCwPRfwpf8c DWDYDaiJCu4ReKrkMHRAgMfw7snMT9Otr8nKfQgpw6wOguqIig9VIaFHp1j4d0kVrtoE8E +AHHA8QZQSnjhe4uiL6tUBnPqSdVN/1wMKq/jZAqTq+wGC6DeufSsjMMOZnc9Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1714078577; a=rsa-sha256; cv=none; b=yCggutnMOxSthDRJHaK6e0hjvP2XFdfONnmN7tGHhhb5ua41P4yrhbgiMfWw9BVupk0cP5 jFCFkhuK+8Dfnfc8JmXNtLZh2/rVB/32we/9oZiZyuRyiB0cPQBKeCJlfMmIwm1ceqOSQM wZvx7aJ2TMzHDukhwPJBkRwf5IbIuvuoRWALGQSmjHdduVyjQs4fkBCmMr5mcbTGeaKsoX h65RW1X0P14UedixaBQsisB2RxJ2fPwEhWWufiZwAwhc23EjvlJmnk5W7eEob6XCg49hWb Eyz4AiN/jL1glH0WAmi5m4YVKCHWchcDeYqzzZvFD+SwqhvSYMZxHBKm6K7dbQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714078577; 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: in-reply-to:in-reply-to:references:references; bh=/MHXXEo1ZfwVOPk2ZflWBUV3wlY5s+6iLd54B0bHry4=; b=pT0BnODmB5qpzlI+oQpAlBKH4zyPIh4MCZj+jgLMcwS2kNGxUsPv2RHm2t7dfTHPjVCIcg EwA4HhrFc8eDwJE2CuUMEdANVr9cSM6YzxKS47kDlo80ATKhL+KQbdCLab2Untabe+Rp3m gZENA+DTjJe793iHHP3DUZXts5UaMSVJzi9sG8fbkUBN5k9V+ModOhAqPJnMO0OnDXL8ch P1iovqDvvYc/flGte/VerLOGKrc1PmEPb49nO02K8pMSpcelzAbYyh7Cg5Q5t000l0ipfb i+FpaTSsQMgtDKbuP7kGn6CA1rV3MPm/0S8OIekOXK1ktfq0j19PDHWI2tBv/A== Received: from thornystick.local (thornystick.gshapiro.net [IPv6:2a0a:280:2357:5506::2ee5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: gshapiro) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VQSnX3lHdz10FK; Thu, 25 Apr 2024 20:56:16 +0000 (UTC) (envelope-from gshapiro@freebsd.org) Date: Thu, 25 Apr 2024 13:56:12 -0700 From: Gregory Shapiro To: Paul Vixie Cc: freebsd-net@freebsd.org Subject: Re: Source IPv4 address selection vs BGP IX connection Message-ID: References: <202404241742.43OHghWB055177@gndrsh.dnsmgr.net> <3exr7zmcxnfxuofbyf57gdbzxxrgntprydeesbjsparq3xgeri@p4irynwruq7f> <9d8cbd3e-6531-5c2b-ce02-0ff056cc946b@redbarn.org> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9d8cbd3e-6531-5c2b-ce02-0ff056cc946b@redbarn.org> > of course, gethostid(3) is now deprecated in favour of sysctl(3), and the > hostid(8) command is gone, and there's now more than one flavour of > Internet-capable UNIX in the world, and there's more than one Internet > address family now. so what i did in 1990 is a guide only inasmuch as some > way should exist to change the default local address of a socket so that it > isn't the address of the interface used for the destination. if that happens > i hope we coordinate with Linux and with the other BSD's. Linux already has a model to give a hint for source address selection via route table "hints". When adding routes (either manually via `ip route' or via things like bird2 BGP daemon), Linux supports setting a source IP for when that route is used. Interestingly, JunOS (which I believe is based on FreeBSD) also supports a way to specify a default IPv4 source address, preferring the primary address on lo0 that is not 127.0.0.1. It is a common practice for BGP systems to attach their announced IPs to the loopback interface. https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/default-address-selection-edit-system.html For the Linux and bird (BGP) documentation: Linux ----- http://linux-ip.net/html/tools-ip-route.html#ex-tools-ip-route-add-src "The src option provides a hint to the kernel for source address selection. When you are working with multiple routing tables and different classes of traffic, you can ease your administrative burden, by hosting several different IPs on your linux machine and setting the source address differently, depending on the type of traffic. In the example below, let's assume that our masquerading host also runs a DNS resolver for the internal network and we have selected all of the outbound DNS packets to be routed according to table 7 [53]. Now, any packet which originates on this box (or is masqueraded through this table) will have its source IP set to 205.254.211.198. Example D.19. Using src in a routing command with route add [root@masq-gw]# ip route add default via 205.254.211.254 src 205.254.211.198 table 7 " man ip-route "src ADDRESS the source address to prefer when sending to the destinations covered by the route prefix." Bird (BGP Daemon) ---- "The Kernel protocol defines several attributes. These attributes are translated to appropriate system (and OS-specific) route attributes. We support these attributes: ... ip krt_prefsrc (Linux) The preferred source address. Used in source address selection for outgoing packets. Has to be one of the IP addresses of the router." From nobody Thu Apr 25 22:39:13 2024 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 4VQW4Y6gScz5Jhl5 for ; Thu, 25 Apr 2024 22:39:25 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VQW4Y2qt2z4946; Thu, 25 Apr 2024 22:39:25 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 43PMdDMa060096; Thu, 25 Apr 2024 15:39:13 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 43PMdD4f060095; Thu, 25 Apr 2024 15:39:13 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202404252239.43PMdD4f060095@gndrsh.dnsmgr.net> Subject: Re: Source IPv4 address selection vs BGP IX connection In-Reply-To: To: Gregory Shapiro Date: Thu, 25 Apr 2024 15:39:13 -0700 (PDT) CC: Paul Vixie , freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] 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 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4VQW4Y2qt2z4946 > > of course, gethostid(3) is now deprecated in favour of sysctl(3), and the > > hostid(8) command is gone, and there's now more than one flavour of > > Internet-capable UNIX in the world, and there's more than one Internet > > address family now. so what i did in 1990 is a guide only inasmuch as some > > way should exist to change the default local address of a socket so that it > > isn't the address of the interface used for the destination. if that happens > > i hope we coordinate with Linux and with the other BSD's. > > Linux already has a model to give a hint for source address selection via > route table "hints". When adding routes (either manually via `ip route' > or via things like bird2 BGP daemon), Linux supports setting a source IP > for when that route is used. > > Interestingly, JunOS (which I believe is based on FreeBSD) also supports > a way to specify a default IPv4 source address, preferring the primary address > on lo0 that is not 127.0.0.1. The part of JunOS which is FreeBSD based runs inside a VM on Juniper routers and is a control plane only thing, what your probably seing is an artifact of the switch to Linux by Juniper. > It is a common practice for BGP systems to > attach their announced IPs to the loopback interface. These routers are almost always reject type routes and used to hold the routes 'UP' even if the IGP of an AS flaps them. This is not done to effect source IP address selection. > > https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/default-address-selection-edit-system.html > > For the Linux and bird (BGP) documentation: > > Linux > ----- > http://linux-ip.net/html/tools-ip-route.html#ex-tools-ip-route-add-src > > "The src option provides a hint to the kernel for source address selection. When you are working with multiple routing tables and different classes of traffic, you can ease your administrative burden, by hosting several different IPs on your linux machine and setting the source address differently, depending on the type of traffic. > > In the example below, let's assume that our masquerading host also runs a DNS resolver for the internal network and we have selected all of the outbound DNS packets to be routed according to table 7 [53]. Now, any packet which originates on this box (or is masqueraded through this table) will have its source IP set to 205.254.211.198. This is in effect what someone else suggested using multiple route tables in freeBSD and ipfw rules, iirc. > > Example D.19. Using src in a routing command with route add > > [root@masq-gw]# ip route add default via 205.254.211.254 src 205.254.211.198 table 7 > " > > man ip-route > > "src ADDRESS > the source address to prefer when sending to the > destinations covered by the route prefix." > > > Bird (BGP Daemon) > ---- > "The Kernel protocol defines several attributes. These attributes are translated to appropriate system (and OS-specific) route attributes. We support these attributes: > .. > ip krt_prefsrc > (Linux) The preferred source address. Used in source address selection for outgoing packets. Has to be one of the IP addresses of the router." This is for the purpose of bird process only and does not effect other processes. This is mainly used to control the source addressed used for eBGP sessions, though this can fail misserably when you have multiple interfaces speaking eBGP. Though I can see some merit in what your suggesting to do, I also know that it comes with a many problems as it might solve, like ping would stop working on a local link if the assigned "src IP" is not routable by the entity your trying to ping, which for me would be the case in many places as the IX IP only appears on the IX interface and nothing any place inside or outside my AS has a route to it. I believe this is the intent of the IX IP policy on use of unrouteable IP addresses. -- Rod Grimes rgrimes@freebsd.org From nobody Fri Apr 26 15:58:53 2024 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 4VQy846D0Cz5HSmC for ; Fri, 26 Apr 2024 15:59:00 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VQy844P2lz4ktv; Fri, 26 Apr 2024 15:59:00 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.18.1/8.18.1) with ESMTP id 43QFwsgn083102; Fri, 26 Apr 2024 10:58:54 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1714147134; bh=OZhQdQEo2tkkbDFG6HoXHNxVd8dvlkhTHkxatT8wrQw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Oh31vhickJuNihl/Ymy+yrei+EbiEVrDK6tDSwFli2l9bVJgFhS4RwNSDHOWFuzkx gvmqNF/XMz+9GHfm0EeZSryjWfJ6OupppYcoaGXsI4yI3ZC2uhV2C6LJTOvK928c70 a6AnHXXmnwWtc9Gxlz+Asv/Oo26JY0nPU9E9MkJeDd4CEkSSWDhni/EyX1zErWzSeH mttGh3wSKzyDDj/8viyeeNT9FY5KnQycXF5rEfI87uWYFvfNRXOVoGsyiHyH/WcXEG z2zFJuZaIKF4GTblLT6kqbdXjYDnqTh/6xwiWyUcPbatpAP5LOBK18C7k8FtimLYnM M1+Nz64cV4ksg== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id ryiNFD7PK2acRAEAs/W3XQ (envelope-from ); Fri, 26 Apr 2024 10:58:54 -0500 From: Mike Karels To: Gregory Shapiro Cc: freebsd-net@freebsd.org Subject: Re: Source IPv4 address selection vs BGP IX connection Date: Fri, 26 Apr 2024 10:58:53 -0500 X-Mailer: MailMate (1.14r6028) Message-ID: In-Reply-To: References: <202404241742.43OHghWB055177@gndrsh.dnsmgr.net> <3exr7zmcxnfxuofbyf57gdbzxxrgntprydeesbjsparq3xgeri@p4irynwruq7f> <9d8cbd3e-6531-5c2b-ce02-0ff056cc946b@redbarn.org> 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 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Queue-Id: 4VQy844P2lz4ktv On 25 Apr 2024, at 15:56, Gregory Shapiro wrote: >> of course, gethostid(3) is now deprecated in favour of sysctl(3), and = the >> hostid(8) command is gone, and there's now more than one flavour of >> Internet-capable UNIX in the world, and there's more than one Internet= >> address family now. so what i did in 1990 is a guide only inasmuch as = some >> way should exist to change the default local address of a socket so th= at it >> isn't the address of the interface used for the destination. if that h= appens >> i hope we coordinate with Linux and with the other BSD's. > > Linux already has a model to give a hint for source address selection v= ia > route table "hints". When adding routes (either manually via `ip route= ' > or via things like bird2 BGP daemon), Linux supports setting a source I= P > for when that route is used. > > Interestingly, JunOS (which I believe is based on FreeBSD) also support= s > a way to specify a default IPv4 source address, preferring the primary = address > on lo0 that is not 127.0.0.1. It is a common practice for BGP systems = to > attach their announced IPs to the loopback interface. > > https://www.juniper.net/documentation/us/en/software/junos/cli-referenc= e/topics/ref/statement/default-address-selection-edit-system.html > > For the Linux and bird (BGP) documentation: > > Linux > ----- > http://linux-ip.net/html/tools-ip-route.html#ex-tools-ip-route-add-src > > "The src option provides a hint to the kernel for source address select= ion. When you are working with multiple routing tables and different clas= ses of traffic, you can ease your administrative burden, by hosting sever= al different IPs on your linux machine and setting the source address dif= ferently, depending on the type of traffic. > > In the example below, let's assume that our masquerading host also runs= a DNS resolver for the internal network and we have selected all of the = outbound DNS packets to be routed according to table 7 [53]. Now, any pac= ket which originates on this box (or is masqueraded through this table) w= ill have its source IP set to 205.254.211.198. > > Example D.19. Using src in a routing command with route add > > [root@masq-gw]# ip route add default via 205.254.211.254 src 205.254.21= 1.198 table 7 > " > > man ip-route > > "src ADDRESS > the source address to prefer when sending to the > destinations covered by the route prefix." When you first asked this question, my first thought was that this should= be in the routing table. It seems to me that choosing the source address= is more a function of the destination than of the process (vnet, jail, etc). In fact, this problem seemed familiar, so I went looking. It turn= s out that this feature has been available since 4.4BSD. route(8) has a keyword to do just this, -ifa (interface address). It onl= y seems to work when the alias is on the same interface. It also seems to be broken in -current and 14.0, but I got it to work with 13.3 and 12.4. While experimenting, I tried to use -ifp as well, but it seems to be igno= red; route add -ifp foobar ... does not fail. (12.4 got the interface wrong when the alias was on the loopback.) Anyone know why -ifa is ineffective in 14.0 and -current? It could be fallout from netlink. The documentation is weak at best; route(8) says only "the -ifp or -ifa modifiers may be used to determine the interface or interface address". "route get" does not display the ifa; I think it did at one time. I'll also note that binding the desired source address manually works; ping -S uses this. Mike > > Bird (BGP Daemon) > ---- > "The Kernel protocol defines several attributes. These attributes are t= ranslated to appropriate system (and OS-specific) route attributes. We su= pport these attributes: > .. > ip krt_prefsrc > (Linux) The preferred source address. Used in source address selection = for outgoing packets. Has to be one of the IP addresses of the router." From nobody Fri Apr 26 20:01:59 2024 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 4VR3Xl10cGz5J7ZT for ; Fri, 26 Apr 2024 20:02:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VR3Xk1r6wz48Bf for ; Fri, 26 Apr 2024 20:02:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20230601.gappssmtp.com header.s=20230601 header.b=B4rezhPu; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::236) smtp.mailfrom=wlosh@bsdimp.com Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2d8a24f8a3cso30958381fa.1 for ; Fri, 26 Apr 2024 13:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1714161731; x=1714766531; darn=freebsd.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=druCQ0bU4KTF4+MMOPSFQhXrxnuAIZDe9VxeLprC4YM=; b=B4rezhPuxvMSNQ20NslJOjYJzjBLv1led5zD0CE7Ta0KkLb7d68KvfvpRnwcAAv8ch +1IjfpdpNKU8r0GObeAnWmC7uBkcdBKXYFgmGJgX/sVnFVA1RDw4gR4y3Q/0LrQojyrL oJIKqtPwrr1K+/opZjmdyXcSt3UoPjPxJqp2fZzH1XjeS/4geZzkuoUodyuewi66Zvlc rg49mW5sRnrMkI9QJEEfNT9PNhKv3NI0HNcHQPnQc9OzdgMH2H2eNYLorMJSPeDsrV8z gcFdLf4L2lLnoSLS35BHwxDZF9xoTRvXW5bePJcIx5UF0A4iRuS/F3DiA0Rf+XDQ1BqS DCUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714161731; x=1714766531; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=druCQ0bU4KTF4+MMOPSFQhXrxnuAIZDe9VxeLprC4YM=; b=N/Y876rpTR8kaWwvPqkW8HpBLT++QejlogkZFu8V6AG566LYso33pGQxz0L/cPgWOY I85yZPFiuhBmbbtml8wk/weKdXWbS/5U+bLfIODoaAxIdt6DmMsTF6UK60M5o3R2n9rb VW4wLuPZABfD5+0WO2155kxJ7K4qhKLqo5+z7DTaYkphgftuLdYvkssh3DWartWiIU0u 9bCPfPi0ZFxUT0g0Gp1qhNSZMR3PPo+DMyPOnjc4AfiopHDPQpfVLFmwAJnZWDtOz2/U Rltf/b7+t0wWmgFLYN+CDc9CVi2zSXoK/oxHkNZ5KIxEoJmVReXfkZZRBmxXUK9zDWKn xA/w== X-Gm-Message-State: AOJu0YyYjODVyvfG0Z+mzsitkis7o4WUHdoqkdHEZLsZ5A4sff+LFuyj 8w1TPhKXzsNa23z7sh7sPO1Kg2mwXUuajWgdc+FoD6lfsjy9poY9i3h/HSw6yiJerP5sBITjai8 8iBiTOeCHYKU4FYOt14pn6iceZU4bHC40EjDdAezggK9iJ94l78KrwA== X-Google-Smtp-Source: AGHT+IFDeleFlWpRM/pnIi63QrMl+2RlAX95WR0CgIL++LbNvK3lVQCp2LsmV9W8pANeFqiK+v7/YA1oodoZE/L5Jr8= X-Received: by 2002:a05:6512:44a:b0:51c:348:3ba9 with SMTP id y10-20020a056512044a00b0051c03483ba9mr2270381lfk.22.1714161730810; Fri, 26 Apr 2024 13:02:10 -0700 (PDT) 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 From: Warner Losh Date: Fri, 26 Apr 2024 14:01:59 -0600 Message-ID: Subject: Question about netinet6/in6.h To: FreeBSD Net Content-Type: multipart/alternative; boundary="0000000000000d9ca5061705613d" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20230601.gappssmtp.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::236:from]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DKIM_TRACE(0.00)[bsdimp-com.20230601.gappssmtp.com:+] X-Rspamd-Queue-Id: 4VR3Xk1r6wz48Bf --0000000000000d9ca5061705613d Content-Type: text/plain; charset="UTF-8" This has to be a FAQ I'm porting a program from Linux, I often see an error like: ../test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in 'struct in6_addr' 95 | ipv6->sin6_addr.s6_addr32[3] = 0; | ~~~~~~~~~~~~~~~ ^ but yet, we kinda define them, but only for the kernel and boot loader: /* * IPv6 address */ struct in6_addr { union { uint8_t __u6_addr8[16]; uint16_t __u6_addr16[8]; uint32_t __u6_addr32[4]; } __u6_addr; /* 128-bit IP6 address */ }; #define s6_addr __u6_addr.__u6_addr8 #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */ #define s6_addr8 __u6_addr.__u6_addr8 #define s6_addr16 __u6_addr.__u6_addr16 #define s6_addr32 __u6_addr.__u6_addr32 #endif I'm wondering if anybody why it's like that? git blame suggests we imported that from kame, with only tweaks by people that are now deceased*.* Why not just expose them? Warner --0000000000000d9ca5061705613d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This has to be a FAQ

I'm= porting a program from Linux, I often see an error like:
../test= /mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in 's= truct in6_addr'
=C2=A0 =C2=A095 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 ipv6->sin6_addr.s6_addr32[3] =3D 0;
=C2=A0 =C2= =A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ~~~~~~= ~~~~~~~~~ ^
but yet, we kinda define them, but only for the kerne= l and boot loader:
/*
=C2=A0* IPv6 address
=C2=A0*/
stru= ct in6_addr {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 union {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint8_t =C2=A0 =C2=A0 =C2=A0 =C2=A0 = __u6_addr8[16];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = uint16_t =C2=A0 =C2=A0 =C2=A0 =C2=A0__u6_addr16[8];
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32_t =C2=A0 =C2=A0 =C2=A0 =C2=A0__u= 6_addr32[4];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } __u6_addr; =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 128-bit IP6 address = */
};

#define s6_addr =C2=A0 __u6_addr.__u6_addr8
#if defined(= _KERNEL) || defined(_STANDALONE) /* XXX nonstandard */
#define s6_addr8 = =C2=A0__u6_addr.__u6_addr8
#define s6_addr16 __u6_addr.__u6_addr16
#d= efine s6_addr32 __u6_addr.__u6_addr32
#endif

I&= #39;m wondering if anybody why it's like that? git blame suggests we im= ported that from kame, with
only tweaks by people that are now de= ceased.

Why not just expose them?

Warner
--0000000000000d9ca5061705613d-- From nobody Fri Apr 26 20:49:03 2024 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 4VR4Zp62K8z5JCC8 for ; Fri, 26 Apr 2024 20:49:06 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VR4Zp4KKNz4Dwr for ; Fri, 26 Apr 2024 20:49:06 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.18.1/8.18.1) with ESMTP id 43QKn4Wv084310; Fri, 26 Apr 2024 15:49:04 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1714164544; bh=BHLuvtOLPF37qr2kp+DlNSYzpHpBfGNRA6LRLLgxFMQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Ubh54cdNZv36lveon4Vrz/9QIb7MYNdHNnPClj+juGCYxBHeFKQgx7hQsT6xlhQh/ gwZn6aldF4BGYfeMJ9P9Zk1i3J2mrcm8xYTMtSk6KmTDu1h8cgj1nPJYIBX4TdeCx4 HyeW9u5XVKKr8ZvhSEwh5e0hmMdHG1h9nSPYwVsEIQOjAa1AoT/xrUDyj6IRWjZRsz uybXKizRVqztVkPZRFmoRcxOTRrhaZME5FSS95qaJUKvPxts+Men6iycZemNCcWW3O vHPcjRsoC5O46RM20HfEc4/kwuwfQpJK628hYpfzd7/3271Ikpet9Whx0HkMoEUtAx 5N1NQqal6Ne/g== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id CkgQGEATLGZUSQEAs/W3XQ (envelope-from ); Fri, 26 Apr 2024 15:49:04 -0500 From: Mike Karels To: Warner Losh Cc: FreeBSD Net Subject: Re: Question about netinet6/in6.h Date: Fri, 26 Apr 2024 15:49:03 -0500 X-Mailer: MailMate (1.14r6028) Message-ID: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> In-Reply-To: References: 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 Content-Type: text/plain X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Queue-Id: 4VR4Zp4KKNz4Dwr On 26 Apr 2024, at 15:01, Warner Losh wrote: > This has to be a FAQ > > I'm porting a program from Linux, I often see an error like: > ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in 'struct > in6_addr' > 95 | ipv6->sin6_addr.s6_addr32[3] = 0; > | ~~~~~~~~~~~~~~~ ^ > but yet, we kinda define them, but only for the kernel and boot loader: > /* > * IPv6 address > */ > struct in6_addr { > union { > uint8_t __u6_addr8[16]; > uint16_t __u6_addr16[8]; > uint32_t __u6_addr32[4]; > } __u6_addr; /* 128-bit IP6 address */ > }; > > #define s6_addr __u6_addr.__u6_addr8 > #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */ > #define s6_addr8 __u6_addr.__u6_addr8 > #define s6_addr16 __u6_addr.__u6_addr16 > #define s6_addr32 __u6_addr.__u6_addr32 > #endif > > I'm wondering if anybody why it's like that? git blame suggests we imported > that from kame, with > only tweaks by people that are now deceased*.* > > Why not just expose them? Looks like only s6_addr is specified in the RFCs (2553 and 3493). Oddly, though, the RFCs give an example implementation using that union with different element names (like _S6_u8), and show the one #define. Similarly, POSIX specifies only s6_addr, but it allows other members of the structure, so I don't see a problem with exposing them all even in a POSIX environment. I would have no objection to exposing all four definitions, especially if Linux apps use them. Mike From nobody Fri Apr 26 22:21:08 2024 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 4VR6d36S7Vz5JMMq for ; Fri, 26 Apr 2024 22:21:11 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VR6d31YmYz4NKF for ; Fri, 26 Apr 2024 22:21:11 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=karels.net header.s=mail2 header.b="a8GsV5/N"; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 3.19.118.201 as permitted sender) smtp.mailfrom=mike@karels.net Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.18.1/8.18.1) with ESMTP id 43QML8SS084676; Fri, 26 Apr 2024 17:21:08 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1714170069; bh=NdboStA2anGPq16XYfbeabjPLPQ+xW3sHvXJUUMajTw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=a8GsV5/NHRpYFhhDfAJ5VKyFu45FXxSoLLVGZqL53YY3MZce/gBKyPGMpuz39PjbC EKtks9VxJDeQ97Yk5PFE/H0yZAWeOhNFS+g96g7ar8jXVLSC2Ihi9wJUsGwUQZZpZa 1YtxroYghBD2Vn6VKcfAobxfk6unMoEE7/wz/9jDrIO6y63Z2oO4eMxDGM0p5fODIy RTqsifSzY5Z9JdsjsEJUmhSUlTxvOjWGq0Z+ikNfK4LD5qkMqM5Ra7V4StBKVo/wUJ 40LRzM5iC2bAyGbO1v7ro0I0DICTMiEo6MpH+jGkBpW7j66/nBcX8TUIWX+dkRipcn hN9v84N+nvHSg== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id iKxoM9QoLGbCSgEAs/W3XQ (envelope-from ); Fri, 26 Apr 2024 17:21:08 -0500 From: Mike Karels To: Warner Losh Cc: FreeBSD Net Subject: Re: Question about netinet6/in6.h Date: Fri, 26 Apr 2024 17:21:08 -0500 X-Mailer: MailMate (1.14r6028) Message-ID: In-Reply-To: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> References: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> 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 Content-Type: text/plain X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; R_DKIM_ALLOW(-0.20)[karels.net:s=mail2]; R_SPF_ALLOW(-0.20)[+ip4:3.19.118.201]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[mike]; DMARC_NA(0.00)[karels.net]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[karels.net:+] X-Rspamd-Queue-Id: 4VR6d31YmYz4NKF On 26 Apr 2024, at 15:49, Mike Karels wrote: > On 26 Apr 2024, at 15:01, Warner Losh wrote: > >> This has to be a FAQ >> >> I'm porting a program from Linux, I often see an error like: >> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in 'struct >> in6_addr' >> 95 | ipv6->sin6_addr.s6_addr32[3] = 0; >> | ~~~~~~~~~~~~~~~ ^ >> but yet, we kinda define them, but only for the kernel and boot loader: >> /* >> * IPv6 address >> */ >> struct in6_addr { >> union { >> uint8_t __u6_addr8[16]; >> uint16_t __u6_addr16[8]; >> uint32_t __u6_addr32[4]; >> } __u6_addr; /* 128-bit IP6 address */ >> }; >> >> #define s6_addr __u6_addr.__u6_addr8 >> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */ >> #define s6_addr8 __u6_addr.__u6_addr8 >> #define s6_addr16 __u6_addr.__u6_addr16 >> #define s6_addr32 __u6_addr.__u6_addr32 >> #endif >> >> I'm wondering if anybody why it's like that? git blame suggests we imported >> that from kame, with >> only tweaks by people that are now deceased*.* >> >> Why not just expose them? > > Looks like only s6_addr is specified in the RFCs (2553 and 3493). Oddly, > though, the RFCs give an example implementation using that union with > different element names (like _S6_u8), and show the one #define. > Similarly, POSIX specifies only s6_addr, but it allows other members > of the structure, so I don't see a problem with exposing them all even > in a POSIX environment. > > I would have no objection to exposing all four definitions, especially > if Linux apps use them. I put the change, along with an explanatory comment, in https://reviews.freebsd.org/D44979. Comments welcome. Mike From nobody Fri Apr 26 23:06:31 2024 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 4VR7dg3qc3z5JQZh for ; Fri, 26 Apr 2024 23:06:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VR7dg27swz4R5d for ; Fri, 26 Apr 2024 23:06:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-5176f217b7bso4588845e87.0 for ; Fri, 26 Apr 2024 16:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1714172803; x=1714777603; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=c3dy+ceOxcsoKDfUFBpMSBZDiKRrtn2W2zv2bfcVlfU=; b=J1Y9DvAdGTYTDxtwnfmIfo8qYu5UydUIPophSq4KvLYPzWaxpA560VpuQDHqUH+UEy fJ6a5SEg6ey7vvdryfPBiJNtFmATI/oSHdSUERJhQnDrviIwGSHiSxmi0qzsgNADAZFg 3J08oOs5ma1KG545TFWxQE3TWNDUt4KsMEOhqz4F4WXwHLlndfV3aKQUNtKhDj6V/dCU VAInqWwkFBiZybF2Vp684OF4SXxquV19v0sO42UAWbBDqzndDgbdNTsvoR5VD0dVbNsv cPsltsLcIBNzh9HhVsVjgNNot4KpxmdP/8SPIcfGIRlkPSgRUN0bMQPY+2aN52uG6Nx5 4xwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714172803; x=1714777603; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=c3dy+ceOxcsoKDfUFBpMSBZDiKRrtn2W2zv2bfcVlfU=; b=Rr/C29iKgsg6AKO6ctHQap4RiW9sGQS8M6Gf7aJYZmAvDgdBRYllDurqYUGQwB4LBn woOTkE7uWP3tZSyCUTSlF7L6CyyO6zEYJV/4vZwFKe2nMsUiRivZoZdMbFlIFoDzZfKb TESfljWmOy5NXmyS4q0pyvRUB4u2JGoE53OgHyHxXWLgCafzOyZCT9ycgHKcIGOczA1S L+QgCZwEvNVD/+d8vrrwLe9q6eY87lrfDPMThtdKrO7DVqGx6IyCfAd4x2gI8wV8LTVt 9uucQVWXXgllPgAecLClYgx6rVzAwFhdnEAGnmbxDopYDJRGWqSeaqoRvFfIN+jWwc6S NuBw== X-Gm-Message-State: AOJu0YwKt8cdPVa7VObl4y0i5AFklBVn//7osut5g2+AGEOouBH5+wI5 TlvSjID6rj2Vajw5ihNS2O030mix0/xHy9s9ImEEusslGBXHpF8FzOayRNUbMjQCGUHpyqPsSmE zWLdDPt0ZThuSskqjhnzbyioAQsImwhJDh7vD+Q== X-Google-Smtp-Source: AGHT+IF4cG2iWzY6JW13Fymw8xJyrHP8rpHduJ0gpEcKhbxOYKbqkkxTJP71t86pfcRDlzRl65rLmgFmsyg61NK5pWA= X-Received: by 2002:a19:ca54:0:b0:516:d09b:cbe4 with SMTP id h20-20020a19ca54000000b00516d09bcbe4mr3287326lfj.53.1714172802760; Fri, 26 Apr 2024 16:06:42 -0700 (PDT) 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 References: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> In-Reply-To: From: Warner Losh Date: Fri, 26 Apr 2024 17:06:31 -0600 Message-ID: Subject: Re: Question about netinet6/in6.h To: Mike Karels Cc: FreeBSD Net Content-Type: multipart/alternative; boundary="000000000000fe240c061707f464" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VR7dg27swz4R5d --000000000000fe240c061707f464 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2024 at 4:21=E2=80=AFPM Mike Karels wrote= : > On 26 Apr 2024, at 15:49, Mike Karels wrote: > > > On 26 Apr 2024, at 15:01, Warner Losh wrote: > > > >> This has to be a FAQ > >> > >> I'm porting a program from Linux, I often see an error like: > >> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in > 'struct > >> in6_addr' > >> 95 | ipv6->sin6_addr.s6_addr32[3] =3D 0; > >> | ~~~~~~~~~~~~~~~ ^ > >> but yet, we kinda define them, but only for the kernel and boot loader= : > >> /* > >> * IPv6 address > >> */ > >> struct in6_addr { > >> union { > >> uint8_t __u6_addr8[16]; > >> uint16_t __u6_addr16[8]; > >> uint32_t __u6_addr32[4]; > >> } __u6_addr; /* 128-bit IP6 address */ > >> }; > >> > >> #define s6_addr __u6_addr.__u6_addr8 > >> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */ > >> #define s6_addr8 __u6_addr.__u6_addr8 > >> #define s6_addr16 __u6_addr.__u6_addr16 > >> #define s6_addr32 __u6_addr.__u6_addr32 > >> #endif > >> > >> I'm wondering if anybody why it's like that? git blame suggests we > imported > >> that from kame, with > >> only tweaks by people that are now deceased*.* > >> > >> Why not just expose them? > > > > Looks like only s6_addr is specified in the RFCs (2553 and 3493). Oddl= y, > > though, the RFCs give an example implementation using that union with > > different element names (like _S6_u8), and show the one #define. > > Similarly, POSIX specifies only s6_addr, but it allows other members > > of the structure, so I don't see a problem with exposing them all even > > in a POSIX environment. > > > > I would have no objection to exposing all four definitions, especially > > if Linux apps use them. > > I put the change, along with an explanatory comment, in > https://reviews.freebsd.org/D44979. Comments welcome. > Thanks! I was testing a similar change, but I like yours better... though maybe we should just make it visible when __BSD_VISIBLE is true.... I'll have to look closely at what Linux does here... I think they have it always visible, or at least musl does that (glibc is harder to track down due to the many layers of indirection). Warner --000000000000fe240c061707f464 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 26, 2024 at 4:21=E2=80=AF= PM Mike Karels <mike@karels.net&g= t; wrote:
On 26 = Apr 2024, at 15:49, Mike Karels wrote:

> On 26 Apr 2024, at 15:01, Warner Losh wrote:
>
>> This has to be a FAQ
>>
>> I'm porting a program from Linux, I often see an error like: >> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32= ' in 'struct
>> in6_addr'
>>=C2=A0 =C2=A0 95 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0ipv6->sin6_addr.s6_addr32[3] =3D 0;
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0~~~~~~~~~~~~~~~ ^
>> but yet, we kinda define them, but only for the kernel and boot lo= ader:
>> /*
>>=C2=A0 * IPv6 address
>>=C2=A0 */
>> struct in6_addr {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0union {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint8= _t=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__u6_addr8[16];
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint1= 6_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 __u6_addr16[8];
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint3= 2_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 __u6_addr32[4];
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} __u6_addr;=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 128-bit IP6 address */<= br> >> };
>>
>> #define s6_addr=C2=A0 =C2=A0__u6_addr.__u6_addr8
>> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */=
>> #define s6_addr8=C2=A0 __u6_addr.__u6_addr8
>> #define s6_addr16 __u6_addr.__u6_addr16
>> #define s6_addr32 __u6_addr.__u6_addr32
>> #endif
>>
>> I'm wondering if anybody why it's like that? git blame sug= gests we imported
>> that from kame, with
>> only tweaks by people that are now deceased*.*
>>
>> Why not just expose them?
>
> Looks like only s6_addr is specified in the RFCs (2553 and 3493).=C2= =A0 Oddly,
> though, the RFCs give an example implementation using that union with<= br> > different element names (like _S6_u8), and show the one #define.
> Similarly, POSIX specifies only s6_addr, but it allows other members > of the structure, so I don't see a problem with exposing them all = even
> in a POSIX environment.
>
> I would have no objection to exposing all four definitions, especially=
> if Linux apps use them.

I put the change, along with an explanatory comment, in
https://reviews.freebsd.org/D44979.=C2=A0 Comments welcome.

Thanks! I was testing a similar change, b= ut I like yours better... though maybe
we should just make it vis= ible when __BSD_VISIBLE is true.... I'll have to look
closely= at what Linux does here... I think they have it always visible, or at leas= t
musl does that (glibc is harder to track down due to the many l= ayers of indirection).

Warner
--000000000000fe240c061707f464-- From nobody Sat Apr 27 00:02:19 2024 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 4VR8ss36czz5JW8P for ; Sat, 27 Apr 2024 00:02:25 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VR8sr54cLz4X7r for ; Sat, 27 Apr 2024 00:02:24 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.18.1/8.18.1) with ESMTP id 43R02K3B085198; Fri, 26 Apr 2024 19:02:20 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1714176140; bh=/G9EJmLmIpBQPTzAZh/Ka4xrr9dKD/stgt7uSjyOoaM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Pitc3RtlfeU2UKfmQ4T0lvIr6OYe3KxCnfvKYpmz8W99syezs6C4BIgqj80Y56vOY RVzmODzLZD8lh88QoKp44mMu7eamvkwHJoDpiFBytWGMMpp9U4ampuFPdI7BX/PYlC V57P4V8OY4U9nlM1KUYh4fZ4enkTXAXST7UNb9wGWOfKeatCOAFKmsLIQyLcszS68H vePODZzB9xabIaE+FWjf4ZFnDf7duUV48w5Y1t2jqnxOSwnPt7lcIa5yMTgAhhjV3s GE6XPgR+fE6eOjnzm+2DXLBtpJ1arFKHwifjNKvdK3+BLYUb8tpdcinQIGp3Aww9O9 LefHE5dBe1+3A== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id LbHkKYxALGbMTAEAs/W3XQ (envelope-from ); Fri, 26 Apr 2024 19:02:20 -0500 From: Mike Karels To: Warner Losh Cc: FreeBSD Net Subject: Re: Question about netinet6/in6.h Date: Fri, 26 Apr 2024 19:02:19 -0500 X-Mailer: MailMate (1.14r6028) Message-ID: <4AF50212-9141-44FF-937F-A06AF8B15121@karels.net> In-Reply-To: References: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Queue-Id: 4VR8sr54cLz4X7r On 26 Apr 2024, at 18:06, Warner Losh wrote: > On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote: > >> On 26 Apr 2024, at 15:49, Mike Karels wrote: >> >>> On 26 Apr 2024, at 15:01, Warner Losh wrote: >>> >>>> This has to be a FAQ >>>> >>>> I'm porting a program from Linux, I often see an error like: >>>> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in >> 'struct >>>> in6_addr' >>>> 95 | ipv6->sin6_addr.s6_addr32[3] = 0; >>>> | ~~~~~~~~~~~~~~~ ^ >>>> but yet, we kinda define them, but only for the kernel and boot loader: >>>> /* >>>> * IPv6 address >>>> */ >>>> struct in6_addr { >>>> union { >>>> uint8_t __u6_addr8[16]; >>>> uint16_t __u6_addr16[8]; >>>> uint32_t __u6_addr32[4]; >>>> } __u6_addr; /* 128-bit IP6 address */ >>>> }; >>>> >>>> #define s6_addr __u6_addr.__u6_addr8 >>>> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */ >>>> #define s6_addr8 __u6_addr.__u6_addr8 >>>> #define s6_addr16 __u6_addr.__u6_addr16 >>>> #define s6_addr32 __u6_addr.__u6_addr32 >>>> #endif >>>> >>>> I'm wondering if anybody why it's like that? git blame suggests we >> imported >>>> that from kame, with >>>> only tweaks by people that are now deceased*.* >>>> >>>> Why not just expose them? >>> >>> Looks like only s6_addr is specified in the RFCs (2553 and 3493). Oddly, >>> though, the RFCs give an example implementation using that union with >>> different element names (like _S6_u8), and show the one #define. >>> Similarly, POSIX specifies only s6_addr, but it allows other members >>> of the structure, so I don't see a problem with exposing them all even >>> in a POSIX environment. >>> >>> I would have no objection to exposing all four definitions, especially >>> if Linux apps use them. >> >> I put the change, along with an explanatory comment, in >> https://reviews.freebsd.org/D44979. Comments welcome. >> > > Thanks! I was testing a similar change, but I like yours better... though > maybe > we should just make it visible when __BSD_VISIBLE is true.... I'll have to > look > closely at what Linux does here... I think they have it always visible, or > at least > musl does that (glibc is harder to track down due to the many layers of > indirection). I thought briefly about __BSD_VISIBLE, but wasn't sure it was necessary. Let me know what you find out. I think it should work either way; in.h includes cdefs.h, so it's guaranteed to have been included. Mike From nobody Sat Apr 27 03:33:03 2024 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 4VRFYJ2Hqqz5HNTS for ; Sat, 27 Apr 2024 03:33:24 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VRFYH5zk0z4wWM for ; Sat, 27 Apr 2024 03:33:23 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6ed32341906so2739549b3a.1 for ; Fri, 26 Apr 2024 20:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1714188795; x=1714793595; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vbzShtrXGD92SiM+M5voAl/KIcHF9TtNlPlseqzKsFQ=; b=twzot3phMZxeyXrK+3AaSPjkTAdyMH2SPD0Xk5HiylmFFKlUM18D8Di/Ji4+oPtnFm vBJh/qWfo9CmEiNjpAVf4uHCnjOn8fTszpbHFNuNLA7TymOjfxRgEpyqx1cQJQVJvYuU CTu/9Ve98rwGBWTJoCYQ1FSmgv9FvEK0lkDrY5GEBiXFdCfBuuCu+xpFlSn+DSLUdbro zWTdRHWd9Mf48DlW4yWxVySKxHHlV0lOJ5SU7Pcr+BcDU1xL5TMlemoCRsxgCrvuFts1 NfoPtqOOlKtNoF1SwNVl3rAGxXWOFOiAlSNS2OvOa4c1tBAcYmhFFHg6mg4OXC7hXq4X RARg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714188795; x=1714793595; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vbzShtrXGD92SiM+M5voAl/KIcHF9TtNlPlseqzKsFQ=; b=YOhmpUG5sLe3oQJQzJ9hcW54nMaTMXp2sqqGa8D9CGb1URFIjZcVO/pogj8qNwq+ix 5E3iyAX4xLkOUX2XtvyYUu2j50Io3pTWxIoUelna+LzvjZk74L/nysS+lB0j/9BgNcp+ BW9PynzXxZnGSv0fsBGqWhD7tGy3qg9ifwSiLDPNmT/B1kyn5WMXttndNSrl7ad7/jAn rqTzzqUU0VkQ5E++jjQC+7niI4HpaJnlaRgPSCRPfHwNTX6lk5OO9twC6A4wsWY9ZETJ 7wVQVI56tzQ5+o9JU4/m7I77doI52SHx3R4Hjqr/XzDdN9nYZK8e+q6n9PESTs2K+PN7 utlg== X-Forwarded-Encrypted: i=1; AJvYcCWG3zqPHohY+tnP6P0MfC2dyFqXkIZAUsmcZnbLI3wiqhYoL3xZX8BXUHcIgmKWnlUi9NOfUaHHLQ3k0HqJTymnNx0btPx1Aw== X-Gm-Message-State: AOJu0YzYLLj9vSGoMEzbzadaf452n6+shuMGeOe35+EOt73i1V3h6NYi zwOxSiehKia9d671zt5EEp6k8jXHYsU7miBLG6ugUdwW4ZfOZsFxzMvnD5BDgbntwb8mf5mw0TI = X-Google-Smtp-Source: AGHT+IFL7qDPOCN3+JyCPYgccjJgIrKFYH/bL7TFKBVNdKp4sUSbGaaaRDzQV/4LSaEJtmV9fHTOyA== X-Received: by 2002:a05:6a20:1b1c:b0:1a7:78d2:a142 with SMTP id ch28-20020a056a201b1c00b001a778d2a142mr4516862pzb.38.1714188795501; Fri, 26 Apr 2024 20:33:15 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id e13-20020a17090ab38d00b0029c49ed3974sm15213877pjr.37.2024.04.26.20.33.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2024 20:33:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Question about netinet6/in6.h From: Bakul Shah In-Reply-To: <4AF50212-9141-44FF-937F-A06AF8B15121@karels.net> Date: Fri, 26 Apr 2024 20:33:03 -0700 Cc: Warner Losh , FreeBSD Net Content-Transfer-Encoding: quoted-printable Message-Id: <54E63C68-2713-4247-A57C-D3AA9C571327@iitbombay.org> References: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> <4AF50212-9141-44FF-937F-A06AF8B15121@karels.net> To: Mike Karels X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4VRFYH5zk0z4wWM > On Apr 26, 2024, at 5:02=E2=80=AFPM, Mike Karels = wrote: >=20 > On 26 Apr 2024, at 18:06, Warner Losh wrote: >=20 >> On Fri, Apr 26, 2024 at 4:21=E2=80=AFPM Mike Karels = wrote: >>=20 >>> On 26 Apr 2024, at 15:49, Mike Karels wrote: >>>=20 >>>> On 26 Apr 2024, at 15:01, Warner Losh wrote: >>>>=20 >>>>> This has to be a FAQ >>>>>=20 >>>>> I'm porting a program from Linux, I often see an error like: >>>>> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in >>> 'struct >>>>> in6_addr' >>>>> 95 | ipv6->sin6_addr.s6_addr32[3] =3D 0; >>>>> | ~~~~~~~~~~~~~~~ ^ >>>>> but yet, we kinda define them, but only for the kernel and boot = loader: >>>>> /* >>>>> * IPv6 address >>>>> */ >>>>> struct in6_addr { >>>>> union { >>>>> uint8_t __u6_addr8[16]; >>>>> uint16_t __u6_addr16[8]; >>>>> uint32_t __u6_addr32[4]; >>>>> } __u6_addr; /* 128-bit IP6 address */ >>>>> }; >>>>>=20 >>>>> #define s6_addr __u6_addr.__u6_addr8 >>>>> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */ >>>>> #define s6_addr8 __u6_addr.__u6_addr8 >>>>> #define s6_addr16 __u6_addr.__u6_addr16 >>>>> #define s6_addr32 __u6_addr.__u6_addr32 >>>>> #endif >>>>>=20 >>>>> I'm wondering if anybody why it's like that? git blame suggests we >>> imported >>>>> that from kame, with >>>>> only tweaks by people that are now deceased*.* >>>>>=20 >>>>> Why not just expose them? >>>>=20 >>>> Looks like only s6_addr is specified in the RFCs (2553 and 3493). = Oddly, >>>> though, the RFCs give an example implementation using that union = with >>>> different element names (like _S6_u8), and show the one #define. >>>> Similarly, POSIX specifies only s6_addr, but it allows other = members >>>> of the structure, so I don't see a problem with exposing them all = even >>>> in a POSIX environment. >>>>=20 >>>> I would have no objection to exposing all four definitions, = especially >>>> if Linux apps use them. >>>=20 >>> I put the change, along with an explanatory comment, in >>> https://reviews.freebsd.org/D44979. Comments welcome. >>>=20 >>=20 >> Thanks! I was testing a similar change, but I like yours better... = though >> maybe >> we should just make it visible when __BSD_VISIBLE is true.... I'll = have to >> look >> closely at what Linux does here... I think they have it always = visible, or >> at least >> musl does that (glibc is harder to track down due to the many layers = of >> indirection). >=20 > I thought briefly about __BSD_VISIBLE, but wasn't sure it was = necessary. > Let me know what you find out. I think it should work either way; = in.h > includes cdefs.h, so it's guaranteed to have been included. If the -ms-extensions option is used with gcc or clang, this ugliness = can go away as you can have nested anonymous unions or -structs and their = fields can be referenced as if they're directly in the parent struct/union. [IIRC this was present in Plan9 C from very early on. Also in C11 or = later]= From nobody Sat Apr 27 03:41:09 2024 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 4VRFkX5yTJz5HNxW for ; Sat, 27 Apr 2024 03:41:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VRFkX4BtVz4xFK for ; Sat, 27 Apr 2024 03:41:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-5194cebd6caso3160963e87.0 for ; Fri, 26 Apr 2024 20:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1714189281; x=1714794081; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5DDExenNDBuaf3HKgQL9K2hH0NwCrzu/dyoTcGztwq8=; b=S59bXXNxprMFgj4sc5+yb6NNtAmNBoQr5TWMk4MzIsmrIaH2k90q+qRaTbTBiqqdLh q4AEG4nrlwinkkt0AYvIXeM0WNkxh0jS3ub5abLwJQLhjk62o3nGkcfM4BmwEsbV3D3/ Ie7n2girW49p7w0fA9o55jYLcdHVrd/7FdIkuDqucRg8xThejnAyPYXkRrTxVgb/x0K6 s8xEkYjpMZhc67OtRCWzmOFOHPqDlEvKakAHjRa2ekmx/AYc2heCvBQVCvSmqiT+ETBZ HaLFAmrymWl8qLHCNfiVFvJzhV00OTD2Wb477Q1pCnxsSobD8tJY1iBaieMg8uu9EZoy tX2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714189281; x=1714794081; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5DDExenNDBuaf3HKgQL9K2hH0NwCrzu/dyoTcGztwq8=; b=fcfbTupmHnQZbCYTQOgxukMUPS7N91tcgBtVmdI3duFCBu79NYmwR/73kwEakCMSXs bZ3hc1YwM4SKLRpX01FtQa6FplvugQAk4c/5APNSIBX5cmWRssGn7/lOlfpp7Bmrnl1H 3LRwhdmqmfIOwGewv1O896MoZn2Vi6TZpoVGb9ymcCEdML1Wjc3FHU12R/LoTHCSIHQt Fa4izGzkzSTSyIYXKlRg3HnxcoFThmr38ODP6bDVn6dsiUHuccH4Pd1e6xruftsRZtUI mmCsP0J7nXaw9KES33TAanFUHV/MKuHyYpYevquJEJtnI2sGmbFDUZchg0+Owp9uZlcP Ex9Q== X-Forwarded-Encrypted: i=1; AJvYcCUrsGGz8DoKmG4idmDEqkPw5++RFizGAhFwygOXESLbiLDMiYRxzMBcropUGJPwU/LeDRcPpEXxYXR4KhmkhtrwhPDfEshlNw== X-Gm-Message-State: AOJu0YzIPrX7KdJ3KwQJdQ9EEorWVPth44ASpzgvOGyuXdjtS+B+N7fu xi2eSWXse9Zd5xcjz0+uHBP9wiE/Qrhw9AN/6EmNljCwfLVArEGvfXD5fE6nzMm8pJON46ngo9T 95B1GppW1KXA5Qj10R13jJPfQjKuv5Kci8+wnx71PFKCRAgau X-Google-Smtp-Source: AGHT+IGkTZaPaBuH47AgnNUcYWKd1CtwQmFVseug4jxUCxg858lHTacP74c+rVY5dEk6EyM8uSXZGz3BvbSGMuLrBrI= X-Received: by 2002:a19:e017:0:b0:51b:e46c:19fc with SMTP id x23-20020a19e017000000b0051be46c19fcmr2651312lfg.58.1714189281459; Fri, 26 Apr 2024 20:41:21 -0700 (PDT) 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 References: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> <4AF50212-9141-44FF-937F-A06AF8B15121@karels.net> <54E63C68-2713-4247-A57C-D3AA9C571327@iitbombay.org> In-Reply-To: <54E63C68-2713-4247-A57C-D3AA9C571327@iitbombay.org> From: Warner Losh Date: Fri, 26 Apr 2024 21:41:09 -0600 Message-ID: Subject: Re: Question about netinet6/in6.h To: Bakul Shah Cc: Mike Karels , FreeBSD Net Content-Type: multipart/alternative; boundary="00000000000033267b06170bcb31" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4VRFkX4BtVz4xFK --00000000000033267b06170bcb31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2024, 9:33=E2=80=AFPM Bakul Shah wrot= e: > > > > On Apr 26, 2024, at 5:02=E2=80=AFPM, Mike Karels wrot= e: > > > > On 26 Apr 2024, at 18:06, Warner Losh wrote: > > > >> On Fri, Apr 26, 2024 at 4:21=E2=80=AFPM Mike Karels = wrote: > >> > >>> On 26 Apr 2024, at 15:49, Mike Karels wrote: > >>> > >>>> On 26 Apr 2024, at 15:01, Warner Losh wrote: > >>>> > >>>>> This has to be a FAQ > >>>>> > >>>>> I'm porting a program from Linux, I often see an error like: > >>>>> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in > >>> 'struct > >>>>> in6_addr' > >>>>> 95 | ipv6->sin6_addr.s6_addr32[3] =3D 0; > >>>>> | ~~~~~~~~~~~~~~~ ^ > >>>>> but yet, we kinda define them, but only for the kernel and boot > loader: > >>>>> /* > >>>>> * IPv6 address > >>>>> */ > >>>>> struct in6_addr { > >>>>> union { > >>>>> uint8_t __u6_addr8[16]; > >>>>> uint16_t __u6_addr16[8]; > >>>>> uint32_t __u6_addr32[4]; > >>>>> } __u6_addr; /* 128-bit IP6 address */ > >>>>> }; > >>>>> > >>>>> #define s6_addr __u6_addr.__u6_addr8 > >>>>> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */ > >>>>> #define s6_addr8 __u6_addr.__u6_addr8 > >>>>> #define s6_addr16 __u6_addr.__u6_addr16 > >>>>> #define s6_addr32 __u6_addr.__u6_addr32 > >>>>> #endif > >>>>> > >>>>> I'm wondering if anybody why it's like that? git blame suggests we > >>> imported > >>>>> that from kame, with > >>>>> only tweaks by people that are now deceased*.* > >>>>> > >>>>> Why not just expose them? > >>>> > >>>> Looks like only s6_addr is specified in the RFCs (2553 and 3493). > Oddly, > >>>> though, the RFCs give an example implementation using that union wit= h > >>>> different element names (like _S6_u8), and show the one #define. > >>>> Similarly, POSIX specifies only s6_addr, but it allows other members > >>>> of the structure, so I don't see a problem with exposing them all ev= en > >>>> in a POSIX environment. > >>>> > >>>> I would have no objection to exposing all four definitions, especial= ly > >>>> if Linux apps use them. > >>> > >>> I put the change, along with an explanatory comment, in > >>> https://reviews.freebsd.org/D44979. Comments welcome. > >>> > >> > >> Thanks! I was testing a similar change, but I like yours better... > though > >> maybe > >> we should just make it visible when __BSD_VISIBLE is true.... I'll hav= e > to > >> look > >> closely at what Linux does here... I think they have it always visible= , > or > >> at least > >> musl does that (glibc is harder to track down due to the many layers o= f > >> indirection). > > > > I thought briefly about __BSD_VISIBLE, but wasn't sure it was necessary= . > > Let me know what you find out. I think it should work either way; in.h > > includes cdefs.h, so it's guaranteed to have been included. > > If the -ms-extensions option is used with gcc or clang, this ugliness can > go away as you can have nested anonymous unions or -structs and their > fields > can be referenced as if they're directly in the parent struct/union. > > [IIRC this was present in Plan9 C from very early on. Also in C11 or late= r] True. In fact c11 and newer doesn't need anything on the command line here. If it were only in the kernel then I'd chamge it like thay while I was here... but lots of code in ports will specify c99 + POSIX 2001 and to compile there your only hope is this construct.... Warner --00000000000033267b06170bcb31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 26, 2024, 9:33=E2=80=AFPM Bakul Shah <<= a href=3D"mailto:bakul@iitbombay.org">bakul@iitbombay.org> wrote:


> On Apr 26, 2024, at 5:02=E2=80=AFPM, Mike Karels <mike@karels.net&= gt; wrote:
>
> On 26 Apr 2024, at 18:06, Warner Losh wrote:
>
>> On Fri, Apr 26, 2024 at 4:21=E2=80=AFPM Mike Karels <mike@karels.n= et> wrote:
>>
>>> On 26 Apr 2024, at 15:49, Mike Karels wrote:
>>>
>>>> On 26 Apr 2024, at 15:01, Warner Losh wrote:
>>>>
>>>>> This has to be a FAQ
>>>>>
>>>>> I'm porting a program from Linux, I often see an e= rror like:
>>>>> ./test/mock-ifaddrs.c:95:19: error: no member named &#= 39;s6_addr32' in
>>> 'struct
>>>>> in6_addr'
>>>>>=C2=A0 =C2=A095 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0ipv6->sin6_addr.s6_addr32[3] =3D 0;
>>>>>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0~~~~~~~~~~~~~~~ ^
>>>>> but yet, we kinda define them, but only for the kernel= and boot loader:
>>>>> /*
>>>>> * IPv6 address
>>>>> */
>>>>> struct in6_addr {
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 union {
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= uint8_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__u6_addr8[16];
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= uint16_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 __u6_addr16[8];
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= uint32_t=C2=A0 =C2=A0 =C2=A0 =C2=A0 __u6_addr32[4];
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 } __u6_addr;=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 128-bit IP6 addr= ess */
>>>>> };
>>>>>
>>>>> #define s6_addr=C2=A0 =C2=A0__u6_addr.__u6_addr8
>>>>> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX no= nstandard */
>>>>> #define s6_addr8=C2=A0 __u6_addr.__u6_addr8
>>>>> #define s6_addr16 __u6_addr.__u6_addr16
>>>>> #define s6_addr32 __u6_addr.__u6_addr32
>>>>> #endif
>>>>>
>>>>> I'm wondering if anybody why it's like that? g= it blame suggests we
>>> imported
>>>>> that from kame, with
>>>>> only tweaks by people that are now deceased*.*
>>>>>
>>>>> Why not just expose them?
>>>>
>>>> Looks like only s6_addr is specified in the RFCs (2553 and= 3493).=C2=A0 Oddly,
>>>> though, the RFCs give an example implementation using that= union with
>>>> different element names (like _S6_u8), and show the one #d= efine.
>>>> Similarly, POSIX specifies only s6_addr, but it allows oth= er members
>>>> of the structure, so I don't see a problem with exposi= ng them all even
>>>> in a POSIX environment.
>>>>
>>>> I would have no objection to exposing all four definitions= , especially
>>>> if Linux apps use them.
>>>
>>> I put the change, along with an explanatory comment, in
>>> https://reviews.freebsd.org/D44979.=C2= =A0 Comments welcome.
>>>
>>
>> Thanks! I was testing a similar change, but I like yours better...= though
>> maybe
>> we should just make it visible when __BSD_VISIBLE is true.... I= 9;ll have to
>> look
>> closely at what Linux does here... I think they have it always vis= ible, or
>> at least
>> musl does that (glibc is harder to track down due to the many laye= rs of
>> indirection).
>
> I thought briefly about __BSD_VISIBLE, but wasn't sure it was nece= ssary.
> Let me know what you find out.=C2=A0 I think it should work either way= ; in.h
> includes cdefs.h, so it's guaranteed to have been included.

If the -ms-extensions option is used with gcc or clang, this ugliness can go away as you can have nested anonymous unions or -structs and their field= s
can be referenced as if they're directly in the parent struct/union.
[IIRC this was present in Plan9 C from very early on. Also in C11 or later]=

True= . In fact c11 and newer doesn't need anything on the command line here.= If it were only in the kernel then I'd chamge it like thay while I was= here... but lots of code in ports will specify c99 + POSIX 2001 and to com= pile there your only hope is this construct....

=
Warner=C2=A0
--00000000000033267b06170bcb31-- From nobody Sat Apr 27 04:02:34 2024 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 4VRGCD4rJzz5HRR2 for ; Sat, 27 Apr 2024 04:02:48 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VRGCD2ljPz51bg for ; Sat, 27 Apr 2024 04:02:48 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-2a519ac18b3so2171946a91.2 for ; Fri, 26 Apr 2024 21:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1714190566; x=1714795366; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QC78cVQehSmRCqqBIDPPJJbcO64W/t789ZC7YOT2+pE=; b=gh58B3baXekK5lLCwrke0by8H9tDk95jOdwmdQM0/tUu6s+CjzowG2/MWD2BU9r7ft iYotlD1cr8q2Avkp8F+JB5xYYIBt1G4odi6lAW4ZSJsi+XIU2qCXRIZtqNhBRVmxNTFy djd7EN3p091GFVmI8kGsJmWTymhQ7cSAimmMrhfcj3MhtKWJz0oaVODGka85y+VP8w2+ 6MvRMY3QqC7GppoA4Bc22bN8B9vDabstjkXBctv4wNfXt/T51opqQklAkVuI7RFy1/35 V8JOcOCyKCy+T0FBk1FTwLsLF8oVFBj3JA/8k3JDSbtFj/L4AHKI2oS/YX2w4/Vq36L3 MWPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714190566; x=1714795366; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QC78cVQehSmRCqqBIDPPJJbcO64W/t789ZC7YOT2+pE=; b=Hd6NJYyh7hS7ujhZoPLwgrYXr4LkIlz7Qps6TZ7GgPZjmraRA0e8bDDGdLDbKwoEz8 RY3kaOt7inMejwTLjAapRC3Sn7J8TUlc/u+qxqJN7CXevlcgQojyPd1DeEQ+tBa3qxGQ hjzEjK0q5t6ADcLa/KFxb2J45o1RU6wGW6ejTIMREKYU8+lC0ou0aOe2DDdivT2nJmmB VFsy4rEMFiUagbeeJbp4RiUDOwKJQIwpzNW9+hs0iNe+dQwMAPVerhJZpPeX3uHWs70Q hXfseav1i58CXl/d+qz4w3FDMhg3KFkYFhyzWhwk4pYL/5jkNwdEP1OZu0n8EOJP/bh2 ePKQ== X-Forwarded-Encrypted: i=1; AJvYcCUJofKH8vJgp2/TwsSxfiRKdunFT4a7EiXy8d8yctpGZY8Rqx/gKDIKyZiR9KOoGUzZJdQ6z2QDmYdgLumBIDRxsNV2c/KwbA== X-Gm-Message-State: AOJu0YwcPwtSjJadt0HgjJS34XNIn+etiTMZjwD5xm5pakEt0w8zUEge sZUG0DePePQEWjBpSpMgZ5mpDGHYOn60FIOUsaTd5uRNXyoQfzP1GqHOuPdlwzK2Nmcek/yWEH8 = X-Google-Smtp-Source: AGHT+IFKM3llvtaXGvtRgr6/5hL+BQCOYeaSCAEVEpM3N8GF+f2LXLO+i53Y2ElkmffezKNtPbTlTw== X-Received: by 2002:a17:90b:310f:b0:29b:c2b3:2712 with SMTP id gc15-20020a17090b310f00b0029bc2b32712mr4721144pjb.26.1714190566454; Fri, 26 Apr 2024 21:02:46 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id y10-20020a17090ad70a00b002a63e966fd7sm15256858pju.47.2024.04.26.21.02.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2024 21:02:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: Question about netinet6/in6.h From: Bakul Shah In-Reply-To: Date: Fri, 26 Apr 2024 21:02:34 -0700 Cc: Mike Karels , FreeBSD Net Content-Transfer-Encoding: quoted-printable Message-Id: References: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> <4AF50212-9141-44FF-937F-A06AF8B15121@karels.net> <54E63C68-2713-4247-A57C-D3AA9C571327@iitbombay.org> To: Warner Losh X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4VRGCD2ljPz51bg On Apr 26, 2024, at 8:41=E2=80=AFPM, Warner Losh wrote: >=20 >=20 >=20 > On Fri, Apr 26, 2024, 9:33=E2=80=AFPM Bakul Shah = wrote: >=20 >=20 > > On Apr 26, 2024, at 5:02=E2=80=AFPM, Mike Karels = wrote: > >=20 > > On 26 Apr 2024, at 18:06, Warner Losh wrote: > >=20 > >> On Fri, Apr 26, 2024 at 4:21=E2=80=AFPM Mike Karels = wrote: > >>=20 > >>> On 26 Apr 2024, at 15:49, Mike Karels wrote: > >>>=20 > >>>> On 26 Apr 2024, at 15:01, Warner Losh wrote: > >>>>=20 > >>>>> This has to be a FAQ > >>>>>=20 > >>>>> I'm porting a program from Linux, I often see an error like: > >>>>> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' = in > >>> 'struct > >>>>> in6_addr' > >>>>> 95 | ipv6->sin6_addr.s6_addr32[3] =3D 0; > >>>>> | ~~~~~~~~~~~~~~~ ^ > >>>>> but yet, we kinda define them, but only for the kernel and boot = loader: > >>>>> /* > >>>>> * IPv6 address > >>>>> */ > >>>>> struct in6_addr { > >>>>> union { > >>>>> uint8_t __u6_addr8[16]; > >>>>> uint16_t __u6_addr16[8]; > >>>>> uint32_t __u6_addr32[4]; > >>>>> } __u6_addr; /* 128-bit IP6 address */ > >>>>> }; > >>>>>=20 > >>>>> #define s6_addr __u6_addr.__u6_addr8 > >>>>> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard = */ > >>>>> #define s6_addr8 __u6_addr.__u6_addr8 > >>>>> #define s6_addr16 __u6_addr.__u6_addr16 > >>>>> #define s6_addr32 __u6_addr.__u6_addr32 > >>>>> #endif > >>>>>=20 > >>>>> I'm wondering if anybody why it's like that? git blame suggests = we > >>> imported > >>>>> that from kame, with > >>>>> only tweaks by people that are now deceased*.* > >>>>>=20 > >>>>> Why not just expose them? > >>>>=20 > >>>> Looks like only s6_addr is specified in the RFCs (2553 and 3493). = Oddly, > >>>> though, the RFCs give an example implementation using that union = with > >>>> different element names (like _S6_u8), and show the one #define. > >>>> Similarly, POSIX specifies only s6_addr, but it allows other = members > >>>> of the structure, so I don't see a problem with exposing them all = even > >>>> in a POSIX environment. > >>>>=20 > >>>> I would have no objection to exposing all four definitions, = especially > >>>> if Linux apps use them. > >>>=20 > >>> I put the change, along with an explanatory comment, in > >>> https://reviews.freebsd.org/D44979. Comments welcome. > >>>=20 > >>=20 > >> Thanks! I was testing a similar change, but I like yours better... = though > >> maybe > >> we should just make it visible when __BSD_VISIBLE is true.... I'll = have to > >> look > >> closely at what Linux does here... I think they have it always = visible, or > >> at least > >> musl does that (glibc is harder to track down due to the many = layers of > >> indirection). > >=20 > > I thought briefly about __BSD_VISIBLE, but wasn't sure it was = necessary. > > Let me know what you find out. I think it should work either way; = in.h > > includes cdefs.h, so it's guaranteed to have been included. >=20 > If the -ms-extensions option is used with gcc or clang, this ugliness = can > go away as you can have nested anonymous unions or -structs and their = fields > can be referenced as if they're directly in the parent struct/union. >=20 > [IIRC this was present in Plan9 C from very early on. Also in C11 or = later] >=20 > True. In fact c11 and newer doesn't need anything on the command line = here. If it were only in the kernel then I'd chamge it like thay while I = was here... but lots of code in ports will specify c99 + POSIX 2001 and = to compile there your only hope is this construct.... Such defines were typically within #if defined(KERNEL) .. #endif so non-kld ports shouldn't be referring to them, right?! From nobody Sat Apr 27 11:57:41 2024 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 4VRSlD6Dnpz5JS4F for ; Sat, 27 Apr 2024 11:57:44 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VRSlD3wnmz4ZxC for ; Sat, 27 Apr 2024 11:57:44 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.18.1/8.18.1) with ESMTP id 43RBvfei088714; Sat, 27 Apr 2024 06:57:42 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1714219062; bh=poslSk6EHAklAm+2a0+JG4XeoCAJBdp2hAb0O7Xr660=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=eZ9OeJkca7Cdj7LFZ4iupu9JT3ShY0osvwtYR2N/4AWvNHQzTLh13aquyWRa9NpfC iA931Tc0QK3Vmhz5wfRxzNKIgCbMatwpsGoWZS1TQ5jC0uQk3vSgiyjgmapzttGzST vAG3o5sz54ZQViY7BI8CWHGPXfe+CxUTFZ55NBNpJLS5GvEh3Qja8vsrdNAWLeTiLU xj4W0MapsbhhS9ecM44uY2v4Vb3uOwpwrC8np17KY2qyRdjzQloqNseF50fXOvieeU MAplksVEdyRwhnePhqvCZpzWv9Y+0kDb5ugGRXhWk/pCl+YI3C+Vdt2Nhf7kAW9oxn YtYiFd/7MaP3Q== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id HZUPNzXoLGaIWgEAs/W3XQ (envelope-from ); Sat, 27 Apr 2024 06:57:41 -0500 From: Mike Karels To: Bakul Shah Cc: Warner Losh , FreeBSD Net Subject: Re: Question about netinet6/in6.h Date: Sat, 27 Apr 2024 06:57:41 -0500 X-Mailer: MailMate (1.14r6028) Message-ID: <03AAFE2A-8BCE-4E5E-8510-1D5AB58AC363@karels.net> In-Reply-To: References: <229EB3F8-FB68-461C-BF1F-3B2846510EBA@karels.net> <4AF50212-9141-44FF-937F-A06AF8B15121@karels.net> <54E63C68-2713-4247-A57C-D3AA9C571327@iitbombay.org> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Queue-Id: 4VRSlD3wnmz4ZxC On 26 Apr 2024, at 23:02, Bakul Shah wrote: > On Apr 26, 2024, at 8:41=E2=80=AFPM, Warner Losh wrote= : >> >> >> >> On Fri, Apr 26, 2024, 9:33=E2=80=AFPM Bakul Shah = wrote: >> >> >>> On Apr 26, 2024, at 5:02=E2=80=AFPM, Mike Karels wr= ote: >>> >>> On 26 Apr 2024, at 18:06, Warner Losh wrote: >>> >>>> On Fri, Apr 26, 2024 at 4:21=E2=80=AFPM Mike Karels wrote: >>>> >>>>> On 26 Apr 2024, at 15:49, Mike Karels wrote: >>>>> >>>>>> On 26 Apr 2024, at 15:01, Warner Losh wrote: >>>>>> >>>>>>> This has to be a FAQ >>>>>>> >>>>>>> I'm porting a program from Linux, I often see an error like: >>>>>>> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' i= n >>>>> 'struct >>>>>>> in6_addr' >>>>>>> 95 | ipv6->sin6_addr.s6_addr32[3] =3D 0; >>>>>>> | ~~~~~~~~~~~~~~~ ^ >>>>>>> but yet, we kinda define them, but only for the kernel and boot l= oader: >>>>>>> /* >>>>>>> * IPv6 address >>>>>>> */ >>>>>>> struct in6_addr { >>>>>>> union { >>>>>>> uint8_t __u6_addr8[16]; >>>>>>> uint16_t __u6_addr16[8]; >>>>>>> uint32_t __u6_addr32[4]; >>>>>>> } __u6_addr; /* 128-bit IP6 address */ >>>>>>> }; >>>>>>> >>>>>>> #define s6_addr __u6_addr.__u6_addr8 >>>>>>> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard *= / >>>>>>> #define s6_addr8 __u6_addr.__u6_addr8 >>>>>>> #define s6_addr16 __u6_addr.__u6_addr16 >>>>>>> #define s6_addr32 __u6_addr.__u6_addr32 >>>>>>> #endif >>>>>>> >>>>>>> I'm wondering if anybody why it's like that? git blame suggests w= e >>>>> imported >>>>>>> that from kame, with >>>>>>> only tweaks by people that are now deceased*.* >>>>>>> >>>>>>> Why not just expose them? >>>>>> >>>>>> Looks like only s6_addr is specified in the RFCs (2553 and 3493). = Oddly, >>>>>> though, the RFCs give an example implementation using that union w= ith >>>>>> different element names (like _S6_u8), and show the one #define. >>>>>> Similarly, POSIX specifies only s6_addr, but it allows other membe= rs >>>>>> of the structure, so I don't see a problem with exposing them all = even >>>>>> in a POSIX environment. >>>>>> >>>>>> I would have no objection to exposing all four definitions, especi= ally >>>>>> if Linux apps use them. >>>>> >>>>> I put the change, along with an explanatory comment, in >>>>> https://reviews.freebsd.org/D44979. Comments welcome. >>>>> >>>> >>>> Thanks! I was testing a similar change, but I like yours better... t= hough >>>> maybe >>>> we should just make it visible when __BSD_VISIBLE is true.... I'll h= ave to >>>> look >>>> closely at what Linux does here... I think they have it always visib= le, or >>>> at least >>>> musl does that (glibc is harder to track down due to the many layers= of >>>> indirection). >>> >>> I thought briefly about __BSD_VISIBLE, but wasn't sure it was necessa= ry. >>> Let me know what you find out. I think it should work either way; in= =2Eh >>> includes cdefs.h, so it's guaranteed to have been included. >> >> If the -ms-extensions option is used with gcc or clang, this ugliness = can >> go away as you can have nested anonymous unions or -structs and their = fields >> can be referenced as if they're directly in the parent struct/union. >> >> [IIRC this was present in Plan9 C from very early on. Also in C11 or l= ater] >> >> True. In fact c11 and newer doesn't need anything on the command line = here. If it were only in the kernel then I'd chamge it like thay while I = was here... but lots of code in ports will specify c99 + POSIX 2001 and t= o compile there your only hope is this construct.... > > Such defines were typically within #if defined(KERNEL) .. #endif > so non-kld ports shouldn't be referring to them, right?! I don't know if that is typical, but in this case the point is to make it= visible to user level. We don't expect base/ports to do that currently, but imported programs will. Mike From nobody Sun Apr 28 21:00:37 2024 X-Original-To: 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 4VSJlB2HJbz5JxHT for ; Sun, 28 Apr 2024 21:00:38 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VSJl95s5dz4HB0 for ; Sun, 28 Apr 2024 21:00:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1714338037; a=rsa-sha256; cv=none; b=bF+vmeuV+nsakw7XJwaJH2cl+ElhFWF5pnDRHLTDoM73rCU9TaONpBgIMOhjPgYamx5p6V co90pQXwpQi6Q41vEqROL5sGg1ht0shYfTAvzSeAidXp/iQ1dRrHkqAs40qjGT6alzIdXE xBIhsmxyFRXVP2gzsuEIaXfZLk4xBvPmiFNF5OaHS0Sk8b/kYNbxCrmdArphq+K+CPN0sa G+tEHVwsyAcuz5M7PSEsZiJeiuz0BWT7mWov1+NrDZ8o+Cmn7Bis5n1wmklO0FD07cDPIo ddjfhZ0/WrPVm3fsubuPiAjzTsmF1ihdIK1PY+5F+sQl156i3MFXf+8ExW/aug== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714338037; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=uMcyshPCSmm9dJdcSLR4GbIKpJdmkeSELJEjyToOHSw=; b=LKHLbGFCK6q31TN9ymQozcKkt5DjFecXebxyfZzUqXSFmE8YQI5S3p8APRXvwBMdAEbh2t lr/0z8cY4wQA9BcrxL+YVZbGBi5WUldxggMcK8ilRd8hGStG9o67aDO5mg4tobt/egEFpM 66sXOpO/ME34qwj9Hy5YnPuT62J3O1hjANomFNieAk7N3DOSii1QuKOJKp/A4H1smbOoed JzsbDDPhR+YQt9Pdoy+xzpoUy5MX1hXcRd6uRtuIQJWXfvbcD9B2X0/vUo6RzNX1wHMbLV 0irZ4rclt8qZYUBcCWXCa/pJifgZoA9rDc+H0g50W0M5Y9OPPQWpAFrU4OsoNg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4VSJl95469zh6H for ; Sun, 28 Apr 2024 21:00:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 43SL0bch043659 for ; Sun, 28 Apr 2024 21:00:37 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43SL0bIt043657 for net@FreeBSD.org; Sun, 28 Apr 2024 21:00:37 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202404282100.43SL0bIt043657@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: net@FreeBSD.org Subject: Problem reports for net@FreeBSD.org that need special attention Date: Sun, 28 Apr 2024 21:00:37 +0000 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 Content-Type: multipart/alternative; boundary="17143380374.77ba0C.37807" Content-Transfer-Encoding: 7bit --17143380374.77ba0C.37807 Date: Sun, 28 Apr 2024 21:00:37 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 254445 | cloned_interfaces="bridge0" does not respect net. Open | 166724 | if_re(4): watchdog timeout Open | 200836 | iovctl(8): Return descriptions in the returned sc Open | 223824 | Panic in ng_base.c (netgraph) Open | 232472 | ixgbe(4): SR-IOV passthru not working on Hyper-V Open | 234073 | ixl(4): Host X710-DA2 drops connect starting bhyv Open | 241106 | tun/ppp: panic: vm_fault: fault on nofault entry Open | 245981 | bnxt(4): BCM57414 / BCM57416 not initializing: bn Open | 256217 | [tcp] High system load because of interrupts with Open | 257038 | em(4): Panic on HTTP traffic to or from jail thro Open | 257286 | gateway with `ping -6 -e` is ignored Open | 258623 | cxgbe(4): Slow routing performance: 2 numa domain Open | 258850 | lagg(4): interface vanishes when both member inte Open | 261866 | ixgbe(4): Resets media type -> autoselect after s Open | 262024 | em(4): iflib handles bad packets incorrectly Open | 262093 | ixl(4): RX packet errors on Intel X710 after 12.2 Open | 263568 | ix(4): SR-IOV connection lost after loading VM wi In Progress | 118111 | rc: network.subr Add MAC address based interface 18 problems total for which you should take action. --17143380374.77ba0C.37807 Date: Sun, 28 Apr 2024 21:00:37 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
New         |    254445 | cloned_interfaces="bridge0" does not respect net.
Open        |    166724 | if_re(4): watchdog timeout
Open        |    200836 | iovctl(8): Return descriptions in the returned sc
Open        |    223824 | Panic in ng_base.c (netgraph)
Open        |    232472 | ixgbe(4): SR-IOV passthru not working on Hyper-V 
Open        |    234073 | ixl(4): Host X710-DA2 drops connect starting bhyv
Open        |    241106 | tun/ppp: panic: vm_fault: fault on nofault entry 
Open        |    245981 | bnxt(4): BCM57414 / BCM57416 not initializing: bn
Open        |    256217 | [tcp] High system load because of interrupts with
Open        |    257038 | em(4): Panic on HTTP traffic to or from jail thro
Open        |    257286 | gateway with `ping -6 -e` is ignored
Open        |    258623 | cxgbe(4): Slow routing performance: 2 numa domain
Open        |    258850 | lagg(4): interface vanishes when both member inte
Open        |    261866 | ixgbe(4): Resets media type -> autoselect after s
Open        |    262024 | em(4): iflib handles bad packets incorrectly
Open        |    262093 | ixl(4): RX packet errors on Intel X710 after 12.2
Open        |    263568 | ix(4): SR-IOV connection lost after loading VM wi
In Progress |    118111 | rc: network.subr Add MAC address based interface 

18 problems total for which you should take action.
--17143380374.77ba0C.37807--