From nobody Mon Sep 15 02:31:42 2025 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 4cQ8Db0VpLz67slg for ; Mon, 15 Sep 2025 02:31:43 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQ8DZ61N8z3q4h for ; Mon, 15 Sep 2025 02:31:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757903502; 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=TYTj67M6sU8eoPhOh+Cmr4Ia3aF+B/uBF2icu4ZoPw0=; b=YE4/BdMNti7Ta79TVze/SytRK3r90w0n5eHX5xxDMHzJjj3iVplouXNXOAs/JV3eImM4cq 5ONOL+gqZ1w7NlhM+2uVPPS7ePTrGBiCFGwoX0ql0HDFGv4mqPpaQMxTi6B7MMHPaH/OtT bVcQaNEcAXkYZWEN/9nMbYBoiI+BMNrK8yRfnCxaKiwen/3+cojY34fr0R077bEjhst0N8 AA9AvW57By0heZ/Lv2SOa7M9ZU+zNdPC9+wSxeEWcVrbyBK7TI72is8vmtUFdnwGA48wkN Sxnx1TJg050Xpj5XGFiw5fQZkknoNglk0CZBsDHIWmBSwTyo3Z4UWrhvjqooEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757903502; 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=TYTj67M6sU8eoPhOh+Cmr4Ia3aF+B/uBF2icu4ZoPw0=; b=rZhH3fVuom9URnWq3f3rjn1Fd+SCz7gysJXkmPqvpr9bTcc6k7yYAexOIR8c9Okxi06KS/ OEQSzJAeGVa8D5NTVoignULcUR8RA4E5YIrhOZzhcPJO0qJ7gNNEQbEvw4XBB1uHYW8pmN Y2ncr4eOnga3W9yjgeUzPuMPVPd8GnB4yznwCQ5E28ftprRqlq+gA4C6uK087/L48XOJXp d1iPZWutt1pccicCwXX/XEBs3OmTjkObZJvrbXwH6g6S0VJYJhOzj9nnRBDaPQpBCI6sad AV6D3dVd5FAzcXxNr4OpFS2+ZBY8CL3u7gDLNe3uM9sXuOWzlN9MQiv8FRpbzw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757903502; a=rsa-sha256; cv=none; b=ZknmdYUPRf4WCnX36VLxcBzqVags+6DUQWNqoaA6rAaNG2BT1iJN3gNmSC7DBa6DVf9hTg TEDXjsYOb0qyLEIg2HnCrKSkTfG5wYkDgz6ZO+eGkwVmOST/7e32ZudCJoik3QwgcAF6Gm 3GHNrFP/qY+Hqt3fk08nfRSSng3szBdlMevTl4ZSq+uMawW0R9IJuYsUV/LfnD7U/Sq2nq Gyn+SiqYavbPKMw+/UaPb8ajXq2uBj6N6ach26E33e9nZYqqjjkie2uul1rMTFybMrTZHr IfLPcQo3iowyOlVwnei2W+CJYF7/TgsCcZFQqktDGTWxJByA2qdhH6aM4Q8vsA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4cQ8DZ5G71zcHf for ; Mon, 15 Sep 2025 02:31:42 +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 58F2VgM4072608 for ; Mon, 15 Sep 2025 02:31:42 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58F2VgWk072607 for net@FreeBSD.org; Mon, 15 Sep 2025 02:31:42 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 289545] No option to disable NOMAP leads to network down/up with em0 when starting bridge. Date: Mon, 15 Sep 2025 02:31:42 +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.5-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: spork@bway.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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=3D289545 --- Comment #4 from spork@bway.net --- this feels like a lot of words to discredit that this has a large impact on people that run lots of virtualized things. The reason some were asking for= a toggle was to let the "it's not a problem" crowd carry on while those who f= ound it not acceptable for their environment could change the behavior from defa= ult. In a server environment, it's not really an option to be either a) swapping= out all your servers or b) adding new ethernet cards to expensive 1U servers th= at already include a high quality pair of NICs that operate fine under other O= Ses. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Sep 15 04:22:06 2025 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 4cQBgy6dTqz681Sj for ; Mon, 15 Sep 2025 04:22:06 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQBgy69fRz48GD for ; Mon, 15 Sep 2025 04:22:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757910126; 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=SuwAVePhsaLjmVnRTuzWrGnQJsqcPSIoLW7VsikPq6g=; b=AJlRcJZoBrhh60kXgZ5fr+7k6B0jeTXh0T68jZ7bVrdm32xmxhqWh2Lh+uSsASlXQCRrjI hRvGPHHaxkbnmVUveKGAp6pn9HUpqsb7xOkDsEV0NRWcDIqtUIJZj3t/8i4ujDFLktfqac vgS9v53xiLogLQpnLW7QvQOaexs14nuZYQz2skoCGGfcVDUY+xJmYwUt2vdrQ6oUnKjTOM RCoVoeUVymE3tONNAqkV91uJPX0GBWBjv+O38UiVpBPaCqrjn25fzT0nWJ8ROYeSlX2hIM q2mPrWdMOkXtsVqtoStLbXI9Z+tqJg1T3uOhpacpGX+wUuCuLEjA999Ssqx7EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757910126; 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=SuwAVePhsaLjmVnRTuzWrGnQJsqcPSIoLW7VsikPq6g=; b=YTWW/pciwU357dcKzELU1Gs42F4p4U0NYYmRG9560Rk2ltu9L/+wzpNvBSbDZgQHr5LPsW pYivM0c66C7+W6cwBJSztwDmt8n/MKBAwICHocuxNIr4T3BDGqcR/NM3wl9jDtq9pKEjpN A7qTr5QQ7GlNIkXCYzxJJ78LMUIF22LNICAzI4QjFvga59IM3gdPNFcA4vfsqjuCtJf6EQ KHGHK7zpx8AmNu2ZO/ORSP7oWn74pHLxH2ui0VKAH5AbsMor6OEUrDHgU6dv5Sduz7jO7x qrHfGsdowqI2PLtZaq59gzyRSJ2HH1oZhpGKr4OuGL2N7BxhOUc5Gg5Pht6bog== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757910126; a=rsa-sha256; cv=none; b=OzcqWZM+pJZqg+NU8CQ8cVRz2Y2m23KWQtuKTOOYSBvsdB1BIEwKI7yfkWB+RUeWGNUymh TNuM5ZeFKuP4PVnwCwnt42ia+2bcsXgkYzfFmi5GBcNHbljvZXOXjz3t+ZFRpmizkRIkDH AtJhrrfboRHStX5fxGz3+DBJNrcRQmHs/Y8j5oReSgXUBWTe688oa0UeDKYP4ThkBdgvx4 CH9h+W8YVzjbQY3dv44RCHU/XIx+BQUfFWry+KmMeC4goWptzIHHR31eZcRWCirjp60ZZX dwlV1wivZjtkpF1bf0mjQip0npG1Cz/+TMujvDx9xc4k2RBKBI2Wv8uC2QhV4Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4cQBgy5g8tzg3M for ; Mon, 15 Sep 2025 04:22:06 +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 58F4M6Cj049586 for ; Mon, 15 Sep 2025 04:22:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58F4M6u7049585 for net@FreeBSD.org; Mon, 15 Sep 2025 04:22:06 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 289612] divert(4) may not work correctly on gif(4) interface Date: Mon, 15 Sep 2025 04:22:06 +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: 14.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=3D289612 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Sep 15 10:07:20 2025 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 4cQLLL5y6pz68Mkl for ; Mon, 15 Sep 2025 10:07:22 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQLLL3rV1z3mfg for ; Mon, 15 Sep 2025 10:07:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757930842; 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=0632WX4JNGh3HfFwJRKBKd91z1z6F57dqm8TyqS/wGs=; b=CRv470SudxSALn10KM1XHjg2+4v9xtNc0BXB2V5dqqvn/DpeiZ5OGDcF6Fosl1N4HvWHLO GYOsDh9+MhFfAMroulwKp8QGsDi1xl6zi6mHsN4sra7JprJOPPN3s2qWkbMA1VDWGCXopG eSJIACwiVh2ry5aS8FQBiLwi9q0yv2vWTv8rvmbzRL1gJsFqlQQer9GlskJWkQNJQFmSuj /UJ+DAOUUfd+TIAusuluiNKVG2nZXs3KBozkYp489/1Jeo4/wrlSCJ6iyn6jzIBGRdosDR ORDPXYYNQh4+R66JoaI1K35Vb/vVupcUgjtdyErwsOyCIIaOemSdD3Jj8JQl7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757930842; 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=0632WX4JNGh3HfFwJRKBKd91z1z6F57dqm8TyqS/wGs=; b=QoU3RoFzKqzb8l2he+6Rye4sRI495xbOFHYJSd+UIr5BABz2nt2IrPULr4SD1f8Sy1OD80 75l0b8xw+DDruIYWZFi26o3hzViln9qUw/ETYyuIpVBglvD8L6qrkHxgETT/2KxuI9/QlB U+5XXaiHBvJxXMgSwgwjwLy9clkzr+92d0lclY22MAXTTiMZaplpno5b3CWlTiD8qb6Rrp j0LORzLxWUAO64v0H+nkO2ckvCSlx+37sE5HG2kIMVaD6S1isdjWWaybpL32CKxpZ+TuJN /TDn9fC/xvUQxZi6/WAGj86M9ZTQJ89xqTUgdPf6p/Aw6QyXakbI6YUGSZvGJA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757930842; a=rsa-sha256; cv=none; b=mRn0h0loe/WKLzJnuqQ3PdbwfJMKaHS/JIQSfwlkUaaZqgunUBa4rzuZkf87B+Ad8L/R49 Za5pEdBUd8nHe61PlkzvnUrV81OzJto5CVbhBxDDazxtT78h1NpJObjmSGMjoyOTnwP0Wb mV/sKosdKDt+m9uJOL5NCS7CJOiPT59NEwh5+8DTto6zZOdFCTpswcs0Y9WSg+WMSGM4Mz 3aTe+VNQYXl9TwvQ5YN0J2rgJr7tB8yiNMjC2A+zBNckyNNb2VXMt9ppLTjQWiTyMct5y1 9ykvtSh3GX7E8uGT57PH1lnUUtKU+9cEZeM5Wm9x9VrV+aqd+zAzcucd0qN2WQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4cQLLL3RB4zqsk for ; Mon, 15 Sep 2025 10:07:22 +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 58FA7Mll093395 for ; Mon, 15 Sep 2025 10:07:22 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58FA7MYp093394 for net@FreeBSD.org; Mon, 15 Sep 2025 10:07:22 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 221122] Attaching interface to a bridge stops all traffic on uplink NIC for few seconds Date: Mon, 15 Sep 2025 10:07:20 +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: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=3D221122 --- Comment #36 from Andriy Gapon --- This bug is marked as resolved, but I am still seeing exactly the same issu= e as originally reported on 13.5 and CURRENT with igb interfaces. I don't understand on what comment #28 is based. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Sep 15 12:59:35 2025 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 4cQQ9C5yhmz67KTS for ; Mon, 15 Sep 2025 12:59:43 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4cQQ9B3Bbyz3CVZ for ; Mon, 15 Sep 2025 12:59:42 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (unknown [162.81.137.111]) by colo1.denninger.net (Postfix) with ESMTP id DE173B05B1 for ; Mon, 15 Sep 2025 08:58:30 -0400 (EDT) Received: by denninger.net (Postfix, from userid 58) id EF66C456ABE; Mon, 15 Sep 2025 08:59:35 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on NewFS.denninger.net X-Spam-Level: X-Spam-Status: No, score=-4.9 required=3.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=no autolearn_force=no version=4.0.1 X-Spam-Report: * -3.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message Received: from [192.168.10.15] (D5.Denninger.Net [192.168.10.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 8714D456BCA for ; Mon, 15 Sep 2025 08:59:35 -0400 (EDT) Message-ID: <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> Date: Mon, 15 Sep 2025 08:59:35 -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: IPv6 networking problems in 14.3 To: freebsd-net@freebsd.org References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <6fce77fb-9ba8-4c7b-bb9b-0e337d91f278@denninger.net> <1780EFAC-DA9C-4593-BE37-28E7FFCE4388@distal.com> <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> Content-Language: en-US From: Karl Denninger In-Reply-To: <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020603070909040007020900" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.84 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_LONG(-0.99)[-0.990]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; NEURAL_SPAM_SHORT(0.93)[0.934]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; FREEFALL_USER(0.00)[karl]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4cQQ9B3Bbyz3CVZ This is a cryptographically signed message in MIME format. --------------ms020603070909040007020900 Content-Type: multipart/alternative; boundary="------------wsFs4jN7ljLk9wimzIDnnbp4" --------------wsFs4jN7ljLk9wimzIDnnbp4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SG1tbW1tLi4uLiBqdXN0IGNhbWUgaW4gdmlhIGdpdCBwdWxsOg0KDQpjb21taXQgZmZkOTU2 YTM5MThjZDVlNjRjODg1MGViNzcyNDc0MjhhMjlmNzIyMQ0KQXV0aG9yOiBNaWNoYWVsIFR1 ZXhlbiA8dHVleGVuQEZyZWVCU0Qub3JnPg0KRGF0ZTrCoCDCoFdlZCBTZXAgMTAgMTc6MTM6 MzUgMjAyNSArMDIwMA0KDQogwqAgwqAgZGhjbGllbnQ6IGltcHJvdmUgVURQIGNoZWNrc3Vt IGhhbmRsaW5nDQoNCiDCoCDCoCBXaGVuIHNlbmRpbmcgVURQIHBhY2tldHM6DQogwqAgwqAg KiBjb21wdXRlIHRoZSBjaGVja3N1bSBpbiB0aGUgY29ycmVjdCBvcmRlci4gVGhpcyBvbmx5 IGhhcyBhbiBpbXBhY3QNCiDCoCDCoCDCoCBpZiB0aGUgbGVuZ3RoIG9mIHRoZSBwYXlsb2Fk IGlzIG9kZC4NCiDCoCDCoCAqIGRvbid0IHNlbmQgcGFja2V0IHdpdGggYSBjaGVja3N1bSBv ZiB6ZXJvLCB1c2UgMHhmZmZmIGluc3RlYWQgYXMNCiDCoCDCoCDCoCByZXF1aXJlZC4NCiDC oCDCoCBXaGVuIHJlY2VpdmluZyBVRFAgcGFja2V0czoNCiDCoCDCoCAqIGRvbid0IGRvIGFu eSBjb21wdXRhdGlvbnMgd2hlbiB0aGUgY2hlY2tzdW0gaXMgemVyby4NCiDCoCDCoCAqIGNv bXB1dGUgdGhlIGNoZWNrc3VtIGluIHRoZSBjb3JyZWN0IG9yZGVyLiBUaGlzIG9ubHkgaGFz IGFuIGltcGFjdA0KIMKgIMKgIMKgIGlmIHRoZSBsZW5ndGggb2YgdGhlIHBheWxvYWQgaXMg b2RkLg0KIMKgIMKgICogd2hlbiBjb21wdXRpbmcgdGhlIGNoZWNrc3VtLCBzdG9yZSB0aGUg cHNldWRvIGhlYWRlciBjaGVja3N1bQ0KIMKgIMKgICogaWYgdGhlIGNoZWNrc3VtIGlzIGNv bXB1dGVkIGFzIHplcm8sIHVzZSAweGZmZmYgaW5zdGVhZC4NCiDCoCDCoCAqIGFsc28gYWNj ZXB0IHBhY2tldHMsIHdoZW4gdGhlIGNoZWNrc3VtIGluIHRoZSBwYWNrZXQgaXMgdGhlIHBz ZXVkbw0KIMKgIMKgIMKgIGhlYWRlciBjaGVja3N1bS4NCipUaGUgbGFzdCBwb2ludCBmaXhl cyBhIHByb2JsZW0gd2hlbiB0aGUgREhDUCBjbGllbnQgcnVucyBpbiBhIFZNLA0KIMKgIMKg IHRoZSBESENQIHNlcnZlciBydW5zIG9uIHRoZSBob3N0IHNlcnZpbmcgdGhlIFZNIF9hbmQg dGhlIG5ldHdvcmsNCiDCoCDCoCBpbnRlcmZhY2Ugc3VwcG9ydHMgdHJhbnNtaXQgY2hlY2tz dW0gb2ZmbG9hZGluZ18uIFNpbmNlIGRoY2xpZW50DQogwqAgwqAgZG9lc24ndCB1c2UgVURQ IHNvY2tldHMgYnV0IGJwZiBkZXZpY2VzIHRvIHJlYWQgdGhlIHBhY2tldHMsIHRoZQ0KIMKg IMKgIGNoZWNrc3VtIHdpbGwgYmUgaW5jb3JyZWN0IGFuZCBvbmx5IGNvbnRhaW4gdGhlIGNo ZWNrc3VtIG9mIHRoZQ0KIMKgIMKgIHBzZXVkbyBoZWFkZXIuKg0KDQpUaGlzIGNvdWxkIHBv dGVudGlhbGx5IGFwcGx5IHRvIG90aGVyIGJwZi11c2luZyB0aGluZ3MgLS0gd2hpY2ggaW5j bHVkZXMgDQpkaGNwY2QuwqAgQW5kIHlvdSBoYXZlIHRzby9scm8gdHVybmVkIG9uLg0KDQpJ dCBpcyBhIHBhdGNoIHRvIGRoY2xpZW50LCBub3QgZGhjcGNkIGJ1dCBkb2VzIHRoZSBzYW1l IGlzc3VlIA0KcG90ZW50aWFsbHkgYXBwbHk/DQoNCk9uIDkvMTQvMjAyNSAxMzowMCwgS2Fy bCBEZW5uaW5nZXIgd3JvdGU6DQo+IE9uIDkvMTQvMjAyNSAxMjozOCwgQ2hyaXMgUm9zcyB3 cm90ZToNCj4+PiBPbiBTZXAgMTQsIDIwMjUsIGF0IDEyOjI5LCBLYXJsIERlbm5pbmdlcjxr YXJsQGRlbm5pbmdlci5uZXQ+IHdyb3RlOg0KPj4+IFJvbGxpbmcgdGhpcyBhcm91bmQgaW4g bXkgaGVhZCBzb21lIG1vcmUuLi4uLiB3aGF0IGlzIHRoZSB1bmRlcmx5aW5nIGludGVyZmFj ZT8NCj4+PiBJIGFzayBiZWNhdXNlIEkgc2F3IHRoaXMgaGFwcGVuIHdpdGggInJlIiBkcml2 ZXIgaW50ZXJmYWNlcyAoYm90aCBJUHY0IGFuZCA2KSB3aGVyZSBpdCB3b3VsZCBub3QgZ2V0 IGFuIEFSUCBtYXAgYW5kIHRodXMgY291bGRuJ3Qgc2VlIGFueXRoaW5nIGF0IGFsbCBvbiB0 aGUgb3V0c2lkZSAtIHRoZXJlIHdlcmUgZW5vdWdoIG90aGVyIHNjcmV3YmFsbCB0aGluZ3Mg Z29pbmcgb24gd2l0aCB0aGUgInJlIiBkcml2ZXIgKHRpbWVvdXRzIGFuZCBzaW1pbGFyKSB0 aGF0IEkgdG9zc2VkIHRoYXQgYW5kIG5vdyBydW4gb24gaXggYW5kIGEgY291cGxlIG9mIFNG UCsgdHJhbnNjZWl2ZXJzIHdoaWNoIGhhcyBiZWVuIGVudGlyZWx5LXN0YWJsZSAoYWx0aG91 Z2ggaWdiIGFsc28gYXBwZWFycyB0byB3b3JrIGFzIEkndmUgZ290dGVuIG15IGhhbmRzIG9u IGEgYm94IHdpdGggYSBjb3VwbGUgb2YgdGhvc2UgYW5kIHRlc3RlZCB0aGF0IHRvby4pDQo+ PiBJbiBteSBjYXNlIGl04oCZcyBhbiBpeC4gIENvbm5lY3RlZCB0byBhIDFnYnBzIHN3aXRj aCBpbnRlcmZhY2UsIGJ1dCBhbiBpeCBpbnRlcmZhY2UuICBBbmQsIHRoZSBzYW1lIGhhcmR3 YXJlIHRoYXQgd2FzIGRvaW5nIHRoaXMgZmluZSBhIGZldyBtb250aHMgYWdvLg0KPj4NCj4+ IHZsYW4wOiBmbGFncz0xMDA4ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVM VElDQVNULExPV0VSX1VQPiBtZXRyaWMgMCBtdHUgMTUwMA0KPj4gICAgICAgICAgb3B0aW9u cz00NjAwNzAzPFJYQ1NVTSxUWENTVU0sVFNPNCxUU082LExSTyxSWENTVU1fSVBWNixUWENT VU1fSVBWNixNRVhUUEc+DQo+PiAgICAgICAgICBldGhlciBhNDo1MzowZTo3OTpiOTo4Mg0K Pj4gICAgICAgICAgaW5ldCBBLkIuQy5EIG5ldG1hc2sgMHhmZmZmZmYwMCBicm9hZGNhc3Qg QS5CLkMuMjU1DQo+PiAgICAgICAgICBpbmV0NiBmZTgwOjo2ZTg6ZTY3NTpmMzU5OjM0NjUl dmxhbjAgcHJlZml4bGVuIDY0IHNjb3BlaWQgMHg0DQo+PiAgICAgICAgICBncm91cHM6IHZs YW4NCj4+ICAgICAgICAgIHZsYW46IDYgdmxhbnByb3RvOiA4MDIuMXEgdmxhbnBjcDogMCBw YXJlbnQgaW50ZXJmYWNlOiBpeDANCj4+ICAgICAgICAgIG1lZGlhOiBFdGhlcm5ldCBhdXRv c2VsZWN0ICgxMDAwYmFzZVQgPGZ1bGwtZHVwbGV4PikNCj4+ICAgICAgICAgIHN0YXR1czog YWN0aXZlDQo+PiAgICAgICAgICBuZDYgb3B0aW9ucz0xPFBFUkZPUk1OVUQ+DQo+Pg0KPj4g aXgwOiBmbGFncz0xMDA4ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElD QVNULExPV0VSX1VQPiBtZXRyaWMgMCBtdHUgMTUwMA0KPj4gCW9wdGlvbnM9NGU1M2ZiYjxS WENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5fSFdUQUdHSU5HLEpVTUJPX01UVSxWTEFOX0hX Q1NVTSxUU080LFRTTzYsTFJPLFdPTF9VQ0FTVCxXT0xfTUNBU1QsV09MX01BR0lDLFZMQU5f SFdGSUxURVIsVkxBTl9IV1RTTyxSWENTVU1fSVBWNixUWENTVU1fSVBWNixIV1NUQVRTLE1F WFRQRz4NCj4+ICAgICAgICAgIGV0aGVyIGE0OjUzOjBlOjc5OmI5OjgyDQo+PiAgICAgICAg ICBtZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdCAoMTAwMGJhc2VUIDxmdWxsLWR1cGxleD4p DQo+PiAgICAgICAgICBzdGF0dXM6IGFjdGl2ZQ0KPj4gICAgICAgICAgbmQ2IG9wdGlvbnM9 Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPg0KPj4NCj4gSWYgeW91 IGZpbmQgYW55dGhpbmcgYSBub3RlIGJhY2sgaGVyZSB3b3VsZCBiZSBncmVhdGx5IGV4Y2Vs bGVudC7CoCBJIA0KPiBkbyBub3RlIHRoYXQgcGVyIHRoZSB2YXJpb3VzIG5vdGVzIGZyb20g bG9uZyBhZ28gSSBoYXZlIGJvdGggdHNvIGFuZCANCj4gbHJvIHR1cm5lZCBvZmYgKGJ1dCBJ IHVzZSBpcGZ3LCB3aGljaCBpcyB3aGVyZSB0aGF0IGFwcGFyZW50bHkgY29tZXMgDQo+IGZy b20pIG9uIHRoZSBvdXRzaWRlIGludGVyZmFjZSAtLSBidXQgSSBkb3VidCB0aGF0IGlzIGlu dm9sdmVkIGFzIEkgDQo+IGRpZCB0cnkgd2l0aCBpdCBvbiBhbmQgaXQgZGlkbid0IGNoYW5n ZSBhbnl0aGluZy4NCj4NCj4NCj4gLS0gDQo+IEthcmwgRGVubmluZ2VyDQo+IGthcmxAZGVu bmluZ2VyLm5ldA0KPiAvVGhlIE1hcmtldCBUaWNrZXIvDQo+IC9bUy9NSU1FIGVuY3J5cHRl ZCBlbWFpbCBwcmVmZXJyZWRdLw0KLS0gDQpLYXJsIERlbm5pbmdlcg0Ka2FybEBkZW5uaW5n ZXIubmV0DQovVGhlIE1hcmtldCBUaWNrZXIvDQovW1MvTUlNRSBlbmNyeXB0ZWQgZW1haWwg cHJlZmVycmVkXS8NCg== --------------wsFs4jN7ljLk9wimzIDnnbp4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hmmmmm.... just came in via git pull:

commit ffd956a3918cd5e64c8850eb77247428a29f7221
Author: Michael Tuexen <tuexen@FreeBSD.org>
Date:=C2=A0 =C2=A0Wed Sep 10 17:13:35 2025 +0200

=C2=A0 =C2=A0 dhclient: improve UDP checksum handling

=C2=A0 =C2=A0 When sending UDP packets:
=C2=A0 =C2=A0 * compute the checksum in the correct order. This onl= y has an impact
=C2=A0 =C2=A0 =C2=A0 if the length of the payload is odd.
=C2=A0 =C2=A0 * don't send packet with a checksum of zero, use 0xff= ff instead as
=C2=A0 =C2=A0 =C2=A0 required.
=C2=A0 =C2=A0 When receiving UDP packets:
=C2=A0 =C2=A0 * don't do any computations when the checksum is zero= =2E
=C2=A0 =C2=A0 * compute the checksum in the correct order. This onl= y has an impact
=C2=A0 =C2=A0 =C2=A0 if the length of the payload is odd.
=C2=A0 =C2=A0 * when computing the checksum, store the pseudo heade= r checksum
=C2=A0 =C2=A0 * if the checksum is computed as zero, use 0xffff ins= tead.
=C2=A0 =C2=A0 * also accept packets, when the checksum in the packe= t is the pseudo
=C2=A0 =C2=A0 =C2=A0 header checksum.
=C2=A0 =C2=A0 The last point fixes a problem when the DHCP clien= t runs in a VM,
=C2=A0 =C2=A0 the DHCP server runs on the host serving the VM = and the network
=C2=A0 =C2=A0 interface supports transmit checksum offloading. Since dhclient
=C2=A0 =C2=A0 doesn't use UDP sockets but bpf devices to read the= packets, the
=C2=A0 =C2=A0 checksum will be incorrect and only contain the che= cksum of the
=C2=A0 =C2=A0 pseudo header.

This could potentially apply to other bpf-using things -- which includes dhcpcd.=C2=A0 And you have tso/lro turned on.

It is a patch to dhclient, not dhcpcd but does the same issue potentially apply?

On 9/14/2025 13:00, Karl Denninger wrote:
On 9/14/2025 12:38, Chris Ross wrote= : 
On Sep 14, 2025, at 12:2=
9, Karl Denninger <karl@denninger.net> wrote:
Rolling this around in my head some more..... what is the underlying inte=
rface?
I ask because I saw this happen with "re" driver interfaces (both IPv4 an=
d 6) where it would not get an ARP map and thus couldn't see anything at =
all on the outside - there were enough other screwball things going on wi=
th the "re" driver (timeouts and similar) that I tossed that and now run =
on ix and a couple of SFP+ transceivers which has been entirely-stable (a=
lthough igb also appears to work as I've gotten my hands on a box with a =
couple of those and tested that too.)

In my case it=E2=80=99s an=
 ix.  Connected to a 1gbps switch interface, but an ix interface.  And, t=
he same hardware that was doing this fine a few months ago.

vlan0: flags=3D1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP=
> metric 0 mtu 1500
        options=3D4600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCS=
UM_IPV6,MEXTPG>
        ether a4:53:0e:79:b9:82
        inet A.B.C.D netmask 0xffffff00 broadcast A.B.C.255
        inet6 fe80::6e8:e675:f359:3465%vlan0 prefixlen 64 scopeid 0x4
        groups: vlan
        vlan: 6 vlanproto: 802.1q vlanpcp: 0 parent interface: ix0
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=3D1<PERFORMNUD>

ix0: flags=3D1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP&g=
t; metric 0 mtu 1500
	options=3D4e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLA=
N_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_H=
WTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether a4:53:0e:79:b9:82
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

If you find anything a note back here would be greatly excellent.=C2=A0 I do note that per the various notes from long a= go I have both tso and lro turned off (but I use ipfw, which is where that apparently comes from) on the outside interface -- but I doubt that is involved as I did try with it on and it didn't change anything.


--
Karl Denninger
karl@d= enninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]<= /div> --------------wsFs4jN7ljLk9wimzIDnnbp4-- --------------ms020603070909040007020900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC C4owggWZMIIDgaADAgECAhRZU8dKdMneRI1Vq5kv0k54Q5rQuDANBgkqhkiG9w0BAQsFADB2 MQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRYwFAYDVQQKDA1EZW5uaW5nZXIu TmV0MRcwFQYDVQQDDA5EZW5uaW5nZXIgUm9vdDEiMCAGCSqGSIb3DQEJARYTYWRtaW5AZGVu bmluZ2VyLm5ldDAeFw0yNDA1MDkyMTA4MDNaFw00NDA1MDQyMTA4MDNaMF0xCzAJBgNVBAYT AlVTMRIwEAYDVQQIDAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNV BAMMGURlbm5pbmdlci5OZXQgU2lnbmluZyBJbnQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDbR0tSiuLG5HPfo+cWtdeYQ8jc8Bjfuo0GTcNRT0glHnH1apUtInIktUknEZDH ohahInN+mMBdKg54FCHOiYZrJbyxBIo9FwX7hRmOc+spxmSYWnOd2E/YcGInMK4ZpjPzldzB Yt1n3zygkhx2bssxTJS3x4nv1qAXfLSZd1VwqoQufifEoPyTtymkkvHLv86vLgqAqooM/cXc 4LSIQ5u2uM308n42r8RkKtp7X1v9fJW8oRZN2XnFZtiUPH44YY2rHqyN2Hea9Y3+TXbldXjo xhPHTA+JYVFq8KTmbQBqU7YcMhlIG0cSxPeFLMxnP6pqPcIVTAlK+a6YGRFppfjZAgMBAAGj ggE2MIIBMjAdBgNVHQ4EFgQUH+VuxXhBxaJAQrvDekwkH91hBi4wgbMGA1UdIwSBqzCBqIAU RFYC4p6L6KITnEvrpx2cyt+PcMmheqR4MHYxCzAJBgNVBAYTAlVTMRIwEAYDVQQIDAlUZW5u ZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5OZXQxFzAVBgNVBAMMDkRlbm5pbmdlciBSb290 MSIwIAYJKoZIhvcNAQkBFhNhZG1pbkBkZW5uaW5nZXIubmV0ghQZE7NBItWtQsCouuwU6jZ+ HPPwnjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+gLaAr hilodHRwOi8vd3d3LmRlbm5pbmdlci5uZXQvcm9vdC1yZXZva2VkLmNybDANBgkqhkiG9w0B AQsFAAOCAgEAfFbhPc82AfhyUqONs7IccYD36w+OP4nQgwfC4IWf3y/aQAZ2Zk6IITzYqwf7 PFM0bJRT3zi7xyetolqHDhfMJvnOQWpITZiyM/FSKwIvuBsy/uJUqPuqui4XQMYoSbAA1qmI MW/z7VZZHwaRFoeWE40UirYcf0fNcooBZ72bmd+iBaVyjtZvky0Vgcz0eC6e6LR5kNb23yC6 TkyQIlGyQkK5/afXUYFzk49rOHVbVyxW3oXRfq8Ow6HCrpDGAS8p84S04MFwBVAUfbe4aXs3 bampaI2LzKgkVywyFP14LSvvdjCfLYfnLy1Z9hm2EHMqNHA2tCGdRhWp2d7aZC1MYFqng0ZS fjPJjqHrI1qPU0p6k9A1GxAtrQlL2v/IUzUnMZkiawFV3qlxMGZf/kTYTUOcJhx1KU4zSLHu 80qO7ldRpp5gHssCAGFbeTu2gp6LxfmaFhLPDBJ1VGfdPx9lUrU/9OcoHczcl5x2Rb8IUZyX 9elzP5WdAU8p5R/DLlOAq24VcabhFtYBCA2dOESLupSfWKNQuJCN/1gz7ysSc+mjnnPV77IO mpszJfkFFJEDNJlGIVKX1vwwygtC/9Ulox8frgbZlRAYAgDc/YbOBFxticVVre0Y3Ujx6Kzb tkgZRlgfdZWbT1W5smncqJxg5qAL8e/yTb3fCe2nJ0jhiP4wggXpMIIE0aADAgECAhMAmNFt CiCF3j+FwQLYtBTmGjzkMA0GCSqGSIb3DQEBCwUAMF0xCzAJBgNVBAYTAlVTMRIwEAYDVQQI DAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNVBAMMGURlbm5pbmdl ci5OZXQgU2lnbmluZyBJbnQwHhcNMjQwNTEwMTkyNjU5WhcNMjkwNTA5MTkyNjU5WjBXMQsw CQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRcwFQYDVQQKDA5LYXJsIERlbm5pbmdl cjEbMBkGA1UEAwwSa2FybEBkZW5uaW5nZXIubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8A MIICCgKCAgEAvh1UssVbSYctzobPjwBkbjv/w4WvQNepeRTwE6+sLnXvc41+X9pa5EclPL4Q l02Vu1m71mSqXGfK9HbWZoivbhefBHOoYb35MSc24PelhwcORbpneWoWc7giQ7QgFlvEe/yj fs8M0H9fgdzFS5m2lwBQbis8kioSjHB2yt/8I1GE4Mvt1Cur9kga6ML5FAQvo8TYN1stdhrE 13FEv/BWCF4FVT4H2Wa2ySW+R1jkKb74SC6Twg98bGCRTShD5bVylh0+0LXNhzaopIDcI/KK jm/j3mRjIlmqbGrSpvJsbjjhjhAYQKE1U8FB5TDU4OkFAibblhQit/KjgspPR2o/vOpVFPER uhZEV1oDGzUJtZlkREIcN2sYBi0p7Y4585ya+b7L10mEenPlyi3eSkGXEuiy/BR2DY6lShwW DPoQ5602TKmttCSwBdWGoLrQ4jEVEVNt4lku2wPbTHF3KpHJU0g7RbcWoUYn10SOxKathkir hF3v9U32+QhPELGwqRrH0sL9rWf0qalRtPDHUYl8TebZmYkFqNeSMlqHijl5f4SsQPSj7gx5 4F19Ntm9ZcvuWTmW8QQGWTKHeMuG+BYkVIUSPe6/ZQsbD/xDx7rkyGfNgWIa4W7Wm/B7kaNq H53tk3wFmNgZQOxMTPF0oTHfW0T2azU6JD0D1AlgoAnSAE0CAwEAAaOCAaYwggGiMDoGCCsG AQUFBwEBBC4wLDAqBggrBgEFBQcwAYYeaHR0cDovL29jc3AuZGVubmluZ2VyLm5ldDo3Nzc3 MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAzBglghkgBhvhCAQ0EJhYkT3BlblNTTCBHZW5lcmF0ZWQgQ2xpZW50IENlcnRp ZmljYXRlMB0GA1UdDgQWBBSxJZjVnlYLAT3uzvDYgc4742J6UTCBswYDVR0jBIGrMIGogBQf 5W7FeEHFokBCu8N6TCQf3WEGLqF6pHgwdjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5l c3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLk5ldDEXMBUGA1UEAwwORGVubmluZ2VyIFJvb3Qx IjAgBgkqhkiG9w0BCQEWE2FkbWluQGRlbm5pbmdlci5uZXSCFFlTx0p0yd5EjVWrmS/STnhD mtC4MB0GA1UdEQQWMBSBEmthcmxAZGVubmluZ2VyLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEA TrQ45/tBN3SiuqItFv/V+CF3h7Hxe0YLsL+A/P+q9ZhxIscaNjaclgQhPA+rUr+l8DGoXJ/w yAl1E0SSBK+9phIc/9xFOBg3rCy4ngubzP+lHS1t03nMCBSUNsu5qPzqLBPiKaPabUu3Gr9o koRezSszgM3/zNJfr8cMO93csCK/fBccsMx5q+3nxB5XeT7UciicjfEzUA4m2mQxBmGk9SSU 147Gy8UmdSq57Tw82KqUrQ1pJ6IOzVPLREpwlqGbHykSU3MwtPYPtfQeFVjvO/XcWvoFQjbV UyhzAqMMYFudxoVLlJQiAgU38OScTLDgKxCO41h7VOjb2mss0zHndzGCBZUwggWRAgEBMHQw XTELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2Vy Lm5ldDEiMCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC 2LQU5ho85DANBglghkgBZQMEAgMFAKCCAvIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMjUwOTE1MTI1OTM1WjBPBgkqhkiG9w0BCQQxQgRAFSzYPXVfLEvX DGaAXt8glFeyt7PBaVzxADI8cXttHR2vPCU6ASsZ14ppfm56mJUPTbNFk2laTTyJfjzCqrjS DzCBgwYJKwYBBAGCNxAEMXYwdDBdMQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2Vl MRYwFAYDVQQKDA1EZW5uaW5nZXIubmV0MSIwIAYDVQQDDBlEZW5uaW5nZXIuTmV0IFNpZ25p bmcgSW50AhMAmNFtCiCF3j+FwQLYtBTmGjzkMIGFBgsqhkiG9w0BCRACCzF2oHQwXTELMAkG A1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLm5ldDEi MCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC2LQU5ho8 5DCCAVcGCSqGSIb3DQEJDzGCAUgwggFEMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDQYIKoZIhvcNAwICAQUwDQYIKoZIhvcNAwICAQUwBwYFKw4DAgcwDQYIKoZI hvcNAwICAQUwBwYFKw4DAhowCwYJYIZIAWUDBAIBMAsGCWCGSAFlAwQCAjALBglghkgBZQME AgMwCwYJYIZIAWUDBAIEMAsGCWCGSAFlAwQCBzALBglghkgBZQMEAggwCwYJYIZIAWUDBAIJ MAsGCWCGSAFlAwQCCjALBgkqhkiG9w0BAQEwCwYJK4EFEIZIPwACMAgGBiuBBAELADAIBgYr gQQBCwEwCAYGK4EEAQsCMAgGBiuBBAELAzALBgkrgQUQhkg/AAMwCAYGK4EEAQ4AMAgGBiuB BAEOATAIBgYrgQQBDgIwCAYGK4EEAQ4DMA0GCSqGSIb3DQEBAQUABIICAGfemrs2jLbn0BAD 2gl3JmokvBC58klP+2AiSzjNROTApv+TaRL1++HuaMQFnRCvd2NnUJ8ELtsRZeOciA6wTTJj rjHQmisaluGenKRxYFi/32knM5R3KxMVdv0maEwnm7HPZmvTA0/l+nxFhx0GM8KZkkZ4HbkP CSrHryP7gvwQUmC8coDSo8Q2RFjcvihLghl64uH0+k/NYW93fHV1JhBUIycXWTRO8984bwOi sJeCbFFMp7lN1EXIk3A1g/GpViUrVWzaCeu+S3H8OK2VvXHMcJmONTdr79A/PMcqBtdBWkU/ nMesrOc8uzciRzBMkPGMsFasVmySFtbJqxlIPxlShqKZhchWSfLbuqhrrrtP6c07ODDpftvd VvV2h2d8933UexPCbJhXEnJa9hilk50DId3tixiAB8Qv7BRx9/yXn1eJTXd3DIfgAvsCSt5R HBrTM3e5Zz7xl5ftcqpnCAj7C/Qc+M9t+xIBg91bYeLqokFyVlHzY9cO1Wr91aIowjTlfPTj nYVIgw31Soc40+A5S8Hb3S78qz+WHBT/76Fu3mShHkgICJer/UujmbAeQwKJ8j6JEC7suAWe DplvQmR4S388sA85yMJQ1BkUnLE00fEgBw7dXhv6qgDRzQDKs5/WxpZrEYnfw4o6Cigccc9Q w7GtE2YANdThSfKtDN8QAAAAAAAA --------------ms020603070909040007020900-- From nobody Mon Sep 15 16:50:05 2025 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 4cQWH2152nz67cF6 for ; Mon, 15 Sep 2025 16:50:06 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQWH20PWqz3kY8 for ; Mon, 15 Sep 2025 16:50:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757955006; 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=EsZGHN/1p4/mQvvuyuo3KtbVqACoVcS3VMD97zPSc8M=; b=Ar3E0fPpJaWE8bH9PVF/opfg90RvUNthk1IBTjSD3xH9H25mIvxvTqbEvBY/q5FX1rOC7P GY4CP2pzpOBpf5qxsmqyZpOAtZSxZCvhWUOMHPwlGHVLm9t19cRlw3fSwAbUUUjjr3KTeo sl9bpw3QMNuZauIfZWHzTdze8noFwzkXTzCrmZcTEG89tVhg3wqgi5uAUq/0VrSjZKDA3R /aetBpHFiXYAVt6B90tKmk1vdbLxJ1b2TE6ctfJmhHZipENv2z8lC5oKojpLNyH07NW+46 JuIqOriuUe2Vg4PX6OaY9jPywTHFXARwmX9WCeJY7tsXGZ2ics6+x4ycrv2oPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757955006; 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=EsZGHN/1p4/mQvvuyuo3KtbVqACoVcS3VMD97zPSc8M=; b=r/4tKGeymZ1DKyiV9IBfcLq/F+gffgDb8CqC+aOBTOMXIcDA10+xbbBCl3oma5rNjULmUg U5pQptZsTDhP9qEnwZMBHLisPVGWXWfnGg0fQ5cHS8/UHybs2AAV26xlotvNChcBXUi/vS gf8p5ZH27u2VNaZQv+3ogZj/+deVIbXLE4q0/aZMq2beFoxWTVF2zP8IdaZ7FX0LfDFEm1 bpRPz3oW7x4ibmojkQtNaHBnqXXlaaEe8DhiusjU9y11thtl1NDXNf8FOjkukLkMXOJb4q gugHoVLqbFI73a1i53uqlmcKf04t+wmMXf5JPoxKMfUpbuqo7pYbO9pcVjxP0Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757955006; a=rsa-sha256; cv=none; b=nJd+ky4ZSR6RNrccxZyB7+DU7jv3pX1tpaEiwOdootcNo+xiKlfRZKxfKhyOmggIewIbfQ I5sPx5gJoIF8K852ZhlW+dSq7eTqN7u4CQElWnpGzIRfa66HtMpISVuFc+BoO2IR368UDX fXqifl3D8s3Rpl3JJgRRPXhj4eqojxBhRyJCCRY0qK+/BUPZJg4cBe/N9nSi0tZ2oix4Oh sbM/4vjIaLNXUc/MEhOPq0cyGz2ETm9scXPVDFqicOVEr1wx63Dr1HIka0LnxNobzElAFc Yy+23CdRQAbFOjmF+U1DEOYEHwVt72KM1iAdYaT4nLfREjW0UvWZjzBhwQE+Ww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4cQWH175R1z12Sw for ; Mon, 15 Sep 2025 16:50:05 +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 58FGo5rH014218 for ; Mon, 15 Sep 2025 16:50:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58FGo5xg014217 for net@FreeBSD.org; Mon, 15 Sep 2025 16:50:05 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 289423] SO_BINTIME seems to not work for IPv6 Date: Mon, 15 Sep 2025 16:50:05 +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: 14.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some 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: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=3D289423 --- Comment #3 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3Dcd02a8a9f8be2085d5242606a79668dc3= 720e7b0 commit cd02a8a9f8be2085d5242606a79668dc3720e7b0 Author: Jonathan T. Looney AuthorDate: 2025-09-12 17:49:17 +0000 Commit: Jonathan T. Looney CommitDate: 2025-09-15 16:46:03 +0000 ip6: add SO_BINTIME support This adds support for obtaining timestamps from IPv6 packets using the SO_BINTIME socket option, bringing it in parity with IPv4 behavior. Enable testing the SO_BINTIME option in the relevant (manual) regression test. PR: 289423 Reviewed by: markj MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D52504 sys/netinet6/ip6_input.c | 53 +++++++++++++++---= ---- .../regression/sockets/udp_pingpong/udp_pingpong.c | 8 ++-- 2 files changed, 39 insertions(+), 22 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Sep 15 16:53:40 2025 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 4cQWM83cmSz67cSM for ; Mon, 15 Sep 2025 16:53:40 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQWM82x9pz3lSR for ; Mon, 15 Sep 2025 16:53:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757955220; 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=qKrTT/rdOiDA/+M/vYZ2uHl5ORg+j0up7WCbumKimhU=; b=HFiCwiEtQWjaqogGnsaCXM7jI/GnqxcCE4qnHpbZ/R0XlYPxgx3mNgWMu9SGFsue6dM+/M gEejGRnE3dQV8G9m7dsjwR4IKBjfzU5LwJSp1BjaBuPbnJ62e4XVxLtaVAO18V2ywXkyw6 e5NvnQixBDrK5jHk02tgc4jzAWCK/7PX5J/dHdlKgCi1yIKJ2U854gtmMWaRG88gA0hKXa qriSmEvq6gmYCkzHVpW9rWot/ompdqNyRZLUQOAXPcJDcsN4x9zXeh9Lkvua+MTLptEVju MITT5zLc9spmaU/oyygFor2XCB+AvS9FTTc4Ow+BnlcqKs+l+LgIVZpU+16pVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757955220; 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=qKrTT/rdOiDA/+M/vYZ2uHl5ORg+j0up7WCbumKimhU=; b=kZDXYECnx9elY92a4Gp7ypkz5ceYo09Zl5podWRiiN7+7J0fbK6VB+nKRBiTDNtjb3ZIGs O+6meOpt9Qxe8I8Hed1G/RlDicE54Aef1CgcpcCH6820fNkBMrlsgOYSU0Mez27SYrpBGN qOhj0RxzIKIJt07IvnYF+XjdU2J3woxMkGIjEXsoMW+mL/kKqQsJlylwbpuEru3FBPlBo/ V0rqrQi9aq32umn/7TtCG9H0RJWNLcqpTd9KlDAIK5hQnFhp/C2KH6LYB9mAEQ2D5zXONm ldxqFwEYaZqU0A2z2rirv580Tjt43mopNjlNQLeZ4lAHu5vfg9e8P3FC9a4/lg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757955220; a=rsa-sha256; cv=none; b=OzSqToqn7WvSLnVggv5EA638kpmoOMyJ1yzulVawk9tC6LCVjRnPCvthQbOXg/KaUcdSGw 4Pw2v9Ef25E87evXRGDeAZWNRliBoz5CAuR8aJ4k/vbVxBUEVL/J3EBvjnjvkq16L8329/ lI7yhtnm9j9B5RwosfighG/AW5fZU09BWY+qFJbsCHsMsxnvziesfe46wT0IcKtBuRzDcJ s9uEEKhxyng7/qIXe/6aXeLdj8UNlUyPitTM3QN0NBGoeHsKPHQ2NgwsG/gAjpQFunQ6v/ F93HHEpKkN7SLDibs8jGAMM3ioEM8A/Utbr5lMxHpoUunV6Xvx7F6atY90vVXg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4cQWM82NtRz13B6 for ; Mon, 15 Sep 2025 16:53:40 +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 58FGreOX025646 for ; Mon, 15 Sep 2025 16:53:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58FGreDQ025645 for net@FreeBSD.org; Mon, 15 Sep 2025 16:53:40 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 289423] SO_BINTIME seems to not work for IPv6 Date: Mon, 15 Sep 2025 16:53:40 +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: 14.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jtl@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=3D289423 Jonathan T. Looney changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jtl@freebsd.org Status|Open |In Progress --- Comment #4 from Jonathan T. Looney --- I committed a fix to main. I will close the bug once it is MFCd. In the meantime, feel free to test with -CURRENT. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Sep 15 16:54:00 2025 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 4cQWMY5Nlbz67cxG for ; Mon, 15 Sep 2025 16:54:01 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQWMX6gjJz3lqk for ; Mon, 15 Sep 2025 16:54:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757955241; 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=woYbx+bYR38RlE/aW4Y+DSexfk7OrHh+Lnl8l9YLY8c=; b=J3f6Ktfe9cPkNwrJbGySU159n+ZOc3Ec/8yqrgS+oaBk0inCux5abq+/QdD0P2uklZJ/Ra tKv6nmctzIA+cLpfjkSdrfY4ersjR8JKQmfKYnIK3Mhnf1WNyO0VPGXa6nN0qSbj4+D03z vI8/ZOcXKpIbrP7Jj/2mxSGahDDeErl3FO41KT49AMI7KQvHqRlyciwiU/dMmzg5aSDcvE v+aRXDXT/zsLy5HjZXqaKvskidK15HcdCTfvUolt+Q0lo0OBe3RTsYC6WPVKO8HLtXZXV6 kQxKMBcZbA4NsQtQgp2Dm+v2BIm+ce/SjXBUKzFSJKqMzhIYsqArGxnU8xwMjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757955241; 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=woYbx+bYR38RlE/aW4Y+DSexfk7OrHh+Lnl8l9YLY8c=; b=jBXuGAMmX9Hy2d7VEQnA0clwpek8dwgYJiny/dttYzWoR+IzPlf1cAKzNTQRQUIsNJr2FE TI1ffHALl8gtbUmQ0QWdT58cR1PzmLr7NCZgyIku4g0AP312xzgJtlkgkhcZk3VsYn2BVJ WULCquMlKRY7FoDJbuzVp0B5HrHCVAss3usImoouACG2Sur+UKY4QdOI2nZEMi1MSK+mj5 kJRBmHTFapBQYWrVXQzERR90BKN/k8zO5l0gW08UxSSPa9ATj7HNxPxWqitDE6/oRpoHJf HPeto+VDJBxkJseLoy7c/Kef49QJAcjwQLHgAdES5NxICfooX2Enqd+mXkDXMg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757955241; a=rsa-sha256; cv=none; b=uAG27/x+TVriV+81h/7SG0947eNFNd30uOg+Tpd0no5EEztnEVO6oefS6AvtJqbh0CNn42 H26tfcKfdahjHDJeLgxi+BTEjUi4ULNIRv4vI+9LJOY+G8PH4GEuO4yG6f0CfHTJuvhrJe 6d6DsQOG5x1oRqipv86t6QPiV85h9sV1PFa5VQCiiIaWWBLKycEXtPWWF31IuUBH3Ftws7 ddwxICF4Izj6F7bpsbikAvbU5lnwSF5SsfqquRGbbbAphj7/BmkdpNneg20YmNE6qykYg0 yKsZXzHZIWm+Jf5RUubHXGghzXd1fRJsKLAASBimw9nEnS2PsYIaHkvSogN3nQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4cQWMX6CYjz13DN for ; Mon, 15 Sep 2025 16:54:00 +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 58FGs0Md025918 for ; Mon, 15 Sep 2025 16:54:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58FGs0dO025917 for net@FreeBSD.org; Mon, 15 Sep 2025 16:54:00 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 289423] SO_BINTIME seems to not work for IPv6 Date: Mon, 15 Sep 2025 16:54:00 +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: 14.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: jtl@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: jtl@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=3D289423 Jonathan T. Looney changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|net@FreeBSD.org |jtl@freebsd.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Sep 15 17:00:23 2025 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 4cQWVx3Z41z67dCC for ; Mon, 15 Sep 2025 17:00:25 +0000 (UTC) (envelope-from tuexen@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 "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQWVx369tz3nCn; Mon, 15 Sep 2025 17:00:25 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757955625; 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=vbRsGeScy+9UE64DKSiaKLIjKKQbSibtHNz4fMSl52Q=; b=BRxRcPsYtTDCv7vP8w8Z5fNG3bQjZ88Oi9re077d/mZhh0JYi8nPiGHryavLoa7szMZCv2 5tdJdaNHETipaNDWBm5yZxJmap3CTbignxoCcD8v0cBv633lZAF3Vskfc+Yff9aIkhL5Zd yVMHN95N3dzj291h4iAaMo/nSnS2gCmqS+U9z8qR1cxJRgmVPQQQgUab+DfyByTqlesArx USlkMpgh4uLPvU5sOsZDJaIEVSqyTflM5VqWGYBDoUKfWShbTPJ6VDfIW+sVUp0QmzSzP2 TQPoWoMb5KnMmGtlkiYOFJJp0811UY6kNFiZc/hRjGwGyQL3peNqq8q7UgKjiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757955625; 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=vbRsGeScy+9UE64DKSiaKLIjKKQbSibtHNz4fMSl52Q=; b=D/ytpX9AHaz4cKD5BkgsuAWWxwwv0myv29DrGnzngBDtNLLNDQLan7yj6qDH5/DLZF5/MK knAsPft/O/lemjf395NbABcRGI3YCIqmOHbuwh7hlObfJJuDd+dznvz539sZauf++VmSLJ APH4BIcfDErXXfQwiXoc9cFeyck7glpkTx7QiKZ+SImRFYySUC7RASp9qpD89fGM1/giDg cbEuNQq0l+Z8E+mPOSadAAjg2KhUW3Nfj4QLrf0pm+Y0wRgwKjkYCtv8YRXkicg6ATLv5D doUnrQ0kcpE4NAerHs3Si5/I7/1H0M8INisWZWPqo+9hnM2ZoeZMQtHF9dGOOg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757955625; a=rsa-sha256; cv=none; b=ZzsMkORDTVDE2IGUHrmNDdfxWcYmXEdWuTJf87UW1ueKsjRCUBvCWET0P4iMg3L61XdIQh HFNShoq3UGjzKMozq+DslcRfZI4P3CBSCDdPyvUkXAv2JmdUzMIXPtTOS697g5Mf1hh9Ae OIH90C4xjNPJXDGiT1f0fw1FkA5fbCNcd6z52Dr7mkHA9Nzvb/NPG3JAkr5V8guj3ZRxaB MRNTGbFHL7h9RMDhM+Mn13HWs1VloO0WxCzbV9dbuM1qRNIAZESxtUveDiqc61bZvQaBwO On4eT2l+5pQDgbk5kiQkx58NpSbIACib/VGH+jIVZyrJmiuILWwKMX20S+X4dQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:a17f:b5da:da9c:c18a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: tuexen) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cQWVx087nz19LS; Mon, 15 Sep 2025 17:00:24 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) 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 \(3826.700.81\)) Subject: Re: IPv6 networking problems in 14.3 From: Michael Tuexen In-Reply-To: <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> Date: Mon, 15 Sep 2025 19:00:23 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <75B331C2-856A-4977-ADCD-D7FA6854AA03@FreeBSD.org> References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <6fce77fb-9ba8-4c7b-bb9b-0e337d91f278@denninger.net> <1780EFAC-DA9C-4593-BE37-28E7FFCE4388@distal.com> <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3826.700.81) > On 15. Sep 2025, at 14:59, Karl Denninger wrote: >=20 > Hmmmmm.... just came in via git pull: > commit ffd956a3918cd5e64c8850eb77247428a29f7221 > Author: Michael Tuexen > Date: Wed Sep 10 17:13:35 2025 +0200 >=20 > dhclient: improve UDP checksum handling >=20 > When sending UDP packets: > * compute the checksum in the correct order. This only has an = impact > if the length of the payload is odd. > * don't send packet with a checksum of zero, use 0xffff instead as > required. > When receiving UDP packets: > * don't do any computations when the checksum is zero. > * compute the checksum in the correct order. This only has an = impact > if the length of the payload is odd. > * when computing the checksum, store the pseudo header checksum > * if the checksum is computed as zero, use 0xffff instead. > * also accept packets, when the checksum in the packet is the = pseudo > header checksum. > The last point fixes a problem when the DHCP client runs in a VM, > the DHCP server runs on the host serving the VM and the network > interface supports transmit checksum offloading. Since dhclient > doesn't use UDP sockets but bpf devices to read the packets, the > checksum will be incorrect and only contain the checksum of the > pseudo header. >=20 > This could potentially apply to other bpf-using things -- which = includes dhcpcd. And you have tso/lro turned on. Hi Karl, this is true. Do we have an dhcpd in-tree? Or are you aware of other = in-tree programs which use UDP via bpf and not via the socket interface? Best regards Michael > It is a patch to dhclient, not dhcpcd but does the same issue = potentially apply? > On 9/14/2025 13:00, Karl Denninger wrote: >> On 9/14/2025 12:38, Chris Ross wrote: >>>=20 >>>> On Sep 14, 2025, at 12:29, Karl Denninger = wrote: >>>> Rolling this around in my head some more..... what is the = underlying interface? >>>> I ask because I saw this happen with "re" driver interfaces (both = IPv4 and 6) where it would not get an ARP map and thus couldn't see = anything at all on the outside - there were enough other screwball = things going on with the "re" driver (timeouts and similar) that I = tossed that and now run on ix and a couple of SFP+ transceivers which = has been entirely-stable (although igb also appears to work as I've = gotten my hands on a box with a couple of those and tested that too.) >>>>=20 >>> In my case it=E2=80=99s an ix. Connected to a 1gbps switch = interface, but an ix interface. And, the same hardware that was doing = this fine a few months ago. >>>=20 >>> vlan0: = flags=3D1008843 metric = 0 mtu 1500 >>> = options=3D4600703 >>> ether a4:53:0e:79:b9:82 >>> inet A.B.C.D netmask 0xffffff00 broadcast A.B.C.255 >>> inet6 fe80::6e8:e675:f359:3465%vlan0 prefixlen 64 scopeid 0x4 >>> groups: vlan >>> vlan: 6 vlanproto: 802.1q vlanpcp: 0 parent interface: ix0 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> nd6 options=3D1 >>>=20 >>> ix0: flags=3D1008843 = metric 0 mtu 1500 >>> = options=3D4e53fbb >>> ether a4:53:0e:79:b9:82 >>> media: Ethernet autoselect (1000baseT ) >>> status: active >>> nd6 options=3D29 >>>=20 >>>=20 >> If you find anything a note back here would be greatly excellent. I = do note that per the various notes from long ago I have both tso and lro = turned off (but I use ipfw, which is where that apparently comes from) = on the outside interface -- but I doubt that is involved as I did try = with it on and it didn't change anything. >>=20 >> --=20 >> Karl Denninger >> karl@denninger.net >> The Market Ticker >> [S/MIME encrypted email preferred] > --=20 > Karl Denninger > karl@denninger.net > The Market Ticker > [S/MIME encrypted email preferred] From nobody Mon Sep 15 17:16:17 2025 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 4cQWsv54p1z67fXq for ; Mon, 15 Sep 2025 17:16:51 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4cQWst25FNz3rHM for ; Mon, 15 Sep 2025 17:16:50 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (unknown [162.81.137.111]) by colo1.denninger.net (Postfix) with ESMTP id A92E4B05B1 for ; Mon, 15 Sep 2025 13:15:13 -0400 (EDT) Received: by denninger.net (Postfix, from userid 58) id CF40C457859; Mon, 15 Sep 2025 13:16:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on NewFS.denninger.net X-Spam-Level: X-Spam-Status: No, score=-4.9 required=3.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=no autolearn_force=no version=4.0.1 X-Spam-Report: * -3.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message Received: from [192.168.10.15] (D5.Denninger.Net [192.168.10.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 76E6E4576FA for ; Mon, 15 Sep 2025 13:16:18 -0400 (EDT) Message-ID: Date: Mon, 15 Sep 2025 13:16:17 -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: IPv6 networking problems in 14.3 To: freebsd-net@freebsd.org References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <6fce77fb-9ba8-4c7b-bb9b-0e337d91f278@denninger.net> <1780EFAC-DA9C-4593-BE37-28E7FFCE4388@distal.com> <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> <75B331C2-856A-4977-ADCD-D7FA6854AA03@FreeBSD.org> Content-Language: en-US From: Karl Denninger In-Reply-To: <75B331C2-856A-4977-ADCD-D7FA6854AA03@FreeBSD.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000602070504090303080608" X-Spamd-Bar: - X-Spamd-Result: default: False [-1.59 / 15.00]; SIGNED_SMIME(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_SPAM_SHORT(0.98)[0.980]; NEURAL_HAM_LONG(-0.96)[-0.956]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_SPAM_MEDIUM(0.18)[0.184]; MIME_BASE64_TEXT(0.10)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEFALL_USER(0.00)[karl]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4cQWst25FNz3rHM This is a cryptographically signed message in MIME format. --------------ms000602070504090303080608 Content-Type: multipart/alternative; boundary="------------CknxG15mTk2WoeT20Nvkf8Ae" --------------CknxG15mTk2WoeT20Nvkf8Ae Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gOS8xNS8yMDI1IDEzOjAwLCBNaWNoYWVsIFR1ZXhlbiB3cm90ZToNCj4+IE9uIDE1LiBT ZXAgMjAyNSwgYXQgMTQ6NTksIEthcmwgRGVubmluZ2VyPGthcmxAZGVubmluZ2VyLm5ldD4g d3JvdGU6DQo+Pg0KPj4gSG1tbW1tLi4uLiBqdXN0IGNhbWUgaW4gdmlhIGdpdCBwdWxsOg0K Pj4gY29tbWl0IGZmZDk1NmEzOTE4Y2Q1ZTY0Yzg4NTBlYjc3MjQ3NDI4YTI5ZjcyMjENCj4+ IEF1dGhvcjogTWljaGFlbCBUdWV4ZW48dHVleGVuQEZyZWVCU0Qub3JnPg0KPj4gRGF0ZTog ICBXZWQgU2VwIDEwIDE3OjEzOjM1IDIwMjUgKzAyMDANCj4+DQo+PiAgICAgIGRoY2xpZW50 OiBpbXByb3ZlIFVEUCBjaGVja3N1bSBoYW5kbGluZw0KPj4NCj4+ICAgICAgV2hlbiBzZW5k aW5nIFVEUCBwYWNrZXRzOg0KPj4gICAgICAqIGNvbXB1dGUgdGhlIGNoZWNrc3VtIGluIHRo ZSBjb3JyZWN0IG9yZGVyLiBUaGlzIG9ubHkgaGFzIGFuIGltcGFjdA0KPj4gICAgICAgIGlm IHRoZSBsZW5ndGggb2YgdGhlIHBheWxvYWQgaXMgb2RkLg0KPj4gICAgICAqIGRvbid0IHNl bmQgcGFja2V0IHdpdGggYSBjaGVja3N1bSBvZiB6ZXJvLCB1c2UgMHhmZmZmIGluc3RlYWQg YXMNCj4+ICAgICAgICByZXF1aXJlZC4NCj4+ICAgICAgV2hlbiByZWNlaXZpbmcgVURQIHBh Y2tldHM6DQo+PiAgICAgICogZG9uJ3QgZG8gYW55IGNvbXB1dGF0aW9ucyB3aGVuIHRoZSBj aGVja3N1bSBpcyB6ZXJvLg0KPj4gICAgICAqIGNvbXB1dGUgdGhlIGNoZWNrc3VtIGluIHRo ZSBjb3JyZWN0IG9yZGVyLiBUaGlzIG9ubHkgaGFzIGFuIGltcGFjdA0KPj4gICAgICAgIGlm IHRoZSBsZW5ndGggb2YgdGhlIHBheWxvYWQgaXMgb2RkLg0KPj4gICAgICAqIHdoZW4gY29t cHV0aW5nIHRoZSBjaGVja3N1bSwgc3RvcmUgdGhlIHBzZXVkbyBoZWFkZXIgY2hlY2tzdW0N Cj4+ICAgICAgKiBpZiB0aGUgY2hlY2tzdW0gaXMgY29tcHV0ZWQgYXMgemVybywgdXNlIDB4 ZmZmZiBpbnN0ZWFkLg0KPj4gICAgICAqIGFsc28gYWNjZXB0IHBhY2tldHMsIHdoZW4gdGhl IGNoZWNrc3VtIGluIHRoZSBwYWNrZXQgaXMgdGhlIHBzZXVkbw0KPj4gICAgICAgIGhlYWRl ciBjaGVja3N1bS4NCj4+ICAgICAgVGhlIGxhc3QgcG9pbnQgZml4ZXMgYSBwcm9ibGVtIHdo ZW4gdGhlIERIQ1AgY2xpZW50IHJ1bnMgaW4gYSBWTSwNCj4+ICAgICAgdGhlIERIQ1Agc2Vy dmVyIHJ1bnMgb24gdGhlIGhvc3Qgc2VydmluZyB0aGUgVk0gYW5kIHRoZSBuZXR3b3JrDQo+ PiAgICAgIGludGVyZmFjZSBzdXBwb3J0cyB0cmFuc21pdCBjaGVja3N1bSBvZmZsb2FkaW5n LiBTaW5jZSBkaGNsaWVudA0KPj4gICAgICBkb2Vzbid0IHVzZSBVRFAgc29ja2V0cyBidXQg YnBmIGRldmljZXMgdG8gcmVhZCB0aGUgcGFja2V0cywgdGhlDQo+PiAgICAgIGNoZWNrc3Vt IHdpbGwgYmUgaW5jb3JyZWN0IGFuZCBvbmx5IGNvbnRhaW4gdGhlIGNoZWNrc3VtIG9mIHRo ZQ0KPj4gICAgICBwc2V1ZG8gaGVhZGVyLg0KPj4NCj4+IFRoaXMgY291bGQgcG90ZW50aWFs bHkgYXBwbHkgdG8gb3RoZXIgYnBmLXVzaW5nIHRoaW5ncyAtLSB3aGljaCBpbmNsdWRlcyBk aGNwY2QuICBBbmQgeW91IGhhdmUgdHNvL2xybyB0dXJuZWQgb24uDQo+IEhpIEthcmwsDQo+ DQo+IHRoaXMgaXMgdHJ1ZS4gRG8gd2UgaGF2ZSBhbiBkaGNwZCBpbi10cmVlPyBPciBhcmUg eW91IGF3YXJlIG9mIG90aGVyIGluLXRyZWUNCj4gcHJvZ3JhbXMgd2hpY2ggdXNlIFVEUCB2 aWEgYnBmIGFuZCBub3QgdmlhIHRoZSBzb2NrZXQgaW50ZXJmYWNlPw0KPg0KPiBCZXN0IHJl Z2FyZHMNCj4gTWljaGFlbA0KDQpkaGNsaWVudCB1c2VzIGl0IGluIGJhc2UgYnV0IGRoY3A2 YyBpcywgSSBiZWxpZXZlLCBvdXQgb2YgcGFja2FnZXMvcG9ydHMgDQooYXMgaXMgZGhjcGNk IHdoaWNoIHJlcGxhY2VzIGJvdGggZGhjbGllbnQgYW5kIGRoY3A2YyBpbiB0ZXJtcyBvZiAN CmZ1bmN0aW9uYWxpdHkuKQ0KDQpPbmUgb2YgZGhjcDZjIG9yIGRoY3BjZCBpcyBuZWNlc3Nh cnkgdG8gZ2V0IGEgZGVsZWdhdGlvbiBmcm9tIGFuIElTUDsgDQp5b3UgY2FuIGdldCBhIFNM QUNDIGFkZHJlc3Mgd2l0aG91dCBlaXRoZXIgc2ltcGx5IGJ5IGVuYWJsaW5nIGl0IHN1Y2gg YXM6DQoNCmlmY29uZmlnX21jZTBfaXB2Nj0iaW5ldDYgYWNjZXB0X3J0YWR2Ig0KcnRzb2xk X2VuYWJsZT0iWUVTIg0KDQpUaGF0IGlzIHN1ZmZpY2llbnQgb24gYSBjbGllbnQgbWFjaGlu ZSBpZiB5b3VyIGdhdGV3YXkgaGFuZHMgb3V0IA0KYWRkcmVzc2VzIGJhc2VkIG9uIFNMQUND LCBidXQgdGhlIGdhdGV3YXkgdGhlbiBoYXMgdG8gZ2V0IHRoZSB1cHN0cmVhbSANCmRlbGVn YXRpb24gKGFuZCBydW4gcnRhZHZkIGluIG9yZGVyIHRvIHNlbmQgdGhlIHJvdXRpbmcgZGF0 YSBvdXQgb24gdGhlIA0KbG9jYWwgc2lkZSBzbyB5b3VyIFNMQUNDIGNsaWVudCBjYW4gcGlj ayBpdCB1cCkgc28gdW5sZXNzIHlvdSBoYXZlIHRoYXQgDQpkZWxlZ2F0aW9uIGhhcmQtY29k ZWQgaW4geW91ciBlZGdlIGRldmljZSBvbiB0aGUgb3V0c2lkZSBpbnRlcmZhY2Ugb25lIA0K b2YgdGhlIGFib3ZlIGhhcyB0byBiZSBydW5uaW5nIG9uIHRoZSBnYXRld2F5LCBwcmVzdW1p bmcgaXRzIGEgRnJlZUJTRCANCmdhdGV3YXkgb2YgY291cnNlLg0KDQotLSANCkthcmwgRGVu bmluZ2VyDQprYXJsQGRlbm5pbmdlci5uZXQNCi9UaGUgTWFya2V0IFRpY2tlci8NCi9bUy9N SU1FIGVuY3J5cHRlZCBlbWFpbCBwcmVmZXJyZWRdLw0K --------------CknxG15mTk2WoeT20Nvkf8Ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9/15/2025 13:00, Michael Tuexen wrote:
On 15. Sep 2025, at 14:59,=
 Karl Denninger <karl@denninger.net> wrote:

Hmmmmm.... just came in via git pull:
commit ffd956a3918cd5e64c8850eb77247428a29f7221
Author: Michael Tuexen <tuexen@FreeBSD.org>
Date:   Wed Sep 10 17:13:35 2025 +0200

    dhclient: improve UDP checksum handling

    When sending UDP packets:
    * compute the checksum in the correct order. This only has an impact
      if the length of the payload is odd.
    * don't send packet with a checksum of zero, use 0xffff instead as
      required.
    When receiving UDP packets:
    * don't do any computations when the checksum is zero.
    * compute the checksum in the correct order. This only has an impact
      if the length of the payload is odd.
    * when computing the checksum, store the pseudo header checksum
    * if the checksum is computed as zero, use 0xffff instead.
    * also accept packets, when the checksum in the packet is the pseudo
      header checksum.
    The last point fixes a problem when the DHCP client runs in a VM,
    the DHCP server runs on the host serving the VM and the network
    interface supports transmit checksum offloading. Since dhclient
    doesn't use UDP sockets but bpf devices to read the packets, the
    checksum will be incorrect and only contain the checksum of the
    pseudo header.

This could potentially apply to other bpf-using things -- which includes =
dhcpcd.  And you have tso/lro turned on.

Hi Karl,

this is true. Do we have an dhcpd in-tree? Or are you aware of other in-t=
ree
programs which use UDP via bpf and not via the socket interface?

Best regards
Michael

dhclient uses it in base but dhcp6c is, I believe, out of packages/ports (as is dhcpcd which replaces both dhclient and dhcp6c in terms of functionality.)

One of dhcp6c or dhcpcd is necessary to get a delegation from an ISP; you can get a SLACC address without either simply by enabling it such as:

ifconfig_mce0_ipv6=3D"inet6 accept_rtadv"
rtsold_enable=3D"YES"

That is sufficient on a client machine if your gateway hands out addresses based on SLACC, but the gateway then has to get the upstream delegation (and run rtadvd in order to send the routing data out on the local side so your SLACC client can pick it up) so unless you have that delegation hard-coded in your edge device on the outside interface one of the above has to be running on the gateway, presuming its a FreeBSD gateway of course.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]<= /div> --------------CknxG15mTk2WoeT20Nvkf8Ae-- --------------ms000602070504090303080608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC C4owggWZMIIDgaADAgECAhRZU8dKdMneRI1Vq5kv0k54Q5rQuDANBgkqhkiG9w0BAQsFADB2 MQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRYwFAYDVQQKDA1EZW5uaW5nZXIu TmV0MRcwFQYDVQQDDA5EZW5uaW5nZXIgUm9vdDEiMCAGCSqGSIb3DQEJARYTYWRtaW5AZGVu bmluZ2VyLm5ldDAeFw0yNDA1MDkyMTA4MDNaFw00NDA1MDQyMTA4MDNaMF0xCzAJBgNVBAYT AlVTMRIwEAYDVQQIDAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNV BAMMGURlbm5pbmdlci5OZXQgU2lnbmluZyBJbnQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDbR0tSiuLG5HPfo+cWtdeYQ8jc8Bjfuo0GTcNRT0glHnH1apUtInIktUknEZDH ohahInN+mMBdKg54FCHOiYZrJbyxBIo9FwX7hRmOc+spxmSYWnOd2E/YcGInMK4ZpjPzldzB Yt1n3zygkhx2bssxTJS3x4nv1qAXfLSZd1VwqoQufifEoPyTtymkkvHLv86vLgqAqooM/cXc 4LSIQ5u2uM308n42r8RkKtp7X1v9fJW8oRZN2XnFZtiUPH44YY2rHqyN2Hea9Y3+TXbldXjo xhPHTA+JYVFq8KTmbQBqU7YcMhlIG0cSxPeFLMxnP6pqPcIVTAlK+a6YGRFppfjZAgMBAAGj ggE2MIIBMjAdBgNVHQ4EFgQUH+VuxXhBxaJAQrvDekwkH91hBi4wgbMGA1UdIwSBqzCBqIAU RFYC4p6L6KITnEvrpx2cyt+PcMmheqR4MHYxCzAJBgNVBAYTAlVTMRIwEAYDVQQIDAlUZW5u ZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5OZXQxFzAVBgNVBAMMDkRlbm5pbmdlciBSb290 MSIwIAYJKoZIhvcNAQkBFhNhZG1pbkBkZW5uaW5nZXIubmV0ghQZE7NBItWtQsCouuwU6jZ+ HPPwnjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+gLaAr hilodHRwOi8vd3d3LmRlbm5pbmdlci5uZXQvcm9vdC1yZXZva2VkLmNybDANBgkqhkiG9w0B AQsFAAOCAgEAfFbhPc82AfhyUqONs7IccYD36w+OP4nQgwfC4IWf3y/aQAZ2Zk6IITzYqwf7 PFM0bJRT3zi7xyetolqHDhfMJvnOQWpITZiyM/FSKwIvuBsy/uJUqPuqui4XQMYoSbAA1qmI MW/z7VZZHwaRFoeWE40UirYcf0fNcooBZ72bmd+iBaVyjtZvky0Vgcz0eC6e6LR5kNb23yC6 TkyQIlGyQkK5/afXUYFzk49rOHVbVyxW3oXRfq8Ow6HCrpDGAS8p84S04MFwBVAUfbe4aXs3 bampaI2LzKgkVywyFP14LSvvdjCfLYfnLy1Z9hm2EHMqNHA2tCGdRhWp2d7aZC1MYFqng0ZS fjPJjqHrI1qPU0p6k9A1GxAtrQlL2v/IUzUnMZkiawFV3qlxMGZf/kTYTUOcJhx1KU4zSLHu 80qO7ldRpp5gHssCAGFbeTu2gp6LxfmaFhLPDBJ1VGfdPx9lUrU/9OcoHczcl5x2Rb8IUZyX 9elzP5WdAU8p5R/DLlOAq24VcabhFtYBCA2dOESLupSfWKNQuJCN/1gz7ysSc+mjnnPV77IO mpszJfkFFJEDNJlGIVKX1vwwygtC/9Ulox8frgbZlRAYAgDc/YbOBFxticVVre0Y3Ujx6Kzb tkgZRlgfdZWbT1W5smncqJxg5qAL8e/yTb3fCe2nJ0jhiP4wggXpMIIE0aADAgECAhMAmNFt CiCF3j+FwQLYtBTmGjzkMA0GCSqGSIb3DQEBCwUAMF0xCzAJBgNVBAYTAlVTMRIwEAYDVQQI DAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNVBAMMGURlbm5pbmdl ci5OZXQgU2lnbmluZyBJbnQwHhcNMjQwNTEwMTkyNjU5WhcNMjkwNTA5MTkyNjU5WjBXMQsw CQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRcwFQYDVQQKDA5LYXJsIERlbm5pbmdl cjEbMBkGA1UEAwwSa2FybEBkZW5uaW5nZXIubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8A MIICCgKCAgEAvh1UssVbSYctzobPjwBkbjv/w4WvQNepeRTwE6+sLnXvc41+X9pa5EclPL4Q l02Vu1m71mSqXGfK9HbWZoivbhefBHOoYb35MSc24PelhwcORbpneWoWc7giQ7QgFlvEe/yj fs8M0H9fgdzFS5m2lwBQbis8kioSjHB2yt/8I1GE4Mvt1Cur9kga6ML5FAQvo8TYN1stdhrE 13FEv/BWCF4FVT4H2Wa2ySW+R1jkKb74SC6Twg98bGCRTShD5bVylh0+0LXNhzaopIDcI/KK jm/j3mRjIlmqbGrSpvJsbjjhjhAYQKE1U8FB5TDU4OkFAibblhQit/KjgspPR2o/vOpVFPER uhZEV1oDGzUJtZlkREIcN2sYBi0p7Y4585ya+b7L10mEenPlyi3eSkGXEuiy/BR2DY6lShwW DPoQ5602TKmttCSwBdWGoLrQ4jEVEVNt4lku2wPbTHF3KpHJU0g7RbcWoUYn10SOxKathkir hF3v9U32+QhPELGwqRrH0sL9rWf0qalRtPDHUYl8TebZmYkFqNeSMlqHijl5f4SsQPSj7gx5 4F19Ntm9ZcvuWTmW8QQGWTKHeMuG+BYkVIUSPe6/ZQsbD/xDx7rkyGfNgWIa4W7Wm/B7kaNq H53tk3wFmNgZQOxMTPF0oTHfW0T2azU6JD0D1AlgoAnSAE0CAwEAAaOCAaYwggGiMDoGCCsG AQUFBwEBBC4wLDAqBggrBgEFBQcwAYYeaHR0cDovL29jc3AuZGVubmluZ2VyLm5ldDo3Nzc3 MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAzBglghkgBhvhCAQ0EJhYkT3BlblNTTCBHZW5lcmF0ZWQgQ2xpZW50IENlcnRp ZmljYXRlMB0GA1UdDgQWBBSxJZjVnlYLAT3uzvDYgc4742J6UTCBswYDVR0jBIGrMIGogBQf 5W7FeEHFokBCu8N6TCQf3WEGLqF6pHgwdjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5l c3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLk5ldDEXMBUGA1UEAwwORGVubmluZ2VyIFJvb3Qx IjAgBgkqhkiG9w0BCQEWE2FkbWluQGRlbm5pbmdlci5uZXSCFFlTx0p0yd5EjVWrmS/STnhD mtC4MB0GA1UdEQQWMBSBEmthcmxAZGVubmluZ2VyLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEA TrQ45/tBN3SiuqItFv/V+CF3h7Hxe0YLsL+A/P+q9ZhxIscaNjaclgQhPA+rUr+l8DGoXJ/w yAl1E0SSBK+9phIc/9xFOBg3rCy4ngubzP+lHS1t03nMCBSUNsu5qPzqLBPiKaPabUu3Gr9o koRezSszgM3/zNJfr8cMO93csCK/fBccsMx5q+3nxB5XeT7UciicjfEzUA4m2mQxBmGk9SSU 147Gy8UmdSq57Tw82KqUrQ1pJ6IOzVPLREpwlqGbHykSU3MwtPYPtfQeFVjvO/XcWvoFQjbV UyhzAqMMYFudxoVLlJQiAgU38OScTLDgKxCO41h7VOjb2mss0zHndzGCBZUwggWRAgEBMHQw XTELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2Vy Lm5ldDEiMCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC 2LQU5ho85DANBglghkgBZQMEAgMFAKCCAvIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMjUwOTE1MTcxNjE3WjBPBgkqhkiG9w0BCQQxQgRANuiU3p70cu7r L00nkiIdXOHf5kUTwL3uPsJJpUCBjuorSqG6lSd0sk2c9UkTsL3Ua6EHPopSGR2jS2AQGzxF YDCBgwYJKwYBBAGCNxAEMXYwdDBdMQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2Vl MRYwFAYDVQQKDA1EZW5uaW5nZXIubmV0MSIwIAYDVQQDDBlEZW5uaW5nZXIuTmV0IFNpZ25p bmcgSW50AhMAmNFtCiCF3j+FwQLYtBTmGjzkMIGFBgsqhkiG9w0BCRACCzF2oHQwXTELMAkG A1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLm5ldDEi MCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC2LQU5ho8 5DCCAVcGCSqGSIb3DQEJDzGCAUgwggFEMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDQYIKoZIhvcNAwICAQUwDQYIKoZIhvcNAwICAQUwBwYFKw4DAgcwDQYIKoZI hvcNAwICAQUwBwYFKw4DAhowCwYJYIZIAWUDBAIBMAsGCWCGSAFlAwQCAjALBglghkgBZQME AgMwCwYJYIZIAWUDBAIEMAsGCWCGSAFlAwQCBzALBglghkgBZQMEAggwCwYJYIZIAWUDBAIJ MAsGCWCGSAFlAwQCCjALBgkqhkiG9w0BAQEwCwYJK4EFEIZIPwACMAgGBiuBBAELADAIBgYr gQQBCwEwCAYGK4EEAQsCMAgGBiuBBAELAzALBgkrgQUQhkg/AAMwCAYGK4EEAQ4AMAgGBiuB BAEOATAIBgYrgQQBDgIwCAYGK4EEAQ4DMA0GCSqGSIb3DQEBAQUABIICAA28NCRb7ivkl2dn TIgh4loxOn3h1un4d/1WLNSDzYFKnAtUpflEpyjWMm7J7+OvBKKj1NGXlzD6dyh09Ndzs9oi E9L1mre4moWQRK0y2Y7SQNLdjH4N+mCBlzI9mrUdMZqQkG6+0R6WFBefBiOkxjKlaI+G4smS j91QHy7Ems5u3x7vvzIF6gp1eidt90dUzHiZZjqjaJd494PoUaWkHJo4igGNNF0w/A74i57u ip+rRyjYQVdUGrgaJtcntz10c2a9hpuqIN5LekUJBducSvuRjdAXnfdcATxDio3Bgq5ZqgH8 8t0tSQTzoXiB7RtQlgHzl6Y2KJzGHZBhT+W1Nt7RmsS8C0e/mai3NK3PcPUkNwMqcgcJryCG UT4qrV6z+Mx3DgeW4qGpmD5Dx/cb7cjqWsSR8f6WNZRVaJ5geoO71+QilEpPEs0HYGE+pm6J qJclsDZGh70cDJVFdn8nHRPjtVfDBF/H3v56C/s8zbD9DhfBsLun5tb12XXseGDD5x4FRDFO n/YU5WW6cosuNmuTTGRZqPI7SvXa5UDm6upk4qkrOx/OO4/cqwx1rB4ugu12uwv+I1mVBH36 sc4uYkG/tybq3280GXwO3Ok4kWgX1FL5AXNttLLwj+TsrKVZ6ojOsY7ku3V7T7EWyKV61w2H boJ9WZiE1pbENaASS0prAAAAAAAA --------------ms000602070504090303080608-- From nobody Mon Sep 15 17:20:16 2025 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 4cQWzL3KgZz67ffd for ; Mon, 15 Sep 2025 17:21:34 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.95.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQWzL0FQLz3rqZ for ; Mon, 15 Sep 2025 17:21:33 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Authentication-Results: mx1.freebsd.org; none dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:In-Reply-To:References; bh=LZDqTC/skJ2wIIrdOzI3wWgOOTFMJuhXrSIBKFgOL/A=; b=JBqM6CvXeo1uWd7VnGtrYgJx7rvMFgL+Ssn8SeXgcw+UQFDAWUBqirN1Odn0/hlR4rqbF5+ex76f1iJdZPIhprAk6ctY3LBIJOP1bJU7rWXgZR3pV9tSdgxr0TdPSUP7jBuo0sYO/pedZxR/KTC5s7Oa4je7+BKJtUCrKQyAHz1ZX9ANF+unzyP2XwhYoT/GmAtS6dXUf6o6TnB94Kr5tXlca3jds6dqZTkz2qMef5rXHRZkB8w7WeOgTq 4j4jjwJNo4PHAmV71tPUzSdMZn+rOrX53hy2g4GeFTfBmb5SB+mhKXOjlHVqSKG2kCkpbnm8C3TckkJ11oqs81PSUjww== Received: from mail.distal.com (pool-108-51-233-124.washdc.fios.verizon.net [108.51.233.124]) by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256) ; Mon, 15 Sep 2025 17:21:22 +0000 Received: from smtpclient.apple ( [2600:4040:2c9d:5220:4179:a2c2:d96f:6397]) by tristain.distal.com (OpenSMTPD) with ESMTPSA id 91c44045 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Mon, 15 Sep 2025 13:21:12 -0400 (EDT) From: Chris Ross Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2D098B07-C004-43DE-A975-B7EF1A9DC0F5" 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 \(3826.700.81\)) Subject: Re: IPv6 networking problems in 14.3 Date: Mon, 15 Sep 2025 13:20:16 -0400 In-Reply-To: <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> Cc: freebsd-net@freebsd.org, Roy Marples To: Karl Denninger References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <6fce77fb-9ba8-4c7b-bb9b-0e337d91f278@denninger.net> <1780EFAC-DA9C-4593-BE37-28E7FFCE4388@distal.com> <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[freebsd] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cQWzL0FQLz3rqZ --Apple-Mail=_2D098B07-C004-43DE-A975-B7EF1A9DC0F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 15, 2025, at 08:59, Karl Denninger wrote: >=20 > Hmmmmm.... just came in via git pull: >=20 > dhclient: improve UDP checksum handling >=20 > This could potentially apply to other bpf-using things -- which = includes dhcpcd. And you have tso/lro turned on. >=20 > It is a patch to dhclient, not dhcpcd but does the same issue = potentially apply? >=20 I don=E2=80=99t know, but I think that isn=E2=80=99t my problem. It = seems like the NS that dhcpcd is sending is alright, and tcpdump doesn=E2=80=99t see an NA = coming back in at all. - Chris --Apple-Mail=_2D098B07-C004-43DE-A975-B7EF1A9DC0F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 15, 2025, at 08:59, Karl Denninger = <karl@denninger.net> wrote:

=20 =20

Hmmmmm.... just came in via git pull:

    = dhclient: improve UDP checksum handling

This could potentially apply to other bpf-using things -- = which includes dhcpcd.  And you have tso/lro turned on.

It is = a patch to dhclient, not dhcpcd but does the same issue potentially apply?


I = don=E2=80=99t know, but I think that isn=E2=80=99t my problem.  It = seems like the NS that
dhcpcd is sending is alright, and = tcpdump doesn=E2=80=99t see an NA coming
back in at = all.

- Chris

= --Apple-Mail=_2D098B07-C004-43DE-A975-B7EF1A9DC0F5-- From nobody Mon Sep 15 17:28:51 2025 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 4cQX815KKFz67g40 for ; Mon, 15 Sep 2025 17:29:05 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Certum Domain Validation CA SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQX811t4Yz3tC7 for ; Mon, 15 Sep 2025 17:29:05 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:a17f:b5da:da9c:c18a]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 31B1D721E281C; Mon, 15 Sep 2025 19:28:52 +0200 (CEST) Content-Type: text/plain; charset=us-ascii 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 \(3826.700.81\)) Subject: Re: IPv6 networking problems in 14.3 From: Michael Tuexen In-Reply-To: Date: Mon, 15 Sep 2025 19:28:51 +0200 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <85063FCE-0FCE-4E4D-B03D-2B67FCCC21B7@lurchi.franken.de> References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <6fce77fb-9ba8-4c7b-bb9b-0e337d91f278@denninger.net> <1780EFAC-DA9C-4593-BE37-28E7FFCE4388@distal.com> <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> <75B331C2-856A-4977-ADCD-D7FA6854AA03@FreeBSD.org> To: Karl Denninger X-Mailer: Apple Mail (2.3826.700.81) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cQX811t4Yz3tC7 > On 15. Sep 2025, at 19:16, Karl Denninger wrote: >=20 > On 9/15/2025 13:00, Michael Tuexen wrote: >>> On 15. Sep 2025, at 14:59, Karl Denninger = wrote: >>>=20 >>> Hmmmmm.... just came in via git pull: >>> commit ffd956a3918cd5e64c8850eb77247428a29f7221 >>> Author: Michael Tuexen >>> Date: Wed Sep 10 17:13:35 2025 +0200 >>>=20 >>> dhclient: improve UDP checksum handling >>>=20 >>> When sending UDP packets: >>> * compute the checksum in the correct order. This only has an impact >>> if the length of the payload is odd. >>> * don't send packet with a checksum of zero, use 0xffff instead as >>> required. >>> When receiving UDP packets: >>> * don't do any computations when the checksum is zero. >>> * compute the checksum in the correct order. This only has an impact >>> if the length of the payload is odd. >>> * when computing the checksum, store the pseudo header checksum >>> * if the checksum is computed as zero, use 0xffff instead. >>> * also accept packets, when the checksum in the packet is the pseudo >>> header checksum. >>> The last point fixes a problem when the DHCP client runs in a VM, >>> the DHCP server runs on the host serving the VM and the network >>> interface supports transmit checksum offloading. Since dhclient >>> doesn't use UDP sockets but bpf devices to read the packets, the >>> checksum will be incorrect and only contain the checksum of the >>> pseudo header. >>>=20 >>> This could potentially apply to other bpf-using things -- which = includes dhcpcd. And you have tso/lro turned on. >>>=20 >> Hi Karl, >>=20 >> this is true. Do we have an dhcpd in-tree? Or are you aware of other = in-tree >> programs which use UDP via bpf and not via the socket interface? >>=20 >> Best regards >> Michael > dhclient uses it in base but dhcp6c is, I believe, out of = packages/ports (as is dhcpcd which replaces both dhclient and dhcp6c in = terms of functionality.) OK. But this is not something I can easily investigate and possibly fix, = since that software is not in the tree I can make changes to. I think fixes to = ports should go upstream. Best regards Michael > One of dhcp6c or dhcpcd is necessary to get a delegation from an ISP; = you can get a SLACC address without either simply by enabling it such = as: > ifconfig_mce0_ipv6=3D"inet6 accept_rtadv" > rtsold_enable=3D"YES" > That is sufficient on a client machine if your gateway hands out = addresses based on SLACC, but the gateway then has to get the upstream = delegation (and run rtadvd in order to send the routing data out on the = local side so your SLACC client can pick it up) so unless you have that = delegation hard-coded in your edge device on the outside interface one = of the above has to be running on the gateway, presuming its a FreeBSD = gateway of course. > --=20 > Karl Denninger > karl@denninger.net > The Market Ticker > [S/MIME encrypted email preferred] From nobody Mon Sep 15 17:59:15 2025 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 4cQXqT2VLnz67jwL for ; Mon, 15 Sep 2025 17:59:49 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4cQXqS0KKqz3yfB for ; Mon, 15 Sep 2025 17:59:48 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (unknown [162.81.137.111]) by colo1.denninger.net (Postfix) with ESMTP id 8FD0AB05B1 for ; Mon, 15 Sep 2025 13:58:11 -0400 (EDT) Received: by denninger.net (Postfix, from userid 58) id C3225457C3F; Mon, 15 Sep 2025 13:59:16 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on NewFS.denninger.net X-Spam-Level: X-Spam-Status: No, score=-4.9 required=3.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=no autolearn_force=no version=4.0.1 X-Spam-Report: * -3.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message Received: from [192.168.10.15] (D5.Denninger.Net [192.168.10.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 83CB5457D00 for ; Mon, 15 Sep 2025 13:59:16 -0400 (EDT) Message-ID: Date: Mon, 15 Sep 2025 13:59:15 -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: IPv6 networking problems in 14.3 To: freebsd-net@freebsd.org References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <6fce77fb-9ba8-4c7b-bb9b-0e337d91f278@denninger.net> <1780EFAC-DA9C-4593-BE37-28E7FFCE4388@distal.com> <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> Content-Language: en-US From: Karl Denninger In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090009030509060101060509" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.67 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_LONG(-0.98)[-0.980]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; NEURAL_SPAM_MEDIUM(0.35)[0.348]; NEURAL_HAM_SHORT(-0.24)[-0.235]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; MIME_BASE64_TEXT(0.10)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; FREEFALL_USER(0.00)[karl]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4cQXqS0KKqz3yfB This is a cryptographically signed message in MIME format. --------------ms090009030509060101060509 Content-Type: multipart/alternative; boundary="------------rnd7wBzYFjzMSmy0OoB1CsGL" --------------rnd7wBzYFjzMSmy0OoB1CsGL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gOS8xNS8yMDI1IDEzOjIwLCBDaHJpcyBSb3NzIHdyb3RlOg0KPg0KPj4gT24gU2VwIDE1 LCAyMDI1LCBhdCAwODo1OSwgS2FybCBEZW5uaW5nZXIgPGthcmxAZGVubmluZ2VyLm5ldD4g d3JvdGU6DQo+Pg0KPj4gSG1tbW1tLi4uLiBqdXN0IGNhbWUgaW4gdmlhIGdpdCBwdWxsOg0K Pj4NCj4+IMKgIMKgIGRoY2xpZW50OiBpbXByb3ZlIFVEUCBjaGVja3N1bSBoYW5kbGluZw0K Pj4NCj4+IFRoaXMgY291bGQgcG90ZW50aWFsbHkgYXBwbHkgdG8gb3RoZXIgYnBmLXVzaW5n IHRoaW5ncyAtLSB3aGljaCANCj4+IGluY2x1ZGVzIGRoY3BjZC7CoCBBbmQgeW91IGhhdmUg dHNvL2xybyB0dXJuZWQgb24uDQo+Pg0KPj4gSXQgaXMgYSBwYXRjaCB0byBkaGNsaWVudCwg bm90IGRoY3BjZCBidXQgZG9lcyB0aGUgc2FtZSBpc3N1ZSANCj4+IHBvdGVudGlhbGx5IGFw cGx5Pw0KPj4NCj4NCj4gSSBkb27igJl0IGtub3csIGJ1dCBJIHRoaW5rIHRoYXQgaXNu4oCZ dCBteSBwcm9ibGVtLiDCoEl0IHNlZW1zIGxpa2UgdGhlIE5TIA0KPiB0aGF0DQo+IGRoY3Bj ZCBpcyBzZW5kaW5nIGlzIGFscmlnaHQsIGFuZCB0Y3BkdW1wIGRvZXNu4oCZdCBzZWUgYW4g TkEgY29taW5nDQo+IGJhY2sgaW4gYXQgYWxsLg0KPg0KPiAtIENocmlzDQo+DQpVbmZvcnR1 bmF0ZWx5IHdpdGhvdXQgYmVpbmcgYWJsZSB0byBzbm9vcCBvbiB0aGUgT05UJ3MgZ2xhc3Mg c2lkZSB0aGF0J3MgDQpoYXJkIHRvIGRpYWdub3NlOyBhcmUgdGhleSBzZW5kaW5nIGl0IGF0 IGFsbCwgYXJlIHRoZXkgc2VuZGluZyBpdCB0byB0aGUgDQp3cm9uZyBwbGFjZSwgZG9lcyB0 aGUgT05UIGhhdmUgYSBtYXAgdGhhdCdzIHdyb25nIGJldHdlZW4gaXRzIGZpYmVyIA0KaW50 ZXJmYWNlIGFuZCB0aGUgTUFDIGNvbm5lY3RlZCB0byBpdCwgZXRjLg0KDQpGb3J0dW5hdGVs eSB0aGUgSVNQIEknbSBjb25uZWN0ZWQgdG8gd2hlbiB0aGlzIHNvcnQgb2YgdGhpbmcgaGFw cGVuZWQgdG8gDQptZSBoYWQgcGVvcGxlIHdobyBhY3R1YWxseSBrbmV3IHdoYXQgdGhleSB3 ZXJlIGRvaW5nIGFuZCB3ZXJlIGFibGUgdG8gDQpzbm9vcCB0aGUgcGFja2V0cyBjb21pbmcg YW5kIGdvaW5nIG9uIHRoZWlyIHNpZGUgd2hlbiBJIHdhcyBvbiB0aGUgcGhvbmUgDQp3aXRo IHRoZW0uwqAgR29vZCBsdWNrIGdldHRpbmcgYSBsYXJnZSBJU1AgbGlrZSBWZXJpem9uIHRv IGNvbm5lY3QgeW91IHRvIA0Kc29tZW9uZSB3aXRoIHRoZSBhcHByb3ByaWF0ZSBsZXZlbCBv ZiBhY2Nlc3MgaW50byB0aGVpciBnZWFyIHRvIGJlIGFibGUgDQp0byBkbyB0aGF0LsKgIEl0 IHRvb2sgbWUgYSBjb3VwbGUgb2Ygcm91bmRzIHdpdGggS1VCIGhlcmUgYmVmb3JlIHRoZXkg DQp3ZW50IGJleW9uZCAid2UgY2xlYXJlZCBvdXIgQVJQIHRhYmxlIGVudHJ5IGZvciB5b3Vy IE9OVCBidXQgd2UgZG9uJ3QgDQprbm93IHdoeSBpdCBkaWQgdGhhdCIgdG8gZ2V0dGluZyBz b21lb25lIG9uIHRoZSBsaW5lIHRoYXQgYWN0dWFsbHkgd2FzIA0Kd2lsbGluZyBhbmQgYWJs ZSB0byBzbm9vcCB0aGUgdHJhZmZpYyBhbmQgZGV0ZXJtaW5lIFdIWSBpdCBoYXBwZW5lZC4N Cg0KVGhlIGludGVyZXN0aW5nIHBhcnQgaW4gdGhpcyBjYXNlIChidXQgcHJvYmFibHkgdGhl IGZvcnR1bmF0ZSBwYXJ0ISkgd2FzIA0KdGhhdCB0aGVpciBpbmZyYXN0cnVjdHVyZSBmb3Ig ZGVsZWdhdGluZyBhbiBJUHY0IChzaW5nbGUgYWRkcmVzcywgeW91IGRvIA0KdGhlIE5BVCkg YW5kIC81NiBJUHY2IGlzIGFwcGFyZW50bHkgZW50aXJlbHkgZGlzdGluY3QgdGh1cyB0aGF0 IG9uZSBoYWQgDQphIGhpc3N5IGZpdCBkaWRuJ3QgcHJldmVudCB0aGUgb3RoZXIgZnJvbSBj b21pbmcgdXAgYW5kIGZ1bmN0aW9uaW5nLg0KDQotLSANCkthcmwgRGVubmluZ2VyDQprYXJs QGRlbm5pbmdlci5uZXQNCi9UaGUgTWFya2V0IFRpY2tlci8NCi9bUy9NSU1FIGVuY3J5cHRl ZCBlbWFpbCBwcmVmZXJyZWRdLw0K --------------rnd7wBzYFjzMSmy0OoB1CsGL Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9/15/2025 13:20, Chris Ross wrote:<= br>

On Sep 15, 2025, at 08:59, Karl Denninger <karl@denninger.net> wrote:

Hmmmmm.... just came in via git pull:

=C2=A0 =C2=A0 dhclient: improve UDP checksum handling
This could potentially apply to other bpf-using things -- which includes dhcpcd.=C2=A0 And you have tso/lro turn= ed on.

It is a patch to dhclient, not dhcpcd but does the same issue potentially apply?


I don=E2=80=99t know, but I think that isn=E2=80=99t my problem. = =C2=A0It seems like the NS that
dhcpcd is sending is alright, and tcpdump doesn=E2=80=99t see = an NA coming
back in at all.

- Chris

Unfortunately without being able to snoop on the ONT's glass side that's hard to diagnose; are they sending it at all, are they sending it to the wrong place, does the ONT have a map that's wrong between its fiber interface and the MAC connected to it, etc.

Fortunately the ISP I'm connected to when this sort of thing happened to me had people who actually knew what they were doing and were able to snoop the packets coming and going on their side when I was on the phone with them.=C2=A0 Good luck getting a large = ISP like Verizon to connect you to someone with the appropriate level of access into their gear to be able to do that.=C2=A0 It took me a= couple of rounds with KUB here before they went beyond "we cleared our ARP table entry for your ONT but we don't know why it did that" to getting someone on the line that actually was willing and able to snoop the traffic and determine WHY it happened.

The interesting part in this case (but probably the fortunate part!) was that their infrastructure for delegating an IPv4 (single address, you do the NAT) and /56 IPv6 is apparently entirely distinct thus that one had a hissy fit didn't prevent the other from coming up and functioning.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]<= /div> --------------rnd7wBzYFjzMSmy0OoB1CsGL-- --------------ms090009030509060101060509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC C4owggWZMIIDgaADAgECAhRZU8dKdMneRI1Vq5kv0k54Q5rQuDANBgkqhkiG9w0BAQsFADB2 MQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRYwFAYDVQQKDA1EZW5uaW5nZXIu TmV0MRcwFQYDVQQDDA5EZW5uaW5nZXIgUm9vdDEiMCAGCSqGSIb3DQEJARYTYWRtaW5AZGVu bmluZ2VyLm5ldDAeFw0yNDA1MDkyMTA4MDNaFw00NDA1MDQyMTA4MDNaMF0xCzAJBgNVBAYT AlVTMRIwEAYDVQQIDAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNV BAMMGURlbm5pbmdlci5OZXQgU2lnbmluZyBJbnQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDbR0tSiuLG5HPfo+cWtdeYQ8jc8Bjfuo0GTcNRT0glHnH1apUtInIktUknEZDH ohahInN+mMBdKg54FCHOiYZrJbyxBIo9FwX7hRmOc+spxmSYWnOd2E/YcGInMK4ZpjPzldzB Yt1n3zygkhx2bssxTJS3x4nv1qAXfLSZd1VwqoQufifEoPyTtymkkvHLv86vLgqAqooM/cXc 4LSIQ5u2uM308n42r8RkKtp7X1v9fJW8oRZN2XnFZtiUPH44YY2rHqyN2Hea9Y3+TXbldXjo xhPHTA+JYVFq8KTmbQBqU7YcMhlIG0cSxPeFLMxnP6pqPcIVTAlK+a6YGRFppfjZAgMBAAGj ggE2MIIBMjAdBgNVHQ4EFgQUH+VuxXhBxaJAQrvDekwkH91hBi4wgbMGA1UdIwSBqzCBqIAU RFYC4p6L6KITnEvrpx2cyt+PcMmheqR4MHYxCzAJBgNVBAYTAlVTMRIwEAYDVQQIDAlUZW5u ZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5OZXQxFzAVBgNVBAMMDkRlbm5pbmdlciBSb290 MSIwIAYJKoZIhvcNAQkBFhNhZG1pbkBkZW5uaW5nZXIubmV0ghQZE7NBItWtQsCouuwU6jZ+ HPPwnjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+gLaAr hilodHRwOi8vd3d3LmRlbm5pbmdlci5uZXQvcm9vdC1yZXZva2VkLmNybDANBgkqhkiG9w0B AQsFAAOCAgEAfFbhPc82AfhyUqONs7IccYD36w+OP4nQgwfC4IWf3y/aQAZ2Zk6IITzYqwf7 PFM0bJRT3zi7xyetolqHDhfMJvnOQWpITZiyM/FSKwIvuBsy/uJUqPuqui4XQMYoSbAA1qmI MW/z7VZZHwaRFoeWE40UirYcf0fNcooBZ72bmd+iBaVyjtZvky0Vgcz0eC6e6LR5kNb23yC6 TkyQIlGyQkK5/afXUYFzk49rOHVbVyxW3oXRfq8Ow6HCrpDGAS8p84S04MFwBVAUfbe4aXs3 bampaI2LzKgkVywyFP14LSvvdjCfLYfnLy1Z9hm2EHMqNHA2tCGdRhWp2d7aZC1MYFqng0ZS fjPJjqHrI1qPU0p6k9A1GxAtrQlL2v/IUzUnMZkiawFV3qlxMGZf/kTYTUOcJhx1KU4zSLHu 80qO7ldRpp5gHssCAGFbeTu2gp6LxfmaFhLPDBJ1VGfdPx9lUrU/9OcoHczcl5x2Rb8IUZyX 9elzP5WdAU8p5R/DLlOAq24VcabhFtYBCA2dOESLupSfWKNQuJCN/1gz7ysSc+mjnnPV77IO mpszJfkFFJEDNJlGIVKX1vwwygtC/9Ulox8frgbZlRAYAgDc/YbOBFxticVVre0Y3Ujx6Kzb tkgZRlgfdZWbT1W5smncqJxg5qAL8e/yTb3fCe2nJ0jhiP4wggXpMIIE0aADAgECAhMAmNFt CiCF3j+FwQLYtBTmGjzkMA0GCSqGSIb3DQEBCwUAMF0xCzAJBgNVBAYTAlVTMRIwEAYDVQQI DAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNVBAMMGURlbm5pbmdl ci5OZXQgU2lnbmluZyBJbnQwHhcNMjQwNTEwMTkyNjU5WhcNMjkwNTA5MTkyNjU5WjBXMQsw CQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRcwFQYDVQQKDA5LYXJsIERlbm5pbmdl cjEbMBkGA1UEAwwSa2FybEBkZW5uaW5nZXIubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8A MIICCgKCAgEAvh1UssVbSYctzobPjwBkbjv/w4WvQNepeRTwE6+sLnXvc41+X9pa5EclPL4Q l02Vu1m71mSqXGfK9HbWZoivbhefBHOoYb35MSc24PelhwcORbpneWoWc7giQ7QgFlvEe/yj fs8M0H9fgdzFS5m2lwBQbis8kioSjHB2yt/8I1GE4Mvt1Cur9kga6ML5FAQvo8TYN1stdhrE 13FEv/BWCF4FVT4H2Wa2ySW+R1jkKb74SC6Twg98bGCRTShD5bVylh0+0LXNhzaopIDcI/KK jm/j3mRjIlmqbGrSpvJsbjjhjhAYQKE1U8FB5TDU4OkFAibblhQit/KjgspPR2o/vOpVFPER uhZEV1oDGzUJtZlkREIcN2sYBi0p7Y4585ya+b7L10mEenPlyi3eSkGXEuiy/BR2DY6lShwW DPoQ5602TKmttCSwBdWGoLrQ4jEVEVNt4lku2wPbTHF3KpHJU0g7RbcWoUYn10SOxKathkir hF3v9U32+QhPELGwqRrH0sL9rWf0qalRtPDHUYl8TebZmYkFqNeSMlqHijl5f4SsQPSj7gx5 4F19Ntm9ZcvuWTmW8QQGWTKHeMuG+BYkVIUSPe6/ZQsbD/xDx7rkyGfNgWIa4W7Wm/B7kaNq H53tk3wFmNgZQOxMTPF0oTHfW0T2azU6JD0D1AlgoAnSAE0CAwEAAaOCAaYwggGiMDoGCCsG AQUFBwEBBC4wLDAqBggrBgEFBQcwAYYeaHR0cDovL29jc3AuZGVubmluZ2VyLm5ldDo3Nzc3 MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAzBglghkgBhvhCAQ0EJhYkT3BlblNTTCBHZW5lcmF0ZWQgQ2xpZW50IENlcnRp ZmljYXRlMB0GA1UdDgQWBBSxJZjVnlYLAT3uzvDYgc4742J6UTCBswYDVR0jBIGrMIGogBQf 5W7FeEHFokBCu8N6TCQf3WEGLqF6pHgwdjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5l c3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLk5ldDEXMBUGA1UEAwwORGVubmluZ2VyIFJvb3Qx IjAgBgkqhkiG9w0BCQEWE2FkbWluQGRlbm5pbmdlci5uZXSCFFlTx0p0yd5EjVWrmS/STnhD mtC4MB0GA1UdEQQWMBSBEmthcmxAZGVubmluZ2VyLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEA TrQ45/tBN3SiuqItFv/V+CF3h7Hxe0YLsL+A/P+q9ZhxIscaNjaclgQhPA+rUr+l8DGoXJ/w yAl1E0SSBK+9phIc/9xFOBg3rCy4ngubzP+lHS1t03nMCBSUNsu5qPzqLBPiKaPabUu3Gr9o koRezSszgM3/zNJfr8cMO93csCK/fBccsMx5q+3nxB5XeT7UciicjfEzUA4m2mQxBmGk9SSU 147Gy8UmdSq57Tw82KqUrQ1pJ6IOzVPLREpwlqGbHykSU3MwtPYPtfQeFVjvO/XcWvoFQjbV UyhzAqMMYFudxoVLlJQiAgU38OScTLDgKxCO41h7VOjb2mss0zHndzGCBZUwggWRAgEBMHQw XTELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2Vy Lm5ldDEiMCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC 2LQU5ho85DANBglghkgBZQMEAgMFAKCCAvIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMjUwOTE1MTc1OTE1WjBPBgkqhkiG9w0BCQQxQgRAfgt0PMcVFldp L3KoX1n3+wEb0apnek9OxQczdqXo+p3LS1Ec5GG8+jFSq34/NwswRzcwoQHwYb24WNv9x3an FzCBgwYJKwYBBAGCNxAEMXYwdDBdMQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2Vl MRYwFAYDVQQKDA1EZW5uaW5nZXIubmV0MSIwIAYDVQQDDBlEZW5uaW5nZXIuTmV0IFNpZ25p bmcgSW50AhMAmNFtCiCF3j+FwQLYtBTmGjzkMIGFBgsqhkiG9w0BCRACCzF2oHQwXTELMAkG A1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLm5ldDEi MCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC2LQU5ho8 5DCCAVcGCSqGSIb3DQEJDzGCAUgwggFEMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI KoZIhvcNAwcwDQYIKoZIhvcNAwICAQUwDQYIKoZIhvcNAwICAQUwBwYFKw4DAgcwDQYIKoZI hvcNAwICAQUwBwYFKw4DAhowCwYJYIZIAWUDBAIBMAsGCWCGSAFlAwQCAjALBglghkgBZQME AgMwCwYJYIZIAWUDBAIEMAsGCWCGSAFlAwQCBzALBglghkgBZQMEAggwCwYJYIZIAWUDBAIJ MAsGCWCGSAFlAwQCCjALBgkqhkiG9w0BAQEwCwYJK4EFEIZIPwACMAgGBiuBBAELADAIBgYr gQQBCwEwCAYGK4EEAQsCMAgGBiuBBAELAzALBgkrgQUQhkg/AAMwCAYGK4EEAQ4AMAgGBiuB BAEOATAIBgYrgQQBDgIwCAYGK4EEAQ4DMA0GCSqGSIb3DQEBAQUABIICAIDLbrkjtapr4R4A BRNDGRXGLZeeu9YfExmWQrN/mjyArNt6F/68LHQWGDSQ5QNBW5Pspbq79llhsSzapNcJGs5s 1MBoQNbnsPSIcn+gfXjp69V8BwFwgUNlCfYrwxsfzseGUBUWLr1YkmjQEYpZfqCoPLg2ac61 f7h6epHsbpM+wiH0doG83VChjt7wGe5olv0Vpf4QaeMRbP8O6ccvmLqxKAN7dLDmJfl5hx8R FqJYBKozRdE+90/8E6rrVyo3swpwz8v5C72bVOPgQvFoTpNtD8On5A7oQXe8ZqVI5SHc5G3r 0ip3XGPHxfwpyxk7VK1GeBbz6zXgkZ0A1B1vdVdUbFZxNBCQXnP3lw/371JRPmkm/nznEq1c rhq/YeEVx89BBdNZ1m2j44k6CBue/bhiQsQQF0t228yPdb/BSPEq8T5sCeJSzU4Day15imii 9wEKSd1imE7I/33NdSqCbP3hTECc8zn3WnLBOw2YjbKAj+BEvkBmkGDa710KkM7lr3gRbfwJ E/8Apl6ZFsY+uEGnolfZzpiONH7ccK+ylJU94vMQ/4Lsdn6VOULtpoHN78r2Yk9U3prmXvCE ac/WBXCLrGVjxruQQIv8QuNi1GD8ZeCSPeFBRGtpsJu5123mP9KJkGugOAMR5mGsMe+mtGQQ vI6OhlfcFSYywJrJkKDoAAAAAAAA --------------ms090009030509060101060509-- From nobody Mon Sep 15 18:15:03 2025 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 4cQY9916Qgz67kbN for ; Mon, 15 Sep 2025 18:15:09 +0000 (UTC) (envelope-from roy@marples.name) Received: from sender-of-o51.zoho.eu (sender-of-o51.zoho.eu [136.143.169.51]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4cQY984qj8z41nh for ; Mon, 15 Sep 2025 18:15:08 +0000 (UTC) (envelope-from roy@marples.name) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; t=1757960106; cv=none; d=zohomail.eu; s=zohoarc; b=Q8pXOn0rJJ6WkEPo41hRtCY1jBqik3Z2B0iQav1UZhUKws9EgCgS+oyY5xxNipU9Leytnq2Yx9PB7c2XPiNpdscdUo8L4uIH2ccD3zBdNmk6xXhTtdk8sqXJxbKsiBTUU9mw6jJmuKwAb4ttUY2DknBebVLuUMUkSJrGQGMcXwU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1757960106; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=D8bNpImur2U8Fp3HgSmi8cTShsly+nobmfA1ZeoHinc=; b=G1lIRGEqzdWQ1va3Y1vq5sJGRQFmswVR0Yqru3rjNQT/SRXJ8dU7osswF/SwURF0nWFpNAe20ZJYpLWvBVBz+5rCplQcC76NmNF5/ww2QesgH5Mm2Xr9RiCCjNJ/wLtQ7Ypxmou2chLtDX2deKwxvjKDe7ao2HANGn9ODtBdSSs= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=marples.name; spf=pass smtp.mailfrom=roy@marples.name; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1757960106; s=zmail; d=marples.name; i=roy@marples.name; h=Date:Date:From:From:To:To:Cc:Cc:Message-Id:Message-Id:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Reply-To; bh=D8bNpImur2U8Fp3HgSmi8cTShsly+nobmfA1ZeoHinc=; b=TP6jcVlFsGwEdSZzGZlFKhFlkvMVCqMhqObKbNr2AwUdlh7c9jx97xuz8Pl3OYkH 5Q5t0+D0xiTTsRBw/R4EWRG4kVU8L5oOLxL7kPkZvnAuoxhPkWb6Ktxw3REEYYcDFHb wTPSidEEIv41Z9HA0yJZfNWx+6MD3Mpfl4SiWC6g= Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1757960103962982.5875150480769; Mon, 15 Sep 2025 20:15:03 +0200 (CEST) Date: Mon, 15 Sep 2025 19:15:03 +0100 From: Roy Marples To: "Karl Denninger" Cc: "Freebsd net" Message-Id: <1994e966819.20444a00373298.5175621979752895403@marples.name> In-Reply-To: References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <6fce77fb-9ba8-4c7b-bb9b-0e337d91f278@denninger.net> <1780EFAC-DA9C-4593-BE37-28E7FFCE4388@distal.com> <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> <092f8b7a-9b98-4e2a-b6c5-361b40549cce@denninger.net> Subject: Re: IPv6 networking problems in 14.3 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="----=_Part_3129823_2117311198.1757960103961" User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:41913, ipnet:136.143.168.0/23, country:CH] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cQY984qj8z41nh ------=_Part_3129823_2117311198.1757960103961 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable dhcpcd already has this behaviour. Good luck! Roy =20 =20 =20 ---- On Mon, 15 Sep 2025 18:59:15 +0100 Karl Denninger wrote ---- =20 =20 =20 =20 On 9/15/2025 13:20, Chris Ross wrote: =20 =20 =20 =20 =20 =20 =20 On Sep 15, 2025, at 08:59, Karl Denninger=20 mailto:karl@denninger.net wrote: =20 =20 =20 =20 =20 =20 =20 Hmmmmm.... just came in via git pull: =20 =C2=A0 =C2=A0 dhclient: improve UDP checksum handling =20 =20 =20 This could potentially apply to other bpf-using things=20 -- which includes dhcpcd.=C2=A0 And you have tso/lro turned= =20 on. =20 It is a patch to dhclient, not dhcpcd but does the same=20 issue potentially apply? =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 I don=E2=80=99t know, but I think that isn=E2=80=99t my problem. = =C2=A0It seems like=20 the NS that =20 dhcpcd is sending is alright, and tcpdump doesn=E2=80=99t see an NA= =20 coming =20 back in at all. =20 =20 =20 =20 =20 - Chris =20 =20 =20 =20 =20 =20 =20 Unfortunately without being able to snoop on the ONT's glass side=20 that's hard to diagnose; are they sending it at all, are they=20 sending it to the wrong place, does the ONT have a map that's=20 wrong between its fiber interface and the MAC connected to it,=20 etc. =20 Fortunately the ISP I'm connected to when this sort of thing=20 happened to me had people who actually knew what they were doing=20 and were able to snoop the packets coming and going on their side=20 when I was on the phone with them.=C2=A0 Good luck getting a large IS= P=20 like Verizon to connect you to someone with the appropriate level=20 of access into their gear to be able to do that.=C2=A0 It took me a= =20 couple of rounds with KUB here before they went beyond "we cleared=20 our ARP table entry for your ONT but we don't know why it did=20 that" to getting someone on the line that actually was willing and=20 able to snoop the traffic and determine WHY it happened. =20 The interesting part in this case (but probably the fortunate=20 part!) was that their infrastructure for delegating an IPv4=20 (single address, you do the NAT) and /56 IPv6 is apparently=20 entirely distinct thus that one had a hissy fit didn't prevent the=20 other from coming up and functioning. =20 --=20 =20 Karl Denninger =20 mailto:karl@denninger.net=20 =20 The Market Ticker =20 [S/MIME encrypted email preferred] ------=_Part_3129823_2117311198.1757960103961 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
dhcpcd already has this behaviour.

Good luck!

Roy
<= /div>

=
---- On Mon, 15 Sep 2025 18:59:15 +0100 Karl De= nninger<karl@denninger.net> wrote ----

=20 =20
=20
On 9/15/2025 13:20, Chris Ros= s wrote:
=20
=20

=20
=20
=20
On Sep 15, 2025, at 08:59, Karl Denninger=20 <karl@denninger.net> wrote:=20
=20
=20 =20
=20

Hmmmmm.... just came in via git pull:

=20

    dhclient: improve UDP checksum handling
= =20
=20 This could potentially apply to other bpf-using things=20 -- which includes dhcpcd.  And you have tso/lro turned= =20 on.

=20

It is a patch to dhclient, not dhcpcd but does the same=20 issue potentially apply?

=20
=20
=20
=20

=20
=20 I don=E2=80=99t know, but I think that isn=E2=80=99t my problem. &n= bsp;It seems like=20 the NS that
=20
dhcpcd is sending is alright, and tcpdump doesn=E2=80=99t see an= NA=20 coming
=20
back in at all.
=20

=20
=20
- Chris
=20

=20
=20
=20

Unfortunately without being able to snoop on the ONT's glass side=20 that's hard to diagnose; are they sending it at all, are they=20 sending it to the wrong place, does the ONT have a map that's=20 wrong between its fiber interface and the MAC connected to it,=20 etc.

=20

Fortunately the ISP I'm connected to when this sort of thing=20 happened to me had people who actually knew what they were doing=20 and were able to snoop the packets coming and going on their side=20 when I was on the phone with them.  Good luck getting a large IS= P=20 like Verizon to connect you to someone with the appropriate level=20 of access into their gear to be able to do that.  It took me a= =20 couple of rounds with KUB here before they went beyond "we cleared=20 our ARP table entry for your ONT but we don't know why it did=20 that" to getting someone on the line that actually was willing and=20 able to snoop the traffic and determine WHY it happened.

=20

The interesting part in this case (but probably the fortunate=20 part!) was that their infrastructure for delegating an IPv4=20 (single address, you do the NAT) and /56 IPv6 is apparently=20 entirely distinct thus that one had a hissy fit didn't prevent the=20 other from coming up and functioning.

=20
--
=20 Karl Denninger
=20 karl@denninger.net
=20 The Market Ticker
=20 [S/MIME encrypted email preferred]=20

------=_Part_3129823_2117311198.1757960103961-- From nobody Mon Sep 15 18:20:22 2025 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 4cQYJD5s31z67lGT for ; Mon, 15 Sep 2025 18:21:16 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.95.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQYJD09z2z434x for ; Mon, 15 Sep 2025 18:21:15 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=relay.distal.com header.s=mail header.b=e3vo9kLh; dmarc=none; spf=pass (mx1.freebsd.org: domain of cross+freebsd@relay.distal.com designates 168.235.95.80 as permitted sender) smtp.mailfrom=cross+freebsd@relay.distal.com dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; bh=rCmb/jh8FS053bKJLtCy/Ql4IeDkJHmrD/abqagd6BI=; b=e3vo9kLhlE7ajxxZzEjenjRiN1KX3DN7fIMlzlAzDiTddFnpJQLjtDxgva7EGxn+RcOlWzqpJsKwkpO21Jr8yQLKMVxN8n51GAuGv6vqLe50cGo/1S0dlowizOK3xH2GjcSZrIrc7Ysjbmui+A0nSUKR+5dcUpukXddH1SA8P2z2SY9WXEuteLmBd6M+522HwyEHWEsyFdEL0zaLDGumsMUKRN0/RO79TI/5NAGRwhXn6WURT/6PuBDx6O XlOTp/EAYWcOT6Guo+1diwvnJX0UJduXweXrDPJC5HcfmoGxxyZr56feRZjLlkXTHYdal2rUgbK4kk1elLfdkxn2NfMA== Received: from mail.distal.com (pool-108-51-233-124.washdc.fios.verizon.net [108.51.233.124]) by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256) ; Mon, 15 Sep 2025 18:21:14 +0000 Received: from smtpclient.apple ( [2600:4040:2c9d:5220:4179:a2c2:d96f:6397]) by tristain.distal.com (OpenSMTPD) with ESMTPSA id 9330f279 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Mon, 15 Sep 2025 14:21:12 -0400 (EDT) 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 \(3826.700.81\)) Subject: Re: IPv6 networking problems in 14.3 From: Chris Ross In-Reply-To: <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> Date: Mon, 15 Sep 2025 14:20:22 -0400 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <74D374DA-09B8-4533-B2EE-1AFE2AC8EFAD@distal.com> References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <6fce77fb-9ba8-4c7b-bb9b-0e337d91f278@denninger.net> <1780EFAC-DA9C-4593-BE37-28E7FFCE4388@distal.com> <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[cross@distal.com,cross@relay.distal.com]; R_SPF_ALLOW(-0.20)[+a:relay.dynu.com]; R_DKIM_ALLOW(-0.20)[relay.distal.com:s=mail]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[distal.com]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[cross@distal.com,cross@relay.distal.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; TAGGED_FROM(0.00)[freebsd]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[relay.distal.com:+] X-Rspamd-Queue-Id: 4cQYJD09z2z434x Okay. Apologies to those who like the whole thread to be in each email, = but I=E2=80=99m starting again here after a discovery. I rebooted my router after copying the 14.1p5 kernel I was running = earlier, and while the system failed to come up very well (due to 14.3 userland), = I was able to manually start up dhcpcd, the same actual binary, and it was able to set up my IPv6 connectivity through my ISP just like before. So there=E2=80=99s a regression here. Or something subtle I need to change = that I am so far missing. Summary: When booted with FreeBSD 14.3-RELEASE-p2, dhcpcd gets an RA from my ISP, sends a NS, but never gets the NA response. Therefore no outgoing = packets ever get out. % ndp -an | grep vlan0 fe80::3e8a:b0ff:fe3e:4dce%vlan0 (incomplete) vlan0 1s = I=20 fe80::6e8:e675:f359:3465%vlan0 a4:53:0e:79:b9:82 vlan0 permanent = R % tail /var/log/dhcpcd.log Sep 15 14:03:14 [10047]: vlan0: soliciting an IPv6 router Sep 15 14:03:14 [10047]: vlan0: sending Router Solicitation Sep 15 14:03:14 [10047]: vlan0: Router Advertisement from = fe80::3e8a:b0ff:fe3e:4dce Sep 15 14:03:14 [10047]: vlan0: executing: = /usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT Sep 15 14:03:17 [10047]: vlan0: fe80::3e8a:b0ff:fe3e:4dce is unreachable [...] When booting with 14.1-RELEASE-p5, dhcpcd works as expected: % cat 14.1-ndp-success fe80::3e8a:b0ff:fe3e:4dce%vlan0 3c:8a:b0:3e:4d:ce vlan0 29s = R R fe80::a653:eff:fe79:b982%vlan0 a4:53:0e:79:b9:82 vlan0 permanent = R=20 % (lines from dhcpcd.log) Sep 15 13:50:44 [57415]: vlan0: soliciting an IPv6 router Sep 15 13:50:44 [57415]: vlan0: sending Router Solicitation Sep 15 13:50:44 [57415]: vlan0: Router Advertisement from = fe80::3e8a:b0ff:fe3e:4dce Sep 15 13:50:44 [57415]: vlan0: no global addresses for default route Sep 15 13:50:44 [57415]: vlan0: executing: = /usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT Sep 15 13:50:45 [57415]: vlan0: multicasting REBIND6 (xid 0x142ec7), = next in 1.1 seconds Sep 15 13:50:45 [57415]: vlan0: REPLY6 received from = fe80::3e8a:b0ff:fe3e:4dce Sep 15 13:50:45 [57415]: vlan0: renew in 3600, rebind in 5760, expire in = 7200 seconds Sep 15 13:50:45 [57415]: vlan0: writing lease: = /var/db/dhcpcd/vlan0.lease6 Sep 15 13:50:45 [57415]: vlan0: delegated prefix = 2600:4040:2c9d:5200::/56 [...] Sep 15 13:50:45 [57415]: vlan0: adding default route via = fe80::3e8a:b0ff:fe3e:4dce [...] Sep 15 13:50:45 [57415]: vlan0: executing: = /usr/local/libexec/dhcpcd-run-hooks REBIND6 Sep 15 13:50:45 [56455]: forked to background [...] So. What other information can I help gather? I might be able to run = tcpdump when I=E2=80=99m up in 14.1 kernel, though the system is kinda broken in = a number of ways. Let me know anything else I can gather to help track this = regression. -Chris= From nobody Mon Sep 15 19:01:59 2025 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 4cQZCH2Ry7z67p08 for ; Mon, 15 Sep 2025 19:02:03 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4cQZCG0yFmz49VQ for ; Mon, 15 Sep 2025 19:02:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=i26IH+s9; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of ronald-lists@klop.ws designates 87.255.56.188 as permitted sender) smtp.mailfrom=ronald-lists@klop.ws Received: from smtp-relay-int-backup.realworks.nl (crmpreview2.colo2.realworks.nl [10.2.52.32]) by mailrelayint1.colo2.realworks.nl (Postfix) with ESMTP id 4cQZCC45tWzTq; Mon, 15 Sep 2025 21:01:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1757962919; 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; bh=L936ZBWcFxaqV1ZLoNPlybiUMi8kzCCrZRUiyEUOWEw=; b=i26IH+s94sfTflhEo5m+T9sW/jlIVuSQj/nFofZ7z5E7Kf3o+RV3VjmsAlbj7+qdGNR6FX GUEAxryMdM0QMFunfzoK5XaN3CVzVgFFbj7xsB3KBZVvw4wVLsw4oXIx28E2r4t7seMLPD SDJNyl9Z7Nz4WpQqHzvuzxUjmMQvD0l7a7zO9tXuR61esgOAckFoYWa3hDhHYGC3HkhZVD lxXTbJbvWMhn5GuvNtSPNtdU0daWEHJS5q9ss7WGEGhhoWHDamUhHQZdZyTq1B0EDCjeKp niabV/ZkCsTrVcd1XLZuE1TwAaWMfREwfnUd04ovhnd+6P5d3UN9lvLWPQ+BOw== Received: from crmpreview2.colo2.realworks.nl (localhost [127.0.0.1]) by crmpreview2.colo2.realworks.nl (Postfix) with ESMTP id 4F7DF260505; Mon, 15 Sep 2025 21:01:59 +0200 (CEST) Date: Mon, 15 Sep 2025 21:01:59 +0200 (CEST) From: Ronald Klop To: Chris Ross Cc: freebsd-net@freebsd.org, Karl Denninger Message-ID: <910737314.4002.1757962919189@localhost> In-Reply-To: <74D374DA-09B8-4533-B2EE-1AFE2AC8EFAD@distal.com> Subject: Re: IPv6 networking problems in 14.3 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="----=_Part_4001_2033630004.1757962919185" X-Mailer: Realworks (765.89) X-Originating-Host: from (localhost [127.0.0.1]) by crmpreview2.colo2.realworks.nl [10.2.52.32] with HTTP; Mon, 15 Sep 2025 21:01:59 +0200 Importance: Normal X-Priority: 3 (Normal) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.42 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.922]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; R_SPF_ALLOW(-0.20)[+ip4:87.255.56.128/26]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; TAGGED_RCPT(0.00)[freebsd]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; DKIM_TRACE(0.00)[klop.ws:+] X-Rspamd-Queue-Id: 4cQZCG0yFmz49VQ ------=_Part_4001_2033630004.1757962919185 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Are you able to boot a 14.2 kernel? To split the search space in two.=20 Regards, Ronald Van: Chris Ross Datum: 15 september 2025 20:21 Aan: Karl Denninger CC: freebsd-net@freebsd.org Onderwerp: Re: IPv6 networking problems in 14.3 >=20 >=20 > Okay. Apologies to those who like the whole thread to be in each email, = but > I=E2=80=99m starting again here after a discovery. >=20 > I rebooted my router after copying the 14.1p5 kernel I was running earlie= r, > and while the system failed to come up very well (due to 14.3 userland), = I > was able to manually start up dhcpcd, the same actual binary, and it was > able to set up my IPv6 connectivity through my ISP just like before. So > there=E2=80=99s a regression here. Or something subtle I need to change = that I > am so far missing. >=20 > Summary: > When booted with FreeBSD 14.3-RELEASE-p2, dhcpcd gets an RA from my ISP, > sends a NS, but never gets the NA response. Therefore no outgoing packet= s > ever get out. >=20 > % ndp -an | grep vlan0 > fe80::3e8a:b0ff:fe3e:4dce%vlan0 (incomplete) vlan0 1s I= =20 > fe80::6e8:e675:f359:3465%vlan0 a4:53:0e:79:b9:82 vlan0 permanent R > % tail /var/log/dhcpcd.log > Sep 15 14:03:14 [10047]: vlan0: soliciting an IPv6 router > Sep 15 14:03:14 [10047]: vlan0: sending Router Solicitation > Sep 15 14:03:14 [10047]: vlan0: Router Advertisement from fe80::3e8a:b0ff= :fe3e:4dce > Sep 15 14:03:14 [10047]: vlan0: executing: /usr/local/libexec/dhcpcd-run-= hooks ROUTERADVERT > Sep 15 14:03:17 [10047]: vlan0: fe80::3e8a:b0ff:fe3e:4dce is unreachable > [...] >=20 > When booting with 14.1-RELEASE-p5, dhcpcd works as expected: >=20 > % cat 14.1-ndp-success > fe80::3e8a:b0ff:fe3e:4dce%vlan0 3c:8a:b0:3e:4d:ce vlan0 29s R= R > fe80::a653:eff:fe79:b982%vlan0 a4:53:0e:79:b9:82 vlan0 permanent R= =20 > % (lines from dhcpcd.log) > Sep 15 13:50:44 [57415]: vlan0: soliciting an IPv6 router > Sep 15 13:50:44 [57415]: vlan0: sending Router Solicitation > Sep 15 13:50:44 [57415]: vlan0: Router Advertisement from fe80::3e8a:b0ff= :fe3e:4dce > Sep 15 13:50:44 [57415]: vlan0: no global addresses for default route > Sep 15 13:50:44 [57415]: vlan0: executing: /usr/local/libexec/dhcpcd-run-= hooks ROUTERADVERT > Sep 15 13:50:45 [57415]: vlan0: multicasting REBIND6 (xid 0x142ec7), next= in 1.1 seconds > Sep 15 13:50:45 [57415]: vlan0: REPLY6 received from fe80::3e8a:b0ff:fe3e= :4dce > Sep 15 13:50:45 [57415]: vlan0: renew in 3600, rebind in 5760, expire in = 7200 seconds > Sep 15 13:50:45 [57415]: vlan0: writing lease: /var/db/dhcpcd/vlan0.lease= 6 > Sep 15 13:50:45 [57415]: vlan0: delegated prefix 2600:4040:2c9d:5200::/56 > [...] > Sep 15 13:50:45 [57415]: vlan0: adding default route via fe80::3e8a:b0ff:= fe3e:4dce > [...] > Sep 15 13:50:45 [57415]: vlan0: executing: /usr/local/libexec/dhcpcd-run-= hooks REBIND6 > Sep 15 13:50:45 [56455]: forked to background > [...] >=20 > So. What other information can I help gather? I might be able to run tc= pdump > when I=E2=80=99m up in 14.1 kernel, though the system is kinda broken in = a number of > ways. Let me know anything else I can gather to help track this regressi= on. >=20 > -Chris >=20 >=20 >=20 >=20 >=20 ------=_Part_4001_2033630004.1757962919185 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Are you able to boot a 14.2 kernel?
To split t= he search space in two. 

Regards,
R= onald

Van: Chris Ross <cross+fr= eebsd@distal.com>
Datum: 15 september 2025 20:21
= Aan: Karl Denninger <karl@denninger.net>
= CC: freebsd-net@freebsd.org
Onderwerp: Re: IPv= 6 networking problems in 14.3

Okay.  Apologies to those who like the whole thre= ad to be in each email, but
I=E2=80=99m starting again here after a discovery.

I rebooted my router after copying the 14.1p5 kernel I was running earlier,=
and while the system failed to come up very well (due to 14.3 userland), I<= br> was able to manually start up dhcpcd, the same actual binary, and it was able to set up my IPv6 connectivity through my ISP just like before.  = So
there=E2=80=99s a regression here.  Or something subtle I need to chan= ge that I
am so far missing.

Summary:
When booted with FreeBSD 14.3-RELEASE-p2, dhcpcd gets an RA from my ISP, sends a NS, but never gets the NA response.  Therefore no outgoing pac= kets
ever get out.

% ndp -an | grep vlan0
fe80::3e8a:b0ff:fe3e:4dce%vlan0      (incomplete) =       vlan0 1s      =   I
fe80::6e8:e675:f359:3465%vlan0       a4:53:0e= :79:b9:82  vlan0 permanent R
% tail /var/log/dhcpcd.log
Sep 15 14:03:14 [10047]: vlan0: soliciting an IPv6 router
Sep 15 14:03:14 [10047]: vlan0: sending Router Solicitation
Sep 15 14:03:14 [10047]: vlan0: Router Advertisement from fe80::3e8a:b0ff:f= e3e:4dce
Sep 15 14:03:14 [10047]: vlan0: executing: /usr/local/libexec/dhcpcd-run-ho= oks ROUTERADVERT
Sep 15 14:03:17 [10047]: vlan0: fe80::3e8a:b0ff:fe3e:4dce is unreachable [...]

When booting with 14.1-RELEASE-p5, dhcpcd works as expected:

% cat 14.1-ndp-success
fe80::3e8a:b0ff:fe3e:4dce%vlan0      3c:8a:b0:3e:4= d:ce  vlan0 29s       R R
fe80::a653:eff:fe79:b982%vlan0       a4:53:0e= :79:b9:82  vlan0 permanent R
% (lines from dhcpcd.log)
Sep 15 13:50:44 [57415]: vlan0: soliciting an IPv6 router
Sep 15 13:50:44 [57415]: vlan0: sending Router Solicitation
Sep 15 13:50:44 [57415]: vlan0: Router Advertisement from fe80::3e8a:b0ff:f= e3e:4dce
Sep 15 13:50:44 [57415]: vlan0: no global addresses for default route
Sep 15 13:50:44 [57415]: vlan0: executing: /usr/local/libexec/dhcpcd-run-ho= oks ROUTERADVERT
Sep 15 13:50:45 [57415]: vlan0: multicasting REBIND6 (xid 0x142ec7), next i= n 1.1 seconds
Sep 15 13:50:45 [57415]: vlan0: REPLY6 received from fe80::3e8a:b0ff:fe3e:4= dce
Sep 15 13:50:45 [57415]: vlan0: renew in 3600, rebind in 5760, expire in 72= 00 seconds
Sep 15 13:50:45 [57415]: vlan0: writing lease: /var/db/dhcpcd/vlan0.lease6<= br> Sep 15 13:50:45 [57415]: vlan0: delegated prefix 2600:4040:2c9d:5200::/56 [...]
Sep 15 13:50:45 [57415]: vlan0: adding default route via fe80::3e8a:b0ff:fe= 3e:4dce
[...]
Sep 15 13:50:45 [57415]: vlan0: executing: /usr/local/libexec/dhcpcd-run-ho= oks REBIND6
Sep 15 13:50:45 [56455]: forked to background
[...]

So.  What other information can I help gather?  I might be able t= o run tcpdump
when I=E2=80=99m up in 14.1 kernel, though the system is kinda broken in a = number of
ways.  Let me know anything else I can gather to help track this regre= ssion.

-Chris




------=_Part_4001_2033630004.1757962919185-- From nobody Mon Sep 15 19:05:02 2025 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 4cQZH42pcTz67nxN for ; Mon, 15 Sep 2025 19:05:20 +0000 (UTC) (envelope-from pusateri@keehole.org) Received: from kem.keehole.org (kem.keehole.org [136.41.224.255]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4cQZH32cyWz4BJv for ; Mon, 15 Sep 2025 19:05:19 +0000 (UTC) (envelope-from pusateri@keehole.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=keehole.org header.s=202408 header.b=JBYUJy7q; dmarc=pass (policy=none) header.from=keehole.org; spf=pass (mx1.freebsd.org: domain of pusateri@keehole.org designates 136.41.224.255 as permitted sender) smtp.mailfrom=pusateri@keehole.org Received: from smtpclient.apple (unknown [136.41.224.198]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by kem.keehole.org (Postfix) with ESMTPSA id 3B91972E78; Mon, 15 Sep 2025 15:05:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=keehole.org; s=202408; t=1757963113; bh=ik2wEMlZuS6WKTFSBtA9vitnr5SEBVFKqv8buMBy57g=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=JBYUJy7q76Q0ZViXgtyy0+fsm5ysBk7NdEF6p+0RlPf2v3LLzW4aWPDhNxnBAizMy DsOmxAfP7aFyi72JYr2kEPkGT29fa7gs/EKCGFDdRjT/yzZO46MvxbzuioqMIXxnln VC+FVg0NLQTMU4aJxpC3EF2maCmBv3wYiAhpCXTGd9v0qIrcB1BwhpJgJ2wFAFFl0m FtjYXF/Jtpix5pFFDFE5OI8NsZ1cv/pcnfjJMjVJ8mxxQDFbYdbyXo2WHypzvn+9AU wTzE2sG1u0xB6u2DIO75vp7s0ER6L3hT9vTw6/+yy5VRc3Bat0omlSCDYe2XZBjs62 xgY4Ovn+KW55A== 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 \(3826.700.81\)) Subject: Re: IPv6 networking problems in 14.3 From: Tom Pusateri In-Reply-To: <74D374DA-09B8-4533-B2EE-1AFE2AC8EFAD@distal.com> Date: Mon, 15 Sep 2025 15:05:02 -0400 Cc: Karl Denninger , freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C00D174-21FE-47C4-A30A-A382138571A5@keehole.org> <6fce77fb-9ba8-4c7b-bb9b-0e337d91f278@denninger.net> <1780EFAC-DA9C-4593-BE37-28E7FFCE4388@distal.com> <6e7a8fc6-12c8-4097-ad70-bcb1e4967ade@denninger.net> <74D374DA-09B8-4533-B2EE-1AFE2AC8EFAD@distal.com> To: Chris Ross X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.44 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; NEURAL_HAM_SHORT(-0.67)[-0.671]; DMARC_POLICY_ALLOW(-0.50)[keehole.org,none]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.20)[]; R_DKIM_ALLOW(-0.20)[keehole.org:s=202408]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[keehole.org:+]; RCPT_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:16591, ipnet:136.32.0.0/11, country:US]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[freebsd]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4cQZH32cyWz4BJv I would try running the 14.3p2 system without the VLAN configuration and = a direct connection to the upstream provider hardware (no switch) and = see if the problem persists. That will determine if it=E2=80=99s a VLAN = issue. Tom > On Sep 15, 2025, at 2:20=E2=80=AFPM, Chris Ross = wrote: >=20 > Okay. Apologies to those who like the whole thread to be in each = email, but > I=E2=80=99m starting again here after a discovery. >=20 > I rebooted my router after copying the 14.1p5 kernel I was running = earlier, > and while the system failed to come up very well (due to 14.3 = userland), I > was able to manually start up dhcpcd, the same actual binary, and it = was > able to set up my IPv6 connectivity through my ISP just like before. = So > there=E2=80=99s a regression here. Or something subtle I need to = change that I > am so far missing. >=20 > Summary: > When booted with FreeBSD 14.3-RELEASE-p2, dhcpcd gets an RA from my = ISP, > sends a NS, but never gets the NA response. Therefore no outgoing = packets > ever get out. >=20 > % ndp -an | grep vlan0 > fe80::3e8a:b0ff:fe3e:4dce%vlan0 (incomplete) vlan0 1s = I=20 > fe80::6e8:e675:f359:3465%vlan0 a4:53:0e:79:b9:82 vlan0 = permanent R > % tail /var/log/dhcpcd.log > Sep 15 14:03:14 [10047]: vlan0: soliciting an IPv6 router > Sep 15 14:03:14 [10047]: vlan0: sending Router Solicitation > Sep 15 14:03:14 [10047]: vlan0: Router Advertisement from = fe80::3e8a:b0ff:fe3e:4dce > Sep 15 14:03:14 [10047]: vlan0: executing: = /usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT > Sep 15 14:03:17 [10047]: vlan0: fe80::3e8a:b0ff:fe3e:4dce is = unreachable > [...] >=20 > When booting with 14.1-RELEASE-p5, dhcpcd works as expected: >=20 > % cat 14.1-ndp-success > fe80::3e8a:b0ff:fe3e:4dce%vlan0 3c:8a:b0:3e:4d:ce vlan0 29s = R R > fe80::a653:eff:fe79:b982%vlan0 a4:53:0e:79:b9:82 vlan0 = permanent R=20 > % (lines from dhcpcd.log) > Sep 15 13:50:44 [57415]: vlan0: soliciting an IPv6 router > Sep 15 13:50:44 [57415]: vlan0: sending Router Solicitation > Sep 15 13:50:44 [57415]: vlan0: Router Advertisement from = fe80::3e8a:b0ff:fe3e:4dce > Sep 15 13:50:44 [57415]: vlan0: no global addresses for default route > Sep 15 13:50:44 [57415]: vlan0: executing: = /usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT > Sep 15 13:50:45 [57415]: vlan0: multicasting REBIND6 (xid 0x142ec7), = next in 1.1 seconds > Sep 15 13:50:45 [57415]: vlan0: REPLY6 received from = fe80::3e8a:b0ff:fe3e:4dce > Sep 15 13:50:45 [57415]: vlan0: renew in 3600, rebind in 5760, expire = in 7200 seconds > Sep 15 13:50:45 [57415]: vlan0: writing lease: = /var/db/dhcpcd/vlan0.lease6 > Sep 15 13:50:45 [57415]: vlan0: delegated prefix = 2600:4040:2c9d:5200::/56 > [...] > Sep 15 13:50:45 [57415]: vlan0: adding default route via = fe80::3e8a:b0ff:fe3e:4dce > [...] > Sep 15 13:50:45 [57415]: vlan0: executing: = /usr/local/libexec/dhcpcd-run-hooks REBIND6 > Sep 15 13:50:45 [56455]: forked to background > [...] >=20 > So. What other information can I help gather? I might be able to run = tcpdump > when I=E2=80=99m up in 14.1 kernel, though the system is kinda broken = in a number of > ways. Let me know anything else I can gather to help track this = regression. >=20 > -Chris >=20 From nobody Mon Sep 15 22:54:26 2025 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 4cQgNK3PN1z68Bch for ; Mon, 15 Sep 2025 22:55:13 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.95.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQgNK0JQgz3Zt1 for ; Mon, 15 Sep 2025 22:55:12 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Authentication-Results: mx1.freebsd.org; none dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:In-Reply-To:References; bh=I4OY6XmvBl1stpLgI8R1rxvhOEFcsO/DY/xqdoRBjX0=; b=had+8biKmVVRABjs7Jmi1cLVh1Uipqx6CAUz1ZK6oDZCw2/qQdTFk0w8441BkZ0TRHbdvsu8JwKCEIyNpWaHLAuO6LfqI9RXlKA2MQ+wkhc42RRfBTfSy05pORsjjpSE0rjD8iXvex4COBsWCZB9gzGK33XNK9alFTIySd5pKt5KKeyGXrq1XHEFD+fDDY/5y/t9nACNd0oh32fGpaCoPTZoIH3DegHrRhSMObQghcQ43CYAWdtfAMt7Pd WxM10yNA0+ed8fb4fyIOCB8JOfdoLMtpapsdt9pepntQpfXGXEZnZQQSDPjFa9HI8kQeR18swmhDZqAwZfHLCcL+lpEg== Received: from mail.distal.com (pool-108-51-233-124.washdc.fios.verizon.net [108.51.233.124]) by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256) ; Mon, 15 Sep 2025 22:54:59 +0000 Received: from smtpclient.apple (magrathea.distal.com [206.138.151.12]) by tristain.distal.com (OpenSMTPD) with ESMTPSA id c6e8138a (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Mon, 15 Sep 2025 18:54:57 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4695FE08-810E-4140-9D7B-DEB97B52688E" 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 \(3826.700.81\)) Subject: Re: IPv6 networking problems in 14.3 From: Chris Ross X-Priority: 3 (Normal) In-Reply-To: <910737314.4002.1757962919189@localhost> Date: Mon, 15 Sep 2025 18:54:26 -0400 Cc: freebsd-net@freebsd.org, Karl Denninger Message-Id: <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com> References: <910737314.4002.1757962919189@localhost> To: Ronald Klop , Tom Pusateri X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[freebsd] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cQgNK0JQgz3Zt1 --Apple-Mail=_4695FE08-810E-4140-9D7B-DEB97B52688E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 15, 2025, at 15:01, Ronald Klop wrote: >=20 > Are you able to boot a 14.2 kernel? > To split the search space in two.=20 I could do that. What=E2=80=99s the easy way to get an unpacked 14.2 = generic amd64 kernel? I can install a VM at work and copy it, but I assume there=E2=80=99s a = package I can just unroll. > On Sep 15, 2025, at 15:05, Tom Pusateri wrote: >=20 > I would try running the 14.3p2 system without the VLAN configuration = and a direct connection to the upstream provider hardware (no switch) = and see if the problem persists. That will determine if it=E2=80=99s a = VLAN issue. That would be a bit of work. I have an available ix port, so I can run = a line to the machine without vlan. It would still be a VLAN in the switch, because running a = direct line is not possible without much rewiring and very long cables. But if the test is = to rule out the vlan interface I can do that. It just requires rewriting all of the systems = config to know that the outside is different than it is now, which _should_ be easy, but I = don=E2=80=99t know the depth of it since I haven=E2=80=99t done it in eons. I=E2=80=99ll look to find a = time to try that. - Chris= --Apple-Mail=_4695FE08-810E-4140-9D7B-DEB97B52688E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 15, 2025, at 15:01, Ronald Klop = <ronald-lists@klop.ws> wrote:

Are you able to boot a = 14.2 kernel?
To split the search space in = two. 

I could do that. =  What=E2=80=99s the easy way to get an unpacked 14.2 generic amd64 = kernel?
I can install a VM at work and copy it, but I assume = there=E2=80=99s a package I can just = unroll.

On Sep 15, = 2025, at 15:05, Tom Pusateri <pusateri@keehole.org> = wrote:

I would try = running the 14.3p2 system without the VLAN configuration and a direct = connection to the upstream provider hardware (no switch) and see if the = problem persists. That will determine if it=E2=80=99s a VLAN = issue.

That would be a bit of = work.  I have an available ix port, so I can run a line to the = machine
without vlan. It would still be a VLAN in the switch, = because running a direct line is not
possible without much = rewiring and very long cables.  But if the test is to rule out the = vlan
interface I can do that.  It just requires rewriting = all of the systems config to know that the
outside is = different than it is now, which _should_ be easy, but I don=E2=80=99t = know the depth of
it since I haven=E2=80=99t done it in eons. =  I=E2=80=99ll look to find a time to try = that.

- Chris
= --Apple-Mail=_4695FE08-810E-4140-9D7B-DEB97B52688E-- From nobody Tue Sep 16 00:24:58 2025 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 4cQjNB6QRKz67bTv for ; Tue, 16 Sep 2025 00:25:14 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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 "ultimatedns.net", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQjNB2W8Zz3hXB for ; Tue, 16 Sep 2025 00:25:14 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=ultimatedns.net header.s=mx99 header.b=Tv+uLziK; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 58G0Ox9D023655; Mon, 15 Sep 2025 17:25:05 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1757982308; x=1757982908; r=y; bh=dUPV/Yx+67SKPsJBcvK7/cAh3MSXxw+p5nGRhi/01ng=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Tv+uLziK6QHkZg9pr01hi6hDB+mgyW6NQ+nkLS0t7+4WoQNDaqWxXNRSaEnLpdSkP VRrBocSbHzHG5aEKBvAeQSRo+D/VEJ2l2yUqgDWQXhb/SldMkK2kM+V2nJGliFhTAM OOmXWFjWQsfTCxIv7qBGQz2GPVWANmtV/LqDJtWFzOK0IVvk0HjeCvhRimNvZpBB/d UwswK0/fior679ikDnQABpLhcRY6ztcL0tlrH/9PhGITbdH2LHuQwMtPk8pFGbOm/5 BRNTG1T+rfTx9N9kbVi+gpP2ejlFFfNu5IvC5+J5E22PEXZpzw5TjRVdG5reVNiHpF +gpQPCiWqvnxA== 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 Date: Mon, 15 Sep 2025 17:24:58 -0700 From: Chris To: Chris Ross Cc: Ronald Klop , Tom Pusateri , freebsd-net@freebsd.org, Karl Denninger Subject: Re: IPv6 networking problems in 14.3 In-Reply-To: <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com> References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com> User-Agent: UDNSMS/17.0 Message-ID: <4f25c12b48572737b95e139d9534b0f0@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_5d355f4c45a660dad780cadfa089ed3e" X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.50 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; R_DKIM_REJECT(1.00)[ultimatedns.net:s=mx99]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MIME_UNKNOWN(0.10)[application/pgp-keys]; DKIM_TRACE(0.00)[ultimatedns.net:-]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; TAGGED_RCPT(0.00)[freebsd]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; local_wl_ip(0.00)[24.113.41.81]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Rspamd-Queue-Id: 4cQjNB2W8Zz3hXB --=_5d355f4c45a660dad780cadfa089ed3e Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-09-15 15:54, Chris Ross wrote: >> On Sep 15, 2025, at 15:01, Ronald Klop wrote: >> >> Are you able to boot a 14.2 kernel? >> To split the search space in two. > > I could do that. What’s the easy way to get an unpacked 14.2 generic amd64 > kernel? > I can install a VM at work and copy it, but I assume there’s a package I can > just unroll. You could unpack the necessary archives from here: https://download.freebsd.org/releases/amd64/14.2-RELEASE/ I do this sort of thing all the time for jails. These releases work "out of the box". :) HTH --Chris > >> On Sep 15, 2025, at 15:05, Tom Pusateri wrote: >> >> I would try running the 14.3p2 system without the VLAN configuration and a >> direct connection to the upstream provider hardware (no switch) and see if >> the problem persists. That will determine if it’s a VLAN issue. > > That would be a bit of work. I have an available ix port, so I can run a > line to > the machine > without vlan. It would still be a VLAN in the switch, because running a > direct line is not > possible without much rewiring and very long cables. But if the test is to > rule > out the vlan > interface I can do that. It just requires rewriting all of the systems > config to > know that the > outside is different than it is now, which _should_ be easy, but I don’t > know the depth of > it since I haven’t done it in eons. I’ll look to find a time to try that. > > - Chris -- There is no such place as the internet --=_5d355f4c45a660dad780cadfa089ed3e Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_5d355f4c45a660dad780cadfa089ed3e-- From nobody Tue Sep 16 00:48:17 2025 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 4cQjv149dHz67dbm for ; Tue, 16 Sep 2025 00:48:29 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (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 "ultimatedns.net", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQjv10yW8z3kf4 for ; Tue, 16 Sep 2025 00:48:29 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=fail ("headers rsa verify failed") header.d=ultimatedns.net header.s=mx99 header.b=RZSZ9OI1; dmarc=pass (policy=reject) header.from=bsdforge.com; spf=pass (mx1.freebsd.org: domain of bsd-lists@bsdforge.com designates 24.113.41.81 as permitted sender) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 58G0mIU2028196; Mon, 15 Sep 2025 17:48:24 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1757983704; x=1757984304; r=y; bh=Qu4UI8mD4j0z3n97AboPBUsImlhxQLI9jA1ZgD3Y7tI=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=RZSZ9OI1CQJxRYxpEPtFOAFbrCsIpoMjUv5AN6ssB8iO6Xzv0EnxDYw0PABHoj71K zY+T2IaKTXkC/JFDvZyjJRCHF/bt26sgmjnDIAGHcQNaVwjGRjlQkbbwpW9ymlZVBU 6d4VsFOWWbn+wHqQr83HWGyo+NvfmIvnPGyafhKaw+TaNb8USIZS0BHZtUm9mj87BU H+TlVFU6HaeL1ZPIhTrX/0l87vZWFWBkewyGGu24K1aQ7TNbVmys5jyerhsnM/dXeL DPTyeC4eY4DKuwjT1Fua5wo5twn2ixPtJ+iv5daL11pxoYelLvFecXVUZkDLTN8QuZ 6eyPphdjY5rcw== 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 Date: Mon, 15 Sep 2025 17:48:17 -0700 From: Chris To: Chris Ross Cc: Ronald Klop , Tom Pusateri , freebsd-net@freebsd.org, Karl Denninger Subject: Re: IPv6 networking problems in 14.3 In-Reply-To: <4f25c12b48572737b95e139d9534b0f0@bsdforge.com> References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com> <4f25c12b48572737b95e139d9534b0f0@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_699e7508de2cc998b0d463c6e59efea7" X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.00 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; R_DKIM_REJECT(1.00)[ultimatedns.net:s=mx99]; DMARC_POLICY_ALLOW(-0.50)[bsdforge.com,reject]; ONCE_RECEIVED(0.20)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MIME_UNKNOWN(0.10)[application/pgp-keys]; HAS_ATTACHMENT(0.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; ARC_NA(0.00)[]; TAGGED_RCPT(0.00)[freebsd]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; local_wl_ip(0.00)[24.113.41.81]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[ultimatedns.net:-] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Rspamd-Queue-Id: 4cQjv10yW8z3kf4 --=_699e7508de2cc998b0d463c6e59efea7 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2025-09-15 17:24, Chris wrote: > On 2025-09-15 15:54, Chris Ross wrote: >>> On Sep 15, 2025, at 15:01, Ronald Klop wrote: >>> >>> Are you able to boot a 14.2 kernel? >>> To split the search space in two. >> >> I could do that. What’s the easy way to get an unpacked 14.2 generic amd64 >> kernel? >> I can install a VM at work and copy it, but I assume there’s a package I >> can just unroll. > > You could unpack the necessary archives from here: > https://download.freebsd.org/releases/amd64/14.2-RELEASE/ > I do this sort of thing all the time for jails. These releases work "out of > the box". :) O. Wait. You wanted a VM image. Try these: https://download.freebsd.org/releases/VM-IMAGES/14.2-RELEASE/amd64/Latest/ > > HTH > > --Chris >> >>> On Sep 15, 2025, at 15:05, Tom Pusateri wrote: >>> >>> I would try running the 14.3p2 system without the VLAN configuration and a >>> direct connection to the upstream provider hardware (no switch) and see if >>> the problem persists. That will determine if it’s a VLAN issue. >> >> That would be a bit of work. I have an available ix port, so I can run a >> line to >> the machine >> without vlan. It would still be a VLAN in the switch, because running a >> direct line is not >> possible without much rewiring and very long cables. But if the test is to >> rule >> out the vlan >> interface I can do that. It just requires rewriting all of the systems >> config to >> know that the >> outside is different than it is now, which _should_ be easy, but I don’t >> know the depth of >> it since I haven’t done it in eons. I’ll look to find a time to try that. >> >> - Chris -- There is no such place as the internet --=_699e7508de2cc998b0d463c6e59efea7 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xE512722F.asc Content-Disposition: attachment; filename=0xE512722F.asc; size=3074 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGf/G0IBCADARuJc6IcwOe3jv7dQsP1X/EIHvCFExPbTmlMNFMXbMMccQUnV o8ayEn+wmTvPhw7uL3PDk7DQs16W1sN2b8UMFc804cVWNGtoG3rA+Np+TFEYlXJx eh5Q42VHptkuwzHKl+q2utkpRlS7uHyfjsInQAoHxLyi/wrsaZTHHhDbLLhJ5Ez0 arohQ2Q1w0M5e9rW8Fy5rpC7RpC6uO1SZMxcbdqURI/BBqxbiD1iW62cDWFkfFX+ dtaEXghFV7BIBMDSrgIunGoEfdMZgXys7O6bPWn8z0cuOZIPj4HrjoCYARyQ+sdc rjz/k06SLM/UvEZDorJhT4DbYrwMNvaPWJiPABEBAAG0HkNocmlzIDxic2QtbGlz dHNAYnNkZm9yZ2UuY29tPokBNQQQAQgAHwUCZ/8bQgYLCQcIAwIEFQgKAgMWAgEC GQECGwMCHgEACgkQVKBqaOUSci8bSwf/fK3QcTYXRMrv82HIp4SiGCSD7/bRmyWr ipv2vzknGFHxPBN4AEWIqF/U4j5oDXaodyU6xsy59Z47/lgbyzyZiVR6nmJVgZVf el/EgwnLt7ZuYGLLEhIN2pd9itJkB8PMPZrUHMWgIw8BxX5YFYGuyiNe9pGn0Coj 98t/v3fouhqksH+BpB4TBHJBBDSxSiMm66VTJX4Xcnpf0ZnQVP4GBuoyodnFBfdI wqftPLESsCC08lUhD2j7v2NRWwMi/q3ed8D6VCKPImBByYnBZL5gu56K5bwqaQfN itu06APuIYnG71qxgn1EPO63lovWP5NZGgOKvzs3K+JfPF79BiOUFbQjQ2hyaXMg PG1haWxvcEBocmNvbW11bmljYXRpb25zLm5ldD6JATEEEAEIABwFAmf/G0IGCwkH CAMCBBUICgIDFgIBAhsDAh4BAAoJEFSgamjlEnIvBH8H9RGwzZuU6+zvH1WjQa97 yWpEt9rC+BIBJThev2Cpls2LqBqIeIQVZPnyLAZWgFaiezL6+xbvcNt6OnfidIYa x8iRwCMC6/Bs8H2Wef9qfGxXi+jHPLYQk3juiZVmBhIK6FJZkzaW4wSiawofwzbp zqNxO8dZ0j4foaJZrNi8iqsvKjiiHoSFaJtumIThAeydI18CNLeFaS53sk5nad6I wCYeFKmJ/22dMP7DOFEgyG1iNYgY+AGREMkEsBiLpqYjJ5asK+1UdUy/TRly1hOt HHxCiX0Fh9ZYM2vLIj7sq4LKaMPGeYC3qTqBYugVeyz7LkiI2ft/BKveA5JxuYKk ZrQiQ2hyaXMgPG5hbm9nQGhyY29tbXVuaWNhdGlvbnMubmV0PokBMgQQAQgAHAUC Z/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci+4Bwf8D0Ogk2/X ud/CsAgHozwzKPqfesL5SRWM14hLnU9/EHoplnZgNexbVY1wXIi2FYPo5cve9QxW Nmt3S3UTF9j2fGqv0wmeHv3EqogFUHnftLyWpbeTPOFDMIQp/BOD6ygfeXxXWxRT L6zvUkSrDtHvkQHPWGRxwP+ihWjpw9AQR/R4/qAuTAZZM0O7UnJEo4mWXatl+utF wegG2giwFTTxfF+1rMpFtUDjYCpRQ6ZmE+gC1mHUMoH7GJMQv12DbqwKrxtwGfd0 AJNO3ZDnxl24BmIfl1YqQGZQ5iIH7At4YItESbU45hoNNsG9oDrsil78EUCAtXHd UPScj+eXaeAkgrQfQ2hyaXMgPHBvcnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBMgQQ AQgAHAUCZ/8bQgYLCQcIAwIEFQgKAgMWAgECGwMCHgEACgkQVKBqaOUSci9o7Af+ Lwu5hJlI5HZNGwAll7QTIFZVW+y4OEg+amhxTDGbAAqlnSIkHC1KgkmIOOrThme3 kTFCqfIIsuP73yKxHq6kRG0zH5/7asAPNAUOfzD7B2o/gMyuTRKyG5r9f3UmACr4 6qvtFhIwROXr6+NNT2IKg3l0/8F58A0N/TR8D2PTHeo4x6jYcZQDCrCy7BAdk3cu V16k4z/1UzRa07b5McezbWL20cIaZ+dqNcCjKZpzPlTyTCGgrNNtaDpNVhoWUKMB YNcKql+tfC1IpX8l+IU6OBKcDKMkQojvO1QrZqY8MDJGo8jq/CtotQ8+IpAai3Bx dQEsxrxlcKTR4rUqvd8VGbkBDQRn/xtCAQgAv5Nv/aQN72xsLik+K73PJwpUmyhu vnI6stM6dSecylXVHjZ7C4n/m0eQEeQCl+9lByHR9N8H+WS3DtAd4pmciiIxRQLA JZiuaLYcy9ziy1h7130VoR7hhJHzo9FIhWkTGlCDX3egUZrYhMiwFUO8lNltLB8o TBvIrMSsnUzawtQjq/otv0Jf+oBPbG+gIYnAm7w6r86n/l+eVxf5eEoS7wV0DJfp b2jE5zWErWk8I/tq4e8T+1VQeVQR6wz+NrUCSxkPkpNAm19AFUHOk//yvMGWVlDW F6gr3ErN2a0w/kZ0lz3Msxsb87QT+MnJf/T3cuEqdTIoSk74BfNEAdMohQARAQAB iQEfBBgBCAAJBQJn/xtCAhsMAAoJEFSgamjlEnIvyvIH/26zytSVNDaxtprg7XtX LerIWf9RyVx8omCw/lXKRCcgkfwD7QR+nSZ0thWOGMpcnivjuReeVRkz/webUF47 BXJ/Tge07nrxdtyTIHBbp35fPIriaKaII6YWc2Ufdxwv+cD8PADS6gQWAlgrWLmn VmYtyHs4kwtiPZyUyuBdWnZal2GyYY0WVwYjvbk95eInwOaIdoTjesJ7ZhUFu155 r4hh9GlvM0uv8WJ5Mw9wvHa5fIM205I5g0IWC7yvTwwwKHlV4JQQOqMwfv569OEl 1GKqA12nSVziB1+UV+I0NqOABWi/MOi+IySPzYP+XgdPfRNx4vmoHYZwWOQ3t4Jd TEM= =oj6y -----END PGP PUBLIC KEY BLOCK----- --=_699e7508de2cc998b0d463c6e59efea7-- From nobody Tue Sep 16 07:39:26 2025 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 4cQv1B3VTPz68VMX for ; Tue, 16 Sep 2025 07:39:26 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cQv1B2wJ4z3cZ9 for ; Tue, 16 Sep 2025 07:39:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758008366; 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=ThoInRQzZpG3L5+PX7Y2qaor50HVUjfgUJagAxGxKXk=; b=PapaDuwLpUqofj5lVvbExPPz5QU2j1F8tQgTO7QpXNdOZIViymP1ALF7FTq1uw3Q08eV/B HAYBQWNJVzOD+7RuZr9HEpqk+z1qAYNd7WTjHhGiqZDpYeh2x35OM2I4qwvtNWPNarbv/Y O7JTtMCFj4Ts2IK90oHNpEaHogta3TrOUsaVAPtrb8LaXOpfS3qleNGzJO4lLeVTSX7L3K OPlJXrareCF3QVSp8IrqVWFYSWWp9dv68cXUJhuVeX8tx2YP7gi03AJKCOkUy3ZdpSaU0H coTDvfvoIEjywhGAyJbr2dK0kFhEtSIK88qdANhUsysh+azIXIbpY91S4L4/Pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758008366; 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=ThoInRQzZpG3L5+PX7Y2qaor50HVUjfgUJagAxGxKXk=; b=FbRDU6BpixvmYQOUOoac+qu1fU+Z49Zx69biXts0Itjudu4bNQL2Tz3chd/thjTq2qS9XI 6tbGhYxkQzMRRZtWDTKc2av4/4xy/dbrUVQvjs9NYZCfrCUpa9myzW1OERwQc6nK8LYmm0 18NQoZG2yt/cF75CGoANCtIjr9aHfkurCbSh6TcgkQabUIkKmpQzdp+sCt32jTym2ovDat h4ioyUTYkq6+D+M6+edRQxEdJ6YPOj3j/FmkqL9gWq+OLcfgP9ANn7Ah3g0kOeH7VfIMUz hi28o29joP3vjvJKlk0Rf9hfN5lrPkN9UuHDBXz+7jtzBi6LdtSkz6paO2Vixw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758008366; a=rsa-sha256; cv=none; b=t4l+6zxIeVN/7Gzg/AqEjWIU/9o0XP09aEmUqXXwPRf84OXXxkNaxfT+yUPDObHIgrFUmA Z4EtQOsunXtm7Io169QTTVZzHYSkVg+YkqOfC2H4a3YVOT/5EVAUXVKeAVNG5pFudRx3Yx Vymke1PTyYdcohAiC7HeIb0WXAbmVrtToQlcKCZXfrWulpzU3F3itfopQyZdelHI5W04Mc l/Gzvneyqn65Vq0/LkxYQuc2Pnj7QxtBOVImPVJbEJiZSpOyEi9U7ymJT3KUBbn0BeVBk7 +fJoeT3J59bkD4uwhc0LMBFCjvRQc0UGAVYKELtutcaMJellosLQjyz2qFTiXg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4cQv1B2MvSzXNp for ; Tue, 16 Sep 2025 07:39:26 +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 58G7dQHI062616 for ; Tue, 16 Sep 2025 07:39:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58G7dQGU062615 for net@FreeBSD.org; Tue, 16 Sep 2025 07:39:26 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: =?UTF-8?B?W0J1ZyAyODkxNzddIElQdjYgdGVtcCBhZGRyZXNzKGVzKSB3aXRo?= =?UTF-8?B?IHBsdGltZT0wIGJyaWVmbHkgbG9zZXMgZGVwcmVjYXRlZCBvbiBSQSDihpIg?= =?UTF-8?B?T1MgbWF5IHBpY2sgdGhlIG9sZCBhZGRyZXNzIGFzIHRoZSBzb3VyY2U=?= Date: Tue, 16 Sep 2025 07:39:26 +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: 14.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: commit-hook@FreeBSD.org 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=3D289177 --- Comment #7 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D588a5fad3e8b98955b60707e3e92b8b43= 566e3f7 commit 588a5fad3e8b98955b60707e3e92b8b43566e3f7 Author: Andrey V. Elsukov AuthorDate: 2025-09-16 07:34:55 +0000 Commit: Andrey V. Elsukov CommitDate: 2025-09-16 07:34:55 +0000 IPv6: fix off-by-one in pltime and vltime expiration checks Previously, the macros used '>' instead of '>=3D' when comparing elapsed time against the preferred and valid lifetimes. This caused any depreca= ted address to become usable again for one extra second after receiving each Router Advertisement. In that short window, the address could be selected as a source for outgoing connections. Update the checks to use '>=3D' so that addresses are deprecated or invalid when their lifetime expires. PR: 289177 Reported by: Dmitry Nexus Reviewed by: zlei Submitted by: Marek Zarychta MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D52323 sys/netinet6/in6.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Sep 16 13:36:18 2025 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 4cR2wz11d0z67Gqv for ; Tue, 16 Sep 2025 13:36:19 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cR2wz0V6Zz3Rlv for ; Tue, 16 Sep 2025 13:36:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758029779; 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=5yTR653/XmM/murwkhK8z4d642PGfYqdWKP4h7A8Slw=; b=XjlbthJEz+z64EQ3ATh6Vaafbsxkz1NymmULH5EQT/657SX5BIClf327Nrymfirz5KoBnO T+YWmBK5fWiTM/KXImkSX1JMCLCW36xSpV5znJtRN/WYTSXzfWHwQGtKQ+d/KZzwUBYh3e t4u+Iz9gRuIBQOLnj5jQ3i+UwsV2ZmCJ/XYIctDAR7T1Ec9AA57tzI1PBUlYN5C3P3Qbls n+Qa3SRSDc0EZLmbQYFo/u6kaZXzwMMwAZLjC58/aOFee3JV2oCS+IzaIY8B41RgQQBTyP i8YBbkufUz1+5TYGu6VR+14vWsqR7TFf+503v30CFcYS9jN5bdbHFwkP5HNMFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758029779; 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=5yTR653/XmM/murwkhK8z4d642PGfYqdWKP4h7A8Slw=; b=uEhYffeEX0lOBqC9CyMDinoY/aciI6jfYuCLahJZ17AyWAZ2Xm7HA/WJAtyRrxPYrBF4b0 vwcV76UamX9VRv+oPl5K5rZyBi1bJBB5gqxFzd98OxDEJrAkLM+rEegWT+KmLqy5sR6M9S Y316jKJgAhoJI9/iubMJgAvB62/QFVn/O7w4If6vhrP5fWpuZKR9CQ0ppFEDcDE+x5VpTa p8PeLXxl/CWyokWNMj6qBRyjWPrfN30r4Gkiqlo4LES0l9xbDDjSQNqniOmIJ9NVcPBh4K 9vEscv9Y+vUEqIXCQxbIK20FjYdPxJVpmQ0QgUj1fjyqYCZNoyOcTnpfnv0cxg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758029779; a=rsa-sha256; cv=none; b=mrdaZmtEb6PgGBmrcuS3nUFZme5YNQgkVzGeIn6+Zjt1vUD7HyWZZbCkkKqeUOzexKPAZ0 cXiN4UemyXmWRrgtI1Ypk+8+QrtrlWhMG0DX4iHOX8/CIRcCyTwvThbjWae5LxN3tg3bNu CS7yrOH7KakbTDHQLXx4ucHI+PveL+rCx8HsbE/ZUhmUDJPu3CXL5dcU9qjZm8XHdkObzC 5TgBchxHOprZ5vYa+gjZebvTIZEaXaiFflfiJjjEXl6JxFwPOYEcYwKQh1jLDb5BQugEqt 0R4jdao1cX3i2rXdW/K4CGGbfRBEyRjg9zu/bGgLK8eE26ZkkthZg8jT6Zwdsg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4cR2wz01X3zjYQ for ; Tue, 16 Sep 2025 13:36:19 +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 58GDaIL1015186 for ; Tue, 16 Sep 2025 13:36:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58GDaIhJ015185 for net@FreeBSD.org; Tue, 16 Sep 2025 13:36:18 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 284283] if_re(4) crashes when attaching on RVVM Date: Tue, 16 Sep 2025 13:36:18 +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: mhorne@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=3D284283 Mitchell Horne changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |mhorne@freebsd.org --- Comment #13 from Mitchell Horne --- Hi, Several weeks ago I could reproduce the crash. As mentioned in replies here, the problem had to do with unresolved module dependencies. At present, the crash no longer manifests in main with `kldload if_re.ko`. = I am not sure if the issue was fixed or hidden. However, I have just committed a change which adds the proper PNP info to t= he module, so it will be picked up and loaded automatically by devmatch(8). Notably, the devmatch rc script performs all module loads within a freeze/t= haw of the device hierarchy. It is the following commit, which will be merged to stable branches in the = next few days: https://cgit.freebsd.org/src/commit/?id=3De13b5298ec87be03da2231bc7b44a6a4b= 976b850 Best, Mitchell --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Sep 17 03:24:27 2025 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 4cRPKK738Gz686my for ; Wed, 17 Sep 2025 03:25:09 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.95.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cRPKK0MTPz3TrJ for ; Wed, 17 Sep 2025 03:25:08 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=relay.distal.com header.s=mail header.b=oiMAvn3o; dmarc=none; spf=pass (mx1.freebsd.org: domain of cross+freebsd@relay.distal.com designates 168.235.95.80 as permitted sender) smtp.mailfrom=cross+freebsd@relay.distal.com dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; bh=HkRqg1X+t8RLyQt3O5cqXVyZ2mH3ti9W40229aoGQgw=; b=oiMAvn3o63sHL6H/o1EndNdRoptOY5YpI/ubTe4i0Du31f4dM1Z9kDJkjKx58Q07HVqdWD3v5C5qL9LcbnO+N+TKQSr41lhYypWD2Ien9HFjV6tiol7HOPuuqv8Glu7Fugrkl1Ur6j2Dig4AdTzxRHK2aOJjNHtGARvQYbNoBxZ6vP/tkXd1SMp2hwHEZ0jMh9uHeIyHI1H2kkjXs2fUlWDg9LxTYFfqBvHoDWE32mIpADNLaKv1+FnP6E DUGDpduTe/1nDctqPAh1V/cIQLgTFMpzxkIV68ihN/L3azn7eiDtCtRMXU1hoIL1TUvfHnhzXNpZvxXBMNiGayx0BAcA== Received: from mail.distal.com (pool-108-51-233-124.washdc.fios.verizon.net [108.51.233.124]) by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256) ; Wed, 17 Sep 2025 03:25:00 +0000 Received: from smtpclient.apple (magrathea.distal.com [206.138.151.12]) by tristain.distal.com (OpenSMTPD) with ESMTPSA id e212a1cf (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Tue, 16 Sep 2025 23:24:58 -0400 (EDT) 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 \(3826.700.81\)) Subject: Re: IPv6 networking problems in 14.3 From: Chris Ross X-Priority: 3 (Normal) In-Reply-To: <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com> Date: Tue, 16 Sep 2025 23:24:27 -0400 Cc: freebsd-net@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com> References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com> To: Ronald Klop , Tom Pusateri X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FORGED_SENDER(0.30)[cross@distal.com,cross@relay.distal.com]; R_SPF_ALLOW(-0.20)[+a:relay.dynu.com]; R_DKIM_ALLOW(-0.20)[relay.distal.com:s=mail]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[relay.distal.com:+]; FROM_HAS_DN(0.00)[]; TAGGED_FROM(0.00)[freebsd]; DMARC_NA(0.00)[distal.com]; HAS_X_PRIO_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:3842, ipnet:168.235.92.0/22, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[cross@distal.com,cross@relay.distal.com]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4cRPKK0MTPz3TrJ > On Sep 15, 2025, at 18:54, Chris Ross = wrote: >=20 >> On Sep 15, 2025, at 15:01, Ronald Klop wrote: >>=20 >> Are you able to boot a 14.2 kernel? >> To split the search space in two.=20 >=20 > I could do that. What=E2=80=99s the easy way to get an unpacked 14.2 = generic amd64 kernel? Well, okay, that was something. I extracted a 14.2-RELEASE /boot/kernel = and was able to boot into it. The system came up far more properly than it = had under 14.1-RELEASE-p5 tried earlier. (Resource limits couldn=E2=80=99t = be applied in rc.subr with 14.1). But, the IPv6 routing problem still exposed = itself. Then, just to confirm, I rebooted into 14.1-RELEASE-p5 again. This was where things stopped being useful. This _also_ failed in the same way the more recent kernels had. I don=E2=80=99t _think_ I changed anything = between the last time I tested that, just selecting a different kernel from the boot menu, but this time it didn=E2=80=99t magically work. So, I = can=E2=80=99t say any longer that it=E2=80=99s necessarily a regression between 14.1p5 and = 14.3. I mean, I could try resetting my whole image to a snapshot from 14.1 (ZFS root), but I don=E2=80=99t think it=E2=80=99s worth that effort. >> On Sep 15, 2025, at 15:05, Tom Pusateri wrote: >>=20 >> I would try running the 14.3p2 system without the VLAN configuration = and a direct connection to the upstream provider hardware (no switch) = and see if the problem persists. That will determine if it=E2=80=99s a = VLAN issue. >=20 > That would be a bit of work. I have an available ix port, so I can = run a line to the machine > without vlan. It would still be a VLAN in the switch, because running = a direct line is not > possible without much rewiring and very long cables.=20 So this is my next attempt. I don=E2=80=99t know if I have the energy = for the whole thing tonight, but I=E2=80=99ll start running cables and configuring the = switch at least. See where I get. :-) Thanks all for your time, I am just more confused now. - Chris From nobody Wed Sep 17 03:56:41 2025 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 4cRQ1k0YGDz689CF for ; Wed, 17 Sep 2025 03:56:42 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cRQ1j6cl0z3Y4Z for ; Wed, 17 Sep 2025 03:56:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758081401; 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=cKCyeoXl2jWv/hIlv1BM5oUYybDJ7XlyR0LpKA6eTTs=; b=f4fyFxzJD+Hu7cEfXGBGgDzbcgm8lmVvx/5gHPw/psdVPEreu4OpuWurhU0ONO03GmmoZg 7rbQiN0MAt7EjabnDEEwvMSy92wvrxy+30P+JM4KQ57fjKIBiEco35v2mC4NqjXf43uRFm OnbIF+9IRkMyB/VItyE8de7OMGN6l4WitTIbqNmWJ2fDrpJx5+ND4LhioZuCFW2txZWOMx d19dkDH3tEtlyG9wuKa4Z+8PLfitFJxBPfhp0DPrACmZ5a27cbPC1topik4w8SpVRN7eJu m+E4fjQcIkF3+K2kUXLs+p9GfOwXe4MPOwpKzLawtaEszweFgeXpDorJxPSX+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758081401; 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=cKCyeoXl2jWv/hIlv1BM5oUYybDJ7XlyR0LpKA6eTTs=; b=KCYrvV0MwHjLee/VhUn72vR1fnkuflt+UbmEPSSuWhxGWel0NZwKtbGLQ50v6rjEO0/KVc kf70oyAManq8QMYDtasHPN5WsZAE4yWbazRIOMv4B6LWdaP1ALFo3gXwvmQ53UCnU0EjaU DZiU7DTvZWwztPHcAqClS6s+rX8Ufcj0sGrNgBmpyZbWScMCASVCugHU0hIfxod0JdeFXS CyhfNiB8A3WKZme2tZSoaZW+f2H2iFCpRDDnci+JRLa0lncCxg2xPcdpSJ0EeAhNDI/kM3 aswdjs3VXUgh819YRV/8MoQP9LNv7FUnTTye33ikrGTkFGjU8sBbCrZz9sdgqw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758081401; a=rsa-sha256; cv=none; b=MZF5YN/htDy8H/KObhVzJMY/+b/KlhJZrx1k95ZCpiUyRucn9yre/FiPwE0U22wWbrHmwo prhaGa8SYdgZn43b+Kxp3rXnn29+/oPA0M97Kn68oliGw3Cw2DQDZnM9XxkQmigoDpHEIB UYf2NGU0yb8k6gTEEPZxDNUHP9SRH7Bm9zXSOPqvmrQhNU4P2K4be8+HgARzfqybMCiApC pDdJSZr3Ryy4gpkkuqnXfp89TCaDBFiDZZgVtDVDJCgAmVceXA6wCdmbNcmUcYdmq3er9J pEKa65a50etBzYCav9tEgzw0dtESov+EHcQReiw6OadCJzOsfSlky7M0MrhRnQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4cRQ1j61tDz17kC for ; Wed, 17 Sep 2025 03:56:41 +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 58H3ufVP025575 for ; Wed, 17 Sep 2025 03:56:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58H3ufin025574 for net@FreeBSD.org; Wed, 17 Sep 2025 03:56:41 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 284283] if_re(4) crashes when attaching on RVVM Date: Wed, 17 Sep 2025 03:56:41 +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: hyogeollee@gmail.com X-Bugzilla-Status: In Progress 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=3D284283 --- Comment #14 from Hyogeol Lee --- (In reply to Mitchell Horne from comment #13) Hi, It seems hidden by patch in the bug 286530 And it seems both cases can be closed. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Sep 17 04:07:50 2025 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 4cRQHR25TMz68BCJ for ; Wed, 17 Sep 2025 04:08:35 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.95.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cRQHQ2nKWz3YyK for ; Wed, 17 Sep 2025 04:08:34 +0000 (UTC) (envelope-from cross+freebsd@relay.distal.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=relay.distal.com header.s=mail header.b=Q6dqWfBp; dmarc=none; spf=pass (mx1.freebsd.org: domain of cross+freebsd@relay.distal.com designates 168.235.95.80 as permitted sender) smtp.mailfrom=cross+freebsd@relay.distal.com dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; bh=TO4eaBgaKV/dMJR+e0/WxHOtYOudv9TXOcU62e7RFg0=; b=Q6dqWfBphZtAFLki3HT/StAochZDj+UVubvIsp9ui3/+fIS5iI8gGhz/p85wXCXd+L1LSXkwl2XG9/bdZ7pnElIMKi/gLDsLDYzFqXMC9yYC2Iav28ekG7WZyzV6x+tF7t0zOVJtY/wtQ7MHt0XqnlC769Vq8fxrSo1bV22VGymkVGucICq5W7rStYugNtnVlwOyAPxSLLcPmw5Vq0ApgASQ6XCd37oD1ru5qm73eOGLIWlDBkIXXrt6cD Zc6G+3s9Mng42Jvk0tspqL1XeiOfyoM1e2Xe/z/C/sXqE2cybuI68VG/GLbeCt39grpdtWkuQkq+OLHA2B6t9QinNp+g== Received: from mail.distal.com (pool-108-51-233-124.washdc.fios.verizon.net [108.51.233.124]) by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256) ; Wed, 17 Sep 2025 04:08:23 +0000 Received: from smtpclient.apple (magrathea.distal.com [206.138.151.12]) by tristain.distal.com (OpenSMTPD) with ESMTPSA id b5167148 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Wed, 17 Sep 2025 00:08:21 -0400 (EDT) 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 \(3826.700.81\)) Subject: Re: IPv6 networking problems in 14.3 From: Chris Ross X-Priority: 3 (Normal) In-Reply-To: <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com> Date: Wed, 17 Sep 2025 00:07:50 -0400 Cc: freebsd-net@freebsd.org, Roy Marples Content-Transfer-Encoding: quoted-printable Message-Id: <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com> References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com> <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com> To: Ronald Klop , Tom Pusateri X-Mailer: Apple Mail (2.3826.700.81) X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.18 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.982]; FORGED_SENDER(0.30)[cross@distal.com,cross@relay.distal.com]; R_SPF_ALLOW(-0.20)[+a:relay.dynu.com]; R_DKIM_ALLOW(-0.20)[relay.distal.com:s=mail]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_ALL(0.00)[]; DKIM_TRACE(0.00)[relay.distal.com:+]; FROM_HAS_DN(0.00)[]; TAGGED_FROM(0.00)[freebsd]; DMARC_NA(0.00)[distal.com]; HAS_X_PRIO_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:3842, ipnet:168.235.92.0/22, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[cross@distal.com,cross@relay.distal.com]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; APPLE_MAILER_COMMON(0.00)[]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4cRQHQ2nKWz3YyK > On Sep 16, 2025, at 23:24, Chris Ross = wrote: >>=20 >>>=20 >>> On Sep 15, 2025, at 15:05, Tom Pusateri = wrote: >>>=20 >>> I would try running the 14.3p2 system without the VLAN configuration = and a direct connection to the upstream provider hardware (no switch) = and see if the problem persists. That will determine if it=E2=80=99s a = VLAN issue. >>=20 >> That would be a bit of work. I have an available ix port, so I can = run a line to the machine >> without vlan. It would still be a VLAN in the switch, because running = a direct line is not >> possible without much rewiring and very long cables. >=20 > So this is my next attempt. So, reconfiguring this wasn=E2=80=99t as hard as I feared. But, it=E2=80=99= s not working. I=E2=80=99m getting an IPv4 address as before, surprisingly even the same one, on my ix1 = interface. I=E2=80=99ve changed interface names in rc.conf, pf.conf, and dhcpcd.conf. However, = dhcpcd is now doing something different. Only changing the interface name in the = config, I=E2=80=99m not sure why. Sep 16 23:47:34 [98787]: ix1: soliciting an IPv6 router Sep 16 23:47:34 [98787]: ix1: sending Router Solicitation Sep 16 23:47:34 [98787]: ix1: Router Advertisement from = fe80::3e8a:b0ff:fe3e:4dce Sep 16 23:47:34 [98787]: ix1: no global addresses for default route Sep 16 23:47:34 [98787]: ix1: executing: = /usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT Sep 16 23:47:34 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next = in 1.1 seconds Sep 16 23:47:36 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next = in 2.0 seconds Sep 16 23:47:38 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next = in 4.2 seconds Sep 16 23:47:42 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next = in 8.9 seconds Sep 16 23:47:51 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next = in 17.8 seconds Sep 16 23:48:03 [98787]: timed out Sep 16 23:48:03 [98492]: forked to background Sep 16 23:48:09 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next = in 37.9 seconds Sep 16 23:48:47 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next = in 71.2 seconds Sep 16 23:49:58 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next = in 142.0 seconds Sep 16 23:52:20 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next = in 274.4 seconds Where as before, when it was not getting the answer to NS, it was simply = doing: Sep 15 14:00:58 [10047]: vlan0: soliciting an IPv6 router Sep 15 14:00:58 [10047]: vlan0: sending Router Solicitation Sep 15 14:00:58 [10047]: vlan0: Router Advertisement from = fe80::3e8a:b0ff:fe3e:4dce Sep 15 14:00:58 [10047]: vlan0: no global addresses for default route Sep 15 14:00:58 [10047]: lo0: adding reject route to = 2600:4040:2c9d:5200::/56 via ::1 Sep 15 14:00:58 [10047]: vlan0: executing: = /usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT Sep 15 14:00:58 [10047]: vlan0: multicasting REBIND6 (xid 0x0a7d83), = next in 1.0 seconds Sep 15 14:00:58 [10047]: vlan0: REPLY6 received from = fe80::3e8a:b0ff:fe3e:4dce Sep 15 14:00:58 [10047]: vlan0: renew in 3600, rebind in 5760, expire in = 7200 seconds Sep 15 14:00:58 [10047]: vlan0: writing lease: = /var/db/dhcpcd/vlan0.lease6 Sep 15 14:00:58 [10047]: vlan0: delegated prefix = 2600:4040:aaaa:bb00::/56 Sep 15 14:00:58 [10047]: int1: adding address 2600:4040:aaaa:bb12::1/64 Sep 15 14:00:58 [10047]: int1: pltime 7200 seconds, vltime 7200 seconds Sep 15 14:00:58 [10047]: int1: waiting for DHCPv6 DAD to complete Oh. So with a new interface, dhcpcd isn=E2=80=99t trying to REBIND, so = it=E2=80=99s a different process. I=E2=80=99m not seeing any response to the SOLICIT messages, = but I admit that I wasn=E2=80=99t watching the DHCPv6 ports earlier, only the ICMP6, so = this may not be new. This is all for tonight. I=E2=80=99ll try more tomorrow. Thanks all = for your time. - Chris From nobody Wed Sep 17 07:21:18 2025 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 4cRVYp6vjkz68PY8 for ; Wed, 17 Sep 2025 07:21:18 +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 "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cRVYp4y9Dz3qxg for ; Wed, 17 Sep 2025 07:21:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758093678; 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=rB1a1clyNEmNmYuUTXXEnSvujjUOASHU4LbRKhZUTnY=; b=NbiqTzRRHtxOWj73pxs0uo/mALzUPpf/+jVxruLXAhSdQ+j3F5HJPjEBQ5jF/biDxRohld UfNq3zq0l4OG8GZ+k3wS/vxhAxC6GAvIlw3Y2t605TdkQZ9wIdHCJxFenl8Q9Df9FiA+JC IteXzQjxgacDrWRtqeSmSWDivpYBOMsBvXG/TLjYbbmFSbvJLKIdcBB9rlzIlgMop7QXYd jNnuG3EvXYoKPkgKO1zD2QCLQ9ULZpY7K7JOAN4Qzk46eEhD50KwiWbSQY+LXkEP1gUBIA +vFTn4J+8/czD+4hV56+eqBkNHQT1ZSop/yeHQK1N+hsXQZjl8ic1qwQiq3LVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1758093678; 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=rB1a1clyNEmNmYuUTXXEnSvujjUOASHU4LbRKhZUTnY=; b=iBSoFkOZeLBouvj2Y3IDWq30tjVMV8G/IJzvYqh2iL2JINF3Sdi+wjjs3zPZUTGeGrXfGQ U2LEFyHi89pvUZpCDXj1n0ENYsSPtGOAyVVsZeXEN8MYCdNAG5wvOqqWnqVnJU+OXR1iNz Yq+OMhCL2qLoOveYmKPO5JhYHUsobxVgo/DmoShDFhaMoeP2fR1yWca9td/SFtqCX/ku/F dE7AJ+MsC9ta3dWZ+1U+yx4p+Evsv0me5eIHPfglpR5ySEfwvmqgz2CWlE87b+MuK9a2rt YO1FusmiqI96ceNsWSUboTAX2Tnm/0k5UUHOFPPyTBocdFbHA3bXc1x3vqcAvA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758093678; a=rsa-sha256; cv=none; b=yJlNELXVAiFx9zMoMYuxfjNfo+TMhH79P3D7WFSR1E7IMJIfyVMF7mQTU0eUeukIVhD++5 bhTlUwtjuX8o6rhb7Qac3o4w7LGjnwfs1JfzNtWpsOTRmq6bpsRonPgrWCKS4YP28WCYV/ jsSl4W2uCjNFb8wsPjQ8MtwAZGAVF1YmNCk2yQ71x3r1nxWEKOWtra7iLyX4CKS2HYMiF7 t8MpP+QBOdw4vRRRJ3d4Zb3MJ0+l5+FzeRCKqy3/WfmBJuNEteFuPQYw2lgRtRgkxqAz3J CLIhByRoa4sEW9rpUGH9EVfALfDUcqHa/uFQVBjr2NEF6YaY+/IuQ4gzxAdONg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none 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 4cRVYp4XRVz1rM for ; Wed, 17 Sep 2025 07:21:18 +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 58H7LItu041813 for ; Wed, 17 Sep 2025 07:21:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58H7LIHM041812 for net@FreeBSD.org; Wed, 17 Sep 2025 07:21:18 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 289333] [Feature Request] HFSC overhead calculation Date: Wed, 17 Sep 2025 07:21:18 +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: Unspecified X-Bugzilla-Keywords: feature X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: freebsd@danielengel.com 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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=3D289333 --- Comment #6 from Daniel Engel --- (In reply to Oleksandr Kryvulia from comment #5) I don't see a whole lot ofmuch potential in rate-limiting the number of packets. The mix of packet sizes never skews consistently in one direction= or the other. It varies by time of day and current user pattern(s). I will confess to not knowing much about ng_car and netgraph, but it appears to be mainly an API. It's not clear to me how writing a custom solution in user space is any significant improvement over writing a custom solution directly into the kernel.=20=20 So far, all I see are one-dimensional solutions to what is (at least) a 1.5 dimensional problem. The fact that Linux has a direct analog for the featu= re I am asking for implies to me that it can't be readily synthesized from some = set of lower-level features.=20=20 Based on my reading, it seems that HFSC already has almost all of the infrastructure to support a two-dimensional solution. Namely, the x and y coordinates for the service curve(s). It seems that every time that altq_hfsc.c calls m_pktlen(m) -- and there are only a small handful of such calls -- that it would be relatively easy to add a configurable parameter and/or helper function that simulates downstream overhead.=20=20 A couple of additional parameters could even allow HFSC to simulate the eff= ect of the 48-byte ATM boundaries and encoding, although the conventional 15% derating in line throughput probably remains an adequate approximation. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Sep 17 10:56:26 2025 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 4cRbLC6FmZz68fCD for ; Wed, 17 Sep 2025 10:56:35 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4cRbLB3g2fz3LMt for ; Wed, 17 Sep 2025 10:56:34 +0000 (UTC) (envelope-from karl@denninger.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net Received: from denninger.net (unknown [162.81.137.111]) by colo1.denninger.net (Postfix) with ESMTP id 4A48FB05B1 for ; Wed, 17 Sep 2025 06:55:21 -0400 (EDT) Received: by denninger.net (Postfix, from userid 58) id E0C4CDA9C8; Wed, 17 Sep 2025 06:56:27 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on NewFS.denninger.net X-Spam-Level: X-Spam-Status: No, score=-4.9 required=3.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=no autolearn_force=no version=4.0.1 X-Spam-Report: * -3.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 HTML_MESSAGE BODY: HTML included in message Received: from [192.168.10.15] (D5.Denninger.Net [192.168.10.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 84183DA945 for ; Wed, 17 Sep 2025 06:56:27 -0400 (EDT) Message-ID: <611820c2-05f8-40bc-9b07-bef012183e30@denninger.net> Date: Wed, 17 Sep 2025 06:56:26 -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: IPv6 networking problems in 14.3 To: freebsd-net@freebsd.org References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com> <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com> <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com> Content-Language: en-US From: Karl Denninger In-Reply-To: <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010306090609010801090206" X-Spamd-Bar: / X-Spamd-Result: default: False [-0.55 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; NEURAL_SPAM_SHORT(0.83)[0.830]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; NEURAL_SPAM_LONG(0.43)[0.426]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; MIME_BASE64_TEXT(0.10)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_ATTACHMENT(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_DN_NONE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEFALL_USER(0.00)[karl]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4cRbLB3g2fz3LMt This is a cryptographically signed message in MIME format. --------------ms010306090609010801090206 Content-Type: multipart/alternative; boundary="------------0W1I64LaGA7nv7m00h0IBYKB" --------------0W1I64LaGA7nv7m00h0IBYKB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gOS8xNy8yMDI1IDAwOjA3LCBDaHJpcyBSb3NzIHdyb3RlOg0KPj4gT24gU2VwIDE2LCAy MDI1LCBhdCAyMzoyNCwgQ2hyaXMgUm9zczxjcm9zcytmcmVlYnNkQGRpc3RhbC5jb20+IHdy b3RlOg0KPj4+PiBPbiBTZXAgMTUsIDIwMjUsIGF0IDE1OjA1LCBUb20gUHVzYXRlcmk8cHVz YXRlcmlAa2VlaG9sZS5vcmc+IHdyb3RlOg0KPj4+Pg0KPj4+PiBJIHdvdWxkIHRyeSBydW5u aW5nIHRoZSAxNC4zcDIgc3lzdGVtIHdpdGhvdXQgdGhlIFZMQU4gY29uZmlndXJhdGlvbiBh bmQgYSBkaXJlY3QgY29ubmVjdGlvbiB0byB0aGUgdXBzdHJlYW0gcHJvdmlkZXIgaGFyZHdh cmUgKG5vIHN3aXRjaCkgYW5kIHNlZSBpZiB0aGUgcHJvYmxlbSBwZXJzaXN0cy4gVGhhdCB3 aWxsIGRldGVybWluZSBpZiBpdOKAmXMgYSBWTEFOIGlzc3VlLg0KPj4+IFRoYXQgd291bGQg YmUgYSBiaXQgb2Ygd29yay4gIEkgaGF2ZSBhbiBhdmFpbGFibGUgaXggcG9ydCwgc28gSSBj YW4gcnVuIGEgbGluZSB0byB0aGUgbWFjaGluZQ0KPj4+IHdpdGhvdXQgdmxhbi4gSXQgd291 bGQgc3RpbGwgYmUgYSBWTEFOIGluIHRoZSBzd2l0Y2gsIGJlY2F1c2UgcnVubmluZyBhIGRp cmVjdCBsaW5lIGlzIG5vdA0KPj4+IHBvc3NpYmxlIHdpdGhvdXQgbXVjaCByZXdpcmluZyBh bmQgdmVyeSBsb25nIGNhYmxlcy4NCj4+IFNvIHRoaXMgaXMgbXkgbmV4dCBhdHRlbXB0Lg0K PiBTbywgcmVjb25maWd1cmluZyB0aGlzIHdhc27igJl0IGFzIGhhcmQgYXMgSSBmZWFyZWQu ICBCdXQsIGl04oCZcyBub3Qgd29ya2luZy4gIEnigJltIGdldHRpbmcNCj4gYW4gSVB2NCBh ZGRyZXNzIGFzIGJlZm9yZSwgc3VycHJpc2luZ2x5IGV2ZW4gdGhlIHNhbWUgb25lLCBvbiBt eSBpeDEgaW50ZXJmYWNlLiAgSeKAmXZlDQo+IGNoYW5nZWQgaW50ZXJmYWNlIG5hbWVzIGlu IHJjLmNvbmYsIHBmLmNvbmYsIGFuZCBkaGNwY2QuY29uZi4gIEhvd2V2ZXIsIGRoY3BjZCBp cyBub3cNCj4gZG9pbmcgc29tZXRoaW5nIGRpZmZlcmVudC4gIE9ubHkgY2hhbmdpbmcgdGhl IGludGVyZmFjZSBuYW1lIGluIHRoZSBjb25maWcsIEnigJltIG5vdCBzdXJlDQo+IHdoeS4N Cj4NCj4gU2VwIDE2IDIzOjQ3OjM0IFs5ODc4N106IGl4MTogc29saWNpdGluZyBhbiBJUHY2 IHJvdXRlcg0KPiBTZXAgMTYgMjM6NDc6MzQgWzk4Nzg3XTogaXgxOiBzZW5kaW5nIFJvdXRl ciBTb2xpY2l0YXRpb24NCj4gU2VwIDE2IDIzOjQ3OjM0IFs5ODc4N106IGl4MTogUm91dGVy IEFkdmVydGlzZW1lbnQgZnJvbSBmZTgwOjozZThhOmIwZmY6ZmUzZTo0ZGNlDQo+IFNlcCAx NiAyMzo0NzozNCBbOTg3ODddOiBpeDE6IG5vIGdsb2JhbCBhZGRyZXNzZXMgZm9yIGRlZmF1 bHQgcm91dGUNCj4gU2VwIDE2IDIzOjQ3OjM0IFs5ODc4N106IGl4MTogZXhlY3V0aW5nOiAv dXNyL2xvY2FsL2xpYmV4ZWMvZGhjcGNkLXJ1bi1ob29rcyBST1VURVJBRFZFUlQNCj4gU2Vw IDE2IDIzOjQ3OjM0IFs5ODc4N106IGl4MTogbXVsdGljYXN0aW5nIFNPTElDSVQ2ICh4aWQg MHgxZTk3MzcpLCBuZXh0IGluIDEuMSBzZWNvbmRzDQo+IFNlcCAxNiAyMzo0NzozNiBbOTg3 ODddOiBpeDE6IG11bHRpY2FzdGluZyBTT0xJQ0lUNiAoeGlkIDB4MWU5NzM3KSwgbmV4dCBp biAyLjAgc2Vjb25kcw0KPiBTZXAgMTYgMjM6NDc6MzggWzk4Nzg3XTogaXgxOiBtdWx0aWNh c3RpbmcgU09MSUNJVDYgKHhpZCAweDFlOTczNyksIG5leHQgaW4gNC4yIHNlY29uZHMNCj4g U2VwIDE2IDIzOjQ3OjQyIFs5ODc4N106IGl4MTogbXVsdGljYXN0aW5nIFNPTElDSVQ2ICh4 aWQgMHgxZTk3MzcpLCBuZXh0IGluIDguOSBzZWNvbmRzDQo+IFNlcCAxNiAyMzo0Nzo1MSBb OTg3ODddOiBpeDE6IG11bHRpY2FzdGluZyBTT0xJQ0lUNiAoeGlkIDB4MWU5NzM3KSwgbmV4 dCBpbiAxNy44IHNlY29uZHMNCj4gU2VwIDE2IDIzOjQ4OjAzIFs5ODc4N106IHRpbWVkIG91 dA0KPiBTZXAgMTYgMjM6NDg6MDMgWzk4NDkyXTogZm9ya2VkIHRvIGJhY2tncm91bmQNCj4g U2VwIDE2IDIzOjQ4OjA5IFs5ODc4N106IGl4MTogbXVsdGljYXN0aW5nIFNPTElDSVQ2ICh4 aWQgMHgxZTk3MzcpLCBuZXh0IGluIDM3Ljkgc2Vjb25kcw0KPiBTZXAgMTYgMjM6NDg6NDcg Wzk4Nzg3XTogaXgxOiBtdWx0aWNhc3RpbmcgU09MSUNJVDYgKHhpZCAweDFlOTczNyksIG5l eHQgaW4gNzEuMiBzZWNvbmRzDQo+IFNlcCAxNiAyMzo0OTo1OCBbOTg3ODddOiBpeDE6IG11 bHRpY2FzdGluZyBTT0xJQ0lUNiAoeGlkIDB4MWU5NzM3KSwgbmV4dCBpbiAxNDIuMCBzZWNv bmRzDQo+IFNlcCAxNiAyMzo1MjoyMCBbOTg3ODddOiBpeDE6IG11bHRpY2FzdGluZyBTT0xJ Q0lUNiAoeGlkIDB4MWU5NzM3KSwgbmV4dCBpbiAyNzQuNCBzZWNvbmRzDQo+DQo+IFdoZXJl IGFzIGJlZm9yZSwgd2hlbiBpdCB3YXMgbm90IGdldHRpbmcgdGhlIGFuc3dlciB0byBOUywg aXQgd2FzIHNpbXBseSBkb2luZzoNCj4NCj4gU2VwIDE1IDE0OjAwOjU4IFsxMDA0N106IHZs YW4wOiBzb2xpY2l0aW5nIGFuIElQdjYgcm91dGVyDQo+IFNlcCAxNSAxNDowMDo1OCBbMTAw NDddOiB2bGFuMDogc2VuZGluZyBSb3V0ZXIgU29saWNpdGF0aW9uDQo+IFNlcCAxNSAxNDow MDo1OCBbMTAwNDddOiB2bGFuMDogUm91dGVyIEFkdmVydGlzZW1lbnQgZnJvbSBmZTgwOjoz ZThhOmIwZmY6ZmUzZTo0ZGNlDQo+IFNlcCAxNSAxNDowMDo1OCBbMTAwNDddOiB2bGFuMDog bm8gZ2xvYmFsIGFkZHJlc3NlcyBmb3IgZGVmYXVsdCByb3V0ZQ0KPiBTZXAgMTUgMTQ6MDA6 NTggWzEwMDQ3XTogbG8wOiBhZGRpbmcgcmVqZWN0IHJvdXRlIHRvIDI2MDA6NDA0MDoyYzlk OjUyMDA6Oi81NiB2aWEgOjoxDQo+IFNlcCAxNSAxNDowMDo1OCBbMTAwNDddOiB2bGFuMDog ZXhlY3V0aW5nOiAvdXNyL2xvY2FsL2xpYmV4ZWMvZGhjcGNkLXJ1bi1ob29rcyBST1VURVJB RFZFUlQNCj4gU2VwIDE1IDE0OjAwOjU4IFsxMDA0N106IHZsYW4wOiBtdWx0aWNhc3Rpbmcg UkVCSU5ENiAoeGlkIDB4MGE3ZDgzKSwgbmV4dCBpbiAxLjAgc2Vjb25kcw0KPiBTZXAgMTUg MTQ6MDA6NTggWzEwMDQ3XTogdmxhbjA6IFJFUExZNiByZWNlaXZlZCBmcm9tIGZlODA6OjNl OGE6YjBmZjpmZTNlOjRkY2UNCj4gU2VwIDE1IDE0OjAwOjU4IFsxMDA0N106IHZsYW4wOiBy ZW5ldyBpbiAzNjAwLCByZWJpbmQgaW4gNTc2MCwgZXhwaXJlIGluIDcyMDAgc2Vjb25kcw0K PiBTZXAgMTUgMTQ6MDA6NTggWzEwMDQ3XTogdmxhbjA6IHdyaXRpbmcgbGVhc2U6IC92YXIv ZGIvZGhjcGNkL3ZsYW4wLmxlYXNlNg0KPiBTZXAgMTUgMTQ6MDA6NTggWzEwMDQ3XTogdmxh bjA6IGRlbGVnYXRlZCBwcmVmaXggMjYwMDo0MDQwOmFhYWE6YmIwMDo6LzU2DQo+IFNlcCAx NSAxNDowMDo1OCBbMTAwNDddOiBpbnQxOiBhZGRpbmcgYWRkcmVzcyAyNjAwOjQwNDA6YWFh YTpiYjEyOjoxLzY0DQo+IFNlcCAxNSAxNDowMDo1OCBbMTAwNDddOiBpbnQxOiBwbHRpbWUg NzIwMCBzZWNvbmRzLCB2bHRpbWUgNzIwMCBzZWNvbmRzDQo+IFNlcCAxNSAxNDowMDo1OCBb MTAwNDddOiBpbnQxOiB3YWl0aW5nIGZvciBESENQdjYgREFEIHRvIGNvbXBsZXRlDQo+DQo+ IE9oLiAgU28gd2l0aCBhIG5ldyBpbnRlcmZhY2UsIGRoY3BjZCBpc27igJl0IHRyeWluZyB0 byBSRUJJTkQsIHNvIGl04oCZcyBhIGRpZmZlcmVudA0KPiBwcm9jZXNzLiBJ4oCZbSBub3Qg c2VlaW5nIGFueSByZXNwb25zZSB0byB0aGUgU09MSUNJVCBtZXNzYWdlcywgYnV0IEkgYWRt aXQgdGhhdCBJDQo+IHdhc27igJl0IHdhdGNoaW5nIHRoZSBESENQdjYgcG9ydHMgZWFybGll ciwgb25seSB0aGUgSUNNUDYsIHNvIHRoaXMgbWF5IG5vdCBiZQ0KPiBuZXcuDQo+DQo+IFRo aXMgaXMgYWxsIGZvciB0b25pZ2h0LiAgSeKAmWxsIHRyeSBtb3JlIHRvbW9ycm93LiAgVGhh bmtzIGFsbCBmb3IgeW91ciB0aW1lLg0KPg0KPiAtIENocmlzDQoNClRoYXQgaXMgcHJlY2lz ZWx5IHdoYXQgaXQgd2FzIGRvaW5nIGhlcmUgd2hlbiBteSBJU1AgaGFkIGEgaGlzc3ktZml0 IGR1ZSANCnRvIGNhY2hlZCAob24gdGhlaXIgZW5kKSBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRo ZSBPTlQvTUFDL2R1aWQuDQoNClRoZXkgc2FpZCBpdCB3b3VsZCBldmVudHVhbGx5IGNsZWFy IChhZnRlciB0aGVpciBwbHRpbWUgZXhwaXJlZCAtLSBhYm91dCANCjIgd2Vla3MhKSBidXQg b2J2aW91c2x5IHRoYXQncyBub3QgcmVhbGx5IGFuIGFuc3dlcjsgYXMgc29vbiBhcyB0aGV5 IA0KImtpY2tlZCBpdCIgb24gdGhlaXIgZW5kIGl0IGNhbWUgdXAgaW1tZWRpYXRlbHkuDQoN Ci0tIA0KS2FybCBEZW5uaW5nZXINCmthcmxAZGVubmluZ2VyLm5ldA0KL1RoZSBNYXJrZXQg VGlja2VyLw0KL1tTL01JTUUgZW5jcnlwdGVkIGVtYWlsIHByZWZlcnJlZF0vDQo= --------------0W1I64LaGA7nv7m00h0IBYKB Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 9/17/2025 00:07, Chris Ross wrote:<= span style=3D"white-space: pre-wrap"> 
On Sep 16, 2025, at 23:24,=
 Chris Ross <cross+freebsd@distal.com> wrote:


          

            
On Sep 15, 2025, at 15:05, Tom Pusateri <pusateri@keehole.org> w=
rote:

I would try running the 14.3p2 system without the VLAN configuration and =
a direct connection to the upstream provider hardware (no switch) and see=
 if the problem persists. That will determine if it=E2=80=99s a VLAN issu=
e.


          

          
That would be a bit of work.  I have an available ix port, so I can run a=
 line to the machine
without vlan. It would still be a VLAN in the switch, because running a d=
irect line is not
possible without much rewiring and very long cables.


        

        
So this is my next attempt.


      

      
So, reconfiguring this wasn=E2=80=99t as hard as I feared.  But, it=E2=80=
=99s not working.  I=E2=80=99m getting
an IPv4 address as before, surprisingly even the same one, on my ix1 inte=
rface.  I=E2=80=99ve
changed interface names in rc.conf, pf.conf, and dhcpcd.conf.  However, d=
hcpcd is now
doing something different.  Only changing the interface name in the confi=
g, I=E2=80=99m not sure
why.

Sep 16 23:47:34 [98787]: ix1: soliciting an IPv6 router
Sep 16 23:47:34 [98787]: ix1: sending Router Solicitation
Sep 16 23:47:34 [98787]: ix1: Router Advertisement from fe80::3e8a:b0ff:f=
e3e:4dce
Sep 16 23:47:34 [98787]: ix1: no global addresses for default route
Sep 16 23:47:34 [98787]: ix1: executing: /usr/local/libexec/dhcpcd-run-ho=
oks ROUTERADVERT
Sep 16 23:47:34 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next =
in 1.1 seconds
Sep 16 23:47:36 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next =
in 2.0 seconds
Sep 16 23:47:38 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next =
in 4.2 seconds
Sep 16 23:47:42 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next =
in 8.9 seconds
Sep 16 23:47:51 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next =
in 17.8 seconds
Sep 16 23:48:03 [98787]: timed out
Sep 16 23:48:03 [98492]: forked to background
Sep 16 23:48:09 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next =
in 37.9 seconds
Sep 16 23:48:47 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next =
in 71.2 seconds
Sep 16 23:49:58 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next =
in 142.0 seconds
Sep 16 23:52:20 [98787]: ix1: multicasting SOLICIT6 (xid 0x1e9737), next =
in 274.4 seconds

Where as before, when it was not getting the answer to NS, it was simply =
doing:

Sep 15 14:00:58 [10047]: vlan0: soliciting an IPv6 router
Sep 15 14:00:58 [10047]: vlan0: sending Router Solicitation
Sep 15 14:00:58 [10047]: vlan0: Router Advertisement from fe80::3e8a:b0ff=
:fe3e:4dce
Sep 15 14:00:58 [10047]: vlan0: no global addresses for default route
Sep 15 14:00:58 [10047]: lo0: adding reject route to 2600:4040:2c9d:5200:=
:/56 via ::1
Sep 15 14:00:58 [10047]: vlan0: executing: /usr/local/libexec/dhcpcd-run-=
hooks ROUTERADVERT
Sep 15 14:00:58 [10047]: vlan0: multicasting REBIND6 (xid 0x0a7d83), next=
 in 1.0 seconds
Sep 15 14:00:58 [10047]: vlan0: REPLY6 received from fe80::3e8a:b0ff:fe3e=
:4dce
Sep 15 14:00:58 [10047]: vlan0: renew in 3600, rebind in 5760, expire in =
7200 seconds
Sep 15 14:00:58 [10047]: vlan0: writing lease: /var/db/dhcpcd/vlan0.lease=
6
Sep 15 14:00:58 [10047]: vlan0: delegated prefix 2600:4040:aaaa:bb00::/56=

Sep 15 14:00:58 [10047]: int1: adding address 2600:4040:aaaa:bb12::1/64
Sep 15 14:00:58 [10047]: int1: pltime 7200 seconds, vltime 7200 seconds
Sep 15 14:00:58 [10047]: int1: waiting for DHCPv6 DAD to complete

Oh.  So with a new interface, dhcpcd isn=E2=80=99t trying to REBIND, so i=
t=E2=80=99s a different
process. I=E2=80=99m not seeing any response to the SOLICIT messages, but=
 I admit that I
wasn=E2=80=99t watching the DHCPv6 ports earlier, only the ICMP6, so this=
 may not be
new.

This is all for tonight.  I=E2=80=99ll try more tomorrow.  Thanks all for=
 your time.

- Chris

    

    
That is precisely what it was doing here when my ISP had a
      hissy-fit due to cached (on their end) association between the
      ONT/MAC/duid.

    
They said it would eventually clear (after their pltime expired
      -- about 2 weeks!) but obviously that's not really an answer; as
      soon as they "kicked it" on their end it came up immediately.

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]<=
/div>
  


--------------0W1I64LaGA7nv7m00h0IBYKB--

--------------ms010306090609010801090206
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
C4owggWZMIIDgaADAgECAhRZU8dKdMneRI1Vq5kv0k54Q5rQuDANBgkqhkiG9w0BAQsFADB2
MQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRYwFAYDVQQKDA1EZW5uaW5nZXIu
TmV0MRcwFQYDVQQDDA5EZW5uaW5nZXIgUm9vdDEiMCAGCSqGSIb3DQEJARYTYWRtaW5AZGVu
bmluZ2VyLm5ldDAeFw0yNDA1MDkyMTA4MDNaFw00NDA1MDQyMTA4MDNaMF0xCzAJBgNVBAYT
AlVTMRIwEAYDVQQIDAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNV
BAMMGURlbm5pbmdlci5OZXQgU2lnbmluZyBJbnQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDbR0tSiuLG5HPfo+cWtdeYQ8jc8Bjfuo0GTcNRT0glHnH1apUtInIktUknEZDH
ohahInN+mMBdKg54FCHOiYZrJbyxBIo9FwX7hRmOc+spxmSYWnOd2E/YcGInMK4ZpjPzldzB
Yt1n3zygkhx2bssxTJS3x4nv1qAXfLSZd1VwqoQufifEoPyTtymkkvHLv86vLgqAqooM/cXc
4LSIQ5u2uM308n42r8RkKtp7X1v9fJW8oRZN2XnFZtiUPH44YY2rHqyN2Hea9Y3+TXbldXjo
xhPHTA+JYVFq8KTmbQBqU7YcMhlIG0cSxPeFLMxnP6pqPcIVTAlK+a6YGRFppfjZAgMBAAGj
ggE2MIIBMjAdBgNVHQ4EFgQUH+VuxXhBxaJAQrvDekwkH91hBi4wgbMGA1UdIwSBqzCBqIAU
RFYC4p6L6KITnEvrpx2cyt+PcMmheqR4MHYxCzAJBgNVBAYTAlVTMRIwEAYDVQQIDAlUZW5u
ZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5OZXQxFzAVBgNVBAMMDkRlbm5pbmdlciBSb290
MSIwIAYJKoZIhvcNAQkBFhNhZG1pbkBkZW5uaW5nZXIubmV0ghQZE7NBItWtQsCouuwU6jZ+
HPPwnjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+gLaAr
hilodHRwOi8vd3d3LmRlbm5pbmdlci5uZXQvcm9vdC1yZXZva2VkLmNybDANBgkqhkiG9w0B
AQsFAAOCAgEAfFbhPc82AfhyUqONs7IccYD36w+OP4nQgwfC4IWf3y/aQAZ2Zk6IITzYqwf7
PFM0bJRT3zi7xyetolqHDhfMJvnOQWpITZiyM/FSKwIvuBsy/uJUqPuqui4XQMYoSbAA1qmI
MW/z7VZZHwaRFoeWE40UirYcf0fNcooBZ72bmd+iBaVyjtZvky0Vgcz0eC6e6LR5kNb23yC6
TkyQIlGyQkK5/afXUYFzk49rOHVbVyxW3oXRfq8Ow6HCrpDGAS8p84S04MFwBVAUfbe4aXs3
bampaI2LzKgkVywyFP14LSvvdjCfLYfnLy1Z9hm2EHMqNHA2tCGdRhWp2d7aZC1MYFqng0ZS
fjPJjqHrI1qPU0p6k9A1GxAtrQlL2v/IUzUnMZkiawFV3qlxMGZf/kTYTUOcJhx1KU4zSLHu
80qO7ldRpp5gHssCAGFbeTu2gp6LxfmaFhLPDBJ1VGfdPx9lUrU/9OcoHczcl5x2Rb8IUZyX
9elzP5WdAU8p5R/DLlOAq24VcabhFtYBCA2dOESLupSfWKNQuJCN/1gz7ysSc+mjnnPV77IO
mpszJfkFFJEDNJlGIVKX1vwwygtC/9Ulox8frgbZlRAYAgDc/YbOBFxticVVre0Y3Ujx6Kzb
tkgZRlgfdZWbT1W5smncqJxg5qAL8e/yTb3fCe2nJ0jhiP4wggXpMIIE0aADAgECAhMAmNFt
CiCF3j+FwQLYtBTmGjzkMA0GCSqGSIb3DQEBCwUAMF0xCzAJBgNVBAYTAlVTMRIwEAYDVQQI
DAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNVBAMMGURlbm5pbmdl
ci5OZXQgU2lnbmluZyBJbnQwHhcNMjQwNTEwMTkyNjU5WhcNMjkwNTA5MTkyNjU5WjBXMQsw
CQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRcwFQYDVQQKDA5LYXJsIERlbm5pbmdl
cjEbMBkGA1UEAwwSa2FybEBkZW5uaW5nZXIubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8A
MIICCgKCAgEAvh1UssVbSYctzobPjwBkbjv/w4WvQNepeRTwE6+sLnXvc41+X9pa5EclPL4Q
l02Vu1m71mSqXGfK9HbWZoivbhefBHOoYb35MSc24PelhwcORbpneWoWc7giQ7QgFlvEe/yj
fs8M0H9fgdzFS5m2lwBQbis8kioSjHB2yt/8I1GE4Mvt1Cur9kga6ML5FAQvo8TYN1stdhrE
13FEv/BWCF4FVT4H2Wa2ySW+R1jkKb74SC6Twg98bGCRTShD5bVylh0+0LXNhzaopIDcI/KK
jm/j3mRjIlmqbGrSpvJsbjjhjhAYQKE1U8FB5TDU4OkFAibblhQit/KjgspPR2o/vOpVFPER
uhZEV1oDGzUJtZlkREIcN2sYBi0p7Y4585ya+b7L10mEenPlyi3eSkGXEuiy/BR2DY6lShwW
DPoQ5602TKmttCSwBdWGoLrQ4jEVEVNt4lku2wPbTHF3KpHJU0g7RbcWoUYn10SOxKathkir
hF3v9U32+QhPELGwqRrH0sL9rWf0qalRtPDHUYl8TebZmYkFqNeSMlqHijl5f4SsQPSj7gx5
4F19Ntm9ZcvuWTmW8QQGWTKHeMuG+BYkVIUSPe6/ZQsbD/xDx7rkyGfNgWIa4W7Wm/B7kaNq
H53tk3wFmNgZQOxMTPF0oTHfW0T2azU6JD0D1AlgoAnSAE0CAwEAAaOCAaYwggGiMDoGCCsG
AQUFBwEBBC4wLDAqBggrBgEFBQcwAYYeaHR0cDovL29jc3AuZGVubmluZ2VyLm5ldDo3Nzc3
MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDAzBglghkgBhvhCAQ0EJhYkT3BlblNTTCBHZW5lcmF0ZWQgQ2xpZW50IENlcnRp
ZmljYXRlMB0GA1UdDgQWBBSxJZjVnlYLAT3uzvDYgc4742J6UTCBswYDVR0jBIGrMIGogBQf
5W7FeEHFokBCu8N6TCQf3WEGLqF6pHgwdjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5l
c3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLk5ldDEXMBUGA1UEAwwORGVubmluZ2VyIFJvb3Qx
IjAgBgkqhkiG9w0BCQEWE2FkbWluQGRlbm5pbmdlci5uZXSCFFlTx0p0yd5EjVWrmS/STnhD
mtC4MB0GA1UdEQQWMBSBEmthcmxAZGVubmluZ2VyLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEA
TrQ45/tBN3SiuqItFv/V+CF3h7Hxe0YLsL+A/P+q9ZhxIscaNjaclgQhPA+rUr+l8DGoXJ/w
yAl1E0SSBK+9phIc/9xFOBg3rCy4ngubzP+lHS1t03nMCBSUNsu5qPzqLBPiKaPabUu3Gr9o
koRezSszgM3/zNJfr8cMO93csCK/fBccsMx5q+3nxB5XeT7UciicjfEzUA4m2mQxBmGk9SSU
147Gy8UmdSq57Tw82KqUrQ1pJ6IOzVPLREpwlqGbHykSU3MwtPYPtfQeFVjvO/XcWvoFQjbV
UyhzAqMMYFudxoVLlJQiAgU38OScTLDgKxCO41h7VOjb2mss0zHndzGCBZUwggWRAgEBMHQw
XTELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2Vy
Lm5ldDEiMCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC
2LQU5ho85DANBglghkgBZQMEAgMFAKCCAvIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc
BgkqhkiG9w0BCQUxDxcNMjUwOTE3MTA1NjI2WjBPBgkqhkiG9w0BCQQxQgRA6+GeYkFrOr8u
ZzrKZj7ZNEP4CP6qtQSArYi4W4ZlkA0/wvJrgyEHtzkbcfqe+adMgzlYu3OXeAz3NzMzKa5M
/DCBgwYJKwYBBAGCNxAEMXYwdDBdMQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2Vl
MRYwFAYDVQQKDA1EZW5uaW5nZXIubmV0MSIwIAYDVQQDDBlEZW5uaW5nZXIuTmV0IFNpZ25p
bmcgSW50AhMAmNFtCiCF3j+FwQLYtBTmGjzkMIGFBgsqhkiG9w0BCRACCzF2oHQwXTELMAkG
A1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLm5ldDEi
MCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC2LQU5ho8
5DCCAVcGCSqGSIb3DQEJDzGCAUgwggFEMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI
KoZIhvcNAwcwDQYIKoZIhvcNAwICAQUwDQYIKoZIhvcNAwICAQUwBwYFKw4DAgcwDQYIKoZI
hvcNAwICAQUwBwYFKw4DAhowCwYJYIZIAWUDBAIBMAsGCWCGSAFlAwQCAjALBglghkgBZQME
AgMwCwYJYIZIAWUDBAIEMAsGCWCGSAFlAwQCBzALBglghkgBZQMEAggwCwYJYIZIAWUDBAIJ
MAsGCWCGSAFlAwQCCjALBgkqhkiG9w0BAQEwCwYJK4EFEIZIPwACMAgGBiuBBAELADAIBgYr
gQQBCwEwCAYGK4EEAQsCMAgGBiuBBAELAzALBgkrgQUQhkg/AAMwCAYGK4EEAQ4AMAgGBiuB
BAEOATAIBgYrgQQBDgIwCAYGK4EEAQ4DMA0GCSqGSIb3DQEBAQUABIICAJeHXo5zp67wGlHO
UZlIHslC1o2tHexy/Bc/ypqhtjvGSzejUkdOARd290omzSU4xTTL3/LuVUijSdhInAuBhVvv
xyXjHanpILA0VNGc9EuWXbsA0QG4fkSyu/9jcGt3mpoxsWJbu+DMSDSz/PgI+JLdw5HVYq+A
8VhUs2HucRVtlE94qm5BSRm42tvLnQA+IpSJq0+TqQEseoJuvDXzkfmEmJvuBytIewSlKgXs
wmr7oLFQwBXWQ51sPSbPd37yw6Bl2KCk8ffW7cpHwOG4yz8XLDJr/vp5vcO4OSzFoeEgU6Zd
l/P7nDC1LD0CeAFgXjar8LSWFGflcHvOt2sfVY3w509dWsPie3XnpsKCsTbH1H3aQigYsIoF
0zyl8MpnuBXWqAs9NfesNY9U1Dx1j6CHrgseLLSI6loHPiItGcO7TM8T5rEMws4ph5k/cWUx
z4YbtXjwxl40M1l4RHcXTXc1R9TOWb50nSwWmpm78A+V5yrWoJPccftacXWmL41aoa9YZx0W
5KMqIJrKJpvAffOwE+A3yDZuSEeBeRr5BgYvcXPe0wk1/7dzd9Sft2HF8xyH82KxZMLi5iJG
XVM3hhmFOzk3inJ0g4Abto40QS+fKHad6nED0lnh3PQbeBUEAEPnMEZ7S1bs6+2IDJeJZcui
8DwE8f9qP/1SeHdPuaO5AAAAAAAA
--------------ms010306090609010801090206--

From nobody Wed Sep 17 12:48:48 2025
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 4cRdqh5W7tz67KkP
	for ; Wed, 17 Sep 2025 12:48:48 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cRdqh4TB8z3kvr
	for ; Wed, 17 Sep 2025 12:48:48 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758113328;
	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=EmkeL9SZg9dcdMOXd0KAgG2yW3uLRJwNvZMgbEyKUDA=;
	b=wj8nNYmR5DwJcYzPHdFfX/1XUZpovknlUrWDKcL3HLqmf4DlVo5sCLyz2YHOFIzeluTymz
	Z2NdAzosY1BQw6g/y1k03NLbIKulXoxO25nVs4RbPjm48+66o3cdhxwqwYwob+6gm+IJwl
	dGmX3YhfkYiea5TARz2ZH1VWtVBAk/VWIqpGeavknJfKrrArIhAyzBbU+WxTVOuhogotjQ
	y5b4CzGw47VlCBudJ6103UdcTYKWkrVRw5QI8ha+/aBT7ZRWmJCvc0KSzuozJhoXhjyoz5
	U0L/y8NlbWzECdaVyE2BVDz5XNCh82BHcgrusoANYKHowHIJHWPxKFiaLdhPZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758113328;
	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=EmkeL9SZg9dcdMOXd0KAgG2yW3uLRJwNvZMgbEyKUDA=;
	b=vwfgsqqxolFQNVP4G01Wp7huprvLS0K7c1bNEcHwe+ak4f1h+UaZtywnnZAe/4MMLgMdrY
	XKCEfgE7L23n3KXRhsdYO18OKTjxFyRZ0EVzRcPrno5xtomvWh1iWu9qICrYsNOTEFXfG9
	451Kf4E2m7fDuyytdVOPWatGyFnIQnlz9JjZLIvxAYnZEPyCT+9rhnKgcC3tM5+lyrdyez
	eqmBgspKAANO/y4VKNFX1YgVE/hocMxVsrX8LCUOLfRaMvzif2uHpULbYLS5Jcrsm0qr5s
	kh+vT/m0seZUHyVdh8uxTs8d4V+SIUSRte4X/Sg/quRyDTsR8ZyT1T/U/h0Qxw==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758113328; a=rsa-sha256; cv=none;
	b=KxiJ9Fta52mNNtMUFPccGBkbldlTM7bAtL+m0X3el0aRPBkjZb/43JxHLQ+Z04XbKQFGxG
	JIXSnj0w++E8yY7zjaWmDBkHJHvvRoyZwcUZVldfBWXeRDtcO6JhG4W7zCpcJeYulw5qXw
	rt3CQSn89BS39NMpt+WO4u69B7WLYAJiFzPaxbdelQEsMSLbLaImoNpq5O3j/vv550b1n9
	aqX+kVjuh8eW+uImTYlLygV4Meejb/Hx0/yY+SIoizUWqliRYorAMJ4Esg5+yanXKjccgw
	4AuHFRll7Icc8nsv5A+S1ny8zl6ZLSAibURh7Ia0EppSMkvojXC+jbYg5oSXqA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cRdqh3sRdzBSb
	for ; Wed, 17 Sep 2025 12:48:48 +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 58HCmmqK045762
	for ; Wed, 17 Sep 2025 12:48:48 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58HCmm2U045761
	for net@FreeBSD.org; Wed, 17 Sep 2025 12:48:48 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 289661] system gets unresponsive after syn flooding  (libalias)
Date: Wed, 17 Sep 2025 12:48:48 +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: 14.3-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: net@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: short_desc assigned_to
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289661

Mark Linimon  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[patch] system gets         |system gets unresponsive
                   |unresponsive after syn      |after syn flooding
                   |flooding  (libalias)        |(libalias)
           Assignee|bugs@FreeBSD.org            |net@FreeBSD.org

--- Comment #3 from Mark Linimon  ---
^Triage: now that Bugzilla attachments have the Patch flag, the [patch] usa=
ge
is deprecated.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Wed Sep 17 18:20:05 2025
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 4cRnBR6LyLz67q6g
	for ; Wed, 17 Sep 2025 18:20:31 +0000 (UTC)
	(envelope-from cross+freebsd@relay.distal.com)
Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.95.80])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cRnBR36Dtz3tl5
	for ; Wed, 17 Sep 2025 18:20:31 +0000 (UTC)
	(envelope-from cross+freebsd@relay.distal.com)
Authentication-Results: mx1.freebsd.org;
	none
dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail;
	c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References;
	bh=yO8ZP4BY1BJRMHw1OaoXJ7ODlG7jEO5xFmmtDRU3ApU=;
	b=QYyr3tS7kpGflqoxs9rZvaq1q/m7bR0x9pAcNrn1Z0uYXGpQFy+GVKYwL0c9Ye7om0NASHsOTS4QDFYWGBtkqiZJF17XI5Iqm0a9i+c412jqAYlrsoGIyYNLH3Y7dDRWzY3e7X/7gpBGoSYy7EyiyM4OvRkoFQHAA08JaHZiNIW0EpHESoIijekdjyFHV6OgYUx10zwhpeHzsOZPMbr+QL4DW02I9Sfv/xM4ow6p9R7WgzaMpodN7Gh+Jd
	AM2/IgEwi5OltDiWgYSp9O2C7bhpRNMsyI8PNXNdWlIXrY8dYqmdng7qvW3AC7g0Nlmqnro87CmPoy3uoLo3oGzVERXg==
Received: from mail.distal.com (pool-108-51-233-124.washdc.fios.verizon.net [108.51.233.124])
 by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305
 bits=256) ; Wed, 17 Sep 2025 18:20:27 +0000
Received: from smtpclient.apple ( [173.38.117.81]) by tristain.distal.com (OpenSMTPD)
 with ESMTPSA id 6535837a (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Wed,
 17 Sep 2025 14:20:16 -0400 (EDT)
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 \(3826.700.81\))
Subject: Re: IPv6 networking problems in 14.3
From: Chris Ross 
In-Reply-To: <611820c2-05f8-40bc-9b07-bef012183e30@denninger.net>
Date: Wed, 17 Sep 2025 14:20:05 -0400
Cc: freebsd-net@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <408DE851-47FF-476E-B7F6-C7920A93DD43@distal.com>
References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com>
 <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com> <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com>
 <611820c2-05f8-40bc-9b07-bef012183e30@denninger.net>
To: Karl Denninger 
X-Mailer: Apple Mail (2.3826.700.81)
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	TAGGED_FROM(0.00)[freebsd];
	ASN(0.00)[asn:3842, ipnet:168.235.92.0/22, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cRnBR36Dtz3tl5



> On 17 Sep 2025, at 06:56, Karl Denninger  wrote:
>>=20
>>=20
>> Oh. So with a new interface, dhcpcd isn=E2=80=99t trying to REBIND, =
so it=E2=80=99s a different
>> process. I=E2=80=99m not seeing any response to the SOLICIT messages, =
but I admit that I
>> wasn=E2=80=99t watching the DHCPv6 ports earlier, only the ICMP6, so =
this may not be
>> new.
>>=20
>> This is all for tonight. I=E2=80=99ll try more tomorrow. Thanks all =
for your time.
>>=20
>>=20
> That is precisely what it was doing here when my ISP had a hissy-fit =
due to cached (on their end) association between the ONT/MAC/duid.
> They said it would eventually clear (after their pltime expired -- =
about 2 weeks!) but obviously that's not really an answer; as soon as =
they "kicked it" on their end it came up immediately.

Yeah, and I agree that=E2=80=99s possible.  But, this began as soon as I =
upgraded to
14.3 on August 8.  Interestingly, looking at my dhcpcd.log to confirm =
dates
and times, I see something related to pltime.
It looks like when dhcpcd starts up, it sets pltime infinity on the =
local
interface addresses, and then after getting the REPLY6 resets them to
7200 seconds.  Even now, I=E2=80=99m noticing looking more, that while =
I=E2=80=99m seeing the
=E2=80=9CLL of router is unreachable=E2=80=9D from dhcpcd every few =
seconds, every hour
it will multicast a RENEW6, and get back a REPLY6.  At which point it =
will
add addresses to the internal interfaces, but still the same 3 seconds
later will indicate the routers LL address is unreachable.

I see a few days back in March when the router was unreachable=20
intermittently, but back in a minute or so each time.  And a small
flap once in July.  But since Aug 09, always unreachable.  So, it
nearly _has_ to be related to the 14.3 upgrade, although it certainly
may be that 14.3 is different, not wrong, and the ISP is doing
sometime unpleasant.  I=E2=80=99m not sure how to test that.

But, at least I=E2=80=99ve ruled out the vlan interface being the =
problem,
since I=E2=80=99m in exactly the same state with an ix interface to the
ISP now.

So, on the idea of trying to back-date the whole machine, I have ZFS
snapshots of the whole root from just before the first upgrade,
Aug 7/8.  But in googling around, I didn=E2=80=99t see a clear =
indication
that I could keep where I am, try swithching to that to run for=20
a while, then switch back.  If someone has a guide to doing that,
respond off-list (off freebsd-net at least).  I thought I=E2=80=99d =
answered
the kernel question, but last night showed that 14.1 kernel doesn=E2=80=99=
t
always work, to be sure.  If I can run as 14.1 again, for a few days
or weeks, it will confirm at least that it=E2=80=99s my side for sure =
that=E2=80=99s
changed.

- Chris




From nobody Thu Sep 18 07:41:50 2025
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 4cS6z31vhMz67wMV
	for ; Thu, 18 Sep 2025 07:41:51 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cS6z25sX0z3X9N
	for ; Thu, 18 Sep 2025 07:41:50 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758181310;
	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=Zdqv1alJL6tQzDPGpzy9BCA5Qrr59l2bH3dZSOSvtek=;
	b=R9wbmGQCaeTmdu3WIjgRWuZiFCZXeWBW2cg6bX2CvlM28IPN+9o/3sabg5m1H0q93FOqUc
	zxQjUFIAFv2VKFZ2ICDzpGY1y8ogt6oyjt3LtOkw4Mp171Ot1hc1M/Ghob/cZgRflflb4u
	HSswiPDKccU1RE1oVaKZQicmBQwAh48GC1gae7JrbbpelgpjNqBzkfnuKcsbNYNKavv6TS
	ba/8tYI5cuyK5mR943YAcRSzmuAxPFO6xTPk+A+rr5DCp2u1X3vjgp8213Pl8AO+bhk7P4
	AriZp5MUs3z08rmSMRlXrLoTiXqyLnJnz6ZmXhKuGg5YtoOKGbyEe9u+6AIU5w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758181310;
	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=Zdqv1alJL6tQzDPGpzy9BCA5Qrr59l2bH3dZSOSvtek=;
	b=NarQdpn2p4XZkooJy32TDHZJKskNIuacHjH6z+grSYfXBRzimOSkS3IYb5ID1VYT7Nvy+I
	3CBq0b3s55Nh3u6VCvOJy2pjVOClROy59EDAkncd+EMh1Qz0HkFmDpkYEy2i9sq5hTn2X4
	8I+Q++kNA2SeUy2LaaFgFOxg+eSpOpb5dbe/MMJsYI3TMoFiMbpwfvUeM1pxq+TQlvp1Hz
	PhwJHL3Ega51e+XmxLMzZ6bEy7E3j9Rficw9h/kRRkCMOkDZ6/bgYc5HyX3zXAUcoyEAvK
	8rrRv/FK2SXooLQjiWrbpUtX3ZHDA690b60x9Y4p2IRRJK+kpJamI7pxEZCV3g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758181310; a=rsa-sha256; cv=none;
	b=kU12klm9rSGNd92PjGuD4RG6mA7XNCs6tWJN03DpNDqxHOir7e8kSrc/dUBiaLFQPTYLIS
	7JF53FjP9Kw1XnHAQ98AthbhA1t8L5MDUZRBfrLUmgUzau5UTkxSzmcwzwMQI2gfzxs1i7
	p1vnnqE1ohNLPUjp91rqYB8+7gxAnBg4+nxiCFsRTqc3lCq3NQ+Iqd0cbw7AUbNOKH2WsY
	h0rg4FRd8bhVS38J7QyZNJYBczNvbC3m5rOnhHGkbw3mfmZtOqZ1Qz7FUecaEl2ntWlp6c
	YDt37VwpTdX3nNdKAdnxI2PJX+ZsUBTS02QXv4t9OhjRfp3KG7d5Pf/9cPCCxg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cS6z25B1Rz12s2
	for ; Thu, 18 Sep 2025 07:41:50 +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 58I7foF1085271
	for ; Thu, 18 Sep 2025 07:41:50 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58I7fo8u085269
	for net@FreeBSD.org; Thu, 18 Sep 2025 07:41:50 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 289666] Fatal trap 12: page fault while in kernel mode //
 supervisor read data, page not present // tcp_default_output
Date: Thu, 18 Sep 2025 07:41:50 +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: 14.3-RELEASE
X-Bugzilla-Keywords: crash
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: net@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: assigned_to keywords
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289666

Mark Linimon  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|bugs@FreeBSD.org            |net@FreeBSD.org
           Keywords|                            |crash

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Sep 18 08:24:55 2025
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 4cS7wm03cSz67ytg
	for ; Thu, 18 Sep 2025 08:24:56 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cS7wl5wfmz3fBR
	for ; Thu, 18 Sep 2025 08:24:55 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758183895;
	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=lkZ+ms8SnGqu4o3KkdYNTO6mFcjCicy9UusXqFQqdko=;
	b=YPhdscQRbXKLvr79l0EujlPeR+ebr9YlzA+IqmPeZrSQDuJqmShaBc1x4AaIVD3TdxseAQ
	zgbXMVs60M3g+qWrc3JQr+MqWzbFbpNoHpT9ofRRO2rpvWgkXyn0NXWvvwxRFr3ueZiSFR
	rlinfl4IS11II/ysRCRO7YY4LwYXwZgQYtAX9jJXDI58qssyePssLWCfgWOyhtWnefPuHF
	tOQCHm8/4ztQrl4ae91JSUCqSCFeUQcliWcznOI7s7MakOssmonooeSkmOF0wI+t9ceQkl
	yaoicustOaMjB8aRXzKr4jFkT/PM+vj6uf1cl9oLVjCmd8tIyUdCjD4Bg9iZWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758183895;
	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=lkZ+ms8SnGqu4o3KkdYNTO6mFcjCicy9UusXqFQqdko=;
	b=QktkylP06yhNDtgdRUMOEcCFf13gC/QwYegB082UduuKmuUA1yRs/HZFQlVvo7Xdj8bv3T
	bGns4E5HfNH8+waaR0aHwk2sm0Bq2EWhRVk+mPuYLIeu/kCa1uM5nUcvYo6VCJaafsCJ7V
	aLGJk4F/BzTuZFaoC/d0p22Ei0l5zSUiVL6dpHy5Qren6c2FyMuagIgRgbRzgmIw4GOUjN
	S1kNDUlIlPl5HD15tPJ/ZlFPt2uamLq3bFvcBu2232A0HEO2ekKodWDpXmCiRsRy/ZKxA6
	447Ppu3Ihe/0tFHie3tjil/Q8gh7RfknM1yQyjNI7FEpS96wXkGAv3mBvUrfrQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758183895; a=rsa-sha256; cv=none;
	b=nLdsHtxPHo6v6/shMjFtuAmunBF43tihReJgjw7Tqf1xhTP97vUX78qzqzW+I6Llj0ANyP
	VzLVwbwxTVGN8BVJfKpC8QqmiVbyXTIUOoDhZQJCFbQVPk5oK7l/+83C1PN9yJSSoW3rOn
	EWvrKuFdz11D3zaaU7yMKdT0CMc5yri6g3DadYBByYAqtCIaaw2oAIm0CAZCnOSd9WTiR5
	gCUpQWxkI642+BpI2st3mc4R5YavuVeN8lRSc//gGamWwr5Rm2iU2yMpqNsAOy4MQdfj2q
	hq/ZDyYBj5wz6Kvu7Ry9qm8It2OZ+zuejy2p5xL/ZV/VVAb7TRuyb2mU3xGM0g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cS7wl4qk6z13qY
	for ; Thu, 18 Sep 2025 08:24:55 +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 58I8Otpq057378
	for ; Thu, 18 Sep 2025 08:24:55 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58I8Ot3e057377
	for net@FreeBSD.org; Thu, 18 Sep 2025 08:24:55 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 289215] WOL not working after upgrading to 14.3
Date: Thu, 18 Sep 2025 08:24:55 +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: 14.3-RELEASE
X-Bugzilla-Keywords: regression
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: jhb@FreeBSD.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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289215

John Baldwin  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jhb@FreeBSD.org

--- Comment #9 from John Baldwin  ---
(In reply to Cy Schubert from comment #8)
BTW, I left some feedback in the abandoned review with the changes you would
need to use the new APIs.  Note that the PCI changes might also fix your bug
since I believe the patch in the review was not clearing the pending PME# s=
tate
on bootup (which other drivers used to do in the driver, but now is done by=
 the
PCI bus layer directly).  It is probably worth re-testing on main or stable
after the commits I listed below to see if the issue you describe is now
resolved.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Sep 18 08:50:46 2025
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 4cS8Vw6CyCz681lJ
	for ; Thu, 18 Sep 2025 08:51:04 +0000 (UTC)
	(envelope-from deng1991816@gmail.com)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d])
	(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 "WR4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cS8Vw1lc2z3h2c
	for ; Thu, 18 Sep 2025 08:51:04 +0000 (UTC)
	(envelope-from deng1991816@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20230601 header.b=R8L48njx;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of deng1991816@gmail.com designates 2a00:1450:4864:20::42d as permitted sender) smtp.mailfrom=deng1991816@gmail.com
Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3ee12807d97so317810f8f.0
        for ; Thu, 18 Sep 2025 01:51:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758185461; x=1758790261; darn=freebsd.org;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=Yh7pq7nTH6OgOW/8MVrldM8jqDK8TU/klqBJ0JaP21I=;
        b=R8L48njxN4cWmAWowDT+fwC/4hzf9m2QwZcc+rSYVRYCVyctWPJ0X+d+sma2SPsBCf
         ilaFSdWYv0ktReIdeuhmNh0I844dLsrmmqSQlztKtXsjq8V3SCsYzYhA9uzmrNx/LbqP
         AelkXaghh3rLtuE9BpVFu0bMU35KmUb4pSli79uG28h6AkdzYJH9BgGZpZsYXUpDqHv/
         JdWdTgFpmmRVQcsEx4XJ5h/YUGw2SDr5qlzcJmrOw5DaRC5Mk73eP37ZzEpWMQflfFfp
         DlAQr+CZPPTq2wWdlplHNzJJFX93wn6cjDWpJrYd19JVh1qDxmdNipc2bt6RTOouNzWY
         Jkug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758185461; x=1758790261;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Yh7pq7nTH6OgOW/8MVrldM8jqDK8TU/klqBJ0JaP21I=;
        b=kI3LgGZdpJt1vBRgqZZWuwrx3UXUm2vdqQ1avHPDTfHRAdQECyMDosBirkVtDr0cMq
         5r62L6ujQPClftfEr87WNbUnOgOWX+ykoGzoAF5Tn4OjCtsfYMjVzaB2VdYucXs+R8U6
         8ntgYznBbnYqi+QALOsr5u8+1awBzcwYv3/8280TfbMMEIFVw68+pN32jXHV0XMiANIi
         Rteu9WzR1dWOqE14zlr1N13RUCawyEFDMTzaWzFPKDrBUkNr+pLUiNPE8gHuqDy9pd9v
         Iysu6OGF44JDU18+xQB3UBK38kXdH0ic+JQfKpqmhkFLg8Sep3WTwFLMOKYhf/5UpR7F
         MdrA==
X-Gm-Message-State: AOJu0YxNqWeqKeVHzrPwOfZHbfWrv2aTdHRO2bxmTxfY4LZHsCTHRquF
	QA1vbIpybMg1fpWeRsmaC3hnbfdVmQ+u2yQ14vNScEooRq7VVLBmkQu8IxgcMRnDUrKdvXYgaee
	TrdpNSNZ3VLSeBlAkyonQ9/2eep7nF0iXspTobMYM0w==
X-Gm-Gg: ASbGnctLXGfgIxO+F1Vf9JvI0sNBzfR4wDIiuhwKMTZA0E2eIU6AzVJsb+SYBwDSi5Q
	oJoeDMgb9mbYI7kxEuhIizja73/CYJEgadrjZO7TmqmuUXGUrBgQJ/qevNxbSvn0TBSORMFEdXK
	hMzTP2LtWIsj9aoqaJrNUpgP4+6Y0z5pLZDV5cAA1LTLxmf/PdsB4ThDaNXG0884oUOU6MSb/Zl
	iN56ksUxukK6fhne0UPYucnwQ==
X-Google-Smtp-Source: AGHT+IFwU1XiJoR2OWRbLkG28EWAEmdCzynRMpt5JQ+wWlgwEksCPAZjrqgzXzNBQN6662he0B1YxZKh6gRqcT105JA=
X-Received: by 2002:a05:6000:22c5:b0:3ec:4e41:fd86 with SMTP id
 ffacd0b85a97d-3ecdfa2ae0emr3700096f8f.50.1758185461247; Thu, 18 Sep 2025
 01:51:01 -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: Tilnel 
Date: Thu, 18 Sep 2025 16:50:46 +0800
X-Gm-Features: AS18NWA5Lde509Ti2CqcykwX1VKJNV-RTwGAyMqenftgEFUNaumHiJdzWoy-SCY
Message-ID: 
Subject: Two different places between TCP socket behavior and RFC documents
To: freebsd-net@freebsd.org
Content-Type: text/plain; charset="UTF-8"
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.96 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.96)[-0.960];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601];
	R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_ONE(0.00)[1];
	MISSING_XM_UA(0.00)[];
	RCVD_COUNT_ONE(0.00)[1];
	FREEMAIL_FROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+];
	RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d:from];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	ARC_NA(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-net@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	DKIM_TRACE(0.00)[gmail.com:+]
X-Rspamd-Queue-Id: 4cS8Vw1lc2z3h2c

Hi,

I found two behaviors different with RFC recommendations in FreeBSD 14.3 TCP
socket.

1. Failure to RST on close with data pending
According to RFC2525 section 2.17, RST should be sent when close() on socket
with pending data to read in receive buffer.
According to RFC1122: A host MAY implement a "half-duplex" TCP close sequence,
          ... cannot continue to read data ... If such a host issues a CLOSE
          call while received data is still pending in TCP, or if new data is
          received after CLOSE is called, its TCP SHOULD send a RST to show that
          data was lost.
It's not the case with FreeBSD TCP socket. Here is TCPDUMP output,
showing close()
on socket with pending data emit FIN instead of RST.
  A > B: Flags [S], seq 2636678338, win 65535, length 0
  B > A: Flags [S.], seq 1969223298, ack 2636678339, win 65535, length 0
  A > B: Flags [.], ack 1, win 1277, length 0
  A > B: Flags [P.], seq 1:6, ack 1, win 1277, length 5
  B > A: Flags [.], ack 6, win 1277, length 0
  B > A: Flags [F.], seq 1, ack 6, win 1277, length 0
  A > B: Flags [.], ack 2, win 1277, length 0
All close()/shutdown(SHUT_RDWR)/shutdown(SHUT_RD) and both SO_LINGER on or off
give the same trace. While on Linux the same execution gives this:
  A > B: Flags [S], seq 2879877684, win 65495, length 0
  B > A: Flags [S.], seq 1538598692, ack 2879877685, win 65483, length 0
  A > B: Flags [.], ack 1, win 512, length 0
  A > B: Flags [P.], seq 1:6, ack 1, win 512, length 5
  B > A: Flags [.], ack 6, win 512, length 0
  B > A: Flags [R.], seq 1, ack 6, win 512, length 0

2. Sending RST to segment with old sequence SYN-RECEIVED instead of
acknowledgement
According to RFC793 page 69: If an incoming segment is not acceptable, an
acknowledgement should be sent in reply. (here `should` is not capitalized).
This should be applied to all states including and after SYN-RECEIVED. But it's
not the case with FreeBSD TCP socket. I found this with manually constructed TCP
segment:
  A > B: Flags [S], seq 1, win 8192, length 0
  B > A: Flags [S.], seq 4054810353, ack 2, win 65535, length 0
  A > B: Flags [.], ack 1, win 8192, length 0
  B > A: Flags [R], seq 4054810354, win 0, length 0
Expected behavior is to send an empty ack:
  A > B: Flags [S], seq 1, win 8192, length 0
  B > A: Flags [S.], seq 3620804602, ack 2, win 65495, length 0
  A > B: Flags [.], ack 1, win 8192, length 0
  B > A: Flags [.], ack 1, win 65495, length 0
Which is the case with Linux.

Does anyone know why these two violations exist? Did FreeBSD choose not to
comply with the RFC for a specific reason, or is it simply an implementation
error?

Thanks.

From nobody Thu Sep 18 10:10:40 2025
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 4cSBGm6mqMz687F2
	for ; Thu, 18 Sep 2025 10:10:40 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSBGm4XLBz436K
	for ; Thu, 18 Sep 2025 10:10:40 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758190240;
	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=YfpltLbaN/AK3al1EF4lVdLClmxH82wlBpvb5Slj9Z0=;
	b=LFidi5ltgCF9HZlQMj76pml/oydiVGwqHbwMS9UaNXbkuIl3IptjXi/qndEbK3cePgG15R
	UnLyDccAxyIBkWHq0mCCQqvbkIv6ahBqKtSYpmXFYbd7gK8XNIpw30Ihcfn8/zScVXk/Wi
	jYmI57Ijc6tuouAlml+RoHRKRjMYsjKa7yjHfta+wA5uYw+795r1QwXhI6DfyIFuRA5PlU
	q2nhAU3K1hseFRwgAm2oCMrCXMXwtjqK4dqb5rtg11FBUery9MRguXmZgkq3Eit32TeU14
	2nhApmZrCYyN/TyEll7F3kIhFoKQOeptBXMXKm4ehJfE8HKwMb5gKvHPMgYfqg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758190240;
	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=YfpltLbaN/AK3al1EF4lVdLClmxH82wlBpvb5Slj9Z0=;
	b=lQERfDBwNo0YvDit79VXJfYgCcMr1JT7DJ/FH9s0Cy8ztmxAQJFgpceQ8NHB2oGFp7PdK7
	ukRrEBD1X3iOHDpu5VT2NnJs7yZpYRXFM5FE0qIzGP5M6CyTtOjhHOuxKx0DrJv3WhjMsK
	9DV/H/S9OAYXMTgDY+udpn0XWvNJFLNOH4cOhhUQ6AtWYAIEbHLyDpE5weDBBDZ+fw0NWA
	7iN2EnEUXUZQk2dsS2YXl1UaZr7M19tTsC2YAu3YAT9LpebxK9l9XERvZwH+KN3uZjBRSO
	SO0oDL7qutObchvj4U3DtD/GHWmuGrR+vsioKnA7jsRm+s70Ab92H8rDCFH6jQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758190240; a=rsa-sha256; cv=none;
	b=vcpDySx8E60L15AN35cahnzqmQQjNGBKjNaL4LntPuxYbPzLNlYWIkKPlruqTCe82xJ4cU
	nkrmNJGYi2CxPrcAO41nnmsQVacdazjudPL6iIzcQ8sL5QkrAwz04yMc8mLGUE2GIYYSHV
	iWV4AKVscZVTWxeeuQTSEZBG/QOCwv2vumhWw7QCKDozBIBUwNArZhqjTcS3QH7+km3PYV
	cZsybo3ALgYh0fE9xC+NPR8g5D9qXABl/n3Pzecz78PpVzDrl/i8MkSXemn9f2/pWO38lb
	wpTe1L3egk2hYo1jY5wjNzHCe8UPt2IjeR5P6J8OByAP5WjLb2qbk9qZXjYjIg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cSBGm408zz16QT
	for ; Thu, 18 Sep 2025 10:10:40 +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 58IAAe7n009776
	for ; Thu, 18 Sep 2025 10:10:40 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58IAAeqg009775
	for net@FreeBSD.org; Thu, 18 Sep 2025 10:10:40 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 289666] Fatal trap 12: page fault while in kernel mode //
 supervisor read data, page not present // tcp_default_output
Date: Thu, 18 Sep 2025 10:10:40 +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: 14.3-RELEASE
X-Bugzilla-Keywords: crash
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: tuexen@freebsd.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: net@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: resolution bug_status cc
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289666

Michael Tuexen  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|New                         |Closed
                 CC|                            |tuexen@freebsd.org

--- Comment #1 from Michael Tuexen  ---


*** This bug has been marked as a duplicate of bug 288904 ***

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Sep 18 10:10:40 2025
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 4cSBGp2zn3z687M5
	for ; Thu, 18 Sep 2025 10:10:42 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSBGn6T5Wz43FB
	for ; Thu, 18 Sep 2025 10:10:41 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758190241;
	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=0WPx/q0GmQU762Fskcbt9vAwVjkS4ewjvlfMXtQulB0=;
	b=b5+fARp2xhsLkY+yOpyyhiX5GbEt3OUBZWZ3/GB7kPinmSpHoMmcT3I+2vqqUrpPE6idkG
	cfaW6FtkNXno5hpOUgzhV5KCFMAe8LBMR3wpBk+cBx2g2yZ7+CmyJgdeYgqu0FHc65NKg/
	oiu8Bb5vz++LMLlv85VJb/00Ly+9mzjnaGB/FCFVMsKL/HuEZ8CPPQOniG08VvBsiCLK0l
	pVq/rkg+fnvF4tjVRNmhSvhXjcZ+8jzrp7l5j999/VyMSQgN8ePp6GFx94lHCwtPhXODKO
	puZ/yhVX1mSuW7ueinPLoKZA/HN8lELOhZxSEFWVAoGFjLtvfUIZXekis84V6g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758190241;
	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=0WPx/q0GmQU762Fskcbt9vAwVjkS4ewjvlfMXtQulB0=;
	b=TmsuWIFHtsQqmRpkKFpu6TzGk+YlGW/yxeH2Ww2GtsQrny3N83hWJUCCGwe0UuVSV5SEnj
	sLPFDh7FKe0jEIFeYEZZm12ZW6q3BpScbrcttUsLuHiMsmFndqUlKuGeR1oSpYQ4xDgpKp
	Zo868Lvn5xYn36bUncXJfZA9Kq7TBDIFly6xCdhfYCPlwS3dWNdv3RZs0qjSgYBiPOSf16
	HQ/w0t3OlKpyFdVesfSZ4seyQ3eOde0bW1KkT0WrlHPA4NwAJXusZl8mo8ik31zUKlIip1
	TeJywzP+kBhQ+LOBmTOBatmc1PqlUMroEJG5Wxn4j/oBzFuNL3zLrDx0cG5cQg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758190241; a=rsa-sha256; cv=none;
	b=g/gf+0XT7ie3AQp6gRQdGIV0OXzhAAV23O//IufXOfndzC4vivIXEuWNH0Q1uZhW+YbeSq
	PLqvcK6MIy1bEvGNopQ7pgyz0Xg4KNRBnDtEYLp/m76NuF/zqkyaP+KjI+uOXOhVu+hpov
	S9QtERHX5q+Xlz5910JSopaBR5ZOMJz/xjYgt3lQk5JgzeR6gyM4Wy7quxx41d2iyU6NR9
	3iEAWoFYHqsLcMatXjSNCTuNTqR4t959twgHh+QQwqe3sA/vIWXO5drPw5QYTYbzGn7HTb
	fWGL2WUKoKExvlyEoMOYhbrlaqMN/zVUyQBEIQMbMFbolsnX5G+Vq6YW6xlbMA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cSBGn5V1lz15y0
	for ; Thu, 18 Sep 2025 10:10:41 +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 58IAAfih009809
	for ; Thu, 18 Sep 2025 10:10:41 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58IAAfmg009808
	for net@FreeBSD.org; Thu, 18 Sep 2025 10:10:41 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 288904] [tcp] page fault in tcp_default_output
Date: Thu, 18 Sep 2025 10:10:40 +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: 14.3-RELEASE
X-Bugzilla-Keywords: crash, regression
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: tuexen@freebsd.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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D288904

Michael Tuexen  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |viaprog@gmail.com

--- Comment #8 from Michael Tuexen  ---
*** Bug 289666 has been marked as a duplicate of this bug. ***

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Sep 18 10:11:21 2025
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 4cSBHY3H2vz687Gn
	for ; Thu, 18 Sep 2025 10:11:21 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSBHY0fxKz44St
	for ; Thu, 18 Sep 2025 10:11:21 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758190281;
	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=yMhVKCGvBmRZsDELNld19yeL/hxwBSz3cvU9El0Hxrg=;
	b=tBMkbuUGw5dLKHIET6QMzNcnzG2MkMoqErLh2u+LQqNHxFmJCExnIAcS7+X7+uia93MwED
	q23YxDaRF6x16f/k42ugAzlBR4n4ORJSCQGlSFaLzwWpwfTPENhhoaIijggJj6lwJShXXe
	m9GvtDChGtO4+Wnh95bT7YzrSlhEc7AXH9nwphGfYND1Uwds0spPgZnQ91Pq1X5xI7KTHM
	VfIr9CBAo6FA7uBKYDKoOQN5NDPteTSA9a4vD05w98wg/ONk+a+vNZk9/sNtfubnbBqX+n
	yaC7oc9cLXce8QN+L6EFOPh06leutwjmId2HsLAOojZPUPFLMHVzRx/Jg8ywDg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758190281;
	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=yMhVKCGvBmRZsDELNld19yeL/hxwBSz3cvU9El0Hxrg=;
	b=TcEtJEv4VmcHUXEZUMsaZz7R46oxT+uxmhBtOESmCcfpuylKB9jIDDFl+gs/KKOFA6sfZv
	zq5LIYf6jU9bQ9cXI0Jate+9dcBw9YEr1n9zB3F75ZYc/vTsmWULenGe6X69pNfquPtBOI
	bQG3gMKR9jcOfJoylwB47B6etBemtxPTTvVur6G+gjiPT4dTm2HycVz7tuhQgbV3UBUcYw
	ilt38Q5IcZbTRg1z3GPAazRG/D37R78JlPbrfm8hrt3g7pflDVj2T4dV6QGO0LD2MqnqZ8
	NBbw4z3ycV76wZ0dNPQiOW4gpXJgi8hY7qbhdmLmwon/RCQKlvTORV9uFuWRWQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758190281; a=rsa-sha256; cv=none;
	b=tZSWe8lWthjvptYTVY3Y+5aiybtlLgPG3y4fvkzvzQn2oXdk0kcVXXKTUHz3bZLwn87V/3
	RVh0K8hd9PH30bpJDNMZQKzcUrfo1fDk59ep10G7GtJgLF/iLeMxpwN51PZzgxqBbylV5Q
	8pgyKl6302rEGy58JLx3QlqxRiOJpA4AUFvHo2lv7bTCV9xCvTSdGHh3WjuBxVi0oOK7PH
	wiTS/DCPr8bcjod9yCrLH8C/zSpL7BLBKQ9vBK6PO0ilNYpE3rLrfy0m52PBBsCRT0I+/n
	be6u5ch+WUd3L3Py/a6rs3nyJUdozy3wnl7Ca4gDpr5wBJijXrpqjzGH9JT6Gg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cSBHY04jlz16cs
	for ; Thu, 18 Sep 2025 10:11:21 +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 58IABKaS020273
	for ; Thu, 18 Sep 2025 10:11:20 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58IABKa2020272
	for net@FreeBSD.org; Thu, 18 Sep 2025 10:11:20 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 289666] Fatal trap 12: page fault while in kernel mode //
 supervisor read data, page not present // tcp_default_output
Date: Thu, 18 Sep 2025 10:11:21 +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: 14.3-RELEASE
X-Bugzilla-Keywords: crash
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: tuexen@freebsd.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: net@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289666

--- Comment #2 from Michael Tuexen  ---
Are you able to reproduce this issue?

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Sep 18 10:13:05 2025
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 4cSBKY1LlDz687qg
	for ; Thu, 18 Sep 2025 10:13:05 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSBKY0Rmsz464x
	for ; Thu, 18 Sep 2025 10:13:05 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758190385;
	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=kAfUs+FP/Nas7e6yh4xXU9uI5D7+WBeuimg3g4NAiBg=;
	b=MSXLkYhAKR2Pr1d3Ce0bRCYYKcrXKlh4zBt8/EMbQ4paEwkXCTX3eN/cQ6fVoulXqLOifW
	Oi3dlTMKigT+J9y/Oi+Rvxl4i0//R/h7uKf7HBGylJegbj7NEaDKzuILN7E1bH0cPB1PN/
	0rv5cbdGyKzZpxHvF4CeNsrE5Hdl4NtmVZwFDWnIyMZkrYQwb65o9Pkv+p7WC9yOghqFnP
	pO23ZD73X0v+OcLgnfty+gGYp96oYnG/RS0KdjGFCzu+N0xata3aqoSuSTE65286diWJWx
	e4wIzcpzmFRoQyMGG+BQOQgqfxUlGeX0JgkdH7VWbY88DD800pOhWuZxdPWPKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758190385;
	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=kAfUs+FP/Nas7e6yh4xXU9uI5D7+WBeuimg3g4NAiBg=;
	b=PK8sbIRnwPzb6roQDDJmZZ0i6oaQUCrPfB3Dn2H9d1Pp+KdT2qHVAazjOs7mCm4a7QKxAl
	Z8tXrZL1d/ZdsNivzv7SWoFw4yrBGa3RcJwJM/rtoNCelDxebM+RovwwTrn8LYYjN8KtyP
	VMjHgczZB/J9+pDr33ZJXKOg//Fq2mHLGG1cOFERUqJGaMdN/EmbGvME00Qhqw3CvrB5QQ
	3//vZLsxpPNSrsrdhRwM34DiZVE/kgXRJ0POdjAdiaBfPq6QxM/z8rxPqlWd54qPdknA9c
	tvj3znU5DCsVvcK/RNoGUhO+GmVqxdumNy75bOkm9RcQz2nZp09l4s5gs/BX7g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758190385; a=rsa-sha256; cv=none;
	b=wbIKO6CGRRyUIZwZOmQWFMa1ztiq4lUwXc+GM2ulsrlPCtr8tK2AXnhIrCzHndKntMpBL9
	KhbZECkdlOM4CDpsR+UTEHXZrxwYctrcNH1AsOFB160BrOifZflX9YvWC2Up7tnxX4JHlb
	J5KomS+r8Pe+z87dWPZQL6yGGLvhfSkdJmtvA4azcA0TN76dBZnQqFNzVaUR8350xIVIQA
	feYQ1KZRpY4grdNNDvlyJ/w0RP07tMPlwcsxUjGzz1Lwj9F97TLBRoOIjFCDxTFLTC0CiS
	0TDN4GuQCipfdlkc+hjp8YubfNVr8Hkesbh+32/PaqoLJRNI0+pShAmmeHUEkQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cSBKY01bZz16Yt
	for ; Thu, 18 Sep 2025 10:13:05 +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 58IAD4B2025024
	for ; Thu, 18 Sep 2025 10:13:04 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58IAD44D025023
	for net@FreeBSD.org; Thu, 18 Sep 2025 10:13: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 288904] [tcp] page fault in tcp_default_output
Date: Thu, 18 Sep 2025 10:13:05 +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: 14.3-RELEASE
X-Bugzilla-Keywords: crash, regression
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: tuexen@freebsd.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: see_also
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D288904

Michael Tuexen  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.freebsd.org/bu
                   |                            |gzilla/show_bug.cgi?id=3D2=
896
                   |                            |66

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Sep 18 10:13:05 2025
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 4cSBKZ32nzz687Hf
	for ; Thu, 18 Sep 2025 10:13:06 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSBKZ0Snqz4604
	for ; Thu, 18 Sep 2025 10:13:06 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758190386;
	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=8nNLSa4abIszcoT5o4SO+dimdkrJsANPkTohPN1kIT4=;
	b=vIniLTF4nk9zH6QSkkZYrRBe+EHtBXz/9bPmj56vDW+Vtw/DyEESgWnjgemt1jxf5ENJJo
	gGPuoxibTNUcJLJA/jn2m6icHYUOlHIkod28lwQ8f81caQSH/hRE/jyI6520ITW5HOdPcT
	EkeULRmjRCDWtSejqrl/01TYPF0s+9tcmCP7yZus6mzXQQwP2kZ3F13SIrOyOLFJGoig35
	2nNKKzva1RLwaOuxWPSbqUlIbzuZqxI+/T1GknedxrwA9YgEd1VJbXU3CuocuDAkj22ZH9
	rEpUFbUTJn97tse3uzBhxQo7ZyeAD8XYZNb68fBtUfd28Y4RjiV7b8O+mGv/bg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758190386;
	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=8nNLSa4abIszcoT5o4SO+dimdkrJsANPkTohPN1kIT4=;
	b=kB+dGZan5jSLFi/EHOLDy2lnKsWWzDfUEiZgHOOWvo5Udl75lJNXPLylNd2XHZmRTFwGGN
	0WqUN8aW2rf620sw2/pNNpWz7EohIUDAqSMzNJTrXRcNVlpe8ALMGJMExDHfdDNROqIdkc
	Vk71S5AlWsg6SNBnsslXLXdIMi/Wrg0ZZcrhrlwqERnzEXv/mc8EyrNAgtAygEl7x1g/5w
	1Eq3FdGDuSWvy9zZb8GhGmEaIspQEvxp9n3gPi1qSzNbnvIFz4GwSx05dJRjpzKC9kVrRp
	F64jzTRSkrNGvQt9T2UtaVO3X39HGWlQdfC8KglsAoMC2LFoJdUXggBXLkC+Hg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758190386; a=rsa-sha256; cv=none;
	b=bg2MbZqrO9kfm/HsF9n/hd2L/vKo3ST/EyTGWpxkJb6qkwD2oaGIAZCWgw6p2kgIK9EjHr
	Ridhxv7YcCqFxo8lhilMpPNdFdRs502d8RnO5d5anUjORld+3rD8Efw4c/WE6bohZL557j
	CoCG8p1u+vi+VrW+N5NJwU8Pr9vCBJFEc1oaDJvvhigp7BB2puVbsm33ydYlxp21o3BAxl
	QmPd5ztUvyv5ZTcqLxpSSeTGOxNATG/fCUUHslscphWfNNohV/5u2Op+w58Ap/idxOazbW
	PdRULzVxayUr2CPG7BLbS1MDLeZTSubLPexS+ZPGq5dGWhHXOauU4ZWG0ksKTg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cSBKZ03Qzz16lj
	for ; Thu, 18 Sep 2025 10:13:06 +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 58IAD5tC025075
	for ; Thu, 18 Sep 2025 10:13:05 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58IAD5SW025074
	for net@FreeBSD.org; Thu, 18 Sep 2025 10:13:05 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 289666] Fatal trap 12: page fault while in kernel mode //
 supervisor read data, page not present // tcp_default_output
Date: Thu, 18 Sep 2025 10:13:05 +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: 14.3-RELEASE
X-Bugzilla-Keywords: crash
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: tuexen@freebsd.org
X-Bugzilla-Status: Closed
X-Bugzilla-Resolution: DUPLICATE
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: net@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: see_also
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289666

Michael Tuexen  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.freebsd.org/bu
                   |                            |gzilla/show_bug.cgi?id=3D2=
889
                   |                            |04

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Thu Sep 18 10:24:58 2025
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 4cSBbk6T3Qz6886g
	for ; Thu, 18 Sep 2025 10:25:22 +0000 (UTC)
	(envelope-from michael.tuexen@lurchi.franken.de)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.franken.de", Issuer "Certum Domain Validation CA SHA2" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSBbk37bsz4994
	for ; Thu, 18 Sep 2025 10:25:22 +0000 (UTC)
	(envelope-from michael.tuexen@lurchi.franken.de)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:a8f6:6ab6:7196:7223])
	(Authenticated sender: lurchi)
	by drew.franken.de (Postfix) with ESMTPSA id 9785B721E282E;
	Thu, 18 Sep 2025 12:24:58 +0200 (CEST)
Content-Type: text/plain;
	charset=us-ascii
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 \(3864.100.1.1.5\))
Subject: Re: Two different places between TCP socket behavior and RFC
 documents
From: Michael Tuexen 
In-Reply-To: 
Date: Thu, 18 Sep 2025 12:24:58 +0200
Cc: freebsd-net@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de>
References: 
To: Tilnel 
X-Mailer: Apple Mail (2.3864.100.1.1.5)
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=disabled version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cSBbk37bsz4994

> On 18. Sep 2025, at 10:50, Tilnel  wrote:
>=20
> Hi,
>=20
> I found two behaviors different with RFC recommendations in FreeBSD =
14.3 TCP
> socket.
>=20
> 1. Failure to RST on close with data pending
> According to RFC2525 section 2.17, RST should be sent when close() on =
socket
> with pending data to read in receive buffer.
> According to RFC1122: A host MAY implement a "half-duplex" TCP close =
sequence,
>          ... cannot continue to read data ... If such a host issues a =
CLOSE
>          call while received data is still pending in TCP, or if new =
data is
>          received after CLOSE is called, its TCP SHOULD send a RST to =
show that
>          data was lost.
I agree that FreeBSD is inconsistent here. It reacts different if data =
is
received after the reading end is closed or before.
I don't know why it is that way, but it is there for a long time...
I plan to fix this.
> It's not the case with FreeBSD TCP socket. Here is TCPDUMP output,
> showing close()
> on socket with pending data emit FIN instead of RST.
>  A > B: Flags [S], seq 2636678338, win 65535, length 0
>  B > A: Flags [S.], seq 1969223298, ack 2636678339, win 65535, length =
0
>  A > B: Flags [.], ack 1, win 1277, length 0
>  A > B: Flags [P.], seq 1:6, ack 1, win 1277, length 5
>  B > A: Flags [.], ack 6, win 1277, length 0
>  B > A: Flags [F.], seq 1, ack 6, win 1277, length 0
>  A > B: Flags [.], ack 2, win 1277, length 0
> All close()/shutdown(SHUT_RDWR)/shutdown(SHUT_RD) and both SO_LINGER =
on or off
> give the same trace. While on Linux the same execution gives this:
>  A > B: Flags [S], seq 2879877684, win 65495, length 0
>  B > A: Flags [S.], seq 1538598692, ack 2879877685, win 65483, length =
0
>  A > B: Flags [.], ack 1, win 512, length 0
>  A > B: Flags [P.], seq 1:6, ack 1, win 512, length 5
>  B > A: Flags [.], ack 6, win 512, length 0
>  B > A: Flags [R.], seq 1, ack 6, win 512, length 0
>=20
> 2. Sending RST to segment with old sequence SYN-RECEIVED instead of
> acknowledgement
> According to RFC793 page 69: If an incoming segment is not acceptable, =
an
> acknowledgement should be sent in reply. (here `should` is not =
capitalized).
> This should be applied to all states including and after SYN-RECEIVED. =
But it's
> not the case with FreeBSD TCP socket. I found this with manually =
constructed TCP
> segment:
>  A > B: Flags [S], seq 1, win 8192, length 0
>  B > A: Flags [S.], seq 4054810353, ack 2, win 65535, length 0
>  A > B: Flags [.], ack 1, win 8192, length 0
>  B > A: Flags [R], seq 4054810354, win 0, length 0
I am not sure which scenario are you considering. Could you provide =
SEG.SEQ
for the this TCP segment?
> Expected behavior is to send an empty ack:
>  A > B: Flags [S], seq 1, win 8192, length 0
>  B > A: Flags [S.], seq 3620804602, ack 2, win 65495, length 0
>  A > B: Flags [.], ack 1, win 8192, length 0
>  B > A: Flags [.], ack 1, win 65495, length 0
> Which is the case with Linux.
>=20
> Does anyone know why these two violations exist? Did FreeBSD choose =
not to
> comply with the RFC for a specific reason, or is it simply an =
implementation
> error?
I overall intention is to be RFC compliant...

Best regards
Michael
>=20
> Thanks.
>=20


From nobody Thu Sep 18 11:17:41 2025
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 4cSCmM6sjhz68D1r
	for ; Thu, 18 Sep 2025 11:17:55 +0000 (UTC)
	(envelope-from nakayamakenjiro@gmail.com)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b])
	(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 "WR4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSCmL2854z3HPK
	for ; Thu, 18 Sep 2025 11:17:54 +0000 (UTC)
	(envelope-from nakayamakenjiro@gmail.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=gmail.com header.s=20230601 header.b=Zx+RWgcC;
	dmarc=pass (policy=none) header.from=gmail.com;
	spf=pass (mx1.freebsd.org: domain of nakayamakenjiro@gmail.com designates 2607:f8b0:4864:20::102b as permitted sender) smtp.mailfrom=nakayamakenjiro@gmail.com
Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-329b760080fso648191a91.1
        for ; Thu, 18 Sep 2025 04:17:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758194272; x=1758799072; darn=freebsd.org;
        h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=sqKAE3xjF6RoNqJwe7fMDQ2vh9gJk/X4W5yNgauKO1U=;
        b=Zx+RWgcC6FBuJXfTm6ULlIuS9N2JZOaR8cfTzNKqJJ2tCd2OVmMM3hJwMuh7eb+wOr
         9FiCEynSHbrc4aZSCaTfkh1abERqXlODsm4RzUZD/Ay4laZxlv1okZo14sIxc4xlDblv
         2mGhYsqZyVBS9vuVcI0UWDq4jE6lOqZM29dhnovKKtbnaDRgu+yj+N2+l3zoQEuffUiX
         lRXrYVm5o7MPL7aMHHCjYPnLFs30/mpMTNeHyeozZmoFjaBwknubj3qI4djORqo+71yc
         RcnxQpTfIKkRnEKXq+q7KG9zp3jjl6inY1blqyOV9FtIJBzrhY/yfoD64NWLZXDWiQ+y
         1AfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758194272; x=1758799072;
        h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=sqKAE3xjF6RoNqJwe7fMDQ2vh9gJk/X4W5yNgauKO1U=;
        b=vmk9EDxvbI/ECl6ctlqF6wWuxIXWSKuQgsAebL+d2hUMW0gHd+zRmCokmOMiB5Zbl/
         8BgOMTmLs2w9rZIc/I0tzic6WxYL9MC+Kj9TAxAzKVuzzaCFZs5WSDKC2PlEdMS9Y4El
         VmoG3nye2DtQdbRSLUIRlBKbyqFIm3Rw2vVMLgmZwnq2Iu4ldY+4J0ntUSO/Os94VAHK
         Lgu8jJHkVAJ/yuuGquWh5TbC3XJMa91QySllgMN73xbRzf2vNjE+z8zZyqmzq+DjMz7x
         CxzxJc4u7xkVAdxGYu7pWGls2iF46BRcE/9tvnWhmxFtDWO+zvfJG4IHsjioaQ+y2Hvt
         j5ug==
X-Gm-Message-State: AOJu0YxpdyrDzrLqOtejOb2qmR8OnZOfYYc/l6fYd3kTG0I7bUnozZMu
	fmMqX0YFNtwNbHCbZ5qg7PaCqMEOJNsZoMwnfxosmDQVH6oYbikKZ5ATq7WEg7g0EEh8iUcWUgw
	+dCsevwZldx3UAE4PZGnCW6ercK88ROg=
X-Gm-Gg: ASbGncuEerhLnFGrClb1oRJb7K9UwNPL8O64W0V9ceFz+N7IhKeoF5SJZV4jXpnMFLH
	AMkY7yydB92haaiW8dTgAYL40DD00i9gXx2JMuwJDoEbu/mYRtNoq/IrETOdzOn1fznLk9c9X9Q
	JOSwYE+OOl4mxtZxts5RtXv2ABwM67gWUcfHBLvMFhaTy7KY0MvcP1ZLjHUlcjXt6VA5GDuExcU
	2A/f7SfrFnRsb5PxVeAPZiS1L3bHvTG8g==
X-Google-Smtp-Source: AGHT+IEeCQOEonzg0XcvrDHm8NtnWIMi0scpie0vhQ/irWXVEnGNNKHTJtMQ9sHz55fluDTkHPbwayLgEpTNMV0yAwc=
X-Received: by 2002:a17:90b:5788:b0:32d:dffc:7ad6 with SMTP id
 98e67ed59e1d1-32ee3f8c588mr7176681a91.33.1758194271879; Thu, 18 Sep 2025
 04:17:51 -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: Nakayama Kenjiro 
Date: Thu, 18 Sep 2025 20:17:41 +0900
X-Gm-Features: AS18NWDW2stNSDulqvFMuks4bOv0Y9-z1owh4HCBRQBbRX-lys2FHGK456y5Yaw
Message-ID: 
Subject: Build failure with Clang/LLVM 22 due to alloc-size diagnostic
To: freebsd-hackers@freebsd.org
Cc: freebsd-net@freebsd.org
Content-Type: multipart/alternative; boundary="0000000000000587f9063f11812c"
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.98 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-0.98)[-0.984];
	DMARC_POLICY_ALLOW(-0.50)[gmail.com,none];
	R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c];
	R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601];
	MIME_GOOD(-0.10)[multipart/alternative,text/plain];
	RCVD_TLS_LAST(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	ARC_NA(0.00)[];
	FREEMAIL_ENVFROM(0.00)[gmail.com];
	DKIM_TRACE(0.00)[gmail.com:+];
	FREEMAIL_FROM(0.00)[gmail.com];
	MIME_TRACE(0.00)[0:+,1:+,2:~];
	MISSING_XM_UA(0.00)[];
	FROM_HAS_DN(0.00)[];
	DWL_DNSWL_NONE(0.00)[gmail.com:dkim];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	TO_DN_NONE(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	RCVD_COUNT_ONE(0.00)[1];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org];
	MLMMJ_DEST(0.00)[freebsd-net@freebsd.org];
	MID_RHS_MATCH_FROMTLD(0.00)[];
	ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US];
	RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102b:from]
X-Rspamd-Queue-Id: 4cSCmL2854z3HPK

--0000000000000587f9063f11812c
Content-Type: text/plain; charset="UTF-8"

Hi,

There is a new diagnostic, alloc-size, in clang of LLVM22 that warns if the
size given to a malloc is smaller than the size of the struct pointed to by
its destination - https://github.com/llvm/llvm-project/pull/150028
When we enable this option, in_mcast.c triggers this diagnostic, causing
the build to fail.

```
freebsd/sys/netinet/in_mcast.c:749:10: error: allocation of insufficient
size '40' for type 'struct ip_msource' with size '48' [-Werror,-Walloc-size]
  749 |                 nims = malloc(sizeof(struct in_msource),
M_INMFILTER,
      |                        ^
```

https://github.com/freebsd/freebsd-src/blob/stable/15/sys/netinet/in_mcast.c#L749
```
static int
imf_get_source(struct in_mfilter *imf, const struct sockaddr_in *psin,
    struct in_msource **plims)
{
          ...
struct ip_msource *ims, *nims;
  ...
nims = malloc(sizeof(struct in_msource), M_INMFILTER,
   M_NOWAIT | M_ZERO);
```

As the error message explained, the mismatch between struct ip_msource *
and malloc(sizeof(struct in_msource)) triggers the error.

However, when reading the source code carefully, it seems that *nims is
intentionally of type ip_msource instead of in_msource.
I would like to build with LLVM's alloc-size option enabled, but does
anyone have any good ideas on how to address this problem? Or would it be
better to report it as a false positive to LLVM? Though, I am aware that
there is a workaround to partially disable this option...

--0000000000000587f9063f11812c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

There is a new diagnosti=
c, alloc-size, in clang of LLVM22 that warns if the size given to a malloc =
is smaller than the size of the struct pointed to by its destination - https://github.com=
/llvm/llvm-project/pull/150028
When we enable this option, in_mcast.=
c triggers this diagnostic, causing the build to fail.

```
freebs=
d/sys/netinet/in_mcast.c:749:10: error: allocation of insufficient size =
9;40' for type 'struct ip_msource' with size '48' [-Wer=
ror,-Walloc-size]
=C2=A0 749 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 nims =3D malloc(sizeof(struct in_msource), M_INMFILTER,
=
=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 =C2=A0 =C2=A0^
```

https://g=
ithub.com/freebsd/freebsd-src/blob/stable/15/sys/netinet/in_mcast.c#L749
```
static int
imf_get_source(struct in_mfilter *imf, const stru=
ct sockaddr_in *psin,
=C2=A0 =C2=A0 struct in_msource **plims)
{
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
	struct ip_msource	*ims, *nims;	 =C2=A0 ...
		nims =3D malloc(sizeof(struct in_msource), M_INMFILTER,=

		 =C2=A0 =C2=A0M_NOWAIT | M_ZERO);
```

As the error message =
explained, the mismatch between struct ip_msource * and malloc(sizeof(struc=
t in_msource)) triggers the error.

However, when reading the source =
code carefully, it seems that *nims is intentionally of type ip_msource ins=
tead of in_msource.
I would like to build with LLVM's alloc-size opt=
ion enabled, but does anyone have any good ideas on how to address this pro=
blem? Or would it be better to report it as a false positive to LLVM? Thoug=
h, I am aware that there is a workaround to partially disable this option..=
.


--0000000000000587f9063f11812c--

From nobody Thu Sep 18 14:29:36 2025
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 4cSJ1t5ztzz67THB;
	Thu, 18 Sep 2025 14:29:54 +0000 (UTC)
	(envelope-from zlei@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 "R13" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSJ1t5Gzbz3q3L;
	Thu, 18 Sep 2025 14:29:54 +0000 (UTC)
	(envelope-from zlei@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758205794;
	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=sIhkdUe8XYKoeHTyF7l0ag9J+3XOBP6fBaY/msUHF5k=;
	b=Fvp+mw4r8RfFtySXxFqfUGltJRD50gRyTupGDLGLWinoSQGBw09n9BUUnGi0Kh29lheR+j
	Ar2R+qy5pYwSYtY28BFBYC1nD+HR9mTTeaKPWH/XTBxqgS0phDygs36dQ8y1ktvmKXuT99
	FLYMvPpXA88OJZUfg1KuXJ2GuprXvlmNR3vtHy5Bk4KRmafWuUXildd62C3+cCz1yO06Ba
	umA4/OMhQa9GYMxz+kAwoXJ+iDv5ktZ0EOM+qH/4lj43IgGl5K2xP9BgAjmiGPN8r36eLS
	AGDQd6HLQ4vHAuv4jTj9shqOXITgfFA0ZW7Poql5QiggeOOwaPiUlXZwXp/OaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758205794;
	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=sIhkdUe8XYKoeHTyF7l0ag9J+3XOBP6fBaY/msUHF5k=;
	b=D2sBBnkFOttTnQJ/NXSrCMnVUX5BSYwm2bp8ZdGGlngaNjQ0LgAyFxg13HJ4pw2vRD9sy5
	Mq4OfhGRb1A7pXHttPJSmNEkL2f43935H4A8dg1xxNcqGv2bzuOimlfqQLZS5kW7bCgI9U
	oLn1+aVmpFUNk5amDS0y5EOPsb6ReSAYVhxFrTAaWdGP2DCkI2V49PJZ0aLLkEIzP0+20f
	/3tX19AVa0LMJujDWHr2k9bq764VFNrb5hxY1oEixvA1+xNR0rfUC//KC1EEdMy5Uj01ow
	2W6fhn0OPzud+Jt/Itg2UOI4tfqJ/L/mEozqQt4E7Zfm9IqC0T1oJb/0eyg1/Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758205794; a=rsa-sha256; cv=none;
	b=jO26hy03tAEvR0Iw/TcdXlCoLVvlKHSL5sZ5qDmf9Z97Z+cBjMV/lmwyFHIZBW0/VayT06
	AjVTNFF8aE0DyyoY/1yHuRJA5fTS95NRBDBwUpnVl+Uwi+nQt+xWE+J53gosO30joCy26D
	0Hea/P3FiVWGMwtRNAAp4p5RwnoM0xMtV+To3Dpz1QqMyNusFgMcrJCcIbPQg4J3PiPBDg
	gWmMh5EKedlAxOF96fhQkfsUVeJJe12cxSymm7TxDn223VCC1IeVgNnlG8YScJ/bk3pRQt
	BmknbOzaUjshgHiCLzCYjSpXvAUKTcZXCAKalmXDH1fxOUfAUly7BvN8OwfEDA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
Received: from smtpclient.apple (unknown [IPv6:2001:19f0:6001:9db:98f0:9fe0:3545:10])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: zlei/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4cSJ1q1jPjzl6W;
	Thu, 18 Sep 2025 14:29:50 +0000 (UTC)
	(envelope-from zlei@FreeBSD.org)
From: Zhenlei Huang 
Message-Id: <9B7C5718-5F5E-46FB-BB97-0F75FB5CD117@FreeBSD.org>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_EB7F8416-2F5E-4DD6-A63A-B90158FE5A54"
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 \(3696.120.41.1.10\))
Subject: Re: Build failure with Clang/LLVM 22 due to alloc-size diagnostic
Date: Thu, 18 Sep 2025 22:29:36 +0800
In-Reply-To: 
Cc: freebsd-hackers@freebsd.org,
 freebsd-net@freebsd.org
To: Nakayama Kenjiro 
References: 
X-Mailer: Apple Mail (2.3696.120.41.1.10)


--Apple-Mail=_EB7F8416-2F5E-4DD6-A63A-B90158FE5A54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Sep 18, 2025, at 7:17 PM, Nakayama Kenjiro =
 wrote:
>=20
> Hi,
>=20
> There is a new diagnostic, alloc-size, in clang of LLVM22 that warns =
if the size given to a malloc is smaller than the size of the struct =
pointed to by its destination - =
https://github.com/llvm/llvm-project/pull/150028 =

> When we enable this option, in_mcast.c triggers this diagnostic, =
causing the build to fail.
>=20
> ```
> freebsd/sys/netinet/in_mcast.c:749:10: error: allocation of =
insufficient size '40' for type 'struct ip_msource' with size '48' =
[-Werror,-Walloc-size]
>   749 |                 nims =3D malloc(sizeof(struct in_msource), =
M_INMFILTER,
>       |                        ^
> ```
>=20
> =
https://github.com/freebsd/freebsd-src/blob/stable/15/sys/netinet/in_mcast=
.c#L749 =

> ```
> static int
> imf_get_source(struct in_mfilter *imf, const struct sockaddr_in *psin,
>     struct in_msource **plims)
> {
>           ...
> struct ip_msource *ims, *nims;
>   ...
> nims =3D malloc(sizeof(struct in_msource), M_INMFILTER,
>    M_NOWAIT | M_ZERO);

The following lines has this
```
lims =3D (struct in_msource *)nims;
```

So probably assign the alloced memory directly to lims would make Clang =
happy, say
```
lims =3D malloc(sizeof( .... ;
nims =3D (struct ip_mfilter *)lims;
```

You can have a try with that. Good luck with you !

> ```
>=20
> As the error message explained, the mismatch between struct ip_msource =
* and malloc(sizeof(struct in_msource)) triggers the error.
>=20
> However, when reading the source code carefully, it seems that *nims =
is intentionally of type ip_msource instead of in_msource.
> I would like to build with LLVM's alloc-size option enabled, but does =
anyone have any good ideas on how to address this problem? Or would it =
be better to report it as a false positive to LLVM? Though, I am aware =
that there is a workaround to partially disable this option...

Best regards,
Zhenlei


--Apple-Mail=_EB7F8416-2F5E-4DD6-A63A-B90158FE5A54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On Sep 18, 2025, at 7:17 PM, Nakayama Kenjiro <nakayamakenjiro@gmail.com> wrote:

Hi,

There is a new diagnostic, alloc-size, =
in clang of LLVM22 that warns if the size given to a malloc is smaller =
than the size of the struct pointed to by its destination - https://github.com/llvm/llvm-project/pull/150028
When we enable this option, in_mcast.c triggers this =
diagnostic, causing the build to fail.

```freebsd/sys/netinet/in_mcast.c:749:10: error: allocation of =
insufficient size '40' for type 'struct ip_msource' with size '48' =
[-Werror,-Walloc-size]
  749 |       =
          nims =3D malloc(sizeof(struct =
in_msource), M_INMFILTER,
      |   =
                    =
 ^
```

https://github.com/freebsd/freebsd-src/blob/stable/15/sys/netin=
et/in_mcast.c#L749
```
static int
imf_get_source(struct in_mfilter *imf, const struct =
sockaddr_in *psin,
    struct in_msource =
**plims)
{
        =
  ...
	struct ip_msource	*ims, *nims;
	   ...
		nims =3D =
malloc(sizeof(struct in_msource), M_INMFILTER,
		 =
   M_NOWAIT | M_ZERO);

The following lines has =
this
```
lims =3D (struct in_msource =
*)nims;
```

So probably =
assign the alloced memory directly to lims would make Clang happy, =
say
```
lims =3D malloc(sizeof( .... =
;
nims =3D (struct ip_mfilter =
*)lims;
```

You can have a =
try with that. Good luck with you !

```

As the error message =
explained, the mismatch between struct ip_msource * and =
malloc(sizeof(struct in_msource)) triggers the error.

However, when reading the source code carefully, it seems =
that *nims is intentionally of type ip_msource instead of in_msource.
I would like to build with LLVM's alloc-size option enabled, =
but does anyone have any good ideas on how to address this problem? Or =
would it be better to report it as a false positive to LLVM? Though, I =
am aware that there is a workaround to partially disable this =
option...





Best regards,
Zhenlei





=

--Apple-Mail=_EB7F8416-2F5E-4DD6-A63A-B90158FE5A54--

From nobody Thu Sep 18 16:35:18 2025
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 4cSLpx1DTnz67fwm
	for ; Thu, 18 Sep 2025 16:35:37 +0000 (UTC)
	(envelope-from deng1991816@gmail.com)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a])
	(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 "WR4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSLpw52CZz47n8
	for ; Thu, 18 Sep 2025 16:35:36 +0000 (UTC)
	(envelope-from deng1991816@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3ee12807d97so790638f8f.0
        for ; Thu, 18 Sep 2025 09:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758213330; x=1758818130; darn=freebsd.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=6oro2PZ8iVYc1EJF8/OwiGQHjSvf/vMWkacq/pOzMbY=;
        b=fznXao2Ie/pwQHutQp8LiAnHP97SbSIelt+XDAvLVaDbhJbWLUdz6awjvH+FtxO/M0
         pgQOz7c7zn3QzqQJHqKtMMhiDPu2+kB/QLbhtz0zUuaUo6FyvudNx+5fCU+pIHx8iCkM
         1EXGiJyFNk0wq8jSXa7eHwp2ldKGZ+yDh2jbNIBsVCmKe2YAruiHTF24DCaArWs6udMp
         SkZGt0UZTNgdl3pRG7ITKvJ08MECZFlFc/MqNpXElBhnzGNN2hz7Y3yCqEC/9ABRm+Nd
         OO4cfdvEnzuVytMgbbsO+7tTRRlMgQYppuRiF2OjP5mOFSfwg8i2L2ykJTjWgHi+wHCc
         zvxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758213330; x=1758818130;
        h=content-transfer-encoding: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=6oro2PZ8iVYc1EJF8/OwiGQHjSvf/vMWkacq/pOzMbY=;
        b=rkxOGLabXuOEaQL8Yd8BQXZutlEe1+Ke4aQd17sYBupYi74nsDf/ercoch92A+JTrL
         qv16QQ2aTRS0mec7YWic/GA6o03+ORCfKb4wMq1cZnMK1EftAnutbCngS6Brmw8bJUh7
         jIEPM8D5pXUDViIrzXbGTznNJQm47XKGUKuGG7X1AFmM8G5qGpSwmpFIx6J4l/TlZ83l
         2syTGTkofkoLDKU0AAQhot2fJ+kGGTGsIFrZgeneKeQX0y4LQLTs8zH0lFT2CSNu8iEP
         HfHYAaeofDv0HMVW1OIBgyKVmYiLzsX0sLw9L9XRR2WXydSwQw2QMiwnfDKwgt9jGYrn
         ZRQg==
X-Gm-Message-State: AOJu0Yzvi6mSzelL6KBVbN6xFyEHkuUioeM4486ICo60gCFMiGHT7T7E
	LPWTycZBuC4Ae5oXK83rB1gJr8jIG8Ot0v0z/0RDzIEXLk57mR/ZeorZW0NTFLmgulFmTQ1rmE4
	NvI7uXrqLXzjJd4ym5eNom5KCecyLfw4=
X-Gm-Gg: ASbGncvuYEJpLP84f40lO4ypc0pwdl5MnZ1VuU+ytenNssssZSWKSSb2SElQTELea9O
	NeJ581r/Gbg1j1l6Kuw5GUit13eCYX9eHk8nf5GJo0zL0SXGsnQQHKhKf0O2zbdcMm/EBppegXr
	ud9MC8wic96NoxYfHpL6R+Sk5x9IztXVwrKOX/JMhehoqtAOXqJNxS/8RjhbG/kV+eHvsTfp3l9
	35xLRwGVO1IeCJ4N/CA2mpTfQ==
X-Google-Smtp-Source: AGHT+IFHxajxGP8Km23Fl7GCZ1gYej9UUlfcV4+2XJAHhq4Uz1erfzjfjxpf6lQuMd6CwQ4w12RfkFtlt9TR9g8Bvc0=
X-Received: by 2002:a05:6000:40c8:b0:3ea:f4a1:f063 with SMTP id
 ffacd0b85a97d-3ecdfa41fccmr5813024f8f.55.1758213329957; Thu, 18 Sep 2025
 09:35:29 -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: 
 <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de>
In-Reply-To: <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de>
From: Tilnel 
Date: Fri, 19 Sep 2025 00:35:18 +0800
X-Gm-Features: AS18NWBDqR5bJT3Sv0rRa0U3mKa87bpQL2cE-2Z0qaoUDpYvRDtfyf8AdS_t9bE
Message-ID: 
Subject: Re: Two different places between TCP socket behavior and RFC documents
To: Michael Tuexen 
Cc: freebsd-net@freebsd.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cSLpw52CZz47n8

On Thu, Sep 18, 2025 at 6:25=E2=80=AFPM Michael Tuexen
 wrote:
> > 2. Sending RST to segment with old sequence SYN-RECEIVED instead of
> > acknowledgement
> > According to RFC793 page 69: If an incoming segment is not acceptable, =
an
> > acknowledgement should be sent in reply. (here `should` is not capitali=
zed).
> > This should be applied to all states including and after SYN-RECEIVED. =
But it's
> > not the case with FreeBSD TCP socket. I found this with manually constr=
ucted TCP
> > segment:
> >  A > B: Flags [S], seq 1, win 8192, length 0
> >  B > A: Flags [S.], seq 4054810353, ack 2, win 65535, length 0
> >  A > B: Flags [.], ack 1, win 8192, length 0
> >  B > A: Flags [R], seq 4054810354, win 0, length 0
> I am not sure which scenario are you considering. Could you provide SEG.S=
EQ
> for the this TCP segment?
> > Expected behavior is to send an empty ack:
> >  A > B: Flags [S], seq 1, win 8192, length 0
> >  B > A: Flags [S.], seq 3620804602, ack 2, win 65495, length 0
> >  A > B: Flags [.], ack 1, win 8192, length 0
> >  B > A: Flags [.], ack 1, win 65495, length 0
> > Which is the case with Linux.

I'd be happy to explain the scenario in more detail.
Consider the following TCP handshake sequence:
1. Socket A sends a SYN segment:  to Socket B, which is=
 in the
   TCP_LISTEN state.
2. Socket B transitions to TCP_SYN_RECV and responds with
   .
3. Instead of sending the expected  to com=
plete the
   three-way handshake, Socket A incorrectly sends .
According to the RFC, the appropriate response to such a malformed ACK shou=
ld be
an empty ACK segment: . After that, Socket=
 B should
either wait for a valid ACK or retransmit the SYN-ACK if necessary.
However, in FreeBSD=E2=80=99s current implementation, a RST segment is sent=
 instead:
, which aborts the connection prematurely.
This behavior appears to deviate from the RFC guidance and may lead to
unnecessary connection resets in edge cases.
Best regards
Tilnel

From nobody Thu Sep 18 18:22:34 2025
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 4cSPBd1Jvdz67pk4
	for ; Thu, 18 Sep 2025 18:22:49 +0000 (UTC)
	(envelope-from michael.tuexen@lurchi.franken.de)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "*.franken.de", Issuer "Certum Domain Validation CA SHA2" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSPBc5qBDz4P7N
	for ; Thu, 18 Sep 2025 18:22:48 +0000 (UTC)
	(envelope-from michael.tuexen@lurchi.franken.de)
Authentication-Results: mx1.freebsd.org;
	none
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:41c6:4036:5ab9:6ac6])
	(Authenticated sender: lurchi)
	by drew.franken.de (Postfix) with ESMTPSA id 1739E721E283A;
	Thu, 18 Sep 2025 20:22:35 +0200 (CEST)
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 \(3864.100.1.1.5\))
Subject: Re: Two different places between TCP socket behavior and RFC
 documents
From: Michael Tuexen 
In-Reply-To: 
Date: Thu, 18 Sep 2025 20:22:34 +0200
Cc: freebsd-net@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de>
 
To: Tilnel 
X-Mailer: Apple Mail (2.3864.100.1.1.5)
X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00
	autolearn=disabled version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cSPBc5qBDz4P7N

> On 18. Sep 2025, at 18:35, Tilnel  wrote:
>=20
> On Thu, Sep 18, 2025 at 6:25=E2=80=AFPM Michael Tuexen
>  wrote:
>>> 2. Sending RST to segment with old sequence SYN-RECEIVED instead of
>>> acknowledgement
>>> According to RFC793 page 69: If an incoming segment is not =
acceptable, an
>>> acknowledgement should be sent in reply. (here `should` is not =
capitalized).
>>> This should be applied to all states including and after =
SYN-RECEIVED. But it's
>>> not the case with FreeBSD TCP socket. I found this with manually =
constructed TCP
>>> segment:
>>> A > B: Flags [S], seq 1, win 8192, length 0
>>> B > A: Flags [S.], seq 4054810353, ack 2, win 65535, length 0
>>> A > B: Flags [.], ack 1, win 8192, length 0
>>> B > A: Flags [R], seq 4054810354, win 0, length 0
>> I am not sure which scenario are you considering. Could you provide =
SEG.SEQ
>> for the this TCP segment?
>>> Expected behavior is to send an empty ack:
>>> A > B: Flags [S], seq 1, win 8192, length 0
>>> B > A: Flags [S.], seq 3620804602, ack 2, win 65495, length 0
>>> A > B: Flags [.], ack 1, win 8192, length 0
>>> B > A: Flags [.], ack 1, win 65495, length 0
>>> Which is the case with Linux.
>=20
> I'd be happy to explain the scenario in more detail.
> Consider the following TCP handshake sequence:
> 1. Socket A sends a SYN segment:  to Socket B, =
which is in the
>   TCP_LISTEN state.
> 2. Socket B transitions to TCP_SYN_RECV and responds with
>   .
> 3. Instead of sending the expected  =
to complete the
>   three-way handshake, Socket A incorrectly sends =
.
> According to the RFC, the appropriate response to such a malformed ACK =
should be
> an empty ACK segment: . After that, =
Socket B should
> either wait for a valid ACK or retransmit the SYN-ACK if necessary.
> However, in FreeBSD=E2=80=99s current implementation, a RST segment is =
sent instead:
> , which aborts the connection prematurely.
> This behavior appears to deviate from the RFC guidance and may lead to
> unnecessary connection resets in edge cases.
Hi Tilnel,

OK, now I understand your scenario. Let me test it and come back to you.
Give me a day or two.

Best regards
Michael
> Best regards
> Tilnel


From nobody Thu Sep 18 19:42:03 2025
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 4cSQyF3XHRz67wGJ;
	Thu, 18 Sep 2025 19:42:13 +0000 (UTC)
	(envelope-from paul@redbarn.org)
Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::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 4cSQyF0lwgz3JDQ;
	Thu, 18 Sep 2025 19:42:13 +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 1ADC3160BFE;
	Thu, 18 Sep 2025 19:42:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util;
	t=1758224525; bh=kJ3XK4YZ1/dMKXAKF/SLxRejHW2qcSUR413By8r5Z9Y=;
	h=From:To:Cc:Subject:Date:In-Reply-To:References;
	b=qcn6xp9D+7p3FlFNUZPTofmxT9sUGYeFmFiMWYM44xyvwmU6ZUHxrf8/OJBJLeVtO
	 p+X7Mta3NxlKPl9tCgKJwe12U33hGq/y/0jE7pJ1ePGmoNstGIm4ypsBEYDNdhtuTk
	 cATNszRmLHWkoVa6sMJjDUOKqky4jsIQKuTsIzLk=
Received: from localhost.localnet (2606-4e80-1201-0016-b906-21eb-116e-3550.722262346536e7a17254ef7541820776.ip6.frontiernet.net [IPv6:2606:4e80:1201:16:b906:21eb:116e:3550])
	(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 family.redbarn.org (Postfix) with ESMTPSA id 324919;
	Thu, 18 Sep 2025 19:42:04 +0000 (UTC)
From: Paul Vixie 
To: Nakayama Kenjiro , freebsd-net@freebsd.org
Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org,
 Zhenlei Huang 
Subject: Re: Build failure with Clang/LLVM 22 due to alloc-size diagnostic
Date: Thu, 18 Sep 2025 19:42:03 +0000
Message-ID: <4985340.OV4Wx5bFTl@localhost>
Organization: FW
In-Reply-To: <9B7C5718-5F5E-46FB-BB97-0F75FB5CD117@FreeBSD.org>
References:
 
 <9B7C5718-5F5E-46FB-BB97-0F75FB5CD117@FreeBSD.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: multipart/alternative; boundary="nextPart27054142.1r3eYUQgxm"
Content-Transfer-Encoding: 7Bit
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:33651, ipnet:2001:559:8000::/48, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cSQyF0lwgz3JDQ

This is a multi-part message in MIME format.

--nextPart27054142.1r3eYUQgxm
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Donderdag 18 September 2025 14:29:36 UTC Zhenlei Huang wrote:
> > On Sep 18, 2025, at 7:17 PM, Nakayama Kenjiro 
> > ...
> > freebsd/sys/netinet/in_mcast.c:749:10: error: allocation of insufficient
> > size '40' for type 'struct ip_msource' with size '48'
> > ...
> The following lines has this
> ```
> lims = (struct in_msource *)nims;
> ```
> 
> So probably assign the alloced memory directly to lims would make Clang
> happy, say ```
> lims = malloc(sizeof( .... ;
> nims = (struct ip_mfilter *)lims;
> ```
> 
> You can have a try with that. Good luck with you !

ideally, clang will eventually get around to complaining about that type cast on the same 
basis (destination points to a longer object than the source.) is there a reason we're not 
using a union{} for this data?

-- 
Paul Vixie

--nextPart27054142.1r3eYUQgxm
Content-Transfer-Encoding: 7Bit
Content-Type: text/html; charset="us-ascii"






On Donderdag 18 September 2025 14:29:36 UTC Zhenlei Huang wrote:


> > On Sep 18, 2025, at 7:17 PM, Nakayama Kenjiro <nakayamakenjiro@gmail.com>


> > ...


> > freebsd/sys/netinet/in_mcast.c:749:10: error: allocation of insufficient


> > size '40' for type 'struct ip_msource' with size '48'


> > ...


> The following lines has this


> ```


> lims = (struct in_msource *)nims;


> ```


> 


> So probably assign the alloced memory directly to lims would make Clang


> happy, say ```


> lims = malloc(sizeof( .... ;


> nims = (struct ip_mfilter *)lims;


> ```


> 


> You can have a try with that. Good luck with you !


ideally, clang will eventually get around to complaining about that type cast on the same basis (destination points to a longer object than the source.) is there a reason we're not using a union{} for this data?


-- 


Paul Vixie



--nextPart27054142.1r3eYUQgxm--




From nobody Thu Sep 18 20:36:44 2025
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 4cSS9Z1SJyz680RX
	for ; Thu, 18 Sep 2025 20:37:06 +0000 (UTC)
	(envelope-from cross+freebsd@relay.distal.com)
Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.95.80])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSS9Y37ngz3PmS
	for ; Thu, 18 Sep 2025 20:37:05 +0000 (UTC)
	(envelope-from cross+freebsd@relay.distal.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=relay.distal.com header.s=mail header.b=aETFZrQg;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of cross+freebsd@relay.distal.com designates 168.235.95.80 as permitted sender) smtp.mailfrom=cross+freebsd@relay.distal.com
dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail;
	c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References;
	bh=tXSvTCQSfW1hFzZGPeq4WSFrKP0K5bUBnECDlbK6sDo=;
	b=aETFZrQgbfZc638poQf8R5FshssNIrW5XoJDUrxLk8PQFqXa4sa7SRaZ3Q073atPfpvFxyfBXFc9Pfevwo+zj+JVCQjUoga0b6yHuDTPQdjhslQCf5T+WYaJ3nIMIFJRbXBdsgUTyTQ7GOx3yBg5Ia/14Rwc2OsPXNL3h6kdpmpnyNh8XYK1VtydpZBlUVZG6b8QGm1t8Fyo/hhWxjc7hw6vW8E8rh+AC5dbOXwhXhACn5SsZyo9EK43pC
	DSQg9aYi1H54gUh47ff7ZXoht0AXYoxeLSOSLjRFF1aBkeiny2uI5iYzOeWjuMcIvghCp6gMH/mTY5iuhmGE02sLzJew==
Received: from mail.distal.com (pool-108-51-233-124.washdc.fios.verizon.net [108.51.233.124])
 by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305
 bits=256) ; Thu, 18 Sep 2025 20:36:57 +0000
Received: from smtpclient.apple ( [173.38.117.85]) by tristain.distal.com (OpenSMTPD)
 with ESMTPSA id dad6e79d (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Thu,
 18 Sep 2025 16:36:55 -0400 (EDT)
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 \(3826.700.81\))
Subject: Re: IPv6 networking problems in 14.3
From: Chris Ross 
In-Reply-To: <408DE851-47FF-476E-B7F6-C7920A93DD43@distal.com>
Date: Thu, 18 Sep 2025 16:36:44 -0400
Cc: freebsd-net@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1BF72AB3-69B6-4BC6-BA5B-6517BD35E41D@distal.com>
References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com>
 <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com> <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com>
 <611820c2-05f8-40bc-9b07-bef012183e30@denninger.net> <408DE851-47FF-476E-B7F6-C7920A93DD43@distal.com>
To: Karl Denninger 
X-Mailer: Apple Mail (2.3826.700.81)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-0.999];
	FORGED_SENDER(0.30)[cross@distal.com,cross@relay.distal.com];
	R_DKIM_ALLOW(-0.20)[relay.distal.com:s=mail];
	R_SPF_ALLOW(-0.20)[+a:relay.dynu.com];
	MIME_GOOD(-0.10)[text/plain];
	RCVD_TLS_ALL(0.00)[];
	TAGGED_FROM(0.00)[freebsd];
	DMARC_NA(0.00)[distal.com];
	RCPT_COUNT_TWO(0.00)[2];
	DKIM_TRACE(0.00)[relay.distal.com:+];
	ARC_NA(0.00)[];
	FROM_HAS_DN(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_NEQ_ENVFROM(0.00)[cross@distal.com,cross@relay.distal.com];
	ASN(0.00)[asn:3842, ipnet:168.235.92.0/22, country:US];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-net@freebsd.org];
	APPLE_MAILER_COMMON(0.00)[];
	TO_DN_SOME(0.00)[]
X-Rspamd-Queue-Id: 4cSS9Y37ngz3PmS



> On 17 Sep 2025, at 14:20, Chris Ross  wrote:
> So, on the idea of trying to back-date the whole machine, I have ZFS
> snapshots of the whole root from just before the first upgrade,
> Aug 7/8.  [=E2=80=A6]

Brief update, more to come later I hope.
I don=E2=80=99t know all of the magic of freebsd-update, but I was able =
to
figure/infer that it created versions (clones?) of the root fs
at points of upgrade.  I was able to swap one of those in, leaving
the current system where it was at zroot/ROOT/default.  I=E2=80=99ve set
bootfs to the older 14.1 system and gotten that running.

It _started_ looking bad, doing what the newer system was doing
by sending out SOLICIT6 messages and not getting an answer from my
ISP.  But as Karl noted, if I waited long enough (2ish hours in my
case), it eventually did get an answer!

So, if anyone has suggestions of wise diagnostics to grab while
it=E2=80=99s working, let me know.  Then the next step is to try 4.3
again, and see if it=E2=80=99s failing in the prior way still, or if it =
also
starts by sending SOLICIT6 for a while and maybe after a few hours
will get an answer.  If that doesn=E2=80=99t, I=E2=80=99ll try interface
switching again and other of the prior attempts, but being
more patient will make that process take some days.  So, just
an update that I backed out to an early-August configuration
that is again working, and I=E2=80=99ll try moving back to 14.3 again
in a few days.

- Chris=


From nobody Thu Sep 18 20:49:59 2025
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 4cSSTB5lCbz681Gp
	for ; Thu, 18 Sep 2025 20:50:38 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4cSST92ybZz3R0h
	for ; Thu, 18 Sep 2025 20:50:37 +0000 (UTC)
	(envelope-from karl@denninger.net)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
Received: from denninger.net (unknown [162.81.137.111])
	by colo1.denninger.net (Postfix) with ESMTP id C1EC9B05B1
	for ; Thu, 18 Sep 2025 16:48:52 -0400 (EDT)
Received: by denninger.net (Postfix, from userid 58)
	id 7C6FDDD523; Thu, 18 Sep 2025 16:50:00 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on NewFS.denninger.net
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=3.0 tests=ALL_TRUSTED,BAYES_00,
	HTML_MESSAGE autolearn=no autolearn_force=no version=4.0.1
X-Spam-Report: 
	* -3.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	* -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
	*      [score: 0.0000]
	*  0.0 HTML_MESSAGE BODY: HTML included in message
Received: from [192.168.10.15] (D5.Denninger.Net [192.168.10.15])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id 4E485DD521
	for ; Thu, 18 Sep 2025 16:50:00 -0400 (EDT)
Message-ID: <6d8764d1-f12b-4597-b577-3cb3840cdbc4@denninger.net>
Date: Thu, 18 Sep 2025 16:49:59 -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: IPv6 networking problems in 14.3
To: freebsd-net@freebsd.org
References: <910737314.4002.1757962919189@localhost>
 <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com>
 <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com>
 <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com>
 <611820c2-05f8-40bc-9b07-bef012183e30@denninger.net>
 <408DE851-47FF-476E-B7F6-C7920A93DD43@distal.com>
 <1BF72AB3-69B6-4BC6-BA5B-6517BD35E41D@distal.com>
Content-Language: en-US
From: Karl Denninger 
In-Reply-To: <1BF72AB3-69B6-4BC6-BA5B-6517BD35E41D@distal.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060500030405010804040408"
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.84 / 15.00];
	SIGNED_SMIME(-2.00)[];
	NEURAL_HAM_MEDIUM(-1.00)[-0.999];
	NEURAL_HAM_LONG(-0.99)[-0.993];
	NEURAL_SPAM_SHORT(0.95)[0.953];
	DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_BASE64_TEXT(0.10)[];
	ARC_NA(0.00)[];
	RCPT_COUNT_ONE(0.00)[1];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	FREEFALL_USER(0.00)[karl];
	RCVD_COUNT_THREE(0.00)[3];
	MLMMJ_DEST(0.00)[freebsd-net@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	HAS_ATTACHMENT(0.00)[]
X-Rspamd-Queue-Id: 4cSST92ybZz3R0h

This is a cryptographically signed message in MIME format.

--------------ms060500030405010804040408
Content-Type: multipart/alternative;
 boundary="------------gqJGXlxyAXyuWS317hh1T0lF"

--------------gqJGXlxyAXyuWS317hh1T0lF
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gOS8xOC8yMDI1IDE2OjM2LCBDaHJpcyBSb3NzIHdyb3RlOg0KPj4gT24gMTcgU2VwIDIw
MjUsIGF0IDE0OjIwLCBDaHJpcyBSb3NzPGNyb3NzK2ZyZWVic2RAZGlzdGFsLmNvbT4gd3Jv
dGU6DQo+PiBTbywgb24gdGhlIGlkZWEgb2YgdHJ5aW5nIHRvIGJhY2stZGF0ZSB0aGUgd2hv
bGUgbWFjaGluZSwgSSBoYXZlIFpGUw0KPj4gc25hcHNob3RzIG9mIHRoZSB3aG9sZSByb290
IGZyb20ganVzdCBiZWZvcmUgdGhlIGZpcnN0IHVwZ3JhZGUsDQo+PiBBdWcgNy84LiAgW+KA
pl0NCj4gQnJpZWYgdXBkYXRlLCBtb3JlIHRvIGNvbWUgbGF0ZXIgSSBob3BlLg0KPiBJIGRv
buKAmXQga25vdyBhbGwgb2YgdGhlIG1hZ2ljIG9mIGZyZWVic2QtdXBkYXRlLCBidXQgSSB3
YXMgYWJsZSB0bw0KPiBmaWd1cmUvaW5mZXIgdGhhdCBpdCBjcmVhdGVkIHZlcnNpb25zIChj
bG9uZXM/KSBvZiB0aGUgcm9vdCBmcw0KPiBhdCBwb2ludHMgb2YgdXBncmFkZS4gIEkgd2Fz
IGFibGUgdG8gc3dhcCBvbmUgb2YgdGhvc2UgaW4sIGxlYXZpbmcNCj4gdGhlIGN1cnJlbnQg
c3lzdGVtIHdoZXJlIGl0IHdhcyBhdCB6cm9vdC9ST09UL2RlZmF1bHQuICBJ4oCZdmUgc2V0
DQo+IGJvb3RmcyB0byB0aGUgb2xkZXIgMTQuMSBzeXN0ZW0gYW5kIGdvdHRlbiB0aGF0IHJ1
bm5pbmcuDQo+DQo+IEl0IF9zdGFydGVkXyBsb29raW5nIGJhZCwgZG9pbmcgd2hhdCB0aGUg
bmV3ZXIgc3lzdGVtIHdhcyBkb2luZw0KPiBieSBzZW5kaW5nIG91dCBTT0xJQ0lUNiBtZXNz
YWdlcyBhbmQgbm90IGdldHRpbmcgYW4gYW5zd2VyIGZyb20gbXkNCj4gSVNQLiAgQnV0IGFz
IEthcmwgbm90ZWQsIGlmIEkgd2FpdGVkIGxvbmcgZW5vdWdoICgyaXNoIGhvdXJzIGluIG15
DQo+IGNhc2UpLCBpdCBldmVudHVhbGx5IGRpZCBnZXQgYW4gYW5zd2VyIQ0KDQpZb3UncmUg
bHVja3kgLS0gS1VCIChteSBJU1ApIHRvbGQgbWUgdGhhdCB0aGVpciAiYmluZGluZyIgcmVt
YWluZWQgdmFsaWQgDQpmb3IgKl90aHJlZSB3ZWVrc18qLsKgIE5lZWRsZXNzIHRvIHNheSB0
aGF0J3Mgbm90IG5pY2UgaWYgaXQgZ2V0cyBtYWQgYXQgDQp5b3UuLi4uLiA6LSkNCg0KLS0g
DQpLYXJsIERlbm5pbmdlcg0Ka2FybEBkZW5uaW5nZXIubmV0DQovVGhlIE1hcmtldCBUaWNr
ZXIvDQovW1MvTUlNRSBlbmNyeXB0ZWQgZW1haWwgcHJlZmVycmVkXS8NCg==
--------------gqJGXlxyAXyuWS317hh1T0lF
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



  
    
  
  
    
On 9/18/2025 16:36, Chris Ross wrote:<=
span
      style=3D"white-space: pre-wrap">



    

      

        
On 17 Sep 2025, at 14:20, =
Chris Ross <cross+freebsd@distal.com> wrote:
So, on the idea of trying to back-date the whole machine, I have ZFS
snapshots of the whole root from just before the first upgrade,
Aug 7/8.  [=E2=80=A6]


      

      
Brief update, more to come later I hope.
I don=E2=80=99t know all of the magic of freebsd-update, but I was able t=
o
figure/infer that it created versions (clones?) of the root fs
at points of upgrade.  I was able to swap one of those in, leaving
the current system where it was at zroot/ROOT/default.  I=E2=80=99ve set
bootfs to the older 14.1 system and gotten that running.

It _started_ looking bad, doing what the newer system was doing
by sending out SOLICIT6 messages and not getting an answer from my
ISP.  But as Karl noted, if I waited long enough (2ish hours in my
case), it eventually did get an answer!

    

    
You're lucky -- KUB (my ISP) told me that their "binding"
      remained valid for=C2=A0three weeks.=C2=A0 Needless t=
o say
      that's not nice if it gets mad at you..... :-)

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]<=
/div>
  


--------------gqJGXlxyAXyuWS317hh1T0lF--

--------------ms060500030405010804040408
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
C4owggWZMIIDgaADAgECAhRZU8dKdMneRI1Vq5kv0k54Q5rQuDANBgkqhkiG9w0BAQsFADB2
MQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRYwFAYDVQQKDA1EZW5uaW5nZXIu
TmV0MRcwFQYDVQQDDA5EZW5uaW5nZXIgUm9vdDEiMCAGCSqGSIb3DQEJARYTYWRtaW5AZGVu
bmluZ2VyLm5ldDAeFw0yNDA1MDkyMTA4MDNaFw00NDA1MDQyMTA4MDNaMF0xCzAJBgNVBAYT
AlVTMRIwEAYDVQQIDAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNV
BAMMGURlbm5pbmdlci5OZXQgU2lnbmluZyBJbnQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDbR0tSiuLG5HPfo+cWtdeYQ8jc8Bjfuo0GTcNRT0glHnH1apUtInIktUknEZDH
ohahInN+mMBdKg54FCHOiYZrJbyxBIo9FwX7hRmOc+spxmSYWnOd2E/YcGInMK4ZpjPzldzB
Yt1n3zygkhx2bssxTJS3x4nv1qAXfLSZd1VwqoQufifEoPyTtymkkvHLv86vLgqAqooM/cXc
4LSIQ5u2uM308n42r8RkKtp7X1v9fJW8oRZN2XnFZtiUPH44YY2rHqyN2Hea9Y3+TXbldXjo
xhPHTA+JYVFq8KTmbQBqU7YcMhlIG0cSxPeFLMxnP6pqPcIVTAlK+a6YGRFppfjZAgMBAAGj
ggE2MIIBMjAdBgNVHQ4EFgQUH+VuxXhBxaJAQrvDekwkH91hBi4wgbMGA1UdIwSBqzCBqIAU
RFYC4p6L6KITnEvrpx2cyt+PcMmheqR4MHYxCzAJBgNVBAYTAlVTMRIwEAYDVQQIDAlUZW5u
ZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5OZXQxFzAVBgNVBAMMDkRlbm5pbmdlciBSb290
MSIwIAYJKoZIhvcNAQkBFhNhZG1pbkBkZW5uaW5nZXIubmV0ghQZE7NBItWtQsCouuwU6jZ+
HPPwnjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+gLaAr
hilodHRwOi8vd3d3LmRlbm5pbmdlci5uZXQvcm9vdC1yZXZva2VkLmNybDANBgkqhkiG9w0B
AQsFAAOCAgEAfFbhPc82AfhyUqONs7IccYD36w+OP4nQgwfC4IWf3y/aQAZ2Zk6IITzYqwf7
PFM0bJRT3zi7xyetolqHDhfMJvnOQWpITZiyM/FSKwIvuBsy/uJUqPuqui4XQMYoSbAA1qmI
MW/z7VZZHwaRFoeWE40UirYcf0fNcooBZ72bmd+iBaVyjtZvky0Vgcz0eC6e6LR5kNb23yC6
TkyQIlGyQkK5/afXUYFzk49rOHVbVyxW3oXRfq8Ow6HCrpDGAS8p84S04MFwBVAUfbe4aXs3
bampaI2LzKgkVywyFP14LSvvdjCfLYfnLy1Z9hm2EHMqNHA2tCGdRhWp2d7aZC1MYFqng0ZS
fjPJjqHrI1qPU0p6k9A1GxAtrQlL2v/IUzUnMZkiawFV3qlxMGZf/kTYTUOcJhx1KU4zSLHu
80qO7ldRpp5gHssCAGFbeTu2gp6LxfmaFhLPDBJ1VGfdPx9lUrU/9OcoHczcl5x2Rb8IUZyX
9elzP5WdAU8p5R/DLlOAq24VcabhFtYBCA2dOESLupSfWKNQuJCN/1gz7ysSc+mjnnPV77IO
mpszJfkFFJEDNJlGIVKX1vwwygtC/9Ulox8frgbZlRAYAgDc/YbOBFxticVVre0Y3Ujx6Kzb
tkgZRlgfdZWbT1W5smncqJxg5qAL8e/yTb3fCe2nJ0jhiP4wggXpMIIE0aADAgECAhMAmNFt
CiCF3j+FwQLYtBTmGjzkMA0GCSqGSIb3DQEBCwUAMF0xCzAJBgNVBAYTAlVTMRIwEAYDVQQI
DAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNVBAMMGURlbm5pbmdl
ci5OZXQgU2lnbmluZyBJbnQwHhcNMjQwNTEwMTkyNjU5WhcNMjkwNTA5MTkyNjU5WjBXMQsw
CQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRcwFQYDVQQKDA5LYXJsIERlbm5pbmdl
cjEbMBkGA1UEAwwSa2FybEBkZW5uaW5nZXIubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8A
MIICCgKCAgEAvh1UssVbSYctzobPjwBkbjv/w4WvQNepeRTwE6+sLnXvc41+X9pa5EclPL4Q
l02Vu1m71mSqXGfK9HbWZoivbhefBHOoYb35MSc24PelhwcORbpneWoWc7giQ7QgFlvEe/yj
fs8M0H9fgdzFS5m2lwBQbis8kioSjHB2yt/8I1GE4Mvt1Cur9kga6ML5FAQvo8TYN1stdhrE
13FEv/BWCF4FVT4H2Wa2ySW+R1jkKb74SC6Twg98bGCRTShD5bVylh0+0LXNhzaopIDcI/KK
jm/j3mRjIlmqbGrSpvJsbjjhjhAYQKE1U8FB5TDU4OkFAibblhQit/KjgspPR2o/vOpVFPER
uhZEV1oDGzUJtZlkREIcN2sYBi0p7Y4585ya+b7L10mEenPlyi3eSkGXEuiy/BR2DY6lShwW
DPoQ5602TKmttCSwBdWGoLrQ4jEVEVNt4lku2wPbTHF3KpHJU0g7RbcWoUYn10SOxKathkir
hF3v9U32+QhPELGwqRrH0sL9rWf0qalRtPDHUYl8TebZmYkFqNeSMlqHijl5f4SsQPSj7gx5
4F19Ntm9ZcvuWTmW8QQGWTKHeMuG+BYkVIUSPe6/ZQsbD/xDx7rkyGfNgWIa4W7Wm/B7kaNq
H53tk3wFmNgZQOxMTPF0oTHfW0T2azU6JD0D1AlgoAnSAE0CAwEAAaOCAaYwggGiMDoGCCsG
AQUFBwEBBC4wLDAqBggrBgEFBQcwAYYeaHR0cDovL29jc3AuZGVubmluZ2VyLm5ldDo3Nzc3
MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDAzBglghkgBhvhCAQ0EJhYkT3BlblNTTCBHZW5lcmF0ZWQgQ2xpZW50IENlcnRp
ZmljYXRlMB0GA1UdDgQWBBSxJZjVnlYLAT3uzvDYgc4742J6UTCBswYDVR0jBIGrMIGogBQf
5W7FeEHFokBCu8N6TCQf3WEGLqF6pHgwdjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5l
c3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLk5ldDEXMBUGA1UEAwwORGVubmluZ2VyIFJvb3Qx
IjAgBgkqhkiG9w0BCQEWE2FkbWluQGRlbm5pbmdlci5uZXSCFFlTx0p0yd5EjVWrmS/STnhD
mtC4MB0GA1UdEQQWMBSBEmthcmxAZGVubmluZ2VyLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEA
TrQ45/tBN3SiuqItFv/V+CF3h7Hxe0YLsL+A/P+q9ZhxIscaNjaclgQhPA+rUr+l8DGoXJ/w
yAl1E0SSBK+9phIc/9xFOBg3rCy4ngubzP+lHS1t03nMCBSUNsu5qPzqLBPiKaPabUu3Gr9o
koRezSszgM3/zNJfr8cMO93csCK/fBccsMx5q+3nxB5XeT7UciicjfEzUA4m2mQxBmGk9SSU
147Gy8UmdSq57Tw82KqUrQ1pJ6IOzVPLREpwlqGbHykSU3MwtPYPtfQeFVjvO/XcWvoFQjbV
UyhzAqMMYFudxoVLlJQiAgU38OScTLDgKxCO41h7VOjb2mss0zHndzGCBZUwggWRAgEBMHQw
XTELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2Vy
Lm5ldDEiMCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC
2LQU5ho85DANBglghkgBZQMEAgMFAKCCAvIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc
BgkqhkiG9w0BCQUxDxcNMjUwOTE4MjA0OTU5WjBPBgkqhkiG9w0BCQQxQgRAMseuUGbjAwk/
7Z+N1Jj2f7f4CU5NhUzjgDjxya8mhugJfLi6WhP46YeB081nflziNf2Zf1vBpsAFKSvW95Yr
OTCBgwYJKwYBBAGCNxAEMXYwdDBdMQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2Vl
MRYwFAYDVQQKDA1EZW5uaW5nZXIubmV0MSIwIAYDVQQDDBlEZW5uaW5nZXIuTmV0IFNpZ25p
bmcgSW50AhMAmNFtCiCF3j+FwQLYtBTmGjzkMIGFBgsqhkiG9w0BCRACCzF2oHQwXTELMAkG
A1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLm5ldDEi
MCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC2LQU5ho8
5DCCAVcGCSqGSIb3DQEJDzGCAUgwggFEMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI
KoZIhvcNAwcwDQYIKoZIhvcNAwICAQUwDQYIKoZIhvcNAwICAQUwBwYFKw4DAgcwDQYIKoZI
hvcNAwICAQUwBwYFKw4DAhowCwYJYIZIAWUDBAIBMAsGCWCGSAFlAwQCAjALBglghkgBZQME
AgMwCwYJYIZIAWUDBAIEMAsGCWCGSAFlAwQCBzALBglghkgBZQMEAggwCwYJYIZIAWUDBAIJ
MAsGCWCGSAFlAwQCCjALBgkqhkiG9w0BAQEwCwYJK4EFEIZIPwACMAgGBiuBBAELADAIBgYr
gQQBCwEwCAYGK4EEAQsCMAgGBiuBBAELAzALBgkrgQUQhkg/AAMwCAYGK4EEAQ4AMAgGBiuB
BAEOATAIBgYrgQQBDgIwCAYGK4EEAQ4DMA0GCSqGSIb3DQEBAQUABIICAJCkURsIxI72ia3p
RsX25V48UjUtcnrDTvIhuMQm0j5D7pnb7bo6dtyt5CtnzwKxYMtzGLIpc/8hbZJuVBGjMGij
woHKdk286cpIXXFn/c6CQmWyIeLPF0WpPMMrMZYOapZ8VSDcX+RjK27tkwWAHkqCxQOOUMIt
yCsFHbJl8bzP92ErbzG8qhDHBtrT+LJgprv16x0l7dVhXdcp2NFtITc5fi4vhtVMBPpqPHFe
6MbZJTSm/tK5HuVKiyh7nZ0d3ycUpQmeMZITZSXWl1Spax+32AK3SANW3i5HLuPmlRfEM3gz
h5DG70ajw2BZ7akBMv7IQ0U/8seCECj3d4Fsz/Nfo0OL114aKwsWF8jAWRp2zxxladR4XaFp
U2QIwlYJEuYj0tYMYj1u1RNB8Cgw+EVDQPikou3xhC1nWdeapncNan6LN66wcPvuRGeSwh7V
FXc6WFgBHOAntEEAjtFCOyo6El7wfzTcYRH4Ep7O4wIFW5Q3qF80Y9pMKQvTFxVz3FaZwtSp
53et2jv1rcq36ot2PCdTXe6AR0mY8dY0AEC0QvNudXMB8k1gkll2MWSOMjHODHbbdQa3Fu8V
PfA5zpbOCcIM003P2nNERtaGG2NzfhCJ/Jg0cWXVu7o2hGATqej6MKSuwO0Ni4tHUk1/8ASz
+66AY6Ec/YLuuJtAXmSvAAAAAAAA
--------------ms060500030405010804040408--

From nobody Thu Sep 18 21:26:47 2025
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 4cSTHF4C3cz683qG
	for ; Thu, 18 Sep 2025 21:27:05 +0000 (UTC)
	(envelope-from vadimnuclight@gmail.com)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a])
	(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 "WR4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSTHF1hhXz3bqg
	for ; Thu, 18 Sep 2025 21:27:05 +0000 (UTC)
	(envelope-from vadimnuclight@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-55f7b6e4145so1749231e87.1
        for ; Thu, 18 Sep 2025 14:27:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758230822; x=1758835622; darn=freebsd.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=0+7pgnX+h4Z0R+E2fHnOY2CRnqMma1To6kZpkJh1hyQ=;
        b=k8L3ZCd+XDI5/w3oDYz0GSFxOjCEqJTNQtGp9KeIPH9OJULfcgIGFz4Jl9swSsupad
         tMKsJN1C7uGQzqkbtLwyQVwoV6JE5B7Cj9t0FYYev1YIuyAOyCZYEg6KfmPvQ0rq4UXq
         ptzAO/MU+ZjfX7upEP8NtEUsHqSfTnui3qi1VNok2fHxXh83aRwLmsxc5NQgNMEFESW2
         JPDoSXoQaxp+yN8rdHE38fgNXnux6Xjs3vwdKKh5Yz27AWLjcibnqNfHKhMqUKPMFk+a
         lMnEV2+v1GrhFTPy2EYcMLsW8OsVzJLaihW2tB+NODHVMZp7wuMX3GVxTTNf9p6CdzEH
         8iMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758230822; x=1758835622;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=0+7pgnX+h4Z0R+E2fHnOY2CRnqMma1To6kZpkJh1hyQ=;
        b=F9Ho08sXWgytdaExJf5k76Vv7sBU3NNssuto4/liNBAwUUxqF0zaF3BJYOGzCO7fvJ
         nk4V0To7yYu+GuECwSEpum7YXMo6RUl89/sYfON+OZcnLZmUkhyJzpO9bTQlk3wDvFPr
         pUsbx7vIepkzkPvYIOY1SjA3ISxS4fnjQeslZRKkbp+OK3Dfqldjgo1gRoYhFaurRLXx
         Z5kpb5JENYiDH8jnTYc/5VlMHxkXnn/Ha5o8CSqLw24gwsHOpQKbt8LW/tz6QkhNDEHf
         efs1Hqg0Zz816SA9z9mxvSDvMdgdasHjjhiGoirEI6GZSUcjmB9NpbMDvhPC5S+Q3TYv
         nVMQ==
X-Gm-Message-State: AOJu0YywE++C72ghk+ahgrm7Oifw2FtVJqSuLpch7WTUjltJdgCpRo8D
	Aibvar5T+XQPyLg6TMWbCDnJA7tZFga2AQsjGIsJ63K53HsiOODqWFh3
X-Gm-Gg: ASbGncslCInbp7Kg/Brb+Am8Pf+/4wmO+7epedSyxVep2ni79aD47naTLRb6MynnQxH
	WTeg8OR/y8s80Oayb1vmgP84qNEFGlP9hVYIYmHwMukCoinogJca0Fvn9kQ6aH7yjAiqdg1Z+K0
	VRo+vysPupfTJd0Ej78I0LarlKzVLtC4y4nW1HHao+QmqWv26z2PpmQWnh543Zml9bOZ9NHxukQ
	JLqh/jV+StJ0TrG0mrUe/Iign8B5ruAxYU6ZsSRX2ZTxo22YkrtEb28SuRxzRnnuJoT6gvF7DuP
	1qTsuk4TX/6MjG4UHOUfH20VjAbmi6ok4lZtXVOadrFWku51Io08GTFkw6NKW5zvT6Zaz7ur91F
	eSCQaNIep68LXs9DMFr/s+Pzkx5brGP5G7LUFwCRP4GcJ+xCf+qzCvbev+wFWZo2f96HCNiGZCj
	MNQfe9+mn7
X-Google-Smtp-Source: AGHT+IEaZpzg1CDSnNbvE+kUOYySp5kTfEX2n91Tn4MmrrGCYhNbo7jKSFG9b6VCy6RSf2KoDnPdsQ==
X-Received: by 2002:a05:6512:3a84:b0:560:932a:c3c7 with SMTP id 2adb3069b0e04-579e1b6a80dmr304292e87.13.1758230821507;
        Thu, 18 Sep 2025 14:27:01 -0700 (PDT)
Received: from nuclight.lan (broadband-77-37-180-76.ip.moscow.rt.ru. [77.37.180.76])
        by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-578a5f4479fsm957191e87.12.2025.09.18.14.27.01
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 18 Sep 2025 14:27:01 -0700 (PDT)
Date: Fri, 19 Sep 2025 00:26:47 +0300
From: Vadim Goncharov 
To: Tilnel 
Cc: freebsd-net@freebsd.org
Subject: Re: Two different places between TCP socket behavior and RFC
 documents
Message-ID: <20250919002647.367809e7@nuclight.lan>
In-Reply-To: 
References: 
X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.4)
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-Transfer-Encoding: 7bit
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cSTHF1hhXz3bqg

On Thu, 18 Sep 2025 16:50:46 +0800
Tilnel  wrote:

> Hi,
> 
> I found two behaviors different with RFC recommendations in FreeBSD 14.3 TCP
> socket.
> 
> 1. Failure to RST on close with data pending
> According to RFC2525 section 2.17, RST should be sent when close() on socket
> with pending data to read in receive buffer.
> According to RFC1122: A host MAY implement a "half-duplex" TCP close
> sequence, ... cannot continue to read data ... If such a host issues a CLOSE
>           call while received data is still pending in TCP, or if new data is
>           received after CLOSE is called, its TCP SHOULD send a RST to show
> that data was lost.
> It's not the case with FreeBSD TCP socket. Here is TCPDUMP output,
> showing close()
> on socket with pending data emit FIN instead of RST.
>   A > B: Flags [S], seq 2636678338, win 65535, length 0
>   B > A: Flags [S.], seq 1969223298, ack 2636678339, win 65535, length 0
>   A > B: Flags [.], ack 1, win 1277, length 0
>   A > B: Flags [P.], seq 1:6, ack 1, win 1277, length 5
>   B > A: Flags [.], ack 6, win 1277, length 0
>   B > A: Flags [F.], seq 1, ack 6, win 1277, length 0
>   A > B: Flags [.], ack 2, win 1277, length 0
> All close()/shutdown(SHUT_RDWR)/shutdown(SHUT_RD) and both SO_LINGER on or
> off give the same trace. While on Linux the same execution gives this:
>   A > B: Flags [S], seq 2879877684, win 65495, length 0
>   B > A: Flags [S.], seq 1538598692, ack 2879877685, win 65483, length 0
>   A > B: Flags [.], ack 1, win 512, length 0
>   A > B: Flags [P.], seq 1:6, ack 1, win 512, length 5
>   B > A: Flags [.], ack 6, win 512, length 0
>   B > A: Flags [R.], seq 1, ack 6, win 512, length 0

Is the situation from RFC 2525 section 2/17 still applicable to our TCP stack?
I.e. does the connection still hold indefinitely for A after B's close() ?

> 2. Sending RST to segment with old sequence SYN-RECEIVED instead of
> acknowledgement
> According to RFC793 page 69: If an incoming segment is not acceptable, an
> acknowledgement should be sent in reply. (here `should` is not capitalized).
> This should be applied to all states including and after SYN-RECEIVED. But
> it's not the case with FreeBSD TCP socket. I found this with manually
> constructed TCP segment:
>   A > B: Flags [S], seq 1, win 8192, length 0
>   B > A: Flags [S.], seq 4054810353, ack 2, win 65535, length 0
>   A > B: Flags [.], ack 1, win 8192, length 0
>   B > A: Flags [R], seq 4054810354, win 0, length 0
> Expected behavior is to send an empty ack:
>   A > B: Flags [S], seq 1, win 8192, length 0
>   B > A: Flags [S.], seq 3620804602, ack 2, win 65495, length 0
>   A > B: Flags [.], ack 1, win 8192, length 0
>   B > A: Flags [.], ack 1, win 65495, length 0
> Which is the case with Linux.
> 
> Does anyone know why these two violations exist? Did FreeBSD choose not to
> comply with the RFC for a specific reason, or is it simply an implementation
> error?

RFC 9293 still does not capitalize "should" here, therefore it is not a
normative requirement. In fact, I vaguely recall that some anti-DDoS systems
check the liveness of host (not being spoofed SYN) by sending out-of-window
packet and expecting RST while main connection is unaffected.

-- 
WBR, @nuclight

From nobody Thu Sep 18 21:31:04 2025
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 4cSTMy0JGQz6844S
	for ; Thu, 18 Sep 2025 21:31:10 +0000 (UTC)
	(envelope-from vadimnuclight@gmail.com)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a])
	(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 "WR4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSTMx5Xltz3dBV
	for ; Thu, 18 Sep 2025 21:31:09 +0000 (UTC)
	(envelope-from vadimnuclight@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-579363a4602so1107151e87.0
        for ; Thu, 18 Sep 2025 14:31:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758231068; x=1758835868; darn=freebsd.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=yJ8oqlTBasQjdziq0BGsVhUgk6d97Df+yP1DyE/viac=;
        b=UrkSTAdNvpwW6PVXqIuM3NaBXsza+CSwWg1S/QOkRFBsFSuIPkvh4D/+YKDccgpqGD
         Z3jxIqmRMo09TUfdUofHWEGClQ+3PrJUKFpks5I+UjnH02Rzt0vb38A0cbLxG+9ecf/S
         /sA/EHRk/Fdd0h38b3EY/zzCYYGry4Zq4c4IzxUR3+cp8sNspHNlX0MSfoFoqu+XeW38
         nA+QcvgXPhItU5lbZhDdaX3EqjbauDXu1A5TKXmP5tT8TW6XCQiyw4STJZselv5ukFuG
         +Hf7gghkXHfzKah2yKONiNfq1awtYTAwrDFi5qeFIF9pEdFcBA7bn8H1XPnQ7V+0lxwv
         1FrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758231068; x=1758835868;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=yJ8oqlTBasQjdziq0BGsVhUgk6d97Df+yP1DyE/viac=;
        b=AUZlxMbiNCEJTjit9s1wiJYXyQSEyqtUcOuya/P5tB2Mg7UgUJGzK2Ux7DsuOT28Zp
         WYQam1rWSLAyBRxZesM68272wkVDuvrt6AujAUoeWeamscPn1EXFSolQ8tcunB6wsSHO
         EyF+EMM7Vk/EC9A23AKsEg3GFhlfIFQZcH04QN2tf97CBp/j6oPOkmaA8XEyCyvpmQwN
         hK6RQ9ojRMTvjy/CpwTr6fiePEKnKR269Nh0YlPygwA2UMTrqlAHyIOaSVWjbhRieUSH
         te2bF9ShmlxUA9WHr076lHGDVkv8fOH0xUSYOETl4QEXM6jGU6gPtMeL8pFFY+hEDbks
         H7Ug==
X-Forwarded-Encrypted: i=1; AJvYcCWqPXHm9M/Y6G1aVKKGg9jLJ1BLvw8a+OL0ecnUQJ6uG5vbLtgxKKtf0ksmcue6O1JymMjBbI9FaXM1sQ==@freebsd.org
X-Gm-Message-State: AOJu0YwVTfntTRI3V16lt+Z/oTPc46tisay1HMZPIjq7y8jfZ2hz2TSZ
	mYKVhKTiBeujsA8utDwrmc0dLH49x9L7BHqw5QtnZoemZwgFIvXZMQuE
X-Gm-Gg: ASbGncsdX1WOdCs0WOeNHl8K2fvIYaGrFmBXioB9hIOcs3MKxP/6rN0TFZ1U6wm9x04
	PDOQd1gtiPj1cQI8U4GUDnnUGPZCs/j8wbICmcyXYxFtoS9Vm+eitkJygzQGztdsXVGxYOZH8hm
	butOJjIbRyiqdrNk2wan7Au9YxMb3oyxkFf7bpIVD+Mj6O7oqInzhbYChYqjlWFTFRRkbiCzwka
	x0CgNTGgx44rqwSa93fp9nhqPC2X/OlFtLjpZ+gGQnLOr0yG8m7M4kBjQd9FPTLLVtdVRXnjR27
	0LRJG74vWexy5/H7ZMsnJA0JtRP7xgJqbDcBVsLJLU8aqkAXzWDtJgMmE1XjT/CGOAyG0FHjSQC
	eNnAatLXxFNyBfPUBSDVUWXtGco8jQqXWDOLhZi4UfRcQGG3Ar9nQL+92mu71PsqqUt6zb3uj13
	2Ox9TvE0PO
X-Google-Smtp-Source: AGHT+IF6CVoes4uHw4HK2+Nr/WleMiRJ1+9PbexGLDb9QSRqktgNJrWMbhz+U3O8lMvfVaIK2nGgGA==
X-Received: by 2002:a05:6512:1094:b0:55f:3525:3e52 with SMTP id 2adb3069b0e04-579dfec1eddmr380525e87.14.1758231068099;
        Thu, 18 Sep 2025 14:31:08 -0700 (PDT)
Received: from nuclight.lan (broadband-77-37-180-76.ip.moscow.rt.ru. [77.37.180.76])
        by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-578a90a207bsm952913e87.65.2025.09.18.14.31.07
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 18 Sep 2025 14:31:07 -0700 (PDT)
Date: Fri, 19 Sep 2025 00:31:04 +0300
From: Vadim Goncharov 
To: Tilnel 
Cc: Michael Tuexen ,
 freebsd-net@freebsd.org
Subject: Re: Two different places between TCP socket behavior and RFC
 documents
Message-ID: <20250919003104.5857ecd7@nuclight.lan>
In-Reply-To: 
References: 
	<38DCEDDE-7BAB-4A1D-ACB4-6B2E8FCEB6CE@lurchi.franken.de>
	
X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.4)
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-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cSTMx5Xltz3dBV

On Fri, 19 Sep 2025 00:35:18 +0800
Tilnel  wrote:

> On Thu, Sep 18, 2025 at 6:25=E2=80=AFPM Michael Tuexen
>  wrote:
> > > 2. Sending RST to segment with old sequence SYN-RECEIVED instead of
> > > acknowledgement
> > > According to RFC793 page 69: If an incoming segment is not acceptable=
, an
> > > acknowledgement should be sent in reply. (here `should` is not
> > > capitalized). This should be applied to all states including and after
> > > SYN-RECEIVED. But it's not the case with FreeBSD TCP socket. I found
> > > this with manually constructed TCP segment:
> > >  A > B: Flags [S], seq 1, win 8192, length 0
> > >  B > A: Flags [S.], seq 4054810353, ack 2, win 65535, length 0
> > >  A > B: Flags [.], ack 1, win 8192, length 0
> > >  B > A: Flags [R], seq 4054810354, win 0, length 0 =20
> > I am not sure which scenario are you considering. Could you provide SEG=
.SEQ
> > for the this TCP segment? =20
> > > Expected behavior is to send an empty ack:
> > >  A > B: Flags [S], seq 1, win 8192, length 0
> > >  B > A: Flags [S.], seq 3620804602, ack 2, win 65495, length 0
> > >  A > B: Flags [.], ack 1, win 8192, length 0
> > >  B > A: Flags [.], ack 1, win 65495, length 0
> > > Which is the case with Linux. =20
>=20
> I'd be happy to explain the scenario in more detail.
> Consider the following TCP handshake sequence:
> 1. Socket A sends a SYN segment:  to Socket B, which =
is in
> the TCP_LISTEN state.
> 2. Socket B transitions to TCP_SYN_RECV and responds with
>    .
> 3. Instead of sending the expected  to c=
omplete
> the three-way handshake, Socket A incorrectly sends
> . According to the RFC, the appropriate re=
sponse to
> such a malformed ACK should be an empty ACK segment:
> . After that, Socket B should either wai=
t for a
> valid ACK or retransmit the SYN-ACK if necessary. However, in FreeBSD=E2=
=80=99s
> current implementation, a RST segment is sent instead: ,
> which aborts the connection prematurely. This behavior appears to deviate
> from the RFC guidance and may lead to unnecessary connection resets in ed=
ge
> cases. Best regards
> Tilnel

Did you check it with about ~2 G out of window? That is, your examples above
were about ~200 M different sequence numbers, so that RST could be ignored.

--=20
WBR, @nuclight

From nobody Fri Sep 19 01:44:28 2025
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 4cSb0P2vVPz68N94;
	Fri, 19 Sep 2025 01:44:37 +0000 (UTC)
	(envelope-from zlei@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 "R13" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSb0P29S5z3HMJ;
	Fri, 19 Sep 2025 01:44:37 +0000 (UTC)
	(envelope-from zlei@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758246277;
	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=X06QG60uTikDYql0hYo72Hf/U5Z0xB3GzKT6X433e0I=;
	b=P2CKMqu5UtkWOUSiKzo2TH2PrQEIyqQ2hM51NgeJsyvASOMq8HAXP5Eaqa172Eq6hHQEaI
	ZHx25B3JA9BsGw8DRNlQ6Nom6OBhRhpQL7zrzJXQihnnU+lAq7s1y+JvbSenq/WRGLfo2y
	5uDlqM4eb+J9TkrtXOP1ebJ/JbX8kJ76CBtSC1CwAf/yiw2TjOPQh5xc83o19w4yy4Ce1h
	zSPojygJMlIUQA/ZYB7BYCS+XgI+xP+6XHMSl8Nvb94YwATNAUiXdCbKPoyr5a+goDYIHc
	j8Rp8eVyiveugaVldNrWRds9U8Sh/ea+FJAAcnkyrg6uSvz1sFLeOhl/GooSsg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758246277;
	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=X06QG60uTikDYql0hYo72Hf/U5Z0xB3GzKT6X433e0I=;
	b=Xt/0TObugQavk88W2y/eTKlKM7pO+Ts6vyWSjdHcr/vckb2KnVaoC5rzzsFt71FjlM4byT
	bLpokjnMJAG4wxB5aM2KTMnqeiDBrLVsSfSRIrdzOOmO4tIvkKd6xPk0HVCIrZCMh17HGu
	ExDnltWpawtwOdhvpIdSuMBfm40Q4brV5DFHFYhhpmLNYAlcDTaI30a366+GaRm6dQmStX
	oLIGqlmB2Idhqt1x1pp+ph9moZGUrZnA3gSbJgP5p89Nzsu3FoHCrcZELaeyQm6teuGNZf
	MfoqZL9i2hp+W/i4C4wgBJMagm3bnW/fe99qcZuqB/k+ZUex2hA23k/sxKskPQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758246277; a=rsa-sha256; cv=none;
	b=oCdg6RNLgsWVrmuQOH6pRJhUl87jCCMNhahr3/Xq6CbvaCRM5/gP3ddKOl1tOzyYp+0JZm
	W/XSzJDIMYz1kGt5wDjY3hDc8zIcyUp2lC2VTMOttyw40+aTVHy79LEiIIlll1IQ7LpsQM
	8Pmv1R/G63my4J/GYjzbxgBXpvBaCZ+mtCFFg+FL94NpHzu7VV/s5wau8RwfeiSkL6NX8E
	AkJps1IngCfvVQ0ZVxws8oKyycVs6UofuqsyxGPCtoINCzdOvrThGfyoPHuXugU7T2P7sq
	uqdDkvAHA4G20aTeF1orX4EHeM4Tnj1MJUdFmoMFv3XUav2ZDn8ZZioUdIoJMA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client did not present a certificate)
	(Authenticated sender: zlei/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4cSb0M3kfWz10nF;
	Fri, 19 Sep 2025 01:44:35 +0000 (UTC)
	(envelope-from zlei@FreeBSD.org)
Content-Type: text/plain;
	charset=us-ascii
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 \(3696.120.41.1.10\))
Subject: Re: Build failure with Clang/LLVM 22 due to alloc-size diagnostic
From: Zhenlei Huang 
In-Reply-To: <4985340.OV4Wx5bFTl@localhost>
Date: Fri, 19 Sep 2025 09:44:28 +0800
Cc: Nakayama Kenjiro ,
 freebsd-net@freebsd.org,
 freebsd-hackers@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
 <9B7C5718-5F5E-46FB-BB97-0F75FB5CD117@FreeBSD.org>
 <4985340.OV4Wx5bFTl@localhost>
To: Paul Vixie 
X-Mailer: Apple Mail (2.3696.120.41.1.10)



> On Sep 19, 2025, at 3:42 AM, Paul Vixie  wrote:
>=20
> On Donderdag 18 September 2025 14:29:36 UTC Zhenlei Huang wrote:
> > > On Sep 18, 2025, at 7:17 PM, Nakayama Kenjiro =

> > > ...
> > > freebsd/sys/netinet/in_mcast.c:749:10: error: allocation of =
insufficient
> > > size '40' for type 'struct ip_msource' with size '48'
> > > ...
> > The following lines has this
> > ```
> > lims =3D (struct in_msource *)nims;
> > ```
> >
> > So probably assign the alloced memory directly to lims would make =
Clang
> > happy, say ```
> > lims =3D malloc(sizeof( .... ;
> > nims =3D (struct ip_mfilter *)lims;
> > ```
> >
> > You can have a try with that. Good luck with you !
>=20
> ideally, clang will eventually get around to complaining about that =
type cast on the same basis (destination points to a longer object than =
the source.) is there a reason we're not using a union{} for this data?

I've no idea why not using a union, probably because it wastes a little =
memory ? In C world, basically it is the developer's duty to ensure no =
out of bounds memory access.

I'm not sure how many type casts like this will make Clang unhappy, but =
I think the first step would be turning the warning on but not fail the =
build, so that it is easy to do statistic and then plan what to do next.

>=20
> --
> Paul Vixie

Best regards,
Zhenlei


From nobody Fri Sep 19 16:08:20 2025
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 4cSy906TMbz68CKD
	for ; Fri, 19 Sep 2025 16:08:20 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSy905y8Jz44Mt
	for ; Fri, 19 Sep 2025 16:08:20 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758298100;
	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=NIQgwQKO4qY9mnr5zoCvp/rsxcfANsO9IGxZNYaWhAk=;
	b=R45PfdAE0R5q2LSgdalANx+SRlAGbWhzwZDjnrCHk8wI1DEhacrYK1sSMRiftgSQrqUw/4
	wws/5Q3kTmlZX5rSgGXZxUn/QsNgFWo0sZk/0SvHkYlnS50prq1Azp3tvenJchBaCIJ7j1
	6b+LWknPFtCLgSjw8WtwpWnr1b5aIRudvIzoRTVzR0LUQbgpdg5wxD35VqqnC0C7xgI1VJ
	zd9+uljn7BX2q1//KbtqkZWA3OXZlR0h+L2/7F9Xuv3py55CIR7qKTJe5NtYf2WwwwLULq
	7mJc73n+B7R0viPIkgHWK7F0w+/AgdrYqz0UK7Y0PSDyjjSTuYLe9w4fTyfxqQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758298100;
	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=NIQgwQKO4qY9mnr5zoCvp/rsxcfANsO9IGxZNYaWhAk=;
	b=A+6OIl3RHXMpCnsKxOp+B26aGDnrLvv5qQTlecIh7LCO2Xp0N3apkWHs4HJ2FZPI0YExGA
	kJduNQREz3anK3z05/1ad7g6heNE+5KS+IyVlZ9r0E1E3rFlWMGswQLEoj+OLqJNwQ7gfM
	YTjCu23vdNsIIpWOWL9ZyDXdolBb6MAX6ziiIKrLIrrGqx37/kztEr9UDoerjsfkz9ghrp
	TUQzEqPaw/xVl3qO+vm5Ex02bwLJzxNcJeqheYyRPrt6N8hZZgJYcC0twEdzI6ucNpOPxu
	7jZMHWy/IBWtMdqfUv2YObdSiE6N8NKX1hriORWvJ76xRrDDlN6YX9EvSL06VA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758298100; a=rsa-sha256; cv=none;
	b=l29U2jw9r8UMe+QAW5sxV3ZusgwBLBl8mxNFQwMqZg8/BMYfef4TwYdI0WbY6Nrj5eR1L5
	G9t1+5Kgw+sHILfMnijk6heAV9lSqiMKg4buqPH4YrSmPr7WMCewEp50gheI5PD2uidcBH
	GawdWk6+zjsRUNQ6OGY8ndcu7uxjBPABYQ5odFoDRla4maZnJaAIRyOU+AsNmNF7HxRnwP
	5XQowRP/cUupaJe5Qi35+SYWbq/4GbGSpH64xaWFv3Cm0aL0qTekJqFlfDyeDN1PoDQQtA
	opjupfE/6NBR2OrUyHASRR16ABO6MiY3qucRu0cQqr9JAYaPb7P/qNlQKgDx4Q==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cSy905V8Nz1402
	for ; Fri, 19 Sep 2025 16:08:20 +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 58JG8K7A053805
	for ; Fri, 19 Sep 2025 16:08:20 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58JG8KND053804
	for net@FreeBSD.org; Fri, 19 Sep 2025 16:08:20 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 289545] No option to disable NOMAP leads to network down/up
 with em0 when starting bridge.
Date: Fri, 19 Sep 2025 16:08:20 +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.5-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: markj@FreeBSD.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: bug_status cc
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289545

Mark Johnston  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open
                 CC|                            |markj@FreeBSD.org

--- Comment #5 from Mark Johnston  ---
Does ifconfig em0 -mextpg fix the problem?  I don't understand why ifconfig
reports it as NOMAP instead of MEXTPG.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Sep 19 16:22:51 2025
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 4cSyTl36TTz68DkB
	for ; Fri, 19 Sep 2025 16:22:51 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSyTl2Yvrz47YF
	for ; Fri, 19 Sep 2025 16:22:51 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758298971;
	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=DVbWt1lq7X717QHa40S/5RUG+KRpJ6WtO3r7tZqz0Eg=;
	b=V/jno7kU5sa3qn75PIRgz5ixnnNHL4wU2SeKHzxKZG8a6cjyJxh55AeUWI4lYKhKmL09dP
	jcYspYVptHg4VXz3jZ5/8cwUCp+QZ55xMCorhZNOS1Kvn89iXRoVx9BYzcBYE2nfgq+G91
	gK4cEpTeZlQwV2cVcRHeO1JfgJC6PKnHPluqS77sS1h3RMlpQTHK6FT/cquYbVTQZivrIb
	T+246G3G7FXSe/4RhibwYJk6Epz2UNRpEWVcaOerHlGn9Me75HEX79RrzLP25QyBILBRXw
	rIHfTI9jQGCGuG9iiZd/0HF0SK7BWM4Xl7AMS73WAyIz48nU16PV+SNtG8H3PA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758298971;
	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=DVbWt1lq7X717QHa40S/5RUG+KRpJ6WtO3r7tZqz0Eg=;
	b=wB2tfwHTjfgnL8ESmByquh08S2EzXiXDnh0QMkkklWFiUUq86za7c0X2HP5uS/i+OIlikT
	+hrp0Zn+qvH5HnFRj2EDB0tGVU+cBQdZin1lM3VziPbLBNiAGYsubxDrXfWj6kBEWDZdAU
	vX8wb2YzqwudCIV85/E98iDayIZcDQ/dxNKGgPv+6aO40gqentzfFFuRt1gw3NQhnSKvFa
	kkbNSMWcpheJm+n6xAECqpkLoh8LX0FUpb4AFSzsz+0ffdOOJUBO4rpEzJqk2QYJLYOaEZ
	NiLHg5OZzX4pgEbANue2KUsfK6vE7MeWyZVnte6ebL5bjlXQHFXJslyKimm+RQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758298971; a=rsa-sha256; cv=none;
	b=diV5kPn0KVMf7o2faOyfjkJ4S8rvp1gb1NGzWQUuy+d+2hgWiDGHntfBlU1OiAo76oZ0MX
	32V8KQqmWukIsOFV+At4gSJlR0rGwfAoycTIzzw61jmW7VSIrCFO7xRUSX/glNVNkN7WQ1
	qc8lFU7ZLEzZXUOdzHsT8Z+3E8ZOCgt7VpgzBGq4i1E41xm1ARgSyYyaSCO1fjNzz8k3eI
	hgUcIGHfsT21vHbW627kpa8PkD8TiclnkPFEsfBU4oLTdDulOy2XTSenAVltAKdkcXUBdk
	g7NZHYmxK5PtYwddRARWE607EHz2SW2ZudVm1DmHFHuyr0IZkEqxhMnXlkw2vg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cSyTl23vdz145G
	for ; Fri, 19 Sep 2025 16:22:51 +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 58JGMpa8084763
	for ; Fri, 19 Sep 2025 16:22:51 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58JGMpNm084762
	for net@FreeBSD.org; Fri, 19 Sep 2025 16:22:51 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 289545] No option to disable NOMAP leads to network down/up
 with em0 when starting bridge.
Date: Fri, 19 Sep 2025 16:22:51 +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.5-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: bicknell@ufp.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: 
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289545

--- Comment #6 from Leo Bicknell  ---
(In reply to Mark Johnston from comment #5)

Yes! Adding -mextpg fixes it for me and removes the NOMAP option.=20=20

So, should ifconfig output something like "MEXTPG" instead of "NOMAP"?  Sho=
uld
"NOMAP" be added to the ifconfig man page?

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Sep 19 16:39:35 2025
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 4cSys329N0z68FnM
	for ; Fri, 19 Sep 2025 16:39:35 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSys30jCVz4CwC
	for ; Fri, 19 Sep 2025 16:39:35 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758299975;
	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=Ikqq9ZtY6z+9F5do98QAYI4dbrvBN43ijk+ySS0shds=;
	b=scL1sK1MN8ht+7U71gRx1vUrtKNR/hszbZb+1yWwsrMBOmXslBAEAc1zFR1ck5OIHGaCfq
	Nnl2RjMUaNrUZnes4KwxfpFbsZO3SHMcC+yX0Uk+vk6tHz0PCnjJeN4nLk9UmBjZ5V76Hw
	LMZT9Tj1/TfQspl7mUdGiZ9ippyPSeen16nc9yknHM6rSd7b/nVbj4NcqAqGt8SwjuFlTl
	vmMi2+HPfw0PfyKRbniNcl01Qq9pVC9OlePI8+YAR+M8IiwA5QgHpWtdi7aNP/AhbrJBho
	Aiqh7Pv1eJew9E/g7+bnelJSyz6zG4PjqMoX2gTuYYoMLZW3oMIKUQkRm4GpIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758299975;
	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=Ikqq9ZtY6z+9F5do98QAYI4dbrvBN43ijk+ySS0shds=;
	b=RPy+zB3syWqsETUWdPfeqtGLJJ0ZbOFe5eos51h4vh6B93pdHEkqZUlmLi+AGb8JGqGAfz
	Upr01g+9JvmnDkY/DZq1fqLSlUOM7o2v1o6gSVnbZSOVfgRCXIlobzNX+5hEJSWsQZzAM1
	M6ET9WFY2zyF7aO7+5Q0R4g7Pt226jk+ZGSPXeq0QkoMqCgLw5/LgvySGAr+wRT4t8MZgu
	v6q/XsiC61hRqWCa51HuvXZMf5rFI2kqbRMErVF2exhD9xMKqd2X9rHlCfpn/o8pZqlQa3
	VKxbzfZan5p49HUVelNqYh91NE6RY0n2d961fssnZ36zh5FkLFFGilHFizPoNg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758299975; a=rsa-sha256; cv=none;
	b=fGYhFYr48GcuBIJuqtNFcD//Dg8slOPjdBuErqhXtwa0bq1ffiAA2cDVolDzLft1J+qTF1
	JIDJMO2c10NLovJpW58tGQ2Q7RcrPNX84lub6a65JYylxk9cidr8XsVcfQV+4ASZjiozmL
	OHmHcmWHR6aBcKcsESiNqqsgEDF0lrSXTrKyWggbtPEoaeY4PePplJzmKCk3lt3rWUpX8H
	Ff4iF40L7vz46ou/3xIbQwYOdQIqpQZgPq0A88bZFRYFbNyTa9KtQ215sClpBP1A04rPff
	e5dc/OOjJ09shO2zt1ip17UIw3+4mITElEddPKem0nCOWsBhZQPJP5YjPwNghA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cSys26z3hz14Hw
	for ; Fri, 19 Sep 2025 16:39:34 +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 58JGdY5s005074
	for ; Fri, 19 Sep 2025 16:39:34 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58JGdYvQ005073
	for net@FreeBSD.org; Fri, 19 Sep 2025 16:39:34 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 289545] No option to disable NOMAP leads to network down/up
 with em0 when starting bridge.
Date: Fri, 19 Sep 2025 16:39:35 +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.5-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: markj@FreeBSD.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: 
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289545

--- Comment #7 from Mark Johnston  ---
(In reply to Leo Bicknell from comment #6)
Well, the plot thickens... on one system I have

em1: flags=3D8802 metric 0 mtu 1500=20=20=20=
=20=20=20=20
options=3D4e504bb

i.e., MEXTPG is listed instead of NOMAP.  I don't understand how, the string
"MEXTPG" doesn't appear anywhere in the ifconfig sources, but I do see "NOM=
AP".

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Sep 19 16:59:18 2025
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 4cSzHp67ktz68H30
	for ; Fri, 19 Sep 2025 16:59:18 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSzHp55MKz4HBw
	for ; Fri, 19 Sep 2025 16:59:18 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758301158;
	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=mugrWt5hasT9r+fRx0wlw1JLlaTS46t9Hm05udb/hDI=;
	b=rVx0gVi+Qp8KFUsODciProA1aodzx8XRaoZb2aZ6Agg4To9Dm/kJdERr/QD/8sCnxQ+AH+
	Gar9eiNVTbKkQdoqdlu3tDN5BjR2vgxtFasVgDrYzBPYAd+y9E9Uq4dM0mRjs7faRxS10x
	QBUAtbuiqhSScdbPvKvrCVs6VzWqf+b/wPwRM3m/ROCHZ2qpx7eTx8VRDqZP2x+sFmRa1g
	EUiYwpD3ui6R0DwHXMY5Rcu4vcFNrd9MhiaYApNNGzaOryby4SXm8MG27DPG/97Faf4YQe
	+S0fdGUVZ6y2Q+4ZU1HnEKb5FvH7afNM2S/MTi1cHRO77ow6bPeX+fyMfFbMEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758301158;
	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=mugrWt5hasT9r+fRx0wlw1JLlaTS46t9Hm05udb/hDI=;
	b=v+lBZbBPMWRM0oQtcLZrphMYaYirf7AvTx2JuXG/fLY5piakBHXodt2uhoCUJRN6yeCluo
	iasISPJ/noAqSOR9fWIHDg4hF0Yej8L7gowTl4rF13e3mrOyTrJJWFBvVUMdD57uzh5xpC
	rKyTBnl49RMBUTW+xg+fUFY1dIEzr93huA+AP5lxeovds+Yz4lxnBGzMbFA09BDN9AJocH
	i/YbPRf8WB0Q7+f1ta2W3kfGl+TyDeD66M8D4YTLS1AkLdEKWwaaB98E3lxcaYM0Q/CdKI
	JObsgG1npQ+PI0HMulJFImGCD9FL9FWESKDpDfdXDvlsMf+yJ7Okxbn5b8WCcA==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758301158; a=rsa-sha256; cv=none;
	b=ccoTvBB7VREb1kq0HEp1kxYn0G5Vv0ubjI730nNg2m/offKumPVJgCAmcEu3N8IwdN8Mr7
	pACueuaU2S8mkHGki+1Vxem3zb2hH2L49ntUwIi2uuANrZDpWz56P8uDhSBptmnBahpI6q
	LI3pA+AY4BeQiD8HeZ/58MHkeck/Tc4/AqqKAAk0zTjRvXuxV/Blq8JdYwBboG45+OnfXw
	DbhMQojbRYI9HyFAPixXrtLK549ntUaTQmXnZIRSOz3RfxLHYkphlc1gMbYotVQEjmOYjD
	QFOp1Q+NA10x2zRvorZZVtUwgWenPLROsdznIsdcsTlYiIJ/3JPCeFdHx/RraA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cSzHp4hnXz15lx
	for ; Fri, 19 Sep 2025 16:59:18 +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 58JGxIji033823
	for ; Fri, 19 Sep 2025 16:59:18 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58JGxIXs033822
	for net@FreeBSD.org; Fri, 19 Sep 2025 16:59:18 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 289545] No option to disable NOMAP leads to network down/up
 with em0 when starting bridge.
Date: Fri, 19 Sep 2025 16:59:18 +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.5-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: markj@FreeBSD.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: 
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289545

--- Comment #8 from Mark Johnston  ---
ahh, this was implicitly fixed when ifconfig was converted to use netlink. =
 Now
the name comes from ifcap_bit_names in sys/net/if_strings.h.

So, I believe the problem now is "just fixed".  We should update the string=
 in
the non-netlink case too.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Sep 19 17:05:20 2025
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 4cSzQm6kCRz68H1H
	for ; Fri, 19 Sep 2025 17:05:20 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cSzQm65PPz4JNR
	for ; Fri, 19 Sep 2025 17:05:20 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758301520;
	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=blCLMSRq0rQRgrl6DcgzosM+2YPCU0fkF5YRHLeXupo=;
	b=KYndmjZFCEHr4nU9fOu3mNrOlc0s06T0pkA7K0c87ji7VAL0vqMVyhNcWpL7ZS1fEzXBN4
	Su95W/b/KPeLJYVIK6xbgFuJDeZaGJdHzKzFxgrEDBGoH1aXDzmM57LPzT5A00bgcUhpse
	LQOSwiGl1m71PcKcDmkKuHy1AcnHMfd83FSm/spk8Oh4egCC/pj07aigldt5IXEJ9/rSMo
	eGSoWBZL+kqlJ53WlOvswn2NTGCED2ZueLSJUbf1nfTMqVAAmwjPVVFXsdVAm+O0btn7k/
	uMUYX2fcf7FyqYmePu/t80h8teO6jVqHE7mGgEB2Xo2xySyuWtZlTwcTavgs6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758301520;
	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=blCLMSRq0rQRgrl6DcgzosM+2YPCU0fkF5YRHLeXupo=;
	b=dKtdjid/4mT4b1kX3rz9uP/+9a0Sy0Aa5C+eHwpNrRIBZbGS7UfJ6/CWj5jqcyRt0AaTtB
	Uq9a3ylisExLAFqgtrnTmHfkLB3CY4dqJWdvXkxvIEQthhKyriXEoEgaGZ/Dz5ptPY/En+
	mRw2zchtJrwNsIRskbHkmDk5fJo3Xhar4GVWeSBevXR5RWQYpmtdugC7YrELU8qLCBbOWz
	WPZzgD9Kva+opixZlTJ0nXKWh2T7AoStGNjIGz841S+ZNUlJVDTOJG+OaLPF7OBw14+3IQ
	2n/KgY9TL5EPVvYPgUg10BY5CXzNWlwFSH8KI4LAwu8bHxinrK98IeXMmIbcjQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758301520; a=rsa-sha256; cv=none;
	b=WLmHVnLFd66bC1v2bW04gxP3K+Dc1U5slGig4RvY5iZtGM35By66Mv4rE0Rsnu6P2PiPtx
	3Nu8dHn4aIxvUbiSvaEILe+8WJtfJOG6jIRYZc1qZ8hrcufljrfiIWK490Ct42TfnC0dAU
	HFWwZQiXtJpUWOOI0YDfQwZ91xYr3szCOZ7UpZ/AYthYQ2F+Y0BlLur+1zG1FbSCqM8vNI
	DaQITjO9KnaUVOak3DSTNGm6w8XyIF8156BFkKFlJxpho6Z15x+KAxfWOArTyC8UNq4Opz
	Mx34CllCKHj0vEf276B5kl/O6sQXEf5F7oiQxfVIyKFAYoQCnN1lRBMQCw3wTQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cSzQm5fJ2z15xF
	for ; Fri, 19 Sep 2025 17:05:20 +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 58JH5Kcd047496
	for ; Fri, 19 Sep 2025 17:05:20 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58JH5Klr047495
	for net@FreeBSD.org; Fri, 19 Sep 2025 17:05:20 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 289198] inet_net_pton is broken with AF_INET6
Date: Fri, 19 Sep 2025 17:05:20 +0000
X-Bugzilla-Reason: CC AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: 14.3-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: ivy@FreeBSD.org
X-Bugzilla-Status: Open
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: ivy@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_status component assigned_to cc
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289198

Lexi Winter  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open
          Component|kern                        |bin
           Assignee|net@FreeBSD.org             |ivy@FreeBSD.org
                 CC|                            |net@FreeBSD.org

--=20
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.=

From nobody Fri Sep 19 17:37:52 2025
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 4cT08K12QQz68KT1
	for ; Fri, 19 Sep 2025 17:37:53 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cT08K05lBz4NB6
	for ; Fri, 19 Sep 2025 17:37:53 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758303473;
	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=uOtN2oDEZ1TxoH4Mbca3MctOtfxUDcEqOakjxtDzmdU=;
	b=BeRLTB8p8SJY3DQ09E3Am293gImC9jlARLICEHDiLKfsOC+KXRJE7lbkaOKWlY/9b4auzM
	6WyQg30oGnoWv11ZSxIKoLqdqGjp2wBgJ1X6uSXgy/Hrj4IG7pdZ8TXQJY/eEWuujl8Lph
	5KkgNrS9ngCgEyKA6JilWL01qk6JDoSwaJvJ4h8qFkaqmxpmpklWr5Rzi1qtx6TiHRg3vK
	z5kh11+ZTBvS71ULfOVV+Ooa++ijeJrk+5U2EuYXcXlgbyDXJoT1dHqm9PIMwfbgmvUY8g
	Lbp60iTmtbThIJO0/9uxURp4IrwS3MFNcmAWmfubdBhFqWqu3ZNZcsvgDb5Rdw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758303473;
	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=uOtN2oDEZ1TxoH4Mbca3MctOtfxUDcEqOakjxtDzmdU=;
	b=n3bRL2WzEy1aX1d8rtY+nu3fMwr/oowV7g/+xTIAP0hvf+eEpAMIrRA4YdOHM42nS1T1PZ
	pZVDSc+W8jzr3vlFx54kL+IH4t7ssF/yPRf0DuKKwIuU8OBS4f5E8XOEoURCpEZ+bDbaNd
	pT0cVWfgtvKY+DblJ6MpAbIVW1qB+pfNQNiPMB5LfrHKmZqUK23u8bAkMM8Ti3OQ4oAvEg
	h0QVayW5hXP/jN00wAvWcTOKswppE8YSduPAYDlXc5Y6S5d7K8C3NfIktFWCb3ofO2HoKc
	vYwUkr5/Wn4/j0niUG3a7HTtradlH5w8ML5to30oUcOLPl0vE3E9VsJ5LXnE+Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758303473; a=rsa-sha256; cv=none;
	b=qnqJEAEeWSQrLQEkXJzHPNm5JeWU609YUS21+fEk2s+zJVtLeU6tDtiNO0m+1wUvVOL6VI
	lLTSZbmpGokgAmjINIpXJ6OwLJmwsHNzbLPCENpeww8872A5jnaFv76YaV7zkMr7VOesXi
	Q+1SX+1GEyS0RTOMwrJMDdt4t+5gxMzYWQjfXxUbw9Cs+fozGKYZYVMP4ag8OpxP9cY5GS
	NllxBjsjG7bOzDZUx31Nzb5tYg5feHdMm2LXjUHOT+wjxIr080LqA1Umx7jGkMagnFHMHo
	/fhzEUXTvaT8tQTS02XggI12uZzeUSiPD3IZyqcXeTpsQCM1SewE5YI3+XREww==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cT08J6VYKz16cZ
	for ; Fri, 19 Sep 2025 17:37: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 58JHbqrU091773
	for ; Fri, 19 Sep 2025 17:37:52 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58JHbqY8091772
	for net@FreeBSD.org; Fri, 19 Sep 2025 17:37:52 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 289545] No option to disable NOMAP leads to network down/up
 with em0 when starting bridge.
Date: Fri, 19 Sep 2025 17:37:52 +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.5-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some People
X-Bugzilla-Who: zlei@FreeBSD.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: 
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289545

--- Comment #9 from Zhenlei Huang  ---
(In reply to Mark Johnston from comment #7)
The reporter is on FreeBSD 13.5 .

The IFCAP_NOMAP was introduced by John via commit
https://cgit.freebsd.org/src/commit/?id=3D82334850ea451f7f6903be20e4836118e=
6a77460
, and later it was refactored by Gleb, and converted to IFCAP_MEXTPG via co=
mmit
https://cgit.freebsd.org/src/commit/?id=3D3f43ada98c89bce5ae416e203ba0e8159=
5a5cd88
. The commit was MFCed to stable/13 and is in releng/13.5 .

It appears the refactoring is not complete. The `\33NOMAP` in ifconfig.c was
left unchanged. I think that should be converted to `\33MEXTPG` ( for stabl=
e/13
) . CC @Gleb .

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Sep 19 19:00:05 2025
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 4cT1z92QK2z68QRW
	for ; Fri, 19 Sep 2025 19:00:05 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cT1z91rqJz3GCl
	for ; Fri, 19 Sep 2025 19:00:05 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758308405;
	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=mocJQqNkmEezoo6LsHMw38p4XyIa0fSXw3birI8kWFc=;
	b=dCqIclF+slOYKuPS0x+Oj187ayOWKuklM7674dnJf61QhSQcsNmA8KwlA0hgMrKs6FDjCJ
	/jpdBpHMB9yeZpKBdUVObvjXSRRZkzRTOqMMZOuq78J0CUPf/0k3rq9JFpV+7DhRx7QnEE
	SSuyXgYvQdp5Zij2NF3lmnEUSRlI7Bx77zzbdl63ZPhAhWRBKI7QsfBGzWi9sL8+vSb90+
	hv1xv3mkXuM5Qvpk5X4a9ZERxeY1fi7LYBtmkqzSoz7JRFyTfHBB8Bq6VipoJRfjnB2252
	78TUjOplKykmsWBVsvdmF/yJVDXg2VdAkAGjRA7VPCcZfFitMnJFq/HekZhitw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758308405;
	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=mocJQqNkmEezoo6LsHMw38p4XyIa0fSXw3birI8kWFc=;
	b=OhJxsuzoda+KKxyLgqc4/ysriPo4/h/KwigtoYxyaOYs5C7fFFdG2aHvskOGYJtXpydTjJ
	G29vejy+yyF7Vi0gmk9oOLRSc8InZodDevjFSeXH4vcKPyPCqGzD1tbDckrWMhTvXXDkZV
	WOS2tLF1jNoCQzLv2RPamyHrd1/po9Pm2+I6TrxTMeXaQkZdj3HzEs7FGz/voyCTrPeQiQ
	Zsoh/73OaY44lpErdBuB6aPtpDfhHTQipncImsHp0XBKmxIPLwOnULP3ATTf9MHEMRrDeh
	0VSYKjHnZ1KRx4jpCBkaC5TQ1Hr5+CY1onxIHlYB38QD0O0zXngdVoC5WCW49Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758308405; a=rsa-sha256; cv=none;
	b=TqvKM96+RM+wV8xQSEl+7CILUMQi9eq1k5bRKWusBY7zWzspowUT1g7X+H9YToJLQriyI0
	NffnzX33IuEWxh4uNchBJW4xqhycWHcttvPUc/looy9Bx8qc2/hTM2KBi8kwTgYGZ4Dhi/
	7onIWI6uyl9r5p5ZFrFwZXMEJmh9hhLcuK7eZc5BoJ747Q/AJQKFupnqmBCsg8YnO6clPX
	GQ2wW3bXgfByErkHgEG4FK0ubKKR2Bng5F+zO8OdS/u1NouPqOs0rZi1VFhwmfSAD+bvqC
	uShBI91kePykXMl3ZHDgK8cJaK3uG+KoUMK2L5gWEy5xdpEkTOYw+NJ+hfeLdw==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cT1z91MBgz18Ph
	for ; Fri, 19 Sep 2025 19:00:05 +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 58JJ05uT017361
	for ; Fri, 19 Sep 2025 19:00:05 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58JJ05QW017355
	for net@FreeBSD.org; Fri, 19 Sep 2025 19:00:05 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 289198] inet_net_pton is broken with AF_INET6
Date: Fri, 19 Sep 2025 19:00:05 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: 14.3-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: paul@redbarn.org
X-Bugzilla-Status: Open
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: ivy@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289198

paul vixie  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paul@redbarn.org

--- Comment #1 from paul vixie  ---
openbsd's upstream is:

https://iso.netbsd.org/pub/pkgsrc/current/pkgsrc/net/libbind/index.html

i plan to pull this into github since my own sources are far newer.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=

From nobody Fri Sep 19 19:01:26 2025
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 4cT20k2HKcz68QX2
	for ; Fri, 19 Sep 2025 19:01:26 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cT20k1hkyz3GhG
	for ; Fri, 19 Sep 2025 19:01:26 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758308486;
	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=GC7bfnUlp3AQwankC6JYZO/qK4Jld0IupdnyBajUD+c=;
	b=f5K3OeEr0nKweMvKGcSpMzujUbD5JwaGSw1OA8wkkx4yw4e1rmIm5jaK6aOzIL46CaTqqR
	lEo/EsKYTaj5+e918BuDNe0HCGU8ZbSBAjTVzWAlCFEFbxTXa1sVBwj0j6MIj+2qX0a/H/
	E6U3s1620PRgUePv/o0Yb1yb2EPearb3RpAl9XNwGuVwFHmeRGg0XrKAd24Zqj/FmI7lSd
	QkYL3p/qcZen3jHx7n/VzfFk19Iv5U2yiOvyAnLwsSyfakDtM2IwK2y52/wA9toxJ2X2C3
	IouWMPiyzbwZ0Lv/nayXDLIip+3Wz3anLzM6LBee/aACh3TR8wdxbPDq19Aheg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758308486;
	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=GC7bfnUlp3AQwankC6JYZO/qK4Jld0IupdnyBajUD+c=;
	b=oeIKS7wXSDklGlqcQoT5wcZxBYqoW2d+1JDq/9VVCa5LQXsHOH1Hf7BDBDNtnHe/pn662h
	/XMRKUVkBk+h9IQUVWgXIzXUaEn35JO4xG9FZlEZrbjPcPc+QIO5/0t4wwgyJWzOuRKRZz
	j5CQXfN2PJVcHwOSsvEUJSrqBDBWstsGPnw+nZ2Nss8dKXxU4dzxgLi5jlzRsk2QhprHP8
	Wvr78FLo968l3DvV7gSjuO5OhAwBFjLoNtxk+FIsflLw7UJMFkQgY4CUYj3N8kvkwzQvME
	gJyFNXPd99ki4uoKDw/PA25nZoDz5S/Hxf/chdu35HxsJfdkTN3P2BgOcQ5FZQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758308486; a=rsa-sha256; cv=none;
	b=ZeMYI+bXcnyke7wJJCuLlUv+Y8UprwjoObzdplTfYjZjOvreTqZCHeGn9G22zPVGslDQk9
	O5dVA13E4njqF3OGmpROwjOoGFo6gI+LlYhVGEMK5pdEFRMDGhBbiUniMVzuYzRNfUECTy
	Qgmzk3Qsyc0eiSmyF3ltOzQdf6G0C0r2hYjZY3fKPch2zdUz48WXIPUTjC8ysiu0oyKa0P
	ZtL0H1DiOytuFeNymJz1qY6g16fs2JlF02rtzMexN49mlxpE35E1Djb0CLEIVhJWNlcfbj
	BPjURVOuUSUbV4iOGdOzt2Q/io58wMt8RpU7Pc6GS+h1WgvGeJ1y0OVACUYW8g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cT20k1FWRz18KG
	for ; Fri, 19 Sep 2025 19:01:26 +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 58JJ1Qvc023311
	for ; Fri, 19 Sep 2025 19:01:26 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58JJ1Qm9023310
	for net@FreeBSD.org; Fri, 19 Sep 2025 19:01:26 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 289198] inet_net_pton is broken with AF_INET6
Date: Fri, 19 Sep 2025 19:01:26 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: 14.3-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: ivy@FreeBSD.org
X-Bugzilla-Status: In Progress
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: ivy@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_status
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289198

Lexi Winter  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Open                        |In Progress

--- Comment #2 from Lexi Winter  ---
i was planning to pull this from libbind, but that was abandoned years ago =
and
OpenBSD's version has newer fixes.

however des@ identified at least one bug in the OpenBSD version, so we'll s=
ee.

in the mean time i am writing a test case.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=

From nobody Fri Sep 19 19:13:45 2025
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 4cT2H14Tdyz67SF6
	for ; Fri, 19 Sep 2025 19:13:49 +0000 (UTC)
	(envelope-from avg@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 "R13" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cT2H13Xq4z3Hvv
	for ; Fri, 19 Sep 2025 19:13:49 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758309229;
	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:autocrypt:autocrypt;
	bh=xeF5+1OgJRhLVcGohe/6DnWm7Ja4Pgjfum8zir0SySc=;
	b=HgDuZpEaKXrkfcH0sO1rZjWnAk0azpqFB3rz1z+NqYUbOE8J8RaXOf3IPNEgdHev0CQwFp
	qyY76MCZR4hYAx9dQUIPP3zcDW3jO9hMTxpPU+bcDO3tCN3jDp1IGdHHzcJ9D1puBrKEfa
	v6WXxRFxAq28wYCGmveq8c3OoyaFQIvqQAfJHXIZF1Zsuml2HdGL/jXRdBGHd4OsPKEM2F
	sQwng/LC14ifSO2nviJQOFWr/bckfxt9WXgkr6r7zFx6HZHq0nociEqwk+H26ErawxAhDy
	i26vQF7wZnCBS97khyUqiTj6xhvFzUjGWxHsXGO/8woKWu2GsTge/UPGdlmJVw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758309229;
	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:autocrypt:autocrypt;
	bh=xeF5+1OgJRhLVcGohe/6DnWm7Ja4Pgjfum8zir0SySc=;
	b=uPLvxIsHUorh4SetzEjuiekTZ9vI8OmWU8keCw8Nwg7eP7LvIdz5sbI3iQmOMX7Dd1dPkI
	ZrvXwFwmkXzqiM+ErXlaJ4HbHWWKCQmD+738eH2O8bqs8vOXRaorenR+SZLjl7QjFd/UuP
	B1MlFC6zbsaSn5P9iJNYSXitolvUs4/FXaVMIrvC6VjYAg6ZB6FaD3a2kiW2HKbucMmg+y
	xWk6kRy2tAHQNmnGkMdpiISh+mkcw5favJ5V1CvZcKj3+FXuHS+FJ+YRkBLCahKVx6j/C7
	vfjYngU8cPPK+tNDK+SXIvxxzp+B9X8hphMsZF7wHN71/FbbqqffYM+MR5xfSg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758309229; a=rsa-sha256; cv=none;
	b=lDjtBMVjhuMMOTR6GQ41l0Wv5r8ohAL1bdGjXIzkT1oKiKXiqW3RbpmtMMpsBXgMhkxexT
	Q8sNAZnopfuuJIWzCPSUFFQSjFTbCb3J4viLP+52nDSsoUYm9IdVIvyP0R+8R1iZYUHzeF
	a+WQZzrLurd/0dVpY/oH5WYf5Y9MKlcFrsDrD6905WST+EP4R7ITyG1ZsSQIe+yYg9H0ov
	iSQQs4x41bioSk0Rcn3Z28e4xZIzFU5ZF49t5FZUIEL1zI8CcHJMbmVqx8Sy1fuD1riJ4v
	6znPW35VjvNgQJm7/SImT75n1JUE3CegibUqYRI+Q1eaXmKCOCB1TX3Wi37FrQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
Received: from [192.168.0.88] (unknown [93.188.39.137])
	(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 did not present a certificate)
	(Authenticated sender: avg/mail)
	by smtp.freebsd.org (Postfix) with ESMTPSA id 4cT2H111Wnz71Z
	for ; Fri, 19 Sep 2025 19:13:48 +0000 (UTC)
	(envelope-from avg@FreeBSD.org)
Message-ID: <6abe9da1-9818-438b-ad8f-5424e50a39ce@FreeBSD.org>
Date: Fri, 19 Sep 2025 22:13:45 +0300
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
Content-Language: en-US
To: "net@FreeBSD.org" 
From: Andriy Gapon 
Subject: DHCP on multi-homed host, some thoughts
Autocrypt: addr=avg@FreeBSD.org; keydata=
 xsDNBGcKrHEBDADRvwQOK0b/yo4ys5cs6bOQMhEh4xtfbaZ/CU00cpPgUip3sOZCdrtMWlRC
 g25z97prxE9pKueZi+HXDhIPpa9xl14ghqF4oYScuJ1i18HyiOH2y5Q3Vv/TtFiSzicd3EAu
 QgS3jVidpgDSPDdj2Yz3UxYpZ+PuFl6nOnvCvqOFcjUlzKCyPaiN2b86l1Nscmhnc+zQ/faB
 erUOEFEDQbWMA5YfXi8HrbeR16hfRfGt7E0aMDlIj9FIPIq71UWMN9CimPgs4+rbNr1MAlLa
 z4GxSDhVYZEY5rqtCzr+PLXboRQWnaUwXl0/biw9enf17NHdYv1SNAFTX2eC4dZ3qBVI74dS
 PgNprm+PMfz+6Hhs/dAv+Nan5nVhg3EFIjYTiy0MnjMSq8uI0v0ykpAGAcJJ5xl6d23aLxgN
 6f0z6pJRCO0hGPgU7UzvFD0MxJxmbzqdT1R51KDan1oD41b+tjl2LMBuCDCoB0U44Pu0zLdp
 xMfFTxCXtwIYKIUxwd28jwMAEQEAAc0eQW5kcml5IEdhcG9uIDxhdmdARnJlZUJTRC5vcmc+
 wsENBBMBCAA3FiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHEFCQeEzgACGwMECwkIBwUV
 CAkKCwUWAgMBAAAKCRDMM63k0uPru5tSDACFK15LLbq89RSQ6QMnjiIm1t/wYJyumb519MHu
 Dhzxx1lbr8oghf0RHtF6kYRLQPaW2VdToi74pRobd3CN4bhZKDLSL6WfTn17RfavDjL6Njwp
 KBo30CkOeYKWq1mDmo0xEoQj8cc7ybEZnus+YScZOpj8Ti4EFwhRt6SHer7YDb161IHKL8m4
 MsCxpFSGEjbKj8Iul3Ri/fTOO8w14ivcuEEQIvJt4/+4YV5Az8G23wKzL/3aJ7SOT3oYGmR9
 atBTmVO3DlODjM+rZLegd8SfLSPTcBTHspWE5duemIzZbEX3BP77r3Qx4Fo5Tkit3bG1XVar
 yPQato+sFGFEGifdE9USBQoAoOaaeZevwAWjDU0TIuCT0CUe0sKtQuNP4LRq0n9EEHOXBu9a
 CfdMhFUSkAZnuE7miSVwgPvoVNJ1stA37EXLN/sVsWik7wslTQ5vF81VpdGFiwoQPOe2XEKh
 ogcwGSnXbwv1gD4x+Gz/7Y+kFyr1NY+4/nSaeXVcS2fOwM0EZwqscgEMAMQTe6ypAmQe/TFO
 HqKD2hfFKdksTptKi6uEh8xIwct8G/0FBldDWXo9eu8CGr/ZrDg0/bAwJxbaLRQCMH19Gq2Y
 hLvZ1QK5GQJVzZKcqfxbF2LiDUTs6WkdOBIhGpdDy7p1xFrvqCGCtNFYHuGYm067EozibBSF
 BWAPstKu2FQuVHZNMOfs7p3OIz3Yfqu9woXDeg3/8G2qVQJINe+8EwXKlhgh4CyDbq7nAZoA
 kIu1SE9z9u3WI5mcNy/0dFmVUsFxBqRC3ewbvzie8tKyZ9yFOlaZPT0Y4nRBXQTI3mLZ8zQ8
 mtrWK5OOmrJ02kdeO9RBXe+OMaUUWMf92ZIoBFb4HP6N+B+4N1y1OwULousfl7JRoYxA4MRL
 ls7E2sSoJvrEBTJB3Pc34xu8rsJ1A5V3NgN6djX8yEZYpTRkcmrBeWy/ofDqZPVqneAx0LRm
 eldDS9msXDW4KXODyPZ+9unvmHAcoH0xaBYaSH44CDZDQDg4LNcmbOvuu1TEXBJhjQARAQAB
 wsD8BBgBCAAmFiEEmXvSmjiQFHPVOpLnzDOt5NLj67sFAmcKrHMFCQeEzgACGwwACgkQzDOt
 5NLj67sUCAv5AXqgWnYN9EblapMbZjkiqL8pZQ0GNqh+Pg9FwbyULxjtRTO6rD4D0IxizByb
 ef+neeUNyYlagt5nfKMysEr0SU/gHKCi8vyTF/63ukMrGUNGmJJxrndl5ZYKC6j6eX7twrZF
 L1Uvlmn6FnQ22red5kHO93fDjG4zaDIZvHfwj7kzjZ4tpC7Byinf88s14mdZeScc0PnU2hj4
 UGYju/wg2FF4YxaZYhcmdTiRYY0Wx85XSMZv19pnn78sadEuRvfRd4JTmw++j1xGXeqQGWzz
 /CTG5/Ex9GAkQ02hZbmi236byDXoet4G8TEyOph9QFVkV9bNd0jQZaFZPGEj4PSPUYGAF7s5
 xJaNGgctC3aZ7WjEv1FBoo44XCU4xcjJ1wZQUrHxRhx6TW0Jtcl0U9qfKFW30TSPo6RyiXuj
 X4ltWKAtjoXB8nUmEJckaz7IRu2b4pXDeazZuz5JBygUs10yJjDxh2vFQZo0KaBAPx9MZlPn
 gpPTjT15L8xGftEjQXF6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



Admittedly not a very common configuration, but still possible and some people 
have it (according to the Internet).  I am also trying to set up such a 
configuration for "reasons".

In the simplest form, there are two network interfaces connected to two 
different networks.  Each network has its own DHCP server, its own router / 
gateway to the wider Internet, its own DNS server(s), etc.  The networks are 
likely to be completely unaware of each other.

The host itself may be a router providing internet access to another local 
network via another interface (or even multiple networks + interfaces).  But 
that's not important.

Some things provided via DHCP are per interface, but others are per host 
("global").  Each interface can get its own IP address, that's fine.
But, for example, which gateway to select for the default route?

Dealing with those "global" things is the main issue in such a setup.

What do we have now?
Specifically, with dhclient that's a part of the base.

Essentially, it has a winner takes it all approach.
That's implemented in the default dhclient-script and the gist of the logic is 
in is_default_interface() function.  Whichever interface is first to get a lease 
with a router wins.  dhclient-script would set the default route to the router 
and as long as the default route goes through the interface, the interface 
remains the winner (for subsequent updates).

So, the winner gets to set the default route.
The winner also gets to set the resolver configuration (using resolvconf(8), by 
default).
Losers can only configure their interface, other information is lost.

If DHCP is simply configured for multiple interfaces via rc.conf, without any 
extra settings, then there is an obvious problem.  A winner would depend on 
random things like which interface gets link first, which DHCP sever is more 
responsive, etc.  And a random winner is not always what is desired.

As far as I know, there is no way to set any priority or anything like that.
I found only two solutions used by other people, both not ideal.

One solution is to start dhclient-s "manually" (i.e., outside of rc.conf 
declarative configuration) via something like rc.local.  This way we can control 
which interface gets configured first.

The other approach is to create a dhclient.conf configuration for the 
"secondary" interface(s) which would ignore the "global" options (routers, name 
servers, etc).  This way the "primary" interface would be the only one that gets 
and sets the global configuration while all interfaces get their individual IP 
configuration.

The latter approach is "less intrusive" (more declarative), but it has a flaw 
that if the selected primary network is down then there would be no default 
route at all.

Both solutions still have the issue of discarding the global options from the 
secondary interface (either explicitly in dhclient.conf or by dhclient-script's 
strategy).  And those options may come handy if we want to dynamically flip (and 
as seamlessly as possible) between interfaces based on some events / criteria.

It's especially interesting that dhclient uses the power of resolvconf(8) 
(unless forced to update /etc/resolv.conf directly) but still takes only the 
winner's configuration.
I think that it could just add configurations from all interfaces and let 
resolvconf(8) deal with that.  And an administrator would have control over how 
multiple configurations are merged via resolvconf.conf.  Especially, if a local 
resolver (like unbound, for instance) is used.  E.g., it would be possible to 
use different name servers based on domain, etc.

Regarding routing, these days we can have multiple FIBs, so instead of 
discarding "secondary" routing information we could use it to configure a 
non-default FIB.

Initially, I wanted to start working on some changes to dhclient-script to 
implement those ideas.  But then it occurred to me that it would easier to get 
what I want by changes external to dhclient.

If there was a way to run a secondary dhclient with a non-default FIB (e.g., via 
setfib) then that alone would achieve the goals:
- the secondary dhclient would be considered a winner because it's the only one 
to set the default route of the FIB;
- so, it would obviously set the default route in the FIB;
- and because the dhclient is considered a winner, it would also call resolvconf.

I wonder if it would be a good idea to run dhclient under setfib if an interface 
is configured with DHCP/DHCPSYNC "virtual" option and real ifconfig 'fib' option.
Or would that clash with some other uses / intentions?
Then maybe we could add another virtual option like FIB or DHCPFIB?
Or, probably even better, some thing like dhclient_fib_IF=X?
Akin to background_dhclient, for example.

The standard dhclient_fib option is, obviously, of no use because it would put 
all dhclient-s into the same FIB.

-- 
Andriy Gapon


From nobody Fri Sep 19 19:19:08 2025
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 4cT2PH08Tcz67SM9
	for ; Fri, 19 Sep 2025 19:19:15 +0000 (UTC)
	(envelope-from roy@marples.name)
Received: from sender2-of-o59.zoho.eu (sender2-of-o59.zoho.eu [136.143.171.59])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4cT2PG339jz3Jl1
	for ; Fri, 19 Sep 2025 19:19:14 +0000 (UTC)
	(envelope-from roy@marples.name)
Authentication-Results: mx1.freebsd.org;
	none
ARC-Seal: i=1; a=rsa-sha256; t=1758309548; cv=none; 
	d=zohomail.eu; s=zohoarc; 
	b=j89phmjsN/MakwWzNpWQZe9mUqOpUbN82xxKsOxm1kE8HdHwTLbr8NiuXZm6/WUJPxALdeXaDXw8CQPNRLrSfSuERqVidGY2o5+vFvNxATK0Ny0cVmUHyQUBq89RN5OP42efhMyTSykm0Ml7HJ9IquUbPBu8p088nTqdYE7Cvu8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; 
	t=1758309548; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; 
	bh=8JMxOiX3mLwMKi2KRBjuYQ3R7lDd+nUHZzfaRcfZ6N8=; 
	b=a3Oc6LMYQP43GU8/MqBwZynPuVcKp3BtchruE2Gjoh17sT/5gnThaDv/Za7BW72KEY8tWxPix/ZfcmFhi3VWJnL58ZALan7V7zomoCbkeOM8NnGV9JRzxs2yJ3pVhmqbj5NQ3WJzzUeTh/hzwsHTf93PFvRER5xomEEYpW0j1Ig=
ARC-Authentication-Results: i=1; mx.zohomail.eu;
	dkim=pass  header.i=marples.name;
	spf=pass  smtp.mailfrom=roy@marples.name;
	dmarc=pass header.from=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1758309548;
	s=zmail; d=marples.name; i=roy@marples.name;
	h=Date:Date:From:From:To:To:Cc:Cc:Message-Id:Message-Id:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Reply-To;
	bh=8JMxOiX3mLwMKi2KRBjuYQ3R7lDd+nUHZzfaRcfZ6N8=;
	b=N8u7GaVx2ovVcf6GxqS70PxFfWJOYJw+dfWaKjoSE+ucYSSm+vdQp0zpl/KgF+7H
	uv9ZFN5Yg+/6UmKQcjs4Y/WbzexAqCb8sFgmlkYkLkAltiZKXQ5Q/wEertFYHRuDZXv
	lnFTCvPmBqU+7Xvc3MKgngHPb4QZFHv9DRaAjqxs=
Received: from mail.zoho.eu by mx.zoho.eu
	with SMTP id 1758309548024780.3711491056715; Fri, 19 Sep 2025 21:19:08 +0200 (CEST)
Date: Fri, 19 Sep 2025 20:19:08 +0100
From: Roy Marples 
To: 
Cc: 
Message-Id: <199636a7ff7.6b695ed1462688.6190907331232783668@marples.name>
In-Reply-To: <6abe9da1-9818-438b-ad8f-5424e50a39ce@FreeBSD.org>
References: <6abe9da1-9818-438b-ad8f-5424e50a39ce@FreeBSD.org>
Subject: Re: DHCP on multi-homed host, some thoughts
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="----=_Part_3927069_1112315404.1758309548023"
Importance: medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:41913, ipnet:136.143.170.0/23, country:CH]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cT2PG339jz3Jl1

------=_Part_3927069_1112315404.1758309548023
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

You could look into using dhcpcd from ports which solved this multihome issue years ago.


Each interface automatically get a metric based on type and index. This is override able, lowest wins.
For any competing setup, lowest takes precedence and seamlessly changes when the interface goes down or loses a lease.



Roy






---- On Fri, 19 Sep 2025 20:13:45 +0100 Andriy Gapon  wrote ----





Admittedly not a very common configuration, but still possible and some people 
have it (according to the Internet).  I am also trying to set up such a 
configuration for "reasons". 
 
In the simplest form, there are two network interfaces connected to two 
different networks.  Each network has its own DHCP server, its own router / 
gateway to the wider Internet, its own DNS server(s), etc.  The networks are 
likely to be completely unaware of each other. 
 
The host itself may be a router providing internet access to another local 
network via another interface (or even multiple networks + interfaces).  But 
that's not important. 
 
Some things provided via DHCP are per interface, but others are per host 
("global").  Each interface can get its own IP address, that's fine. 
But, for example, which gateway to select for the default route? 
 
Dealing with those "global" things is the main issue in such a setup. 
 
What do we have now? 
Specifically, with dhclient that's a part of the base. 
 
Essentially, it has a winner takes it all approach. 
That's implemented in the default dhclient-script and the gist of the logic is 
in is_default_interface() function.  Whichever interface is first to get a lease 
with a router wins.  dhclient-script would set the default route to the router 
and as long as the default route goes through the interface, the interface 
remains the winner (for subsequent updates). 
 
So, the winner gets to set the default route. 
The winner also gets to set the resolver configuration (using resolvconf(8), by 
default). 
Losers can only configure their interface, other information is lost. 
 
If DHCP is simply configured for multiple interfaces via rc.conf, without any 
extra settings, then there is an obvious problem.  A winner would depend on 
random things like which interface gets link first, which DHCP sever is more 
responsive, etc.  And a random winner is not always what is desired. 
 
As far as I know, there is no way to set any priority or anything like that. 
I found only two solutions used by other people, both not ideal. 
 
One solution is to start dhclient-s "manually" (i.e., outside of rc.conf 
declarative configuration) via something like rc.local.  This way we can control 
which interface gets configured first. 
 
The other approach is to create a dhclient.conf configuration for the 
"secondary" interface(s) which would ignore the "global" options (routers, name 
servers, etc).  This way the "primary" interface would be the only one that gets 
and sets the global configuration while all interfaces get their individual IP 
configuration. 
 
The latter approach is "less intrusive" (more declarative), but it has a flaw 
that if the selected primary network is down then there would be no default 
route at all. 
 
Both solutions still have the issue of discarding the global options from the 
secondary interface (either explicitly in dhclient.conf or by dhclient-script's 
strategy).  And those options may come handy if we want to dynamically flip (and 
as seamlessly as possible) between interfaces based on some events / criteria. 
 
It's especially interesting that dhclient uses the power of resolvconf(8) 
(unless forced to update /etc/resolv.conf directly) but still takes only the 
winner's configuration. 
I think that it could just add configurations from all interfaces and let 
resolvconf(8) deal with that.  And an administrator would have control over how 
multiple configurations are merged via resolvconf.conf.  Especially, if a local 
resolver (like unbound, for instance) is used.  E.g., it would be possible to 
use different name servers based on domain, etc. 
 
Regarding routing, these days we can have multiple FIBs, so instead of 
discarding "secondary" routing information we could use it to configure a 
non-default FIB. 
 
Initially, I wanted to start working on some changes to dhclient-script to 
implement those ideas.  But then it occurred to me that it would easier to get 
what I want by changes external to dhclient. 
 
If there was a way to run a secondary dhclient with a non-default FIB (e.g., via 
setfib) then that alone would achieve the goals: 
- the secondary dhclient would be considered a winner because it's the only one 
to set the default route of the FIB; 
- so, it would obviously set the default route in the FIB; 
- and because the dhclient is considered a winner, it would also call resolvconf. 
 
I wonder if it would be a good idea to run dhclient under setfib if an interface 
is configured with DHCP/DHCPSYNC "virtual" option and real ifconfig 'fib' option. 
Or would that clash with some other uses / intentions? 
Then maybe we could add another virtual option like FIB or DHCPFIB? 
Or, probably even better, some thing like dhclient_fib_IF=X? 
Akin to background_dhclient, for example. 
 
The standard dhclient_fib option is, obviously, of no use because it would put 
all dhclient-s into the same FIB. 
 
-- 
Andriy Gapon
------=_Part_3927069_1112315404.1758309548023
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=

You c=
ould look into using dhcpcd from ports which solved this multihome issue ye=
ars ago.

Each interface automatically get a metric=
 based on type and index. This is override able, lowest wins.
For=
 any competing setup, lowest takes precedence and seamlessly changes when t=
he interface goes down or loses a lease.

Roy


---- On Fri, 19 S=
ep 2025 20:13:45 +0100 Andriy Gapon <avg@FreeBSD.org> wrote --=
--


Admittedly not a very common configuration, but still possible and some p=
eople 
have it (according to the Internet).  I am also trying to set up =
such a 
configuration for "reasons". 
 
In the simplest form, ther=
e are two network interfaces connected to two 
different networks.  Each=
 network has its own DHCP server, its own router / 
gateway to the wider=
 Internet, its own DNS server(s), etc.  The networks are 
likely to be c=
ompletely unaware of each other. 
 
The host itself may be a router p=
roviding internet access to another local 
network via another interface=
 (or even multiple networks + interfaces).  But 
that's not important. <=
br> 
Some things provided via DHCP are per interface, but others are per=
 host 
("global").  Each interface can get its own IP address, that's fi=
ne. 
But, for example, which gateway to select for the default route?  
Dealing with those "global" things is the main issue in such a setup=
. 
 
What do we have now? 
Specifically, with dhclient that's a pa=
rt of the base. 
 
Essentially, it has a winner takes it all approach=
. 
That's implemented in the default dhclient-script and the gist of the=
 logic is 
in is_default_interface() function.  Whichever interface is f=
irst to get a lease 
with a router wins.  dhclient-script would set the =
default route to the router 
and as long as the default route goes throu=
gh the interface, the interface 
remains the winner (for subsequent upda=
tes). 
 
So, the winner gets to set the default route. 
The winner=
 also gets to set the resolver configuration (using resolvconf(8), by 
d=
efault). 
Losers can only configure their interface, other information i=
s lost. 
 
If DHCP is simply configured for multiple interfaces via r=
c.conf, without any 
extra settings, then there is an obvious problem.  =
A winner would depend on 
random things like which interface gets link f=
irst, which DHCP sever is more 
responsive, etc.  And a random winner is=
 not always what is desired. 
 
As far as I know, there is no way to =
set any priority or anything like that. 
I found only two solutions used=
 by other people, both not ideal. 
 
One solution is to start dhclien=
t-s "manually" (i.e., outside of rc.conf 
declarative configuration) via=
 something like rc.local.  This way we can control 
which interface gets=
 configured first. 
 
The other approach is to create a dhclient.conf=
 configuration for the 
"secondary" interface(s) which would ignore the =
"global" options (routers, name 
servers, etc).  This way the "primary" =
interface would be the only one that gets 
and sets the global configura=
tion while all interfaces get their individual IP 
configuration. 
 <=
br>The latter approach is "less intrusive" (more declarative), but it has a=
 flaw 
that if the selected primary network is down then there would be =
no default 
route at all. 
 
Both solutions still have the issue o=
f discarding the global options from the 
secondary interface (either ex=
plicitly in dhclient.conf or by dhclient-script's 
strategy).  And those=
 options may come handy if we want to dynamically flip (and 
as seamless=
ly as possible) between interfaces based on some events / criteria. 
 It's especially interesting that dhclient uses the power of resolvconf(8)=
 
(unless forced to update /etc/resolv.conf directly) but still takes on=
ly the 
winner's configuration. 
I think that it could just add confi=
gurations from all interfaces and let 
resolvconf(8) deal with that.  An=
d an administrator would have control over how 
multiple configurations =
are merged via resolvconf.conf.  Especially, if a local 
resolver (like =
unbound, for instance) is used.  E.g., it would be possible to 
use diff=
erent name servers based on domain, etc. 
 
Regarding routing, these =
days we can have multiple FIBs, so instead of 
discarding "secondary" ro=
uting information we could use it to configure a 
non-default FIB. 
 =

Initially, I wanted to start working on some changes to dhclient-script=
 to 
implement those ideas.  But then it occurred to me that it would ea=
sier to get 
what I want by changes external to dhclient. 
 
If th=
ere was a way to run a secondary dhclient with a non-default FIB (e.g., via=
 
setfib) then that alone would achieve the goals: 
- the secondary d=
hclient would be considered a winner because it's the only one 
to set t=
he default route of the FIB; 
- so, it would obviously set the default r=
oute in the FIB; 
- and because the dhclient is considered a winner, it =
would also call resolvconf. 
 
I wonder if it would be a good idea to=
 run dhclient under setfib if an interface 
is configured with DHCP/DHCP=
SYNC "virtual" option and real ifconfig 'fib' option. 
Or would that cla=
sh with some other uses / intentions? 
Then maybe we could add another v=
irtual option like FIB<X> or DHCPFIB<X>? 
Or, probably even =
better, some thing like dhclient_fib_IF=3DX? 
Akin to background_dhclien=
t, for example. 
 
The standard dhclient_fib option is, obviously, of=
 no use because it would put 
all dhclient-s into the same FIB. 
 -- 
Andriy Gapon 
 
 

=



------=_Part_3927069_1112315404.1758309548023--


From nobody Fri Sep 19 19:19:51 2025
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 4cT2Pz6lbBz67ST1
	for ; Fri, 19 Sep 2025 19:19:51 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cT2Pz61Jrz3KV8
	for ; Fri, 19 Sep 2025 19:19:51 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758309591;
	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=MOBPHUyQ323iQc9mf1z5HMPi/EaGdn2bd0PFhiz313w=;
	b=skwsNIym+di3kX3tng/2OufwG9NsNIBh+xYy+WDCuE8TO4FwDVx1B4O5nocoUIADHp2GoQ
	+h7MZc4lpxEjP0Xn2ZTgG5GaJ1alKf7dfUgV4+4hFNsAcc44aCgu/0+158AsB64iCz5Zt6
	KwhI/eJS6AHLGBu9VYas/UR+0iZZlr/pK1TLJB7PJHBtnXD471OV03Xxpm7gqt2pDxY4UB
	9GCU5rt2sI5IdxCkCOxq63NcJYC89NWPJy7yXoS3ylfB5wBPsz+qEhPZ/jkRNN9qMv86m0
	m1FJUSncUlKwe5fnbbSbLyGveSS8MEDfZPZnIO4BwyXiNFgX+TLhDzi/vnFxSg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758309591;
	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=MOBPHUyQ323iQc9mf1z5HMPi/EaGdn2bd0PFhiz313w=;
	b=RkBwy6YKwbXszgIxHo0b61d0iqjeUr8Qbd2Cmf49y+K7JhJKXWlN9/gxUKzKYWM8HOfeC1
	/YLPo44FhjKTDtU1zhAnF4RIY21Ci2DqHETSvT731c7eu9caqNEIg+ZK/gP9PpZyWYxL7y
	JxQBrpM2VQ/FHD91Em3EjrXkXiPwv4iKnegAzb+1CoF4GZuwfdYyllfPr3s309P6pw/rhB
	yEnbNTeB+xS/PsUHEanpXJBmdw3PjCvPHK9/9ZUA9pBeaDzBAYTrOYJrI5P6rAfucAKS1u
	vn7TRf3wp1wPTS5IMZRE9pPiOiF3XISaGJ1mh6p106WXTXkbUIsRPQX10T657A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758309591; a=rsa-sha256; cv=none;
	b=HyvffmWRYfrwokFIbQxxbIGDo9tt7aXJUXvcfmAJRRCcM+7zQ9E2DRTI8h3nV0r5uHsnZp
	T2EmqlZBl1Jf/vLjPJWrYwTgZ9SF9pp6QvEyP05bpc4RcBZHsyDxl3iJI+zVJgn+PaphQn
	9yhBqZE3oGvyv7Tbd00gLj+hSSTEszpyyTmPw21GABhtpLraXwISxCyprmKO5rmiXiZhPs
	msc8c/yiLOWYZEEdr7xPJacUqy3BgONK+7WuW05zVrg/dEI09SKawmacB8c1cYlxwjGWoR
	c+d+LVzOZhEHXKYhrWa0mxNTtR08l6dnj/YBRwpOrrSWfgOpZzgcEu4Q53U8nQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cT2Pz5Mlfz197L
	for ; Fri, 19 Sep 2025 19:19:51 +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 58JJJpbT047012
	for ; Fri, 19 Sep 2025 19:19:51 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from bugzilla@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58JJJpxL047010
	for net@FreeBSD.org; Fri, 19 Sep 2025 19:19:51 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 289545] No option to disable NOMAP leads to network down/up
 with em0 when starting bridge.
Date: Fri, 19 Sep 2025 19:19:51 +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.5-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Some 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: 
X-Bugzilla-Changed-Fields: 
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289545

--- Comment #10 from commit-hook@FreeBSD.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=3D5017fdb728811fd3e15d7151524378f49=
a49aee1

commit 5017fdb728811fd3e15d7151524378f49a49aee1
Author:     Zhenlei Huang 
AuthorDate: 2025-09-19 19:18:27 +0000
Commit:     Zhenlei Huang 
CommitDate: 2025-09-19 19:18:27 +0000

    ifconfig: Fix the display of the IFCAP_MEXTPG capability without netlink

    Historically this capability is IFCAP_NOMAP but it was renamed to
    IFCAP_MEXTPG. Catch up with the change 3f43ada98c89.

    PR:             289545
    Fixes:          3f43ada98c89 Catch up with 6edfd179c86: mechanically re=
name
IFCAP_NOMAP to IFCAP_MEXTPG
    MFC after:      3 days

 sbin/ifconfig/ifconfig.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Fri Sep 19 19:59:03 2025
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 4cT3HX61p0z67WXy
	for ; Fri, 19 Sep 2025 19:59:20 +0000 (UTC)
	(envelope-from leeb@ratnaling.org)
Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135])
	(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 "WR4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cT3HX4R2hz3QnD
	for ; Fri, 19 Sep 2025 19:59:20 +0000 (UTC)
	(envelope-from leeb@ratnaling.org)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-71d71bcac45so17659527b3.0
        for ; Fri, 19 Sep 2025 12:59:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=ratnaling-org.20230601.gappssmtp.com; s=20230601; t=1758311958; x=1758916758; 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=YnPxFCgcX1gq/YDQctiX4a3J5RgoxJTVuXdmpjRvx2M=;
        b=2Kuut017LEdSm/4Y2/yoE+R0+GRFDqMHvz8bsrUHnMaoJBEmGOInTP2ZUJc5rNofL8
         q3+uCtFsnxz1EQIaC6NgiIySL7L8zZi17DYdSZ8pEboBeYgbyOZVRTDJVY7l/gllhxV9
         OiVjN5zjYh4192JM2WQ7mHlE5OP7XQvS4K3mGSa/9ubrj/DTwS3ibzDmCaQ/SyQcLrM5
         YBdzcROPOUrm0GEM3IxFCM1zPtogGlSDEYMf0oiouoKXT3rQQgXQnq+ujnE2/+4TR8zQ
         eO13LWhQBwh9RXp0bVJGJDwFdfpiaRb6wl1WYOZOTYav1lzWsjtKcRRyotf/8MXFjFE1
         WSLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758311958; x=1758916758;
        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=YnPxFCgcX1gq/YDQctiX4a3J5RgoxJTVuXdmpjRvx2M=;
        b=Pt/eIiyxC/VhbiRdLxrqq7DqMJYL/qZtil3J7ylcEwi994LnRbbXWJ4Zpg2Chu8vo8
         fF3YSHI0JWr1Nb8JixvroGz/ubkXktX+JjozYE9B5l0ik9WduuRS2Vq5qdv+ROLkTUCp
         sa1UX2OyIwN76CBBfc8LSHCuds8eiD6yhidfp7/S4iz0EPgMFJoYUA5NTklzSH+9BQda
         vLNb1qm9PT54jXdWpLqY8ByPXEnFiFSzXufL6m2A/gG3bqRvmajeV2S8kw7EM1ZytCtE
         EO2uHC4gn9cqcfu/M9wbwX8qMBOMkOr66EbPt4nw/7Vde/2LOPGlE5IMXtwGMYmhgXLw
         AITA==
X-Forwarded-Encrypted: i=1; AJvYcCUxd437pCi5e4gOspodEhlLY49MccR6Bo/swi1B6+aTxLFB8W75Ed89W12YqCflv5OXFZsYTu2P1Bxw9g==@freebsd.org
X-Gm-Message-State: AOJu0YyXmq6+XNX+f/IIJt7SlWVpkYUdmaKUbMzU9fdrV9swcdzGZ6Mj
	CxXS+pq4GEDiI4ohq7e47oz7Ua6uV3OrTXCHzy8pb//6SMBwB0EDg6pryOlDkPX1Fabnx8kAZLY
	Tu2TK9NGwXxCU/qPR8/Nd9uQEPA42r2F/JQzFuP80GXyJT9BMkiLW
X-Gm-Gg: ASbGnctpCEl5O6fLNso4DNFYiSzZ0ZHPenlngW1Y+sbvNJlXNXFkGC7DGFYhalqV4RZ
	41EP3RksqDnev2grC2me0rZ5SQIf0yNhdiXFGx6yh0IcGsPle59sv8Qm3KfsnhxZjEHU98zCexO
	r5PnnqPuektz2xS36vATcAboWXwQevIb3LALU2UYHyWziaXKCiNLmPZdjPzdbi8Z0pHgx97+OUm
	Z8PLCzoJ43VQDrp2gX4Px1ZSYoqXr0rVK20SAijO+3C+2bdz2VM9jPC4X059iP6ofZ6Cycd1xi5
	aOoSn6Bkvk/3sQVEZ/Xeqq0FOSI=
X-Google-Smtp-Source: AGHT+IFJrF5OZmtiOQRlFbgohC8MZKu6ROyhEdKH+v/qZd+I9MhZfo7y//y/Za6sqZWXKmEcJoFNdRQ5SJNjZfJUQVU=
X-Received: by 2002:a05:690c:890:b0:723:9700:716d with SMTP id
 00721157ae682-73d3f5e13d1mr39847647b3.54.1758311958199; Fri, 19 Sep 2025
 12:59:18 -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: <6abe9da1-9818-438b-ad8f-5424e50a39ce@FreeBSD.org> <199636a7ff7.6b695ed1462688.6190907331232783668@marples.name>
In-Reply-To: <199636a7ff7.6b695ed1462688.6190907331232783668@marples.name>
From: Lee Brown 
Date: Fri, 19 Sep 2025 12:59:03 -0700
X-Gm-Features: AS18NWC8qoA190HblO1XIhZCFjRCctiOH46al6I8my3dxtm7J61tL7X0O8pkHY0
Message-ID: 
Subject: Re: DHCP on multi-homed host, some thoughts
To: Roy Marples 
Cc: avg@freebsd.org, freebsd-net@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000ac5224063f2ce746"
X-Spamd-Bar: ----
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-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cT3HX4R2hz3QnD

--000000000000ac5224063f2ce746
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I use /etc/dhclient-enter-hooks and /etc/dhclient-exit hooks to override
functions in dhclient-script.

That way I can control which interface updates /etc/resolv.conf and/or
default routes even in FIB's that are not associated directly with the
interface if I want, or multiple FIB's, etc..

On Fri, Sep 19, 2025 at 12:19=E2=80=AFPM Roy Marples  wro=
te:

> You could look into using dhcpcd from ports which solved this multihome
> issue years ago.
>
> Each interface automatically get a metric based on type and index. This i=
s
> override able, lowest wins.
> For any competing setup, lowest takes precedence and seamlessly changes
> when the interface goes down or loses a lease.
>
> Roy
>
>
>
> ---- On Fri, 19 Sep 2025 20:13:45 +0100 *Andriy Gapon *
> wrote ----
>
>
>
> Admittedly not a very common configuration, but still possible and some
> people
> have it (according to the Internet). I am also trying to set up such a
> configuration for "reasons".
>
> In the simplest form, there are two network interfaces connected to two
> different networks. Each network has its own DHCP server, its own router =
/
> gateway to the wider Internet, its own DNS server(s), etc. The networks
> are
> likely to be completely unaware of each other.
>
> The host itself may be a router providing internet access to another loca=
l
> network via another interface (or even multiple networks + interfaces).
> But
> that's not important.
>
> Some things provided via DHCP are per interface, but others are per host
> ("global"). Each interface can get its own IP address, that's fine.
> But, for example, which gateway to select for the default route?
>
> Dealing with those "global" things is the main issue in such a setup.
>
> What do we have now?
> Specifically, with dhclient that's a part of the base.
>
> Essentially, it has a winner takes it all approach.
> That's implemented in the default dhclient-script and the gist of the
> logic is
> in is_default_interface() function. Whichever interface is first to get a
> lease
> with a router wins. dhclient-script would set the default route to the
> router
> and as long as the default route goes through the interface, the interfac=
e
> remains the winner (for subsequent updates).
>
> So, the winner gets to set the default route.
> The winner also gets to set the resolver configuration (using
> resolvconf(8), by
> default).
> Losers can only configure their interface, other information is lost.
>
> If DHCP is simply configured for multiple interfaces via rc.conf, without
> any
> extra settings, then there is an obvious problem. A winner would depend o=
n
> random things like which interface gets link first, which DHCP sever is
> more
> responsive, etc. And a random winner is not always what is desired.
>
> As far as I know, there is no way to set any priority or anything like
> that.
> I found only two solutions used by other people, both not ideal.
>
> One solution is to start dhclient-s "manually" (i.e., outside of rc.conf
> declarative configuration) via something like rc.local. This way we can
> control
> which interface gets configured first.
>
> The other approach is to create a dhclient.conf configuration for the
> "secondary" interface(s) which would ignore the "global" options (routers=
,
> name
> servers, etc). This way the "primary" interface would be the only one tha=
t
> gets
> and sets the global configuration while all interfaces get their
> individual IP
> configuration.
>
> The latter approach is "less intrusive" (more declarative), but it has a
> flaw
> that if the selected primary network is down then there would be no
> default
> route at all.
>
> Both solutions still have the issue of discarding the global options from
> the
> secondary interface (either explicitly in dhclient.conf or by
> dhclient-script's
> strategy). And those options may come handy if we want to dynamically fli=
p
> (and
> as seamlessly as possible) between interfaces based on some events /
> criteria.
>
> It's especially interesting that dhclient uses the power of resolvconf(8)
> (unless forced to update /etc/resolv.conf directly) but still takes only
> the
> winner's configuration.
> I think that it could just add configurations from all interfaces and let
> resolvconf(8) deal with that. And an administrator would have control ove=
r
> how
> multiple configurations are merged via resolvconf.conf. Especially, if a
> local
> resolver (like unbound, for instance) is used. E.g., it would be possible
> to
> use different name servers based on domain, etc.
>
> Regarding routing, these days we can have multiple FIBs, so instead of
> discarding "secondary" routing information we could use it to configure a
> non-default FIB.
>
> Initially, I wanted to start working on some changes to dhclient-script t=
o
> implement those ideas. But then it occurred to me that it would easier to
> get
> what I want by changes external to dhclient.
>
> If there was a way to run a secondary dhclient with a non-default FIB
> (e.g., via
> setfib) then that alone would achieve the goals:
> - the secondary dhclient would be considered a winner because it's the
> only one
> to set the default route of the FIB;
> - so, it would obviously set the default route in the FIB;
> - and because the dhclient is considered a winner, it would also call
> resolvconf.
>
> I wonder if it would be a good idea to run dhclient under setfib if an
> interface
> is configured with DHCP/DHCPSYNC "virtual" option and real ifconfig 'fib'
> option.
> Or would that clash with some other uses / intentions?
> Then maybe we could add another virtual option like FIB or DHCPFIB?
> Or, probably even better, some thing like dhclient_fib_IF=3DX?
> Akin to background_dhclient, for example.
>
> The standard dhclient_fib option is, obviously, of no use because it woul=
d
> put
> all dhclient-s into the same FIB.
>
> --
> Andriy Gapon
>
>
>
>
>

--000000000000ac5224063f2ce746
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I use /etc/dhclient-enter-hooks and /etc/dhclient-exit hoo=
ks to override functions in dhclient-script.

That way I =
can control which interface updates /etc/resolv.conf and/or default routes =
even in FIB's that are not associated directly with the interface if I =
want,=C2=A0or multiple FIB's, etc..

On Fri, =
Sep 19, 2025 at 12:19=E2=80=AFPM Roy Marples <roy@marples.name> wrote:
You could look into using dhcpcd from ports which solved =
this multihome issue years ago.

Each interface aut=
omatically get a metric based on type and index. This is override able, low=
est wins.
For any competing setup, lowest takes precedence and se=
amlessly changes when the interface goes down or loses a lease.

Roy



---- On Fri, 19 Sep 2025 20:13:45 +0100 Andriy Gapon <avg@FreeBSD.=
org> wrote ----



Admittedly not a very common configuration, but still pos=
sible and some people 
have it (according to the Internet).  I am also t=
rying to set up such a 
configuration for "reasons". 
 
=
In the simplest form, there are two network interfaces connected to two different networks.  Each network has its own DHCP server, its own router =
/ 
gateway to the wider Internet, its own DNS server(s), etc.  The netwo=
rks are 
likely to be completely unaware of each other. 
 
The hos=
t itself may be a router providing internet access to another local 
net=
work via another interface (or even multiple networks + interfaces).  But <=
br>that's not important. 
 
Some things provided via DHCP are per=
 interface, but others are per host 
("global").  Each interfa=
ce can get its own IP address, that's fine. 
But, for example, which=
 gateway to select for the default route? 
 
Dealing with those "=
;global" things is the main issue in such a setup. 
 
What do we=
 have now? 
Specifically, with dhclient that's a part of the base. <=
br> 
Essentially, it has a winner takes it all approach. 
That's =
implemented in the default dhclient-script and the gist of the logic is in is_default_interface() function.  Whichever interface is first to get a=
 lease 
with a router wins.  dhclient-script would set the default route=
 to the router 
and as long as the default route goes through the interf=
ace, the interface 
remains the winner (for subsequent updates). 
 So, the winner gets to set the default route. 
The winner also gets to=
 set the resolver configuration (using resolvconf(8), by 
default). 
=
Losers can only configure their interface, other information is lost. 
 =

If DHCP is simply configured for multiple interfaces via rc.conf, witho=
ut any 
extra settings, then there is an obvious problem.  A winner woul=
d depend on 
random things like which interface gets link first, which D=
HCP sever is more 
responsive, etc.  And a random winner is not always w=
hat is desired. 
 
As far as I know, there is no way to set any prior=
ity or anything like that. 
I found only two solutions used by other peo=
ple, both not ideal. 
 
One solution is to start dhclient-s "man=
ually" (i.e., outside of rc.conf 
declarative configuration) via so=
mething like rc.local.  This way we can control 
which interface gets co=
nfigured first. 
 
The other approach is to create a dhclient.conf co=
nfiguration for the 
"secondary" interface(s) which would igno=
re the "global" options (routers, name 
servers, etc).  This w=
ay the "primary" interface would be the only one that gets 
an=
d sets the global configuration while all interfaces get their individual I=
P 
configuration. 
 
The latter approach is "less intrusive&q=
uot; (more declarative), but it has a flaw 
that if the selected primary=
 network is down then there would be no default 
route at all. 
 
=
Both solutions still have the issue of discarding the global options from t=
he 
secondary interface (either explicitly in dhclient.conf or by dhclie=
nt-script's 
strategy).  And those options may come handy if we want=
 to dynamically flip (and 
as seamlessly as possible) between interfaces=
 based on some events / criteria. 
 
It's especially interesting =
that dhclient uses the power of resolvconf(8) 
(unless forced to update =
/etc/resolv.conf directly) but still takes only the 
winner's config=
uration. 
I think that it could just add configurations from all interfa=
ces and let 
resolvconf(8) deal with that.  And an administrator would h=
ave control over how 
multiple configurations are merged via resolvconf.=
conf.  Especially, if a local 
resolver (like unbound, for instance) is =
used.  E.g., it would be possible to 
use different name servers based o=
n domain, etc. 
 
Regarding routing, these days we can have multiple =
FIBs, so instead of 
discarding "secondary" routing informatio=
n we could use it to configure a 
non-default FIB. 
 
Initially, I=
 wanted to start working on some changes to dhclient-script to 
implemen=
t those ideas.  But then it occurred to me that it would easier to get 
=
what I want by changes external to dhclient. 
 
If there was a way to=
 run a secondary dhclient with a non-default FIB (e.g., via 
setfib) the=
n that alone would achieve the goals: 
- the secondary dhclient would be=
 considered a winner because it's the only one 
to set the default r=
oute of the FIB; 
- so, it would obviously set the default route in the =
FIB; 
- and because the dhclient is considered a winner, it would also c=
all resolvconf. 
 
I wonder if it would be a good idea to run dhclien=
t under setfib if an interface 
is configured with DHCP/DHCPSYNC "v=
irtual" option and real ifconfig 'fib' option. 
Or would th=
at clash with some other uses / intentions? 
Then maybe we could add ano=
ther virtual option like FIB<X> or DHCPFIB<X>? 
Or, probably=
 even better, some thing like dhclient_fib_IF=3DX? 
Akin to background_d=
hclient, for example. 
 
The standard dhclient_fib option is, obvious=
ly, of no use because it would put 
all dhclient-s into the same FIB.  
-- 
Andriy Gapon 
 
 

=




--000000000000ac5224063f2ce746--

From nobody Fri Sep 19 20:21:26 2025
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 4cT3n246m2z67YHp
	for ; Fri, 19 Sep 2025 20:21:26 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cT3n23N8yz3Slb
	for ; Fri, 19 Sep 2025 20:21:26 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758313286;
	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=mvQrB/Trgvsxq76dD5+cSfiaMEzoQz6vcMOrj9zwgzQ=;
	b=gms2aifwFGTVSMl3t+lQFaM78xfnMocbmlDgLs8ULL9w92gL1JSnvCdLO+sXKmyO5ppRll
	sGwttTzoDpVb7FCWN7SkEQ+KhjNn5YgxRPkX2RufjkwomOG9ICx08xkyqa1f99SAvd/Ufd
	ZMvHS2O/PKNbCHU1LrDSQlYDe4XKL9/bOS3jzNGgKWReFhctW+v4GiLoEel5UXMsT7sjF0
	Qak8qm6C/S8ANTAx4oBnT6h9knf/+gng6Xu1+IUNj9b2JHLbZ3obYQsusXuvfju3XdFLW9
	s/BOcbi8BQjKhGyMnLwwR5K0pR68XV6zN1sjTZzTvzJQC4Wl8pgCnpHdo5oZgg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758313286;
	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=mvQrB/Trgvsxq76dD5+cSfiaMEzoQz6vcMOrj9zwgzQ=;
	b=PmqZ5LDwPd54U7c02cOMwf3+ssTWsnPB/19lG8ntpPMXHHWWAKejhGZc+c4YJL2+OhlVyX
	HaSJ0wc3Jiu/79HjTaQK9lB7Wx7R+xnB+s9i2G0ebMAQ4wGfe40EndcqbsIdBFKNqZOeqr
	/y44Iw+eHo7Ld2AHMS+0wN//lmMUE1sv1mHeaSg63KMQnQQeVG4PbOGsdUCQPjUGqB0dRK
	HjJqvkB+V0mMbHKxgilBbAN3uRtyRIqFuFdkMlg2pkefPSEiY5zxclj4zsLkFar6yaJ2go
	8YO2tU8M9AIVA7bfZLcded9C3/GQc5jaId1JKScDuj2V0TfsTPWbPn9hHa1k4g==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758313286; a=rsa-sha256; cv=none;
	b=d+y95pBqHY5/nQ1qK24EM3pbbNM/rFqiJ9/eBnfC1A+vTflbD4SV4M/SJg+Xfq+LpvZPwn
	3hXHmPU1LgsMFGBO1DIXTL6EXb7AuRffIY+3QpOv7DwDoe7/fckcyJ7B8Bm/XnSHpF5B/0
	nbgbaFHmGEIYMdSZq7hvNdVfP+pYCmVASDVJVYrhMgep8pXT+mWP/Kpe5qO4jUJMBl3aXk
	DF/mFM7TNdcPaWY0TSWQCbXiQUf3i/Qvd6kanTlEpa4Hy5yETahvIKp2DyfZQTJm+svNig
	6oTq1VW+SyMQ7Py+OY7hUAm9DsEznIxLWuFBDaZAhJjO1iE4Xpx0H3yotr4q8g==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cT3n22rSCz19rG
	for ; Fri, 19 Sep 2025 20:21:26 +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 58JKLQp5046821
	for ; Fri, 19 Sep 2025 20:21:26 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58JKLQSv046820
	for net@FreeBSD.org; Fri, 19 Sep 2025 20:21:26 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 289198] inet_net_pton is broken with AF_INET6
Date: Fri, 19 Sep 2025 20:21:26 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: bin
X-Bugzilla-Version: 14.3-RELEASE
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: ivy@FreeBSD.org
X-Bugzilla-Status: In Progress
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: ivy@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_file_loc
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289198

Lexi Winter  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://reviews.freebsd.org
                   |                            |/D52629

--=20
You are receiving this mail because:
You are on the CC list for the bug.=

From nobody Sat Sep 20 07:06:56 2025
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 4cTL626v0hz68NY4
	for ; Sat, 20 Sep 2025 07:07:06 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Received: from mx-01.divo.sbone.de (mx-01.divo.sbone.de [IPv6:2003:a:140a:2200:6:594:fffe:19])
	(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 ECDSA (prime256v1) client-digest SHA256)
	(Client CN "mx-01.divo.sbone.de", Issuer "E6" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cTL623rMQz3frX;
	Sat, 20 Sep 2025 07:07:06 +0000 (UTC)
	(envelope-from bzeeb-lists@lists.zabbadoz.net)
Authentication-Results: mx1.freebsd.org;
	none
Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256)
	(No client certificate requested)
	by mx-01.divo.sbone.de (Postfix) with ESMTPS id 8996EA64806;
	Sat, 20 Sep 2025 07:06:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zabbadoz.net;
	s=20240622; t=1758352009;
	bh=qF6Crl5Oyl1lnOle3RXOaMLnhzxWa1l7u3TUvZ1Dxi8=;
	h=Date:From:To:cc:Subject:In-Reply-To:References;
	b=Z5luCBhchHoMCB5nnjXB/s+aTS7ue7ncYYdu3dZ40VaSqxBVZxc5DvCBcnIerGgTh
	 ctkNkKP9J85hpfc8M4jqYsXjgI35H0xRZ+z2DL31nibNwkXw636R9J2VslZc2DEytF
	 ki5+svWItNyGaY3Q5jPHKaF7tGERUyPy3zAzIM2JkrvRbEJ+66rK6aTHaT0TfZa71o
	 KnxyLHi+3cPxMuJThIWbDwpyZbJhKPnFujokHisits6uOzEZN0TyChvHbuthdnu/g9
	 x4B2dDxUbOUkxG+5oZQ0EUUmTNPbpEiH13sQ9vtGoKJ94SsYhGV16Nu9h7kloezsbg
	 k7To+EhIcJ9C3PQaoCMFud4ATeYk8/58Pfhyc6OLUVV1h9ef//vBc7pmh7KaD3chwp
	 Qkh2zk6wqB25J1CcoiGMWmPY8uWoC9sjW/Xq4marmxGZ2/bUcuH7xLGER8yw2oDbDb
	 c7SrDhXOQTrzn+BrpcSRXnPI2ubyS0qp9qzlCGRV9EloTR0i876e79voDIZsYuxjQO
	 oIxQXkdBmzXOkt1aih+gwSnPZpoWGDGpekb1GBaoZKEMCoB2uuvj3/yddVlNwXjjcQ
	 Ty7r2NZj2GL60FHIxHNjl655e9nZRZ0QFROXwq6hxXhZVCMkbz1v65VOqnQ8QdBR4H
	 Oc5E7fDFlTJ9E9nTu8CQTGcA=
Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742])
	(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)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPS id 5F4CE2D029E6;
	Sat, 20 Sep 2025 07:06:58 +0000 (UTC)
X-Virus-Scanned: amavisd-new at sbone.de
Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025])
	by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024)
	with ESMTP id mPvMcbGFMCCB; Sat, 20 Sep 2025 07:06:57 +0000 (UTC)
Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:a66b:b6ff:fe40:39a9])
	(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)
	(No client certificate requested)
	by mail.sbone.de (Postfix) with ESMTPSA id 1EE002D029D8;
	Sat, 20 Sep 2025 07:06:57 +0000 (UTC)
Date: Sat, 20 Sep 2025 07:06:56 +0000 (UTC)
From: "Bjoern A. Zeeb" 
To: Andriy Gapon 
cc: "net@FreeBSD.org" 
Subject: Re: DHCP on multi-homed host, some thoughts
In-Reply-To: <6abe9da1-9818-438b-ad8f-5424e50a39ce@FreeBSD.org>
Message-ID: 
References: <6abe9da1-9818-438b-ad8f-5424e50a39ce@FreeBSD.org>
X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842
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; format=flowed
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	ASN(0.00)[asn:3320, ipnet:2003::/19, country:DE]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cTL623rMQz3frX

On Fri, 19 Sep 2025, Andriy Gapon wrote:

[multihome steup]

What you are describing is in no way special to DHCP.
Even a manual configuration would have the same issue, wouldn't it?

For IPv6 there exist a set of RFCs which have ideas on how to deal with
multi-homing.

The one main issue (routing and source address selection sorted),
is and remains DNS as we have no default way to pick up resolvers on a
per-interface or per-domain setting.  You'll find that per-interface
doesn't really work as you'd have to know which path you go before
you do the DNS lookup.

But chosing an upstream DNS with the wrong source address often won't
work.  At least here ISPs won't allow you to use their resolver if you
are not coming from their IP range.
The answer then really is to run a local resolver independent on
upstream for as long as that is feasible and working (*).

In that way the DHCP approach (which I think should have worked with
multiple IF just fine to merge a resolv.conf) isn't that bad.  Use the
DNS where your default route goes.

My 0.0005 cts
/bz


(*) and before anyone suggests any of the open resolvers which collect
your data, please leave this thread alone.

-- 
Bjoern A. Zeeb                                                     r15:7

From nobody Sat Sep 20 11:27:35 2025
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 4cTRtl56kWz68h03
	for ; Sat, 20 Sep 2025 11:27:43 +0000 (UTC)
	(envelope-from karl@denninger.net)
Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4cTRtk2lZkz3GCd
	for ; Sat, 20 Sep 2025 11:27:42 +0000 (UTC)
	(envelope-from karl@denninger.net)
Authentication-Results: mx1.freebsd.org;
	dkim=none;
	dmarc=pass (policy=none) header.from=denninger.net;
	spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net
Received: from denninger.net (unknown [162.81.137.111])
	by colo1.denninger.net (Postfix) with ESMTP id 724E7B05B1
	for ; Sat, 20 Sep 2025 07:26:27 -0400 (EDT)
Received: by denninger.net (Postfix, from userid 58)
	id 6DF0712DDB7; Sat, 20 Sep 2025 07:27:36 -0400 (EDT)
X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on NewFS.denninger.net
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=3.0 tests=ALL_TRUSTED,BAYES_00,
	HTML_MESSAGE autolearn=no autolearn_force=no version=4.0.1
X-Spam-Report: 
	* -3.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
	* -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
	*      [score: 0.0000]
	*  0.0 HTML_MESSAGE BODY: HTML included in message
Received: from [192.168.10.15] (D5.Denninger.Net [192.168.10.15])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by denninger.net (Postfix) with ESMTPSA id 3591012DCD9
	for ; Sat, 20 Sep 2025 07:27:36 -0400 (EDT)
Message-ID: 
Date: Sat, 20 Sep 2025 07:27:35 -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: DHCP on multi-homed host, some thoughts
To: freebsd-net@freebsd.org
References: <6abe9da1-9818-438b-ad8f-5424e50a39ce@FreeBSD.org>
 
From: Karl Denninger 
Content-Language: en-US
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040803010807080602090207"
X-Spamd-Bar: /
X-Spamd-Result: default: False [-0.74 / 15.00];
	SIGNED_SMIME(-2.00)[];
	NEURAL_SPAM_LONG(1.00)[1.000];
	NEURAL_SPAM_MEDIUM(0.94)[0.941];
	DMARC_POLICY_ALLOW(-0.50)[denninger.net,none];
	R_SPF_ALLOW(-0.20)[+mx];
	MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain];
	NEURAL_SPAM_SHORT(0.12)[0.124];
	MIME_BASE64_TEXT(0.10)[];
	ARC_NA(0.00)[];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US];
	RCPT_COUNT_ONE(0.00)[1];
	MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~];
	FREEFALL_USER(0.00)[karl];
	RCVD_COUNT_THREE(0.00)[3];
	MLMMJ_DEST(0.00)[freebsd-net@freebsd.org];
	R_DKIM_NA(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	FROM_HAS_DN(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TO_DN_NONE(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	RCVD_TLS_LAST(0.00)[];
	HAS_ATTACHMENT(0.00)[]
X-Rspamd-Queue-Id: 4cTRtk2lZkz3GCd

This is a cryptographically signed message in MIME format.

--------------ms040803010807080602090207
Content-Type: multipart/alternative;
 boundary="------------wZnF4uh8tZC3OkdD2PHKhtmB"

--------------wZnF4uh8tZC3OkdD2PHKhtmB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

T24gOS8yMC8yMDI1IDAzOjA2LCBCam9lcm4gQS4gWmVlYiB3cm90ZToNCj4gT24gRnJpLCAx
OSBTZXAgMjAyNSwgQW5kcml5IEdhcG9uIHdyb3RlOg0KPg0KPiBbbXVsdGlob21lIHN0ZXVw
XQ0KPg0KPiBXaGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyBpbiBubyB3YXkgc3BlY2lhbCB0
byBESENQLg0KPiBFdmVuIGEgbWFudWFsIGNvbmZpZ3VyYXRpb24gd291bGQgaGF2ZSB0aGUg
c2FtZSBpc3N1ZSwgd291bGRuJ3QgaXQ/DQo+DQo+IEZvciBJUHY2IHRoZXJlIGV4aXN0IGEg
c2V0IG9mIFJGQ3Mgd2hpY2ggaGF2ZSBpZGVhcyBvbiBob3cgdG8gZGVhbCB3aXRoDQo+IG11
bHRpLWhvbWluZy4NCj4NCj4gVGhlIG9uZSBtYWluIGlzc3VlIChyb3V0aW5nIGFuZCBzb3Vy
Y2UgYWRkcmVzcyBzZWxlY3Rpb24gc29ydGVkKSwNCj4gaXMgYW5kIHJlbWFpbnMgRE5TIGFz
IHdlIGhhdmUgbm8gZGVmYXVsdCB3YXkgdG8gcGljayB1cCByZXNvbHZlcnMgb24gYQ0KPiBw
ZXItaW50ZXJmYWNlIG9yIHBlci1kb21haW4gc2V0dGluZy7CoCBZb3UnbGwgZmluZCB0aGF0
IHBlci1pbnRlcmZhY2UNCj4gZG9lc24ndCByZWFsbHkgd29yayBhcyB5b3UnZCBoYXZlIHRv
IGtub3cgd2hpY2ggcGF0aCB5b3UgZ28gYmVmb3JlDQo+IHlvdSBkbyB0aGUgRE5TIGxvb2t1
cC4NCj4NCj4gQnV0IGNob3NpbmcgYW4gdXBzdHJlYW0gRE5TIHdpdGggdGhlIHdyb25nIHNv
dXJjZSBhZGRyZXNzIG9mdGVuIHdvbid0DQo+IHdvcmsuwqAgQXQgbGVhc3QgaGVyZSBJU1Bz
IHdvbid0IGFsbG93IHlvdSB0byB1c2UgdGhlaXIgcmVzb2x2ZXIgaWYgeW91DQo+IGFyZSBu
b3QgY29taW5nIGZyb20gdGhlaXIgSVAgcmFuZ2UuDQo+IFRoZSBhbnN3ZXIgdGhlbiByZWFs
bHkgaXMgdG8gcnVuIGEgbG9jYWwgcmVzb2x2ZXIgaW5kZXBlbmRlbnQgb24NCj4gdXBzdHJl
YW0gZm9yIGFzIGxvbmcgYXMgdGhhdCBpcyBmZWFzaWJsZSBhbmQgd29ya2luZyAoKikuDQo+
DQo+IEluIHRoYXQgd2F5IHRoZSBESENQIGFwcHJvYWNoICh3aGljaCBJIHRoaW5rIHNob3Vs
ZCBoYXZlIHdvcmtlZCB3aXRoDQo+IG11bHRpcGxlIElGIGp1c3QgZmluZSB0byBtZXJnZSBh
IHJlc29sdi5jb25mKSBpc24ndCB0aGF0IGJhZC7CoCBVc2UgdGhlDQo+IEROUyB3aGVyZSB5
b3VyIGRlZmF1bHQgcm91dGUgZ29lcy4NCj4NCj4gTXkgMC4wMDA1IGN0cw0KPiAvYnoNCg0K
TXkgYW5zd2VyIGhhcyAvYWx3YXlzIC9iZWVuIHRvIHJ1biBhIGxvY2FsIHJlc29sdmVyLg0K
DQpUaGUgcmVhc29uIGlzIG5vdCBqdXN0IHdoYXQgeW91IG5vdGU7IGl0IGlzIC9hbHNvIC90
aGF0IHRoZXJlIGFyZSANCmZyZXF1ZW50bHksIG9uIG5ldHdvcmtzIEknbSByZXNwb25zaWJs
ZSBmb3IsIHR3byBkaWZmZXJlbnQgcmVzb2x2ZWQgDQphZGRyZXNzZXMgZm9yIGEgZ2l2ZW4g
cmVzb3VyY2UgZGVwZW5kaW5nIG9uIHdoZXRoZXIgaXQgaXMgb3V0c2lkZSBvciANCmluc2lk
ZSB0aGUgbG9jYWwgbmV0d29yaywgYXQgbGVhc3QgZm9yIElQdjQsIGJlY2F1c2Ugb2YgTkFU
Lg0KDQpQb3J0IGZvcndhcmRpbmcgYXQgdGhlIGdhdGV3YXkgdGFrZXMgY2FyZSBvZiBhY2Nl
c3MgZnJvbSB0aGUgb3V0c2lkZSANCmhvd2V2ZXIgeW91IGRvIHdhbnQgQklORCdzICJycHoi
IG9yIHVuYm91bmQncyBlcXVpdmFsZW50IGZvciBhY2Nlc3NlcyANCnRoYXQgY29tZSBmcm9t
IGluc2lkZSB0aGUgZ2F0ZXdheS4NCg0KLS0gDQpLYXJsIERlbm5pbmdlcg0Ka2FybEBkZW5u
aW5nZXIubmV0DQovVGhlIE1hcmtldCBUaWNrZXIvDQovW1MvTUlNRSBlbmNyeXB0ZWQgZW1h
aWwgcHJlZmVycmVkXS8NCg==
--------------wZnF4uh8tZC3OkdD2PHKhtmB
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



  
    
  
  
    
On 9/20/2025 03:06, Bjoern A. Zeeb
      wrote:

    

    
On
      Fri, 19 Sep 2025, Andriy Gapon wrote:
      

      

      [multihome steup]
      

      

      What you are describing is in no way special to DHCP.
      

      Even a manual configuration would have the same issue, wouldn't
      it?
      

      

      For IPv6 there exist a set of RFCs which have ideas on how to deal
      with
      

      multi-homing.
      

      

      The one main issue (routing and source address selection sorted),
      

      is and remains DNS as we have no default way to pick up resolvers
      on a
      

      per-interface or per-domain setting.=C2=A0 You'll find that
      per-interface
      

      doesn't really work as you'd have to know which path you go before
      

      you do the DNS lookup.
      

      

      But chosing an upstream DNS with the wrong source address often
      won't
      

      work.=C2=A0 At least here ISPs won't allow you to use their resolve=
r if
      you
      

      are not coming from their IP range.
      

      The answer then really is to run a local resolver independent on
      

      upstream for as long as that is feasible and working (*).
      

      

      In that way the DHCP approach (which I think should have worked
      with
      

      multiple IF just fine to merge a resolv.conf) isn't that bad.=C2=A0=
 Use
      the
      

      DNS where your default route goes.
      

      

      My 0.0005 cts
      

      /bz

    
My answer has=C2=A0always=C2=A0been to run a local resolver=
=2E

    
The reason is not just what you note; it is=C2=A0also=C2=A0=
that
      there are frequently, on networks I'm responsible for, two
      different resolved addresses for a given resource depending on
      whether it is outside or inside the local network, at least for
      IPv4, because of NAT.

    
Port forwarding at the gateway takes care of access from the
      outside however you do want BIND's "rpz" or unbound's equivalent
      for accesses that come from inside the gateway.

    
-- 

      Karl Denninger

      karl@denninger.net

      The Market Ticker

      [S/MIME encrypted email preferred]<=
/div>
  


--------------wZnF4uh8tZC3OkdD2PHKhtmB--

--------------ms040803010807080602090207
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
C4owggWZMIIDgaADAgECAhRZU8dKdMneRI1Vq5kv0k54Q5rQuDANBgkqhkiG9w0BAQsFADB2
MQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRYwFAYDVQQKDA1EZW5uaW5nZXIu
TmV0MRcwFQYDVQQDDA5EZW5uaW5nZXIgUm9vdDEiMCAGCSqGSIb3DQEJARYTYWRtaW5AZGVu
bmluZ2VyLm5ldDAeFw0yNDA1MDkyMTA4MDNaFw00NDA1MDQyMTA4MDNaMF0xCzAJBgNVBAYT
AlVTMRIwEAYDVQQIDAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNV
BAMMGURlbm5pbmdlci5OZXQgU2lnbmluZyBJbnQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDbR0tSiuLG5HPfo+cWtdeYQ8jc8Bjfuo0GTcNRT0glHnH1apUtInIktUknEZDH
ohahInN+mMBdKg54FCHOiYZrJbyxBIo9FwX7hRmOc+spxmSYWnOd2E/YcGInMK4ZpjPzldzB
Yt1n3zygkhx2bssxTJS3x4nv1qAXfLSZd1VwqoQufifEoPyTtymkkvHLv86vLgqAqooM/cXc
4LSIQ5u2uM308n42r8RkKtp7X1v9fJW8oRZN2XnFZtiUPH44YY2rHqyN2Hea9Y3+TXbldXjo
xhPHTA+JYVFq8KTmbQBqU7YcMhlIG0cSxPeFLMxnP6pqPcIVTAlK+a6YGRFppfjZAgMBAAGj
ggE2MIIBMjAdBgNVHQ4EFgQUH+VuxXhBxaJAQrvDekwkH91hBi4wgbMGA1UdIwSBqzCBqIAU
RFYC4p6L6KITnEvrpx2cyt+PcMmheqR4MHYxCzAJBgNVBAYTAlVTMRIwEAYDVQQIDAlUZW5u
ZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5OZXQxFzAVBgNVBAMMDkRlbm5pbmdlciBSb290
MSIwIAYJKoZIhvcNAQkBFhNhZG1pbkBkZW5uaW5nZXIubmV0ghQZE7NBItWtQsCouuwU6jZ+
HPPwnjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+gLaAr
hilodHRwOi8vd3d3LmRlbm5pbmdlci5uZXQvcm9vdC1yZXZva2VkLmNybDANBgkqhkiG9w0B
AQsFAAOCAgEAfFbhPc82AfhyUqONs7IccYD36w+OP4nQgwfC4IWf3y/aQAZ2Zk6IITzYqwf7
PFM0bJRT3zi7xyetolqHDhfMJvnOQWpITZiyM/FSKwIvuBsy/uJUqPuqui4XQMYoSbAA1qmI
MW/z7VZZHwaRFoeWE40UirYcf0fNcooBZ72bmd+iBaVyjtZvky0Vgcz0eC6e6LR5kNb23yC6
TkyQIlGyQkK5/afXUYFzk49rOHVbVyxW3oXRfq8Ow6HCrpDGAS8p84S04MFwBVAUfbe4aXs3
bampaI2LzKgkVywyFP14LSvvdjCfLYfnLy1Z9hm2EHMqNHA2tCGdRhWp2d7aZC1MYFqng0ZS
fjPJjqHrI1qPU0p6k9A1GxAtrQlL2v/IUzUnMZkiawFV3qlxMGZf/kTYTUOcJhx1KU4zSLHu
80qO7ldRpp5gHssCAGFbeTu2gp6LxfmaFhLPDBJ1VGfdPx9lUrU/9OcoHczcl5x2Rb8IUZyX
9elzP5WdAU8p5R/DLlOAq24VcabhFtYBCA2dOESLupSfWKNQuJCN/1gz7ysSc+mjnnPV77IO
mpszJfkFFJEDNJlGIVKX1vwwygtC/9Ulox8frgbZlRAYAgDc/YbOBFxticVVre0Y3Ujx6Kzb
tkgZRlgfdZWbT1W5smncqJxg5qAL8e/yTb3fCe2nJ0jhiP4wggXpMIIE0aADAgECAhMAmNFt
CiCF3j+FwQLYtBTmGjzkMA0GCSqGSIb3DQEBCwUAMF0xCzAJBgNVBAYTAlVTMRIwEAYDVQQI
DAlUZW5uZXNzZWUxFjAUBgNVBAoMDURlbm5pbmdlci5uZXQxIjAgBgNVBAMMGURlbm5pbmdl
ci5OZXQgU2lnbmluZyBJbnQwHhcNMjQwNTEwMTkyNjU5WhcNMjkwNTA5MTkyNjU5WjBXMQsw
CQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2VlMRcwFQYDVQQKDA5LYXJsIERlbm5pbmdl
cjEbMBkGA1UEAwwSa2FybEBkZW5uaW5nZXIubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8A
MIICCgKCAgEAvh1UssVbSYctzobPjwBkbjv/w4WvQNepeRTwE6+sLnXvc41+X9pa5EclPL4Q
l02Vu1m71mSqXGfK9HbWZoivbhefBHOoYb35MSc24PelhwcORbpneWoWc7giQ7QgFlvEe/yj
fs8M0H9fgdzFS5m2lwBQbis8kioSjHB2yt/8I1GE4Mvt1Cur9kga6ML5FAQvo8TYN1stdhrE
13FEv/BWCF4FVT4H2Wa2ySW+R1jkKb74SC6Twg98bGCRTShD5bVylh0+0LXNhzaopIDcI/KK
jm/j3mRjIlmqbGrSpvJsbjjhjhAYQKE1U8FB5TDU4OkFAibblhQit/KjgspPR2o/vOpVFPER
uhZEV1oDGzUJtZlkREIcN2sYBi0p7Y4585ya+b7L10mEenPlyi3eSkGXEuiy/BR2DY6lShwW
DPoQ5602TKmttCSwBdWGoLrQ4jEVEVNt4lku2wPbTHF3KpHJU0g7RbcWoUYn10SOxKathkir
hF3v9U32+QhPELGwqRrH0sL9rWf0qalRtPDHUYl8TebZmYkFqNeSMlqHijl5f4SsQPSj7gx5
4F19Ntm9ZcvuWTmW8QQGWTKHeMuG+BYkVIUSPe6/ZQsbD/xDx7rkyGfNgWIa4W7Wm/B7kaNq
H53tk3wFmNgZQOxMTPF0oTHfW0T2azU6JD0D1AlgoAnSAE0CAwEAAaOCAaYwggGiMDoGCCsG
AQUFBwEBBC4wLDAqBggrBgEFBQcwAYYeaHR0cDovL29jc3AuZGVubmluZ2VyLm5ldDo3Nzc3
MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDAzBglghkgBhvhCAQ0EJhYkT3BlblNTTCBHZW5lcmF0ZWQgQ2xpZW50IENlcnRp
ZmljYXRlMB0GA1UdDgQWBBSxJZjVnlYLAT3uzvDYgc4742J6UTCBswYDVR0jBIGrMIGogBQf
5W7FeEHFokBCu8N6TCQf3WEGLqF6pHgwdjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5l
c3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLk5ldDEXMBUGA1UEAwwORGVubmluZ2VyIFJvb3Qx
IjAgBgkqhkiG9w0BCQEWE2FkbWluQGRlbm5pbmdlci5uZXSCFFlTx0p0yd5EjVWrmS/STnhD
mtC4MB0GA1UdEQQWMBSBEmthcmxAZGVubmluZ2VyLm5ldDANBgkqhkiG9w0BAQsFAAOCAQEA
TrQ45/tBN3SiuqItFv/V+CF3h7Hxe0YLsL+A/P+q9ZhxIscaNjaclgQhPA+rUr+l8DGoXJ/w
yAl1E0SSBK+9phIc/9xFOBg3rCy4ngubzP+lHS1t03nMCBSUNsu5qPzqLBPiKaPabUu3Gr9o
koRezSszgM3/zNJfr8cMO93csCK/fBccsMx5q+3nxB5XeT7UciicjfEzUA4m2mQxBmGk9SSU
147Gy8UmdSq57Tw82KqUrQ1pJ6IOzVPLREpwlqGbHykSU3MwtPYPtfQeFVjvO/XcWvoFQjbV
UyhzAqMMYFudxoVLlJQiAgU38OScTLDgKxCO41h7VOjb2mss0zHndzGCBZUwggWRAgEBMHQw
XTELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2Vy
Lm5ldDEiMCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC
2LQU5ho85DANBglghkgBZQMEAgMFAKCCAvIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc
BgkqhkiG9w0BCQUxDxcNMjUwOTIwMTEyNzM1WjBPBgkqhkiG9w0BCQQxQgRAUCTWID5DrCLu
4ll/hz1EKlA0b8feD0uNzZsewUcLhqjRnX/GsPIa41frQDBTL0lpF0630e5S6/j07SmgigvS
kTCBgwYJKwYBBAGCNxAEMXYwdDBdMQswCQYDVQQGEwJVUzESMBAGA1UECAwJVGVubmVzc2Vl
MRYwFAYDVQQKDA1EZW5uaW5nZXIubmV0MSIwIAYDVQQDDBlEZW5uaW5nZXIuTmV0IFNpZ25p
bmcgSW50AhMAmNFtCiCF3j+FwQLYtBTmGjzkMIGFBgsqhkiG9w0BCRACCzF2oHQwXTELMAkG
A1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEWMBQGA1UECgwNRGVubmluZ2VyLm5ldDEi
MCAGA1UEAwwZRGVubmluZ2VyLk5ldCBTaWduaW5nIEludAITAJjRbQoghd4/hcEC2LQU5ho8
5DCCAVcGCSqGSIb3DQEJDzGCAUgwggFEMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI
KoZIhvcNAwcwDQYIKoZIhvcNAwICAQUwDQYIKoZIhvcNAwICAQUwBwYFKw4DAgcwDQYIKoZI
hvcNAwICAQUwBwYFKw4DAhowCwYJYIZIAWUDBAIBMAsGCWCGSAFlAwQCAjALBglghkgBZQME
AgMwCwYJYIZIAWUDBAIEMAsGCWCGSAFlAwQCBzALBglghkgBZQMEAggwCwYJYIZIAWUDBAIJ
MAsGCWCGSAFlAwQCCjALBgkqhkiG9w0BAQEwCwYJK4EFEIZIPwACMAgGBiuBBAELADAIBgYr
gQQBCwEwCAYGK4EEAQsCMAgGBiuBBAELAzALBgkrgQUQhkg/AAMwCAYGK4EEAQ4AMAgGBiuB
BAEOATAIBgYrgQQBDgIwCAYGK4EEAQ4DMA0GCSqGSIb3DQEBAQUABIICAB7C2WuAMryQGVZX
9s/eifgjnoPGDDOHQUH+Vo/2XeXVqhmMoYajSh3HvbwzmONgd7ByU+jEU5EKK3I2Tat3ckZJ
8J/ZHF3of18WEbPvuJqVCXsgtOcWGb+H6hHwrdvylGhjS0styxP9IzIHi5y5q0RRRo7IDu8t
lNqbVFhjQ5D8CloRpcdZRsXP/Xnma/NrNMeLdqH6LFjN2ykk6L7PpCmu+U7AWKkCfEyavspf
oJ5qHP/rK6kUsw0/NA3a2qnRwaL7a66If6C9qpfwEDzOPpi/foMrvMYEA6AF1ttHEn3QtClb
LL2+Xm6eG6N8lPE4aaMynUATRuxDFh2YmxGK+oR0ix/0BjfN/RUA+adyQCfRlUU2/R28B1RX
1ubSA1HghSZBwXYbKU7zPLqAzp71jz5EK4D+gV4kGnCR11ZcYC2q1+PkcpUWEAu4fEvjgF0w
LdVVH8A/TLj2977c/wLhtdhGu2uLBiLGkI3GRxnqUpLaYMSHiyd3Gfj7U5vWsXAx4AaWGV4g
rHN1w15FJUXSVAkYiVpuBaq48ht5tziCKPf/u/5xT3wYl1l9tYj2REi2QzSgQKxrv7+kzNfl
09GeiHqEPUGTV6uH8oF/t6+YhEV9IndviI5yhLodcr6DdN0/9BBrcxQljqayOkVuukK13fdF
WIOdEC7DTE9Mn/8SY+ikAAAAAAAA
--------------ms040803010807080602090207--

From nobody Sat Sep 20 13:56:21 2025
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 4cTWBY4hfPz67sKH
	for ; Sat, 20 Sep 2025 13:56:37 +0000 (UTC)
	(envelope-from vadimnuclight@gmail.com)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d])
	(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 "WR4" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cTWBY2gNcz3TRh
	for ; Sat, 20 Sep 2025 13:56:37 +0000 (UTC)
	(envelope-from vadimnuclight@gmail.com)
Authentication-Results: mx1.freebsd.org;
	none
Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-573855e2afeso3700888e87.0
        for ; Sat, 20 Sep 2025 06:56:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758376586; x=1758981386; darn=freebsd.org;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=hzsnXK1b+hpNkIKmfwz3uJ1WkFuePL1dP7m8JdXGoeA=;
        b=K1wzLDAB+uFkNXQzuyNzGZiwFzPU+7tEz9ri56yP+KcLHDrUI0OYfOVC3EbEgMWcef
         b562ShdVGNJHc5bfg0WKkxAjLaPG8Is22mLcRqOiIzZFFAz2EKGCwr/HFKDohcFM+0Se
         KtrAnMBMLKjkPIfaYT2k/0QgCu0R3yqvjnAw57Vu/bRE2oo3K35LKI2fHo7MtckvGO99
         ljrZy8gq0l51dbcwt3anLCYfUhU7PMshbRDeX4hi9TJDKmGfrbD8xDSZy+i44vQdwTXU
         4enAj5Fw6SUDvNckuturD8jbWy2v2cnwfbLGkUaJieFe/aW5Ul5R0C3/Zeeo0wlBFOg/
         sWJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758376586; x=1758981386;
        h=content-transfer-encoding:mime-version:references:in-reply-to
         :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=hzsnXK1b+hpNkIKmfwz3uJ1WkFuePL1dP7m8JdXGoeA=;
        b=Z4noH8+7Etv68umCvwCQz/Da0PyV5AZygf2U+z3Rsq0xN+GTFTr0X9BuP/zAegcPZl
         gI8BQMIzWu1wqXCE4lj/iDqXwaf2I0WKCRJuJk1ioJvMVF0Rpr0x6194gxF1t7L1fDZD
         x5MfmRQwx/COTHiIickC38awfbQfMUGvSNZuWNsfwxrFSSN87KqptD2lWPrro300rsTA
         2SvSXFnQgoH6a0lK8LoJhB7Szk5zUU7eTiWi1SoUZpH7vAeKcBcrx+11ycLzlGB62Wxp
         WTMrPX1d8MDNz65zv7RB+qGmfnIVaA59McVNohnIeJF9KpvhYOW731bsS1UUct+jd4sk
         0b5g==
X-Forwarded-Encrypted: i=1; AJvYcCXf03X/IpQRXmtqo1hxWWSUP3wh7DbgMKnDgELM91x3IYLCXsEQXe+pBWTu1w55e3JdREs=@freebsd.org
X-Gm-Message-State: AOJu0YxnBxSAmqO9BfNIubM+4Ml68gerX5HsUbDg73vbAPRA17ij23Tp
	j9PQMnXiCh92nzXzVPNSX0cjVcvew/BITprO9hKqltArzxjjctk9YNUZ
X-Gm-Gg: ASbGncsCl3V49ULhle2DfHEWphpVO8gnmDKKvLZ+BipvFyNdhBqnimWGlRtZFdDhbhZ
	CB4J1nI6RqMr9le0CjTDMYg2w1iHUWrAn6gz7J7mBojbXpBkOUmQL5DubjLwsrpDzz/ErQKOQf0
	yo193NrGH2tnwqLt7cEyilnEpJIflqLBJek6MSdESkHRqKMJBOdGF0V5xulB0oCeasXHIg3l7GB
	F+Y1SYVYFESuWOloII63/aXA/Va2J8iZuw8rO26HkMrtfMY0WuusbGsMrq80u18K7ma8Rx9wCfJ
	ydgs25TLzcCDnzvF7X5hVzRPJWOVRk/s6B8T6rSzxmezrwPh4LzxuJfyG6BubwawyTH+Sj6EnQX
	HTM9yDlmSm8d21LZUdH5ZWd7ex1WCRmSLw03oUE03XA7caizV/SYONDQKxevKAYjdEQ==
X-Google-Smtp-Source: AGHT+IFjkUGxHYlOkd9WCuFHriZThhK2iMWaveC+gFwm7yeYfIFNIWTV6UtgIr20M3azGBMPi+mm0w==
X-Received: by 2002:a05:6512:61cb:20b0:55f:4839:d045 with SMTP id 2adb3069b0e04-579e212f56cmr2369774e87.32.1758376585501;
        Sat, 20 Sep 2025 06:56:25 -0700 (PDT)
Received: from nuclight.lan (broadband-77-37-180-76.ip.moscow.rt.ru. [77.37.180.76])
        by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-57d5d872509sm34356e87.47.2025.09.20.06.56.24
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 20 Sep 2025 06:56:25 -0700 (PDT)
Date: Sat, 20 Sep 2025 16:56:21 +0300
From: Vadim Goncharov 
To: "Bjoern A. Zeeb" 
Cc: Andriy Gapon , "net@FreeBSD.org" 
Subject: Re: DHCP on multi-homed host, some thoughts
Message-ID: <20250920165621.25009928@nuclight.lan>
In-Reply-To: 
References: <6abe9da1-9818-438b-ad8f-5424e50a39ce@FreeBSD.org>
	
X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.4)
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-Transfer-Encoding: 7bit
X-Spamd-Bar: ----
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-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cTWBY2gNcz3TRh

On Sat, 20 Sep 2025 07:06:56 +0000 (UTC)
"Bjoern A. Zeeb"  wrote:

> But chosing an upstream DNS with the wrong source address often won't
> work.  At least here ISPs won't allow you to use their resolver if you
> are not coming from their IP range.
> The answer then really is to run a local resolver independent on
> upstream for as long as that is feasible and working (*).
[...]
> (*) and before anyone suggests any of the open resolvers which collect
> your data, please leave this thread alone.

This way, while works, is not very good for Internet as a whole, and top-level
DNS servers in particular, due to increased number of requests because of
caches in the network are not utilized; and increased latency for user.
And who will pay for this?

Not that I'm advocating for N.N.N.N collectors but they, like ISP resolvers,
don't have this problem.

-- 
WBR, @nuclight

From nobody Sat Sep 20 14:39:43 2025
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 4cTX941NyRz67wCP
	for ; Sat, 20 Sep 2025 14:40:24 +0000 (UTC)
	(envelope-from cross+freebsd@relay.distal.com)
Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.105.136])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cTX932ngPz3ZB6
	for ; Sat, 20 Sep 2025 14:40:23 +0000 (UTC)
	(envelope-from cross+freebsd@relay.distal.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=relay.distal.com header.s=mail header.b=HpWy2IRW;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of cross+freebsd@relay.distal.com designates 168.235.105.136 as permitted sender) smtp.mailfrom=cross+freebsd@relay.distal.com
dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail;
	c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References;
	bh=Z8xCCNE9Yp54bloherr/FxFJBnf+8oFuaVir3uFpIJ4=;
	b=HpWy2IRWCtbJ1spOeAKVMbKRvmdu1zbm3LfR1A0QuNX4nggm91qd7W07GfJV/jD/JTEtIflLAEn2jBXrA9UIVZ+dKKk73Cukx8DHTJ6rzZLXTJ94rgu/G3zPQt4RsuiuAxbpzu656U3isMsyKqwO1pK6yknpBXSE6MpclZYOSMKw721d3tJF6UgO0a/+mElrSmvzhXcbqIsDqtheOQgmGBzU73S7fZoq9xDQ07ObcdPMvS9MeOyEwnlT43
	XuMa0AMfFs5cakAejPqJtf/Hk8U0s1FJGd9kvWUgCCX4neh0n0wwbTvlMdJsqvfeY3OBMXz9P3abVqpEeuER4Bqfezrw==
Received: from mail.distal.com (pool-108-51-233-124.washdc.fios.verizon.net [108.51.233.124])
 by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305
 bits=256) ; Sat, 20 Sep 2025 14:40:16 +0000
Received: from smtpclient.apple (magrathea.distal.com [206.138.151.12]) by tristain.distal.com
 (OpenSMTPD) with ESMTPSA id dc2a6845 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO)
 for ; Sat, 20 Sep 2025 10:40:14 -0400 (EDT)
From: Chris Ross 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 \(3826.700.81\))
Subject: Re: IPv6 networking problems in 14.3
Date: Sat, 20 Sep 2025 10:39:43 -0400
References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com>
 <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com> <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com>
 <611820c2-05f8-40bc-9b07-bef012183e30@denninger.net> <408DE851-47FF-476E-B7F6-C7920A93DD43@distal.com>
 <1BF72AB3-69B6-4BC6-BA5B-6517BD35E41D@distal.com>
To: freebsd-net@freebsd.org
In-Reply-To: <1BF72AB3-69B6-4BC6-BA5B-6517BD35E41D@distal.com>
Message-Id: 
X-Mailer: Apple Mail (2.3826.700.81)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[cross@distal.com,cross@relay.distal.com];
	R_DKIM_ALLOW(-0.20)[relay.distal.com:s=mail];
	R_SPF_ALLOW(-0.20)[+a:relay.dynu.com];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[distal.com];
	RCVD_TLS_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TAGGED_FROM(0.00)[freebsd];
	DKIM_TRACE(0.00)[relay.distal.com:+];
	FROM_HAS_DN(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_NEQ_ENVFROM(0.00)[cross@distal.com,cross@relay.distal.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-net@freebsd.org];
	APPLE_MAILER_COMMON(0.00)[];
	ARC_NA(0.00)[]
X-Rspamd-Queue-Id: 4cTX932ngPz3ZB6



> On Sep 18, 2025, at 16:36, Chris Ross  =
wrote:
>=20
>> On 17 Sep 2025, at 14:20, Chris Ross  =
wrote:
>> So, on the idea of trying to back-date the whole machine, I have ZFS
>> snapshots of the whole root from just before the first upgrade,
>> Aug 7/8.  [=E2=80=A6]
>=20
> [...]  I=E2=80=99ve set bootfs to the older 14.1 system and gotten =
that running.
>=20
> It [...] out SOLICIT6 messages and [..] if I waited long enough (2ish
> hours in my case), it eventually did get an answer!

And, this is where things went odd again.  The above attempt in older
filesystem, I had during boot menu chosen my ROUTER custom kernel.  Just
a config I traditionally use that has fewer devices in it occupying =
memory.
So, thinking it shouldn=E2=80=99t make a difference I rebooted into the =
default,
GENERIC, kernel on the system.  The default kernel had problems [1], so =
I
chose the boot/kernel.generic on the fs.

Sadly, it did not work.  I get the same state where the router LL is
unroutable, ndp -an shows no MAC for it, and I have no IPv6.  So,
despite thinking the kernel config wasn=E2=80=99t key detail, I booted =
back
into kernel.router.  Now I have no IPv6 there either.  I tried just
shutting down dhcpcd overnight to see if it ISP was confused, but no =
help.

So, it certainly could be the ISP, but the fact that I=E2=80=99m getting =
RA=E2=80=99s
(and dhcp6 responses) which dhcpcd is processing, but then the MAC for
the routers LL isn=E2=80=99t available to the system, makes me think =
it=E2=80=99s _not_
the ISP.  I can=E2=80=99t imagine why a working rootfs and kernel could
show a system level problem intermittently, though.

Thoughts again invited.  Not able to reproduce success now, I don=E2=80=99=
t
know that I can actually _test_ anything, but I=E2=80=99d love to hear =
thoughts
about any options/possibilities.

                   - Chris




[1] Sadly there is something wrong with /boot/kernel in that fs.  When
  I boot it I get a number of:

  KLD uhid.ko: depends on kernel - not available or version mismatch
  KLD ums.ko: depends on kernel - not available or version mismatch
  KLD usbhid.ko: depends on kernel - not available or version mismatch
  KLD uhid.ko: depends on kernel - not available or version mismatch

  errors late in boot.  That kernel is 14.1-RELEASE-p7 (despite the fs
  freebsd-update made named =
zroot/ROOT/14.1-RELEASE-p8_2025-08-08_074410).
  The rest of the kernels I have on the fs are 14.1p5. something must be
  off with that one.  So I booted /boot/kernel.generic, 14.1p5, and it
  boots fine.

Current output log of dhcpcd: note "fe80::3e8a:b0ff:fe3e:4dce is =
unreachable=E2=80=9D.
That=E2=80=99s a kernel routing issue, and I think the primary problem.

Sep 20 10:20:32 [30273]: vlan0: REPLY6 received from =
fe80::3e8a:b0ff:fe3e:4dce
Sep 20 10:20:32 [30273]: vlan0: renew in 3600, rebind in 5760, expire in =
7200 seconds
Sep 20 10:20:32 [30273]: lo0: adding reject route to =
2600:4040:2c9c:2d00::/56 via ::1
Sep 20 10:20:32 [30273]: vlan0: writing lease: =
/var/db/dhcpcd/vlan0.lease6
Sep 20 10:20:32 [30273]: vlan0: delegated prefix =
2600:4040:2c9c:2d00::/56
Sep 20 10:20:32 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks BOUND6
Sep 20 10:29:08 [30273]: vlan0: Router Advertisement from =
fe80::3e8a:b0ff:fe3e:4dce
Sep 20 10:29:08 [30273]: vlan0: no global addresses for default route
Sep 20 10:29:08 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT
Sep 20 10:30:15 [30273]: vlan0: fe80::3e8a:b0ff:fe3e:4dce is unreachable
Sep 20 10:30:15 [30273]: vlan0: delaying IPv6 router solicitation for =
0.7 seconds
Sep 20 10:30:16 [30273]: vlan0: soliciting an IPv6 router
Sep 20 10:30:16 [30273]: vlan0: sending Router Solicitation
Sep 20 10:30:16 [30273]: vlan0: Router Advertisement from =
fe80::3e8a:b0ff:fe3e:4dce
Sep 20 10:30:16 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT



From nobody Sat Sep 20 14:39:43 2025
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 4cTX9470Gkz67wJM
	for ; Sat, 20 Sep 2025 14:40:24 +0000 (UTC)
	(envelope-from cross+freebsd@relay.distal.com)
Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.105.136])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cTX934b0Nz3ZML
	for ; Sat, 20 Sep 2025 14:40:23 +0000 (UTC)
	(envelope-from cross+freebsd@relay.distal.com)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=relay.distal.com header.s=mail header.b=HpWy2IRW;
	dmarc=none;
	spf=pass (mx1.freebsd.org: domain of cross+freebsd@relay.distal.com designates 168.235.105.136 as permitted sender) smtp.mailfrom=cross+freebsd@relay.distal.com
dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail;
	c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References;
	bh=Z8xCCNE9Yp54bloherr/FxFJBnf+8oFuaVir3uFpIJ4=;
	b=HpWy2IRWCtbJ1spOeAKVMbKRvmdu1zbm3LfR1A0QuNX4nggm91qd7W07GfJV/jD/JTEtIflLAEn2jBXrA9UIVZ+dKKk73Cukx8DHTJ6rzZLXTJ94rgu/G3zPQt4RsuiuAxbpzu656U3isMsyKqwO1pK6yknpBXSE6MpclZYOSMKw721d3tJF6UgO0a/+mElrSmvzhXcbqIsDqtheOQgmGBzU73S7fZoq9xDQ07ObcdPMvS9MeOyEwnlT43
	XuMa0AMfFs5cakAejPqJtf/Hk8U0s1FJGd9kvWUgCCX4neh0n0wwbTvlMdJsqvfeY3OBMXz9P3abVqpEeuER4Bqfezrw==
Received: from mail.distal.com (pool-108-51-233-124.washdc.fios.verizon.net [108.51.233.124])
 by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305
 bits=256) ; Sat, 20 Sep 2025 14:40:16 +0000
Received: from smtpclient.apple (magrathea.distal.com [206.138.151.12]) by tristain.distal.com
 (OpenSMTPD) with ESMTPSA id 5adcefbc (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO)
 for ; Sat, 20 Sep 2025 10:40:15 -0400 (EDT)
From: Chris Ross 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 \(3826.700.81\))
Subject: Re: IPv6 networking problems in 14.3
Date: Sat, 20 Sep 2025 10:39:43 -0400
References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com>
 <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com> <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com>
 <611820c2-05f8-40bc-9b07-bef012183e30@denninger.net> <408DE851-47FF-476E-B7F6-C7920A93DD43@distal.com>
 <1BF72AB3-69B6-4BC6-BA5B-6517BD35E41D@distal.com>
To: freebsd-net@freebsd.org
In-Reply-To: <1BF72AB3-69B6-4BC6-BA5B-6517BD35E41D@distal.com>
Message-Id: 
X-Mailer: Apple Mail (2.3826.700.81)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.20 / 15.00];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	FORGED_SENDER(0.30)[cross@distal.com,cross@relay.distal.com];
	R_DKIM_ALLOW(-0.20)[relay.distal.com:s=mail];
	R_SPF_ALLOW(-0.20)[+a:relay.dynu.com];
	MIME_GOOD(-0.10)[text/plain];
	RCPT_COUNT_ONE(0.00)[1];
	DMARC_NA(0.00)[distal.com];
	RCVD_TLS_ALL(0.00)[];
	TO_MATCH_ENVRCPT_ALL(0.00)[];
	TAGGED_FROM(0.00)[freebsd];
	DKIM_TRACE(0.00)[relay.distal.com:+];
	FROM_HAS_DN(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_DN_NONE(0.00)[];
	RCVD_COUNT_TWO(0.00)[2];
	FROM_NEQ_ENVFROM(0.00)[cross@distal.com,cross@relay.distal.com];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org];
	MID_RHS_MATCH_FROM(0.00)[];
	MLMMJ_DEST(0.00)[freebsd-net@freebsd.org];
	APPLE_MAILER_COMMON(0.00)[];
	ARC_NA(0.00)[]
X-Rspamd-Queue-Id: 4cTX934b0Nz3ZML



> On Sep 18, 2025, at 16:36, Chris Ross  =
wrote:
>=20
>> On 17 Sep 2025, at 14:20, Chris Ross  =
wrote:
>> So, on the idea of trying to back-date the whole machine, I have ZFS
>> snapshots of the whole root from just before the first upgrade,
>> Aug 7/8.  [=E2=80=A6]
>=20
> [...]  I=E2=80=99ve set bootfs to the older 14.1 system and gotten =
that running.
>=20
> It [...] out SOLICIT6 messages and [..] if I waited long enough (2ish
> hours in my case), it eventually did get an answer!

And, this is where things went odd again.  The above attempt in older
filesystem, I had during boot menu chosen my ROUTER custom kernel.  Just
a config I traditionally use that has fewer devices in it occupying =
memory.
So, thinking it shouldn=E2=80=99t make a difference I rebooted into the =
default,
GENERIC, kernel on the system.  The default kernel had problems [1], so =
I
chose the boot/kernel.generic on the fs.

Sadly, it did not work.  I get the same state where the router LL is
unroutable, ndp -an shows no MAC for it, and I have no IPv6.  So,
despite thinking the kernel config wasn=E2=80=99t key detail, I booted =
back
into kernel.router.  Now I have no IPv6 there either.  I tried just
shutting down dhcpcd overnight to see if it ISP was confused, but no =
help.

So, it certainly could be the ISP, but the fact that I=E2=80=99m getting =
RA=E2=80=99s
(and dhcp6 responses) which dhcpcd is processing, but then the MAC for
the routers LL isn=E2=80=99t available to the system, makes me think =
it=E2=80=99s _not_
the ISP.  I can=E2=80=99t imagine why a working rootfs and kernel could
show a system level problem intermittently, though.

Thoughts again invited.  Not able to reproduce success now, I don=E2=80=99=
t
know that I can actually _test_ anything, but I=E2=80=99d love to hear =
thoughts
about any options/possibilities.

                   - Chris




[1] Sadly there is something wrong with /boot/kernel in that fs.  When
  I boot it I get a number of:

  KLD uhid.ko: depends on kernel - not available or version mismatch
  KLD ums.ko: depends on kernel - not available or version mismatch
  KLD usbhid.ko: depends on kernel - not available or version mismatch
  KLD uhid.ko: depends on kernel - not available or version mismatch

  errors late in boot.  That kernel is 14.1-RELEASE-p7 (despite the fs
  freebsd-update made named =
zroot/ROOT/14.1-RELEASE-p8_2025-08-08_074410).
  The rest of the kernels I have on the fs are 14.1p5. something must be
  off with that one.  So I booted /boot/kernel.generic, 14.1p5, and it
  boots fine.

Current output log of dhcpcd: note "fe80::3e8a:b0ff:fe3e:4dce is =
unreachable=E2=80=9D.
That=E2=80=99s a kernel routing issue, and I think the primary problem.

Sep 20 10:20:32 [30273]: vlan0: REPLY6 received from =
fe80::3e8a:b0ff:fe3e:4dce
Sep 20 10:20:32 [30273]: vlan0: renew in 3600, rebind in 5760, expire in =
7200 seconds
Sep 20 10:20:32 [30273]: lo0: adding reject route to =
2600:4040:2c9c:2d00::/56 via ::1
Sep 20 10:20:32 [30273]: vlan0: writing lease: =
/var/db/dhcpcd/vlan0.lease6
Sep 20 10:20:32 [30273]: vlan0: delegated prefix =
2600:4040:2c9c:2d00::/56
Sep 20 10:20:32 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks BOUND6
Sep 20 10:29:08 [30273]: vlan0: Router Advertisement from =
fe80::3e8a:b0ff:fe3e:4dce
Sep 20 10:29:08 [30273]: vlan0: no global addresses for default route
Sep 20 10:29:08 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT
Sep 20 10:30:15 [30273]: vlan0: fe80::3e8a:b0ff:fe3e:4dce is unreachable
Sep 20 10:30:15 [30273]: vlan0: delaying IPv6 router solicitation for =
0.7 seconds
Sep 20 10:30:16 [30273]: vlan0: soliciting an IPv6 router
Sep 20 10:30:16 [30273]: vlan0: sending Router Solicitation
Sep 20 10:30:16 [30273]: vlan0: Router Advertisement from =
fe80::3e8a:b0ff:fe3e:4dce
Sep 20 10:30:16 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT



From nobody Sat Sep 20 14:58:41 2025
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 4cTXZX3zp6z67xmx
	for ; Sat, 20 Sep 2025 14:59:00 +0000 (UTC)
	(envelope-from pusateri@keehole.org)
Received: from kem.keehole.org (kem.keehole.org [136.41.224.255])
	(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 mx1.freebsd.org (Postfix) with ESMTPS id 4cTXZW17YDz3c9B
	for ; Sat, 20 Sep 2025 14:58:59 +0000 (UTC)
	(envelope-from pusateri@keehole.org)
Authentication-Results: mx1.freebsd.org;
	dkim=pass header.d=keehole.org header.s=202408 header.b="N/v4AwxK";
	dmarc=pass (policy=none) header.from=keehole.org;
	spf=pass (mx1.freebsd.org: domain of pusateri@keehole.org designates 136.41.224.255 as permitted sender) smtp.mailfrom=pusateri@keehole.org
Received: from smtpclient.apple (dhcp-67-145-164-9.gobrightspeed.net [67.145.164.9])
	(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by kem.keehole.org (Postfix) with ESMTPSA id 248A3733C5;
	Sat, 20 Sep 2025 10:58:52 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=keehole.org;
	s=202408; t=1758380332;
	bh=Zj8BXJZuBtFI4dCAytTVhh5+lpged/Wk3uQgr0U58js=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
	b=N/v4AwxKgoy+j4mTHORz+ctk+OBG1nDtEj13MTTd/F1+xRxQufYWsFmKp5dkLHovP
	 Z0I1+eQ1GBAUa3iLhITVAAeb/Zkmmv8nK62x1yZeDKnp5emMhUCSNvx5XmCiNNSE0Y
	 P6Vvgb2mMd3EInYIA1yIsmj3EEgAcnFO9HYm4ayJMfGLMobslbwcbgHiSwp1Dh8bcv
	 cttP1/vQJTr+TgCO0himoC/AN50DSi5lZ2xIInaKoNT7tZq2LJ0CtoYLVYXeeKe5LD
	 JVT6lBTzMVvcJxWf+o4CeEc24VGGZ7xQKHTGFOPZEkumX0QmL+rPr1Wo2iAoHgKKmL
	 G2bYHjLW+t9Qg==
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 \(3826.700.81\))
Subject: Re: IPv6 networking problems in 14.3
From: Tom Pusateri 
In-Reply-To: 
Date: Sat, 20 Sep 2025 10:58:41 -0400
Cc: freebsd-net@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <910737314.4002.1757962919189@localhost>
 <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com>
 <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com>
 <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com>
 <611820c2-05f8-40bc-9b07-bef012183e30@denninger.net>
 <408DE851-47FF-476E-B7F6-C7920A93DD43@distal.com>
 <1BF72AB3-69B6-4BC6-BA5B-6517BD35E41D@distal.com>
 
To: Chris Ross 
X-Mailer: Apple Mail (2.3826.700.81)
X-Spamd-Bar: ---
X-Spamd-Result: default: False [-3.80 / 15.00];
	NEURAL_HAM_MEDIUM(-1.00)[-1.000];
	NEURAL_HAM_LONG(-1.00)[-1.000];
	NEURAL_HAM_SHORT(-1.00)[-1.000];
	DMARC_POLICY_ALLOW(-0.50)[keehole.org,none];
	R_SPF_ALLOW(-0.20)[+mx];
	R_DKIM_ALLOW(-0.20)[keehole.org:s=202408];
	ONCE_RECEIVED(0.20)[];
	MIME_GOOD(-0.10)[text/plain];
	DKIM_TRACE(0.00)[keehole.org:+];
	FROM_HAS_DN(0.00)[];
	RCPT_COUNT_TWO(0.00)[2];
	RCVD_TLS_ALL(0.00)[];
	ARC_NA(0.00)[];
	RCVD_COUNT_ONE(0.00)[1];
	RCVD_VIA_SMTP_AUTH(0.00)[];
	MIME_TRACE(0.00)[0:+];
	TO_MATCH_ENVRCPT_SOME(0.00)[];
	FROM_EQ_ENVFROM(0.00)[];
	ASN(0.00)[asn:16591, ipnet:136.32.0.0/11, country:US];
	MLMMJ_DEST(0.00)[freebsd-net@freebsd.org];
	APPLE_MAILER_COMMON(0.00)[];
	MID_RHS_MATCH_FROM(0.00)[];
	TAGGED_RCPT(0.00)[freebsd];
	TO_DN_SOME(0.00)[]
X-Rspamd-Queue-Id: 4cTXZW17YDz3c9B

Have you considered simplifying everything to the most basic setup =
first. It=E2=80=99s hard to keep up with what you=E2=80=99re doing. If =
it were me, I would use a different box with a new install of a release =
version of 14.3 and test a direct connection to the ONT (no switch, just =
a cable). Knowing whether that works will dictate your next steps. =
Surely you can find an old piece of hardware to put a clean install on =
that you can locate right next to the ONT. If it doesn=E2=80=99t work, =
then try a new install of the release version of 14.2. If that doesn=E2=80=
=99t work, try 14.1. Get a standard and simple setup working and then =
work your way backwards.

Simplifying is key. Removing as many unknowns is key.

Tom

> On Sep 20, 2025, at 10:39=E2=80=AFAM, Chris Ross =
 wrote:
>=20
>=20
>=20
>> On Sep 18, 2025, at 16:36, Chris Ross  =
wrote:
>>=20
>>> On 17 Sep 2025, at 14:20, Chris Ross  =
wrote:
>>> So, on the idea of trying to back-date the whole machine, I have ZFS
>>> snapshots of the whole root from just before the first upgrade,
>>> Aug 7/8.  [=E2=80=A6]
>>=20
>> [...]  I=E2=80=99ve set bootfs to the older 14.1 system and gotten =
that running.
>>=20
>> It [...] out SOLICIT6 messages and [..] if I waited long enough (2ish
>> hours in my case), it eventually did get an answer!
>=20
> And, this is where things went odd again.  The above attempt in older
> filesystem, I had during boot menu chosen my ROUTER custom kernel.  =
Just
> a config I traditionally use that has fewer devices in it occupying =
memory.
> So, thinking it shouldn=E2=80=99t make a difference I rebooted into =
the default,
> GENERIC, kernel on the system.  The default kernel had problems [1], =
so I
> chose the boot/kernel.generic on the fs.
>=20
> Sadly, it did not work.  I get the same state where the router LL is
> unroutable, ndp -an shows no MAC for it, and I have no IPv6.  So,
> despite thinking the kernel config wasn=E2=80=99t key detail, I booted =
back
> into kernel.router.  Now I have no IPv6 there either.  I tried just
> shutting down dhcpcd overnight to see if it ISP was confused, but no =
help.
>=20
> So, it certainly could be the ISP, but the fact that I=E2=80=99m =
getting RA=E2=80=99s
> (and dhcp6 responses) which dhcpcd is processing, but then the MAC for
> the routers LL isn=E2=80=99t available to the system, makes me think =
it=E2=80=99s _not_
> the ISP.  I can=E2=80=99t imagine why a working rootfs and kernel =
could
> show a system level problem intermittently, though.
>=20
> Thoughts again invited.  Not able to reproduce success now, I don=E2=80=99=
t
> know that I can actually _test_ anything, but I=E2=80=99d love to hear =
thoughts
> about any options/possibilities.
>=20
>                   - Chris
>=20
>=20
>=20
>=20
> [1] Sadly there is something wrong with /boot/kernel in that fs.  When
>  I boot it I get a number of:
>=20
>  KLD uhid.ko: depends on kernel - not available or version mismatch
>  KLD ums.ko: depends on kernel - not available or version mismatch
>  KLD usbhid.ko: depends on kernel - not available or version mismatch
>  KLD uhid.ko: depends on kernel - not available or version mismatch
>=20
>  errors late in boot.  That kernel is 14.1-RELEASE-p7 (despite the fs
>  freebsd-update made named =
zroot/ROOT/14.1-RELEASE-p8_2025-08-08_074410).
>  The rest of the kernels I have on the fs are 14.1p5. something must =
be
>  off with that one.  So I booted /boot/kernel.generic, 14.1p5, and it
>  boots fine.
>=20
> Current output log of dhcpcd: note "fe80::3e8a:b0ff:fe3e:4dce is =
unreachable=E2=80=9D.
> That=E2=80=99s a kernel routing issue, and I think the primary =
problem.
>=20
> Sep 20 10:20:32 [30273]: vlan0: REPLY6 received from =
fe80::3e8a:b0ff:fe3e:4dce
> Sep 20 10:20:32 [30273]: vlan0: renew in 3600, rebind in 5760, expire =
in 7200 seconds
> Sep 20 10:20:32 [30273]: lo0: adding reject route to =
2600:4040:2c9c:2d00::/56 via ::1
> Sep 20 10:20:32 [30273]: vlan0: writing lease: =
/var/db/dhcpcd/vlan0.lease6
> Sep 20 10:20:32 [30273]: vlan0: delegated prefix =
2600:4040:2c9c:2d00::/56
> Sep 20 10:20:32 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks BOUND6
> Sep 20 10:29:08 [30273]: vlan0: Router Advertisement from =
fe80::3e8a:b0ff:fe3e:4dce
> Sep 20 10:29:08 [30273]: vlan0: no global addresses for default route
> Sep 20 10:29:08 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT
> Sep 20 10:30:15 [30273]: vlan0: fe80::3e8a:b0ff:fe3e:4dce is =
unreachable
> Sep 20 10:30:15 [30273]: vlan0: delaying IPv6 router solicitation for =
0.7 seconds
> Sep 20 10:30:16 [30273]: vlan0: soliciting an IPv6 router
> Sep 20 10:30:16 [30273]: vlan0: sending Router Solicitation
> Sep 20 10:30:16 [30273]: vlan0: Router Advertisement from =
fe80::3e8a:b0ff:fe3e:4dce
> Sep 20 10:30:16 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT
>=20
>=20
>=20


From nobody Sat Sep 20 15:32:30 2025
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 4cTYKr3mdKz680WZ
	for ; Sat, 20 Sep 2025 15:33:04 +0000 (UTC)
	(envelope-from cross+freebsd@relay.distal.com)
Received: from relay.wiredblade.com (relay.wiredblade.com [168.235.105.136])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(Client did not present a certificate)
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cTYKr0j6yz3hSn
	for ; Sat, 20 Sep 2025 15:33:03 +0000 (UTC)
	(envelope-from cross+freebsd@relay.distal.com)
Authentication-Results: mx1.freebsd.org;
	none
dkim-signature: v=1; a=rsa-sha256; d=relay.distal.com; s=mail;
	c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References;
	bh=MAtR9YsnLmQXtJJabfmR+7KqNb2VcMUSdPWXvOeWXW0=;
	b=Y94UEwfDRzLk02X+nP/pvH1a50HeXLlHgycrsdpd+FiRsh3mXA+V8GGFCYx4HxzxyGoWAwS/kCLzecDLgj7Q2KQO2dF1he0LnN3+X2CE4ehPxWXWA0hrV7wMYKAIVw6dA1KFrJBt7/W/YGf4Tu4QoXmyXdHMLrE6KBXt/avkyLhvcJxx7JnuMjUFIHP5N1dEwpAEFZkpLAkBwULyVVgTXCklwYnvNdbb5Fj1SAx19cdlpYLxrFdBBHeRU6
	6pQcZhqucT66UT8i/uWGGOYD7RT46qgHaz9/hcUPyL4HthifbfnYygxXbQ1KASdiyLQlcWqC4nBtDJyUUsCXRkidXIqw==
Received: from mail.distal.com (pool-108-51-233-124.washdc.fios.verizon.net [108.51.233.124])
 by relay.wiredblade.com with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305
 bits=256) ; Sat, 20 Sep 2025 15:33:02 +0000
Received: from smtpclient.apple (magrathea.distal.com [206.138.151.12]) by tristain.distal.com
 (OpenSMTPD) with ESMTPSA id 3b75f24e (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO);
 Sat, 20 Sep 2025 11:33:01 -0400 (EDT)
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 \(3826.700.81\))
Subject: Re: IPv6 networking problems in 14.3
From: Chris Ross 
In-Reply-To: 
Date: Sat, 20 Sep 2025 11:32:30 -0400
Cc: freebsd-net@freebsd.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B8F394F-9247-4FB3-BF7F-18EAD9631E1C@distal.com>
References: <910737314.4002.1757962919189@localhost> <55365E3D-B7EA-4F95-BC1E-92910A2944EA@distal.com>
 <90A490DE-6BF0-4EBB-97CE-ECA690E2359C@distal.com> <5D82826E-8C0F-45CF-B9FF-093FD014E73F@distal.com>
 <611820c2-05f8-40bc-9b07-bef012183e30@denninger.net> <408DE851-47FF-476E-B7F6-C7920A93DD43@distal.com>
 <1BF72AB3-69B6-4BC6-BA5B-6517BD35E41D@distal.com> 
 
To: Tom Pusateri 
X-Mailer: Apple Mail (2.3826.700.81)
X-Spamd-Bar: ----
X-Spamd-Result: default: False [-4.00 / 15.00];
	REPLY(-4.00)[];
	TAGGED_FROM(0.00)[freebsd];
	ASN(0.00)[asn:3842, ipnet:168.235.104.0/22, country:US]
X-Rspamd-Pre-Result: action=no action;
	module=replies;
	Message is reply to one we originated
X-Rspamd-Queue-Id: 4cTYKr0j6yz3hSn



> On Sep 20, 2025, at 10:58, Tom Pusateri  wrote:
>=20
> Have you considered simplifying everything to the most basic setup =
first. It=E2=80=99s hard to keep up with what you=E2=80=99re doing. If =
it were me, I would use a different box with a new install of a release =
version of 14.3 and test a direct connection to the ONT (no switch, just =
a cable). Knowing whether that works will dictate your next steps. =
Surely you can find an old piece of hardware to put a clean install on =
that you can locate right next to the ONT. If it doesn=E2=80=99t work, =
then try a new install of the release version of 14.2. If that doesn=E2=80=
=99t work, try 14.1. Get a standard and simple setup working and then =
work your way backwards.
>=20
> Simplifying is key. Removing as many unknowns is key.

Thank you.  That=E2=80=99s a good suggestion.  I do have a tendency both =
to
make things to complicated, and also to change as few variables as
possible.  But, there are too many variables here already, I now see.

I don=E2=80=99t know that removing the switches is possible, but =
everything else
should be.  I=E2=80=99ll try to prep a system for that so that I can =
experiment
when I am able to next deny internet to the house.  ;-)

- Chris

>> On Sep 20, 2025, at 10:39=E2=80=AFAM, Chris Ross =
 wrote:
>>=20
>>=20
>>=20
>>> On Sep 18, 2025, at 16:36, Chris Ross  =
wrote:
>>>=20
>>>> On 17 Sep 2025, at 14:20, Chris Ross  =
wrote:
>>>> So, on the idea of trying to back-date the whole machine, I have =
ZFS
>>>> snapshots of the whole root from just before the first upgrade,
>>>> Aug 7/8.  [=E2=80=A6]
>>>=20
>>> [...]  I=E2=80=99ve set bootfs to the older 14.1 system and gotten =
that running.
>>>=20
>>> It [...] out SOLICIT6 messages and [..] if I waited long enough =
(2ish
>>> hours in my case), it eventually did get an answer!
>>=20
>> And, this is where things went odd again.  The above attempt in older
>> filesystem, I had during boot menu chosen my ROUTER custom kernel.  =
Just
>> a config I traditionally use that has fewer devices in it occupying =
memory.
>> So, thinking it shouldn=E2=80=99t make a difference I rebooted into =
the default,
>> GENERIC, kernel on the system.  The default kernel had problems [1], =
so I
>> chose the boot/kernel.generic on the fs.
>>=20
>> Sadly, it did not work.  I get the same state where the router LL is
>> unroutable, ndp -an shows no MAC for it, and I have no IPv6.  So,
>> despite thinking the kernel config wasn=E2=80=99t key detail, I =
booted back
>> into kernel.router.  Now I have no IPv6 there either.  I tried just
>> shutting down dhcpcd overnight to see if it ISP was confused, but no =
help.
>>=20
>> So, it certainly could be the ISP, but the fact that I=E2=80=99m =
getting RA=E2=80=99s
>> (and dhcp6 responses) which dhcpcd is processing, but then the MAC =
for
>> the routers LL isn=E2=80=99t available to the system, makes me think =
it=E2=80=99s _not_
>> the ISP.  I can=E2=80=99t imagine why a working rootfs and kernel =
could
>> show a system level problem intermittently, though.
>>=20
>> Thoughts again invited.  Not able to reproduce success now, I don=E2=80=
=99t
>> know that I can actually _test_ anything, but I=E2=80=99d love to =
hear thoughts
>> about any options/possibilities.
>>=20
>>                  - Chris
>>=20
>>=20
>>=20
>>=20
>> [1] Sadly there is something wrong with /boot/kernel in that fs.  =
When
>> I boot it I get a number of:
>>=20
>> KLD uhid.ko: depends on kernel - not available or version mismatch
>> KLD ums.ko: depends on kernel - not available or version mismatch
>> KLD usbhid.ko: depends on kernel - not available or version mismatch
>> KLD uhid.ko: depends on kernel - not available or version mismatch
>>=20
>> errors late in boot.  That kernel is 14.1-RELEASE-p7 (despite the fs
>> freebsd-update made named =
zroot/ROOT/14.1-RELEASE-p8_2025-08-08_074410).
>> The rest of the kernels I have on the fs are 14.1p5. something must =
be
>> off with that one.  So I booted /boot/kernel.generic, 14.1p5, and it
>> boots fine.
>>=20
>> Current output log of dhcpcd: note "fe80::3e8a:b0ff:fe3e:4dce is =
unreachable=E2=80=9D.
>> That=E2=80=99s a kernel routing issue, and I think the primary =
problem.
>>=20
>> Sep 20 10:20:32 [30273]: vlan0: REPLY6 received from =
fe80::3e8a:b0ff:fe3e:4dce
>> Sep 20 10:20:32 [30273]: vlan0: renew in 3600, rebind in 5760, expire =
in 7200 seconds
>> Sep 20 10:20:32 [30273]: lo0: adding reject route to =
2600:4040:2c9c:2d00::/56 via ::1
>> Sep 20 10:20:32 [30273]: vlan0: writing lease: =
/var/db/dhcpcd/vlan0.lease6
>> Sep 20 10:20:32 [30273]: vlan0: delegated prefix =
2600:4040:2c9c:2d00::/56
>> Sep 20 10:20:32 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks BOUND6
>> Sep 20 10:29:08 [30273]: vlan0: Router Advertisement from =
fe80::3e8a:b0ff:fe3e:4dce
>> Sep 20 10:29:08 [30273]: vlan0: no global addresses for default route
>> Sep 20 10:29:08 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT
>> Sep 20 10:30:15 [30273]: vlan0: fe80::3e8a:b0ff:fe3e:4dce is =
unreachable
>> Sep 20 10:30:15 [30273]: vlan0: delaying IPv6 router solicitation for =
0.7 seconds
>> Sep 20 10:30:16 [30273]: vlan0: soliciting an IPv6 router
>> Sep 20 10:30:16 [30273]: vlan0: sending Router Solicitation
>> Sep 20 10:30:16 [30273]: vlan0: Router Advertisement from =
fe80::3e8a:b0ff:fe3e:4dce
>> Sep 20 10:30:16 [30273]: vlan0: executing: =
/usr/local/libexec/dhcpcd-run-hooks ROUTERADVERT
>>=20
>>=20
>>=20
>=20



From nobody Sun Sep 21 12:25:57 2025
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 4cV57V40F8z68304
	for ; Sun, 21 Sep 2025 12:25:58 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cV57V1yRLz3fN0
	for ; Sun, 21 Sep 2025 12:25:58 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758457558;
	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=muBtHkpIrzfUcs9lMyI+NNknp8CMkIYac8Q4kkUhrX8=;
	b=IjD0ujKGHoseAP8/SJW+H+ISFOg70OYHQwQ4u663xs2ERvVgxxy9GXLYYJJMDA1XN76s8T
	hmHeR3+hmo+h4I1j+t5LXMJUurro2QLR4YnHkmLF0y3SxFtaVJHhzC5e8JSKH/QYkok9f1
	noCXJHFTlYvQ5Z/79RzC/FXxU7am4PDchfhwbgl7R/Bpcik2ZoLavc9npLGi5TnltwZ0p9
	v9f/WjUwj6rHf/ZT6KzGx3bAhwMZkWiD03O8o2bvtnZ6ATh3WNfK8P0yIc/NJl9A3EqtT3
	Y11RJ8BDgc9yHgugoximZ3v3YnhW/ZXgixQOgcw58kbBH9vZeu3iDmuU/cWmwg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758457558;
	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=muBtHkpIrzfUcs9lMyI+NNknp8CMkIYac8Q4kkUhrX8=;
	b=wmH9Bz7rB8sWNtyhhgOpMpueWVyhUJRtrfXGsNdiT1zBT7qZteHXCax7p1D9NomQMGE4SO
	1LUV9mUGQafOC9MSL+AqUBDrLgDI9NQKfUY7GILvyT7CMIkE+y6JtICfDJ9JGdDE4PLNnN
	yx2nvjV2zysyFoOwiGswsPivRyEBRRquf67ddSpmWg6YqjEXoC5aVBZphbm5dVwV5Q6ym8
	s5hlr4iEsj2S+5GfPCG/8SY45D2LATyhrWk/AqbmFgwo5vhGAGoPQL7bZQcSff1qI78y81
	6qvQZV4ojPL3vXE2fRyKUOdNrPfr0AwNI+SPieE+EqK1zJeppidSSspk+B38tg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758457558; a=rsa-sha256; cv=none;
	b=WGKUQpDdqRj35RqVlcxLB/Wx4R7D7T2ppCPQguuVIXPy1ArwAtKflrhtHHpJ1i0hATLVwi
	Ak79RBBBEfrVvpgR9bSX+TuCIgRfjbtWMrUa9XcXDyjWnPIRog39uHTCDW+pFd6Tgsm2Fg
	xIGTKxK6F+gR7/K0gax9YBTE1MJqXMnFpUUzR0aGGLLP9J27eJmb+NKED2ukxCcVXPjZhH
	Su1OY1uHupfkXEApx7dHAF2PmF/FbZCoyCp0zcst7jEGTdSJfIFwX4uV6ja1ia1xGzP6Pk
	zWq/FRpHBH3eKjMMOhqNaGAN8GcYqYP2+u/30+Gka9y/PJ9YOzgZ4jhsAbJhRg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cV57V1WRCzF9
	for ; Sun, 21 Sep 2025 12:25:58 +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 58LCPwcb046929
	for ; Sun, 21 Sep 2025 12:25:58 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58LCPwk5046928
	for net@FreeBSD.org; Sun, 21 Sep 2025 12:25:58 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 289734] panic tcp_usr_close while running mount command after
 configure NFS over TLS
Date: Sun, 21 Sep 2025 12:25:57 +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: 15.0-CURRENT
X-Bugzilla-Keywords: crash, vendor
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: linimon@FreeBSD.org
X-Bugzilla-Status: New
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: ---
X-Bugzilla-Assigned-To: net@FreeBSD.org
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: keywords short_desc assigned_to
Message-ID: 
In-Reply-To: 
References: 
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289734

Mark Linimon  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |crash, vendor
            Summary|[FreeBSD][NFS][TLS] panic   |panic tcp_usr_close while
                   |tcp_usr_close while running |running mount command after
                   |mount command after         |configure NFS over TLS
                   |configure NFS over TLS      |
           Assignee|bugs@FreeBSD.org            |net@FreeBSD.org

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Sep 21 13:51:33 2025
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 4cV72G0VX7z688Pb
	for ; Sun, 21 Sep 2025 13:51:34 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cV72F6MM0z3nw0
	for ; Sun, 21 Sep 2025 13:51:33 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758462693;
	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=SBPbPJ67yGEgQCgboxJvsEgfl2woH6pTk6ACRHjRmAU=;
	b=GmWF1Wa/F82iayleakkwqTU2KxpQmsal2p5VoTnfBziMaMkONfrdrE1o+EwoJ7bXL9nKeN
	ki2rRkDIUJRQMGDM+8ugQaRlQJXaabwTSWtZOIR85CxLs0wSH/5IUp1jDPOL4EWi/KfqmG
	OwzA2NTTIlES8Vc++74UCLBKtaRd3r5+8n4t8XwMxIU1gbl8dGAACsD8DtI8BQNOMvD+q5
	Jj7y8bDywlVDXMhpRVKCAntuXSYQgLbeUSdY1tGIKyH9cNx7wQntEUztT/WV+3q48T5xDq
	wNEv2p/ptvd0iNfxNIXeg7/r2Fh5Y+xtV4YQkpdF8hdxsmP5UZPj/bcc128+/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758462693;
	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=SBPbPJ67yGEgQCgboxJvsEgfl2woH6pTk6ACRHjRmAU=;
	b=nEP5X4Q1thT299rQqecLT4JuswZJ8s5NQXeP2IQ+dPBeAnCxjVNRgSM8vZZ766v5WZiOps
	ptGKVqECTHbOGezCOth0PLOJfRld0qiEtHjFth8YTp24mHP9fk1kAOUHq00pisVJev99Ls
	PAiq4HOoj8SBZrWFLjFHc5HP9tlBg77w3Ex8viOH1fHXRiPVNETz8PbTHr09mrB/RgyL+v
	WtCOfXZg4aGRmsfh5iSUzI7LyAwpAekkzh/6B8BGB7dQ5UI074wVXNMD6kdRrjbLNOrzhx
	B6eYlB/l4K/WfG3T8lKfBGxgNEnXH/K2v1DWc6lHvmILSGlah24N45tokN8L2A==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758462693; a=rsa-sha256; cv=none;
	b=Kh2CLg43G7iKEF1CbS1JrPekm9cs4hZ8SUXYyUsS9y0B48UydgBLJnNfTBzBwUh6A827ej
	4A4dNYkyfAM01PRmJwNwUTck9yMhrkDydw7jEe5a3nmk39YeEHTqIClZZNHUZcTHPyr8S6
	NwNQXdnp4zNb9mczyVUsbUdTodFHYA5die0MvpQWSM1JehGn7aX6i4CCE3D0lV6EpNEW0T
	XR+8l2cx/0LUy2SNMP4yISRm5t26GNEzKua21gk4KBib1VTVhewunzl/dWZ50aIEIT6iPz
	recUBlIkpeI14gt6bA2QS8ARn4ITwgMc7EWSI1QfD0X42KBG968gqmiBiJnTRQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cV72F5l8dz24Q
	for ; Sun, 21 Sep 2025 13:51:33 +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 58LDpXtQ071623
	for ; Sun, 21 Sep 2025 13:51:33 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58LDpXM7071622
	for net@FreeBSD.org; Sun, 21 Sep 2025 13:51:33 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 289734] panic tcp_usr_close while running mount command after
 configure NFS over TLS
Date: Sun, 21 Sep 2025 13:51:33 +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: 15.0-CURRENT
X-Bugzilla-Keywords: crash, vendor
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: rmacklem@FreeBSD.org
X-Bugzilla-Status: New
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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289734

Rick Macklem  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rmacklem@FreeBSD.org

--- Comment #1 from Rick Macklem  ---
(In reply to Wafa Hamzah from comment #0)
I haven't looked at the crash yet, but here
are a few configuration related comments:

V4: / -sec=3Dsys:krb5p:tls
There should be an error in /var/log/messages
for the above. It should look like:
V4: / -sec=3Dsys:krb5p -tls  (You only need krb5p if clients
are going to be doing sec=3Dkrb5p mounts. Also, you always
want "krb5i" as well for Linux clients because they sometimes
use "krb5i" even when you've specified "krb5p".)

Run the following command:
 # rpc.tlsservd
This suggests you didn't reboot after doing the configuration.
(Although rebooting should not be necessary, there are ordering
dependencies w.r.t. the various server daemons, so you should
(re)start all of them after setting the configuration and rebooting
is the easy way to do so.)
--> This might be why you are getting the crashes.

mount -o tls 13.0.0.2:/tmp /mnt
This is an NFSv3 mount. It should work, although I'll admit I
haven't tested using NFS-over-TLS for NFSv3 recently.
(It is a recently adopted feature aimed at NFSv4.)
--> Again, this might explain why you are getting crashes.

I will try an NFSv3 mount in a few days (I'm not at home
right now) and see if I can reproduce the crash.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Sep 21 13:56:24 2025
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 4cV77r01Mqz688nK
	for ; Sun, 21 Sep 2025 13:56:24 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cV77q6cv8z3pjs
	for ; Sun, 21 Sep 2025 13:56:23 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758462983;
	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=DPu/I7Fx85vdKXWQtMiCBH5V5siIa5z2IuIo5PtYbZE=;
	b=hkFtRARICg/8fGBftM+r3W4D4kJA0DtR8Si7NCst79FIFZvWCNtJmC84lMxb4hxqp0LJGS
	mo3ktNl8PGBQlwBEqdDYnt8Ez0h2MeB6pUeDTRkdbI6qoHjNCah9pLYiHqZ51H17GKn8Nr
	EOScfdkPfN6oFhUS74mQgmAZ5Kg6mNTTS2MkLlyh6poWvjpIGVDSyVDEiyVaeHyrXUys6d
	w9tlscAARi/jj3axQBlnPsNIviQu8sH40tk2FGndoxaY4cfq/cZJltbKLQ36p82nNgCbuP
	7+EJhYAp6IeN9YYl13SBs31ZnTIJOZBRJJMPwsOFL2ly9pcM+o3KfkCXcyLsrg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758462983;
	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=DPu/I7Fx85vdKXWQtMiCBH5V5siIa5z2IuIo5PtYbZE=;
	b=Zkzz/+wWAezF+boGpKVLoE85i2XPisZ2DAqai67XKVYMa7/qFCI13OgvZsFBWwwb4vrXG1
	DS/4olkRoXbeVsijH5f466D8zCjDZEe3465cdAovbjef525tODb68xTBa/d6Yp5lCaJnrL
	vI10X33NsPpW7upIGYxlbAmoeAUWnsrN7+t/uGPylN3TIpjqTBt6K2WU+Isu3ciIVPW1fq
	+0JfkcAjv931I/dcCHBTasSsZQYCoEUwlHW1jDAdSORvZi/vwIY6ZSKNv5O7e66NilP3Kc
	DMJvQZ4sGxGt+pw34jo23Bq4eJKS5QmiqE4aIieU5yCGRU7K4tYhQ7Gqvk2KiQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758462983; a=rsa-sha256; cv=none;
	b=mhQWyqANiwRf6k73byrT6eYpLYY6VGsf+kFdFhLEVfIZtb2bSXPpBVs6bkLuZWdxdsgcUo
	kAipP0jMrp6jUhmNH2wddqWlMXOXzAcgyRRjDVRUeFypo4w9xxl/wL1eds5hdtE/wcZOyX
	PoJKpgIhfFZUKWJ09WedexKqYJs4IzYjIoXcwVroWevzi+LaPq/5Qx/866ApLf2IHLzE4L
	Mo7j4vVZMxQWTTY9DOV4915bhNb7MDtksIhwyEj5mmkanzk1GEATJZ+l9Ynk0pcEmQRly7
	V1emw8509AbkC9Y7QWHfD+bg2wh3X5OnAXf6pkrWycPyGCaIz/JvJVd1HstJAQ==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cV77q69cXz2Gy
	for ; Sun, 21 Sep 2025 13:56:23 +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 58LDuNxk079066
	for ; Sun, 21 Sep 2025 13:56:23 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58LDuNGm079065
	for net@FreeBSD.org; Sun, 21 Sep 2025 13:56:23 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 289734] panic tcp_usr_close while running mount command after
 configure NFS over TLS
Date: Sun, 21 Sep 2025 13:56:24 +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: 15.0-CURRENT
X-Bugzilla-Keywords: crash, vendor
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: rmacklem@FreeBSD.org
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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289734

--- Comment #2 from Rick Macklem  ---
Also, you mention the Mellanox NIC.
This might be doing TLS offload.
To be honest, if it is, you are the first
person to ever test NFS-over-TLS where there
is offload hardware involved.

Hopefully someone on the TCP side will
recognize what the crash is and how to work around
it.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Sep 21 14:03:48 2025
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 4cV7JP2MKbz688vD
	for ; Sun, 21 Sep 2025 14:03:49 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cV7JP1dqNz3qtG
	for ; Sun, 21 Sep 2025 14:03:49 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758463429;
	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=4RKJ9RyJD81t4W6H0VjBn/j1q/7xS2PTuolwqc25igA=;
	b=kIrH02tusSN+OPJ7m2Z+ZHWh408XQYwQncFhXuPXPfTz5EV6Y+g+T6Xw0P2hHlY9whEm7V
	IGkg29bYpKL3hMUAxSz8Q1JcK7Sl3Sbb80KitaFcJjK2Gbt3UZZ/etCbQyYNHXcegDF0aB
	DN5st7sDF16EfgGya35RcdNHpLQI6VGahsYunIjsgNgk+/oBiIAxxaDYXCSCbLEYykV+IQ
	bzKZymrKemwRwvOrObruQDh3vqwILEXZtLxRB/AKmwfqClu6mKxj6Tmr8LMNerwuSHhNQl
	/UR9DACFVnR67/iTgewRHAFwR9QIJgUTOZECBy3GaGqvSzeoFUkogMjrtHgqtw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758463429;
	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=4RKJ9RyJD81t4W6H0VjBn/j1q/7xS2PTuolwqc25igA=;
	b=HwtkAEh1J8yv21swsYBGBIPQFAyMLFZV8xEV+HNiHS8xo1vT2i+zOXUtNFt6lQRWen1dc7
	XoVpDLif1/5PKRZDzTp/UOVeZrs/pgEEdbLbUPrlDEYoGVGgt3yvIU3SGdC6UPuBbMxdnu
	qAgmfvgLbo6ybVbuTW3nDahCOSZmmJtVfEdxrF8SNRDRkrIoS71RSMW/Z8pfCMjzGhcCEv
	liqvQoI+gQQMEmFHbrcr39w07GovB5RsZ6aaZuomL7IwQcpUnN0W9xUb1CpVTKsSZDzyMl
	5FEThyJvyXQBRQjKLvB0Jaf89HJrGFBg8dmkv6dSaWWIHNsoFK9DUjs5Z/xEBQ==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758463429; a=rsa-sha256; cv=none;
	b=fbE3HQJYTGrAgg0cZUK1mtQyQWZXj7ae5/8L8cYk+NmBRL9G8nNRQZ6t82YeNKfGX7wtrF
	xEjlGTNUDFo8FWkDV/GxvzNIq2vwsz6z4AakRX/zgqBzuhtO8DlPswSCJBDnb/wc/FPibK
	jvp/uLp3vbB4Kb9uwfTMdhy+edndyTDKS67j6//rPvKXwaHSLYCfsM5GZMMiFJFYl8F+fq
	yVTyxYOmcSx4SX2IJGtN7iMR2M3NxF0KgfdtgJAKMA44NTfAVwoELLIcYHo5E31dolRvol
	7GKTMEI+kcxDZc5bTIkvsTuIBE6xMMmXYtSuLhHQed6s9NS3xFFGlEvgtpUKWg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cV7JP0t7zz2L0
	for ; Sun, 21 Sep 2025 14:03:49 +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 58LE3mEb093862
	for ; Sun, 21 Sep 2025 14:03:48 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58LE3mgn093861
	for net@FreeBSD.org; Sun, 21 Sep 2025 14:03:48 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 289734] panic tcp_usr_close while running mount command after
 configure NFS over TLS
Date: Sun, 21 Sep 2025 14:03:48 +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: 15.0-CURRENT
X-Bugzilla-Keywords: crash, vendor
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: rmacklem@FreeBSD.org
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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289734

--- Comment #3 from Rick Macklem  ---
If you wanted to try something...
You could replace:
    KASSERT(inp !=3D NULL, ("tcp_usr_close: inp =3D=3D NULL"));
with
    if (inp =3D=3D NULL)
         return;
at the beginning of tcp_usr_close() in /usr/src/sys/netinet/tcp_usrreq.c.

Then test to see what happens?

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Sep 21 16:04:16 2025
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 4cV9zP2cTyz68JLH
	for ; Sun, 21 Sep 2025 16:04:17 +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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cV9zP1zSwz43tG
	for ; Sun, 21 Sep 2025 16:04:17 +0000 (UTC)
	(envelope-from bugzilla-noreply@freebsd.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758470657;
	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=nD7jqxMZUSiHcDqQFwswiIdFM40RbPs9Icw7Bcro15I=;
	b=dC+WuU/rG7hmY9SqG4k8I7t+KaMxajVm2Ri/94hrrybbkLVR96DS2aH4QZCOQIuRvBEjiH
	Rb7Pc0iIKX/oJXTeZsMqm5X+tdloH+sqFfYL5bPu0EwfZNuwtdlPJvTPk4uDBGQiW8FbKz
	4+kcdA1B7NOqQgO2PQzKJnF1TPV4B0zHwdCU5UX8A7WHlEcuqDJ5DbG9mnWsJmFxoozCBl
	E0ftXvyVDMmGT5l6DsnsbXkr0dAk/nVUs60sHgEjLynYBRAVK0tClh7b1gCvEFh+JCVUuL
	95KbJ5WQpgzFXAsL9z11dxD2jRiGkWUZDHmNDDXGSco26PVBFtAwDnVySrdXug==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758470657;
	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=nD7jqxMZUSiHcDqQFwswiIdFM40RbPs9Icw7Bcro15I=;
	b=QvxWNHEgd4uRG2z+zgu3UJPuCmPPBp0KB/HO3sQD6HrgpSBw5rlo5rdxfI4zBe8QxVJ/WI
	Gj4nAuOI1X3B0IjwRqVbCJlFC6woEwLflPodc5t/CEt81NYbEK3qwCKe9dSI47KMxopgRb
	rzZR9K0HZ2iE6jJ1mGAY6NcRpAklDLCqqKCxiyGtxX5jHnDIUQi9aynIFjvs3SEGSX2/7p
	FeolXsHUgunVdShD7jvaVtvzoICVpyTi3heE76Pde1BttsXug5Np0xzr1pBXK2l6wuzZwb
	Dw2g+5pOmYXcjwd/2tNnBKgwGtNNc7cFYriVD7MVc19wNZDp9UQUdQeZTPLn/Q==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758470657; a=rsa-sha256; cv=none;
	b=HSBzNmQTl2Spv34c+u0bGFzw4VxD1GbUWw7wUGklbGrgQaDqgW/wiUbgcWvVk0Y8ZkNS1Z
	BLw2r+Ik14u5MpyInJfIkuWogzbSbLAldFDiAKq+KL7W9Tk/khVld4RIifxk58NZKkdKvk
	gFNdKvht63XzfYi3DgWA2XgW5HPNPehyZ1VZHdmf0lgRJakuB8t+y9hrAGtlqlcTPnUFvM
	dis874zD1WX3MmpzUDyMVAMiz3D+yQJKQO+KGS/TLPfdaLc0tYadgTv75M38bP2mjglK3F
	tAYzJnsoDSHY+Qw6c3cCHNPhPqCJDU0OArkJzgtERr7XzRoBpBQ+DL2xlYIvZg==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cV9zP1X9gz62V
	for ; Sun, 21 Sep 2025 16:04:17 +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 58LG4Hkt077330
	for ; Sun, 21 Sep 2025 16:04:17 GMT
	(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
	by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 58LG4HET077329
	for net@FreeBSD.org; Sun, 21 Sep 2025 16:04:17 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 289734] panic tcp_usr_close while running mount command after
 configure NFS over TLS
Date: Sun, 21 Sep 2025 16:04:16 +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: 15.0-CURRENT
X-Bugzilla-Keywords: crash, vendor
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: kib@FreeBSD.org
X-Bugzilla-Status: New
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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
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=3D289734

Konstantin Belousov  changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kib@FreeBSD.org

--- Comment #4 from Konstantin Belousov  ---
(In reply to Rick Macklem from comment #2)
This is the regular test in the verification settings by Nvidia.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

From nobody Sun Sep 21 21:00:37 2025
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 4cVJYL0nmwz67yPl
	for ; Sun, 21 Sep 2025 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 "R12" (verified OK))
	by mx1.freebsd.org (Postfix) with ESMTPS id 4cVJYK4Qzqz3Zh7
	for ; Sun, 21 Sep 2025 21:00:37 +0000 (UTC)
	(envelope-from bugzilla-noreply@FreeBSD.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim;
	t=1758488437;
	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=Cg9AaSisY6RyIz/hVQiei9eL9oVblqMwjMRu/dWrPCI=;
	b=t8iwuholeN+HBy24Qi4I9TaGQmdXKm5J6/wb51KxUyBiju+ZOiKho0oqVbc8TONQiZ81NT
	l/nBKqleZIVXGhLIFr5jQBBFfo044V4ZQtR2hkPj+2/guL8s/YQ+JKkbqEBHJ+Kr/ckehA
	ByF7xBbot+ANhW0mPCq9UB1RYPPiU8U1sCvSHBOLGEnPNn49ejjZBxakklc68jNw/3u6n8
	bN8u1yLKfWxcpZzW+eaks5DgF7inW2AmuPw8SiUsy495bK0dzBYARLFgteDlibBBqbqj+S
	iIspmgxjNoUseaVoUL+jiZxGFCr9KH9mYCb8CvbrmD86bRkFPoFfIOefmqXxMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org;
	s=dkim; t=1758488437;
	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=Cg9AaSisY6RyIz/hVQiei9eL9oVblqMwjMRu/dWrPCI=;
	b=ThtOaFO0MhfhLXge+0wS0UfX0OLYc+SiJOutsmokaKy7eGE2FHn/lDeDwRj05gQqbDzQg5
	TcuIUptd9dE9tH3f2wtGk5ghgjst+SIclaTO+AcvWZbNSdpxDHnrV3Qe/M8HCakF8MtG6U
	ahUWgOhLb/KCz0mZtmNx74wfU7Zv1+j0cbkvtg02nZQNU9+Q1DHMRySEmdI4p8tYmtJIDB
	SdqIfr3Ilme5qWME2eK/WNbv7vtu6iS1Tr8yzWj/m7v1sRX/ELZ0CWQWZd5dUvz0jHUjBK
	yJviAiaIE+d+kK2MmGwtMnPEXt0eIbcPHSAbBg0h7/l9a8wUYHh2+i/Un3C3cg==
ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1758488437; a=rsa-sha256; cv=none;
	b=iV2/FrNpI1KD9FOaDErhnSeIjHG4JBES79zxuSd7OpP+subg69cRnoqUvyVWU5TznDEoyP
	bHlCDJxqFR51WwIiqdi7z7cOdDeOANOEvUxionr3oh8WbNKy6ABBkI0kV7MhiJ55wm4S1M
	jqMge46srzsStfiSe5W+LiFhzxx0azpzKUMlTcSIhkHr16+GjhZeD7uX/KG0h6xebapZtT
	K9bkZbR2sDgj8wdK3WKFNH7znowxV889Dz2XJGOPh/PXCi6/5iUYE8a459eoWiyMPBOVc3
	64ln5hb5TWWQe7qymOUIgpmW0K5NGwyAWiCJMZnJwx/RRpkkfHuwkimWPzs4OA==
ARC-Authentication-Results: i=1;
	mx1.freebsd.org;
	none
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 4cVJYK3rwVzVhK
	for ; Sun, 21 Sep 2025 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 58LL0bIC026763
	for ; Sun, 21 Sep 2025 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 58LL0bjV026762
	for net@FreeBSD.org; Sun, 21 Sep 2025 21:00:37 GMT
	(envelope-from bugzilla-noreply@FreeBSD.org)
Message-Id: <202509212100.58LL0bjV026762@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, 21 Sep 2025 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="17584884373.Ba3AF.23724"
Content-Transfer-Encoding: 7bit


--17584884373.Ba3AF.23724
Date: Sun, 21 Sep 2025 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
------------+-----------+---------------------------------------------------
In Progress |    118111 | rc: network.subr Add MAC address based interface  

1 problems total for which you should take action.

--17584884373.Ba3AF.23724
Date: Sun, 21 Sep 2025 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
------------+-----------+---------------------------------------------------
In Progress |    118111 | rc: network.subr Add MAC address based interface 

1 problems total for which you should take action.


--17584884373.Ba3AF.23724--