From nobody Mon Jun 10 23:16:45 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VynkP4fscz5N6S8 for ; Mon, 10 Jun 2024 23:16:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VynkP2fRzz4ZNK for ; Mon, 10 Jun 2024 23:16:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718061405; a=rsa-sha256; cv=none; b=ZNuZmAnvfKHfnQuHcRqNvDsVVk5zsxJVB3hHjipmIv7iJ8jSD1x7xMdV5+MLJpfQNK1QHm GFQDF2OI5JzkySdiZ7+SEWkDnIYjSiiUGllygtB5SRGdJvoxmAxSk8AklbRc0kZUnMwfY0 BbBI4mtaornECpsZ3sH5DhNvgnJxW4AWXwW1oAxjeo/DEYe+urlSWFZGM4d4mItP9y4U+v VFMh4tUJG6z29SzvIrGOVkno+ScpscWETKBdwlsCOD9rGmmIUYdjRrsvz2Gfssvv+qGSaj 3O4H9JbmxRA5Tn+YdE8bA08Sb6tBOCsqQP9wg0fNsi23Ow10CN8LlkKf2wFbwQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718061405; 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=CCNKsQCMMoqpGzlIZeGF2D5SNYKSc5MzxOFiM9gZcnQ=; b=IiuYuPtL6lSiIaqqGEUQeInNcqKi7S2mJbs3jFFFn0/1a0PIEFxOKz5poRIhsBy3EMqIWc nRo+nigOHFUgP2xPI466qHBqvujnSZsAO0t4oVxsFYI229xnY1aOucdyjLv5VbX4WrYu46 mp5xRMJEwOl2feLqWS46pTEnSBTqTm1l03BgfiTEZLEovcTseRumzhTRWHyurY5vaEfeIY a3VYFJkzfd9xxuyatSNfBdUjb8IfcVafipaK/4G8pN1TWKeG0m7eT5ibaKm6yqM9cPznpp lAyPpw+f8H9RCYO68R/r1df65AhRFF4E7BHrDzUESHwVIuyMkjOv4ecas+TOsg== 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 4VynkP2F9tzlVB for ; Mon, 10 Jun 2024 23:16:45 +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 45ANGjwx006132 for ; Mon, 10 Jun 2024 23:16:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 45ANGjJn006131 for net@FreeBSD.org; Mon, 10 Jun 2024 23:16:45 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 279653] Page fault in in6_selecthlim Date: Mon, 10 Jun 2024 23:16:45 +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.0-STABLE 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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279653 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 Tue Jun 11 01:51:22 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vys8q3vpcz5NMjR for ; Tue, 11 Jun 2024 01:51:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vys8q2s16z4pRP for ; Tue, 11 Jun 2024 01:51:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718070683; a=rsa-sha256; cv=none; b=UfpnMQy08MmENxhiPw+CDJYC5db/dtZO0wP2AqFZ5Qqf6XjJvOK5p3vW3oSTou9vTLuDIo o5OA6u5v8hQKOSuDxoTv3Pez0uRFW4BHZp9BJB6Hnz8Ft33MJp4etRs5lEmKsppVRhqXqQ CSKsLVtvmjQm3nauj2uSA+eodp3cnOpihIniPv7d5zd6SIKNgj/IujYx0lby/OTCKDZyiQ 9V+1a4dsTkZ/t+p8gdDnpka2SiR/zr9kKWbxhYdLxJpynPjWiiDj6I0FTkS6XXsyBirKyv g/4yLACouQ1B7CK+Mz1yMKkJa7pE6DQYo93Ag9cWs7URNage+9UmJAnqHyntBQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718070683; 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=EzERQdPzfS5vkBYd5Me2qYDFTdz8ohqU/TZktw+4eZQ=; b=g6U7pQ8NrHQznsrUHzN4nwtwvGTPnJdqRKiG7cvpTlenEpd+McdExGClnuO9K7iqsh+2Py J10FFgDmEdCtPqNWqTNDulN94Fwht2P5GJFyBEGi6dZPr3UQuxdxkz+rNUhmx+ozBst43s hqGE3hUl4YvWoztrHgFlNE7Qgcq6rXulpp7HOUyJyoSO3lEDBWbAQBGGpDs1uxOkQ4wrxM qqbN4Qcov1lkh3STzIuz6Ciqgn0EU+s4Uhm0q0k6yaYvJExHFu5cQc2pEx3gtQtzKQQrLF QtTrrqaDSWCl3I13U6ZmVUSx9/FfoZ+LDn9imeZzYNs5lL0zAFbOCKQpD88gsw== 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 4Vys8q2TdVzqRM for ; Tue, 11 Jun 2024 01:51: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 45B1pNc5016457 for ; Tue, 11 Jun 2024 01:51:23 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 45B1pNVj016456 for net@FreeBSD.org; Tue, 11 Jun 2024 01:51: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 279653] Page fault in in6_selecthlim Date: Tue, 11 Jun 2024 01:51:22 +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.0-STABLE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: zlei@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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279653 Zhenlei Huang changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zlei@FreeBSD.org --- Comment #1 from Zhenlei Huang --- (In reply to Daniel Ponte from comment #0) The stack trace is weird. The caller `sys/netinet/tcp_output.c` ``` 1444 ip6->ip6_hlim =3D in6_selecthlim(inp, NULL); ``` The callee, `sys/netinet6/in6_src.c`: ``` 843 int 844 in6_selecthlim(struct inpcb *inp, struct ifnet *ifp) 845 { 846=20 847 if (inp && inp->in6p_hops >=3D 0) 848 return (inp->in6p_hops); 849 else if (ifp) 850 return (ND_IFINFO(ifp)->chlim); 851 else if (inp && !IN6_IS_ADDR_UNSPECIFIED(&inp->in6p_faddr)) { ... } ``` The line 850 of should never hit as `ifp` is NULL, the backtrace also shows that clearly. That is quite odd ... Is it possible that kgdb report the wrong line number= ? --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Jun 11 10:09:57 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vz4D54xBSz5P4r2 for ; Tue, 11 Jun 2024 10:09:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vz4D519R4z4Ml4 for ; Tue, 11 Jun 2024 10:09:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718100597; a=rsa-sha256; cv=none; b=gDMMoHBHNODZvGahWtAowE93H+5jjnw4ybbpPh4kRiWMRTmR3w294mAq9yWi8x+1c+c5vl LEydXlq4i3zYvK7AAgGvf0+zIis/bZyP9T85RLnwN6KXtuu2wv2FH+fyqHF2d4sDF8ofuj fMcQPyhilrDMOkfCkRAtucIUoHtsTF3gzY6cz8GnmtiQMJ7aKgsm7gzE2PSognJ8rV+hLY s4Oj99IiKxW44veWg0eo//kvetq1JvkkSL8NOde+7oSvdeP47LxQSQwNSw7RAwDN6q9wSg utNjpHCgkFsK84ww+jBb89kzl63+pxvbWM8anFtTtqMU04zw1DmwYki4SP7JJQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718100597; 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=fErnHhZ9QjZPp/DP5NOZXAQ4BTp7pTSwoszhcJVGicQ=; b=ceS/OTVO+3MpeG2sGWpDca/SNQO5L3yiuBLqYg5kNkUkeFtZVo0MkQsDejjBJj0coGWJha oklLy/BCd8UdywLZnPOaQPaxR2WlIWGWtYtpGLf9RlRtLnKZyXgE2TUTbcEXW9MnPy+kh2 H+hjoypoycc/jS12yfUrFveh/C6nuzgWr0HSDumpd5eNrwYpyiYDNiM7qH/En7L/GDbyEe S4qdQg+Wci0N3aUbvltKqEAvkR0HadzGG6IdAjrIWkGpRUulxT09pPyBgK6Mh1XqYEKhOs u7RGxhP6xqpAP7VSSe7KGl3cqAWwKwjZd6nVT18G2vAdxrZ07ykmSMWUenO8BA== 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 4Vz4D50cZpz14fl for ; Tue, 11 Jun 2024 10:09:57 +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 45BA9ukt043570 for ; Tue, 11 Jun 2024 10:09:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 45BA9u9O043568 for net@FreeBSD.org; Tue, 11 Jun 2024 10:09:56 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 279653] Page fault in in6_selecthlim Date: Tue, 11 Jun 2024 10:09: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: 14.0-STABLE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279653 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org --- Comment #2 from Andrey V. Elsukov --- (In reply to Zhenlei Huang from comment #1) fault virtual address =3D 0x10 corresponds to offset of nd_ifinfo field in = struct in6_ifextra that is returned by if_getafdata(). --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jun 12 15:33:20 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VzqLm35Lzz5Mw7c for ; Wed, 12 Jun 2024 15:33: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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VzqLm1rfnz4Vc0 for ; Wed, 12 Jun 2024 15:33:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718206400; a=rsa-sha256; cv=none; b=LaYB84+jPA2ezQmw7Pzw/2612MnQzs0GPBEn6O3HPmxkJZIvY0FUb3ck/XjuGAcRl6vjqE OREjDUjDFMSw7L9c6C0F6pRs1kYzi+53NijGP/HgVqDcYqiHV+P8auKG9i7eRMdy/r/QD4 eYKXcXJumHtWkMX/kR9P0Z7XTi5ALnryj2KzgqWnEQOEgm3i7y2bTmYM6sHWWD5g/aLi5Z FGTvVkDpjkDBlpOFmZXLEO/qo4yAeFSyCJfoNyvbfmVton56eDfqQ42BYSH/TXusEs3zpV MojZ5F7+3/2Cph8bZNZYkR7stxrdlaqw9nYlq/XQ8VtTMkMa7QsZjpO6LOeQRA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718206400; 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=REurZ9ivdgg4FCbum7KG/61GZUszVYzO+Rn1sWX4FA0=; b=oBBlS6LNGs2lWyzB52XJ75d0OGph9a1fKE0rL0vTat8v4QfipiVImsAFxqzX7ZGgOICwJ4 kRgHmCoszP4w3Xuf5l1fWUZHn7Lj68FoQE32PmRY08o6UGbh/YDrGAb1KtF8SLgpb1sHP8 hARtxipXvE4+tg5pptnqO0kFrx+HcSwfgttM62rFNLvC9wG1PfX2F0BHAmqKPwkx2TMSlE 6PLQi8kgJeqXiPy92oFBjUKE32ZnKX0xB7Wp4IhG5bO2wb9INbcdI/7VJtdvNWXMh8XI4r UnAE8Gg7wTKJRT2UFcz/n5l8P5pTxIn6+aoFWpYqQh5Hvh+Eg+1C1dagSbnMFQ== 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 4VzqLm1S3RzymX for ; Wed, 12 Jun 2024 15:33: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 45CFXKVC086755 for ; Wed, 12 Jun 2024 15:33:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 45CFXKb7086752 for net@FreeBSD.org; Wed, 12 Jun 2024 15:33: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 279550] tun interface get stuck and cannot be destroyed Date: Wed, 12 Jun 2024 15:33: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.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: r4@sovserv.ru X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279550 --- Comment #2 from Ivan --- Sorry for the sub reply, but I'm not getting any emails from bugzilla for s= ome reason. It happened once, after some time the stuck interface self-destructed. It h= as not reproduced again so far. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jun 12 15:33:20 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VzqLn103Tz5Mw7j for ; Wed, 12 Jun 2024 15:33: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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VzqLm61Ryz4VW2 for ; Wed, 12 Jun 2024 15:33:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718206400; a=rsa-sha256; cv=none; b=UAjtXvXvZvXFIpmDzauudD6v1EIrb3udxeAGXYwbg2466i6WORXn7zqaqQDoXw+mpQSkaG SrbzHFJE21Pm/IM6NUth/2W10zw9y7OGmYYEJpnxAsikOEzeY/n5ygW0UYwMvz8pqb6LIq DNMviK5/boai/0qEc3Uch+0syCq4ylXGkvRiOkR71N/mJQqvR/Gc0DFHfdAw1rB+PPjjZF 7d/9aXGHXxmhrUT/NyIuMRfZKzB/gP2gJNCpztU56DRNhzbYew8DzhWS0Cytu3fZmiw/Cv q6uJEmUAI8sFfsTwR2TptI+BmKSyNmT2+ck4eiPO5Xbe92x1J5ZZYc904JJpyw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718206400; 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=bENVh6UW8t0Zjl+A5sZ0oyQC2opIf2cG5PqmvsmGA/U=; b=jdpqjTHJQc9QQBPPfafK4HmhyXFIfIviJu2PhNbC6vA2Z3tnY3iN1tFP8DNhZwskPHenTI XpOabZ3kGMRXGCxH/4qjHnU/JXnvi+iHKncJleBvD4x0R1uDaoyq/0bAXfwfH6J/IIKD/J 2/6LbnzIxaQpGsv7FxAi7LfsBfmvEJy9nEDF1ywXluVGmgd52gU5MtcUtl0658bUE1TTgK hKEiq0tD6aODBH/xHxhsluQwvoHKIyBMihxp5KddPHoyVYXEDABol3zaqZqhRv2jPAfpU1 DxTdOQzSXgGGZnbsP9WxWi7dRYeoKs1T/Xv7vFYwboBAX5h7+13w0v7OoW7hNg== 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 4VzqLm5Vj1zykV for ; Wed, 12 Jun 2024 15:33: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 45CFXKSO086795 for ; Wed, 12 Jun 2024 15:33:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 45CFXKXj086794 for net@FreeBSD.org; Wed, 12 Jun 2024 15:33: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 279550] tun interface get stuck and cannot be destroyed Date: Wed, 12 Jun 2024 15:33: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.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: r4@sovserv.ru X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279550 --- Comment #2 from Ivan --- Sorry for the sub reply, but I'm not getting any emails from bugzilla for s= ome reason. It happened once, after some time the stuck interface self-destructed. It h= as not reproduced again so far. --- Comment #3 from Ivan --- Sorry for the sub reply, but I'm not getting any emails from bugzilla for s= ome reason. It happened once, after some time the stuck interface self-destructed. It h= as not reproduced again so far. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Jun 12 21:47:54 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vzzg61KBgz5NWpy for ; Wed, 12 Jun 2024 21:48:02 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vzzg50xjkz4NC7; Wed, 12 Jun 2024 21:48:01 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gndrsh.dnsmgr.net; spf=pass (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net designates 65.75.216.6 as permitted sender) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 45CLls89042314; Wed, 12 Jun 2024 14:47:54 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 45CLlsgN042313; Wed, 12 Jun 2024 14:47:54 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202406122147.45CLlsgN042313@gndrsh.dnsmgr.net> Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: To: Ed Maste Date: Wed, 12 Jun 2024 14:47:54 -0700 (PDT) CC: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.896]; DMARC_POLICY_ALLOW(-0.50)[gndrsh.dnsmgr.net,none]; R_SPF_ALLOW(-0.20)[+ip4:65.75.216.0/23]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4Vzzg50xjkz4NC7 > I propose that we start dropping inbound ICMP REDIRECTs by default, by > setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and > changing the associated rc.conf machinery). I've opened a Phabricator > review at https://reviews.freebsd.org/D45102. I propse that we NOT do this. If you need this to protect your end node your probably doing something really unsafe network wise. The place that ICMP REDIRECTS should be dropped, and is most places, is at access routers and firewalls. Any one that needs this change to protect there network has larger issues than an ICMP REDIECT causing some issues. ICMP redirectr are very usefull for not having to run routing protocols on all your end nodes and allowing your edge/access routers tell your internal hosts via redirects how to get to places more efficiently. > > ICMP REDIRECTs served a useful purpose in earlier networks, but on They still serve this very usefull purpose. > balance are more likely to represent a security issue today than to > provide a routing benefit. With the change in review it is of course > still possible to enable them if desired for a given installation. > This change would appear in FreeBSD 15.0 and would not be MFC'd. > > One question raised in the review is about switching the default to > YES but keeping the special handling for "auto" (dropping ICMP > REDIRECT if a routing daemon is in use, honouring them if not). I > don't think this is particularly valuable given that auto was > introduced to override the default NO when necessary; there's no need > for it with the default being YES. That functionality could be > maintained if there is a compelling use case, though. The policy that is there now is exactly how things should be configured for a host in a network protected by a proper router w/firewall. The existing "auto" does exactly the right thing. > > If you have any questions or feedback please follow up here or in the review. > > -- Rod Grimes rgrimes@freebsd.org From nobody Wed Jun 12 22:05:39 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W003Z6BjLz5NXx2 for ; Wed, 12 Jun 2024 22:05:46 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W003Z4Mcnz4S41; Wed, 12 Jun 2024 22:05:46 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 45CM5esh018851; Wed, 12 Jun 2024 15:05:46 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1718229946; x=1718230546; r=y; bh=FaP2M6eO7bzOnrXkcNfpZG6k0oTzQ0Q/prS3hcASwbA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=bLJh3RFTDWV0Dld8qzU6k/tSsAODledgv9GU1LPHM+3erRM+DsLvQHU4xHrf3rX+I kznIvOXh14SAmxvbNTKIHbPX4HKq0khdfnMmVtgAG217oa0QSoLJfhjyKhz8EEThR/ un6T4BlH9S1QqsRkhk6RrbzvlcKqs41IQUyEjdJV1vgZdVXrYRaBwufK5HRRbXb0M7 wqzPyxs77s1HRqRes0VESKlY7oJ+pehiFfrRdaW0QkGyWUgG6gmNGROTVBRxK4Ty4q gqt9gLQ4O7rZA4QmZ+lw0LAzuOKXYOABRLSGoNMjI1n56hS/oQzqwLVa4d/rw6wp79 D5ezbRYbtHSoQ== 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: Wed, 12 Jun 2024 15:05:39 -0700 From: Chris To: "Rodney W. Grimes" Cc: Ed Maste , freebsd-net@freebsd.org Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: <202406122147.45CLlsgN042313@gndrsh.dnsmgr.net> References: <202406122147.45CLlsgN042313@gndrsh.dnsmgr.net> User-Agent: UDNSMS/17.0 Message-ID: <72ceb2fe26812a237a17bd8de4024b7f@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4W003Z4Mcnz4S41 On 2024-06-12 14:47, Rodney W. Grimes wrote: >> I propose that we start dropping inbound ICMP REDIRECTs by default, by >> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >> changing the associated rc.conf machinery). I've opened a Phabricator >> review at https://reviews.freebsd.org/D45102. > > I propse that we NOT do this. If you need this to protect your end > node your probably doing something really unsafe network wise. The > place that ICMP REDIRECTS should be dropped, and is most places, is > at access routers and firewalls. > > Any one that needs this change to protect there network has larger > issues than an ICMP REDIECT causing some issues. > > ICMP redirectr are very usefull for not having to run routing > protocols on all your end nodes and allowing your edge/access > routers tell your internal hosts via redirects how to get to > places more efficiently. > >> >> ICMP REDIRECTs served a useful purpose in earlier networks, but on > They still serve this very usefull purpose. > >> balance are more likely to represent a security issue today than to >> provide a routing benefit. With the change in review it is of course >> still possible to enable them if desired for a given installation. >> This change would appear in FreeBSD 15.0 and would not be MFC'd. >> >> One question raised in the review is about switching the default to >> YES but keeping the special handling for "auto" (dropping ICMP >> REDIRECT if a routing daemon is in use, honouring them if not). I >> don't think this is particularly valuable given that auto was >> introduced to override the default NO when necessary; there's no need >> for it with the default being YES. That functionality could be >> maintained if there is a compelling use case, though. > > The policy that is there now is exactly how things should be configured > for a host in a network protected by a proper router w/firewall. > The existing "auto" does exactly the right thing. > >> >> If you have any questions or feedback please follow up here or in the >> review. As Rodeney already effectively explains; dropping packets makes routing, and discovery exceedingly difficult. Which is NOT what the average user wants, or expects. I use "set block-policy drop" in pf(4). But as already noted, this is for "filtering" purposes. Your suggestion also has the negative affect of hanging remote ports. Which can result in other negative results by peers. Please don't. :) >> >> --Chris From nobody Wed Jun 12 22:37:04 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W00lr4Ndkz5NbJM for ; Wed, 12 Jun 2024 22:37:12 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W00lq48xGz4WQy; Wed, 12 Jun 2024 22:37:11 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ultimatedns.net header.s=mx99 header.b=M1XpBQ8X; spf=none (mx1.freebsd.org: domain of bsd-lists@bsdforge.com has no SPF policy when checking 24.113.41.81) 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 45CMb5HQ091289; Wed, 12 Jun 2024 15:37:11 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1718231831; x=1718232431; r=y; bh=fTvLKGEkOXtlLwIG6hno8NI/LdgTkk7oCIHjWJ2oR4s=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=M1XpBQ8XcELhqo2U+j4PwhP4olSgMVyT/J8HcY3jaVcP3m0OuxD4Kg1GlId/4VFkt NhfWuLQD2kHh6nn5gsrg9z/lm3P+q4LmSrnvat/k5NkCe64DmUuYWYoJU0ZZTuQbbQ acsUzuc0XUMSIbn0FDbdJw9XHZ7YQIMjbVwnGzOUOw8y0BHf4suGNbHyPdR1ta0Z+L Ka/K6XdnJ7JV6s+dZQYduRKer4PvQKR7eSGMfL8dIOUjl+pid84YC4fAuN9xtSEtSm IFWHb+QqN0GtxgiZPZsuo+2NNZMzBe7g3LEvAH0u6XTTztaTS5leyE2tKgPB7g2I+C NnS0c1MwkmqKw== 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: Wed, 12 Jun 2024 15:37:04 -0700 From: Chris To: "Rodney W. Grimes" Cc: Ed Maste , freebsd-net@freebsd.org Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: <72ceb2fe26812a237a17bd8de4024b7f@bsdforge.com> References: <202406122147.45CLlsgN042313@gndrsh.dnsmgr.net> <72ceb2fe26812a237a17bd8de4024b7f@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: <7628aa81fb381a08cbb1c2fabf6bc493@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [-0.20 / 15.00]; R_DKIM_ALLOW(-0.20)[ultimatedns.net:s=mx99]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; DKIM_TRACE(0.00)[ultimatedns.net:+]; R_SPF_NA(0.00)[no SPF record]; local_wl_ip(0.00)[24.113.41.81]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4W00lq48xGz4WQy On 2024-06-12 15:05, Chris wrote: > On 2024-06-12 14:47, Rodney W. Grimes wrote: >>> I propose that we start dropping inbound ICMP REDIRECTs by default, by >>> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >>> changing the associated rc.conf machinery). I've opened a Phabricator >>> review at https://reviews.freebsd.org/D45102. >> >> I propse that we NOT do this. If you need this to protect your end >> node your probably doing something really unsafe network wise. The >> place that ICMP REDIRECTS should be dropped, and is most places, is >> at access routers and firewalls. >> >> Any one that needs this change to protect there network has larger >> issues than an ICMP REDIECT causing some issues. >> >> ICMP redirectr are very usefull for not having to run routing >> protocols on all your end nodes and allowing your edge/access >> routers tell your internal hosts via redirects how to get to >> places more efficiently. >> >>> >>> ICMP REDIRECTs served a useful purpose in earlier networks, but on >> They still serve this very usefull purpose. >> >>> balance are more likely to represent a security issue today than to >>> provide a routing benefit. With the change in review it is of course >>> still possible to enable them if desired for a given installation. >>> This change would appear in FreeBSD 15.0 and would not be MFC'd. >>> >>> One question raised in the review is about switching the default to >>> YES but keeping the special handling for "auto" (dropping ICMP >>> REDIRECT if a routing daemon is in use, honouring them if not). I >>> don't think this is particularly valuable given that auto was >>> introduced to override the default NO when necessary; there's no need >>> for it with the default being YES. That functionality could be >>> maintained if there is a compelling use case, though. >> >> The policy that is there now is exactly how things should be configured >> for a host in a network protected by a proper router w/firewall. >> The existing "auto" does exactly the right thing. >> >>> >>> If you have any questions or feedback please follow up here or in the >>> review. > As Rodeney already effectively explains; dropping packets makes routing, > and discovery exceedingly difficult. Which is NOT what the average user > wants, > or expects. I use "set block-policy drop" in pf(4). But as already noted, > this is for "filtering" purposes. Your suggestion also has the negative > affect > of hanging remote ports. Which can result in other negative results by > peers. > > Please don't. :) >>> >>> > --Chris OK, now having actually read the (phab) review. I'm of the opposite opinion. Your review seems to make the right decision. :) --Chris From nobody Thu Jun 13 13:34:21 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0NgQ25kSz5Ngvg for ; Thu, 13 Jun 2024 13:34:42 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0NgP5VhRz46k2; Thu, 13 Jun 2024 13:34:41 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 45DDYLQ1044762; Thu, 13 Jun 2024 06:34:21 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 45DDYLg5044761; Thu, 13 Jun 2024 06:34:21 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: <7628aa81fb381a08cbb1c2fabf6bc493@bsdforge.com> To: Chris Date: Thu, 13 Jun 2024 06:34:21 -0700 (PDT) CC: "Rodney W. Grimes" , Ed Maste , freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4W0NgP5VhRz46k2 > On 2024-06-12 15:05, Chris wrote: > > On 2024-06-12 14:47, Rodney W. Grimes wrote: > >>> I propose that we start dropping inbound ICMP REDIRECTs by default, by > >>> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and > >>> changing the associated rc.conf machinery). I've opened a Phabricator > >>> review at https://reviews.freebsd.org/D45102. > >> > >> I propse that we NOT do this. If you need this to protect your end > >> node your probably doing something really unsafe network wise. The > >> place that ICMP REDIRECTS should be dropped, and is most places, is > >> at access routers and firewalls. > >> > >> Any one that needs this change to protect there network has larger > >> issues than an ICMP REDIECT causing some issues. > >> > >> ICMP redirectr are very usefull for not having to run routing > >> protocols on all your end nodes and allowing your edge/access > >> routers tell your internal hosts via redirects how to get to > >> places more efficiently. > >> > >>> > >>> ICMP REDIRECTs served a useful purpose in earlier networks, but on > >> They still serve this very usefull purpose. > >> > >>> balance are more likely to represent a security issue today than to > >>> provide a routing benefit. With the change in review it is of course > >>> still possible to enable them if desired for a given installation. > >>> This change would appear in FreeBSD 15.0 and would not be MFC'd. > >>> > >>> One question raised in the review is about switching the default to > >>> YES but keeping the special handling for "auto" (dropping ICMP > >>> REDIRECT if a routing daemon is in use, honouring them if not). I > >>> don't think this is particularly valuable given that auto was > >>> introduced to override the default NO when necessary; there's no need > >>> for it with the default being YES. That functionality could be > >>> maintained if there is a compelling use case, though. > >> > >> The policy that is there now is exactly how things should be configured > >> for a host in a network protected by a proper router w/firewall. > >> The existing "auto" does exactly the right thing. > >> > >>> > >>> If you have any questions or feedback please follow up here or in the > >>> review. > > As Rodeney already effectively explains; dropping packets makes routing, > > and discovery exceedingly difficult. Which is NOT what the average user > > wants, > > or expects. I use "set block-policy drop" in pf(4). But as already noted, > > this is for "filtering" purposes. Your suggestion also has the negative > > affect > > of hanging remote ports. Which can result in other negative results by > > peers. > > > > Please don't. :) > >>> > >>> > > --Chris > OK, now having actually read the (phab) review. I'm of the opposite opinion. > Your review seems to make the right decision. :) You do get that the final effect of the change is that by default ALL freeBSD boxes well be dropping ICMP REDIRECTS, both routers and end nodes. I know first hand that this change WOULD break my network(s) in locations that have more than 1 router as all of the interior hosts simply depend on an ICMP redirect to get them using the optimal router after they wrongly use the default router for a packet. A quick check on Ubunty 22.04 and Debian 12 indicate these are stlll accepted by default on those systems. Again, this is gona be one of those "bite someone in the ass" and your actually not providing any real security to anyone by making this change. If this is such a security issue, how come FREEFALL.freebsd.org still has: net.inet.icmp.drop_redirect: 0 Because it does not need to do that, because it is properly protected by routers and firewalls that do the dropping for them. DOG food Dog FOOD DOG FOOD!!! -- Rod Grimes rgrimes@freebsd.org From nobody Thu Jun 13 13:39:13 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0Nml55CLz5NhKW for ; Thu, 13 Jun 2024 13:39:19 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0Nmk6PH6z47Xs; Thu, 13 Jun 2024 13:39:18 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gndrsh.dnsmgr.net; spf=pass (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net designates 65.75.216.6 as permitted sender) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 45DDdD8D044780; Thu, 13 Jun 2024 06:39:13 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 45DDdDma044779; Thu, 13 Jun 2024 06:39:13 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202406131339.45DDdDma044779@gndrsh.dnsmgr.net> Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: To: Ed Maste Date: Thu, 13 Jun 2024 06:39:13 -0700 (PDT) CC: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.69 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.893]; DMARC_POLICY_ALLOW(-0.50)[gndrsh.dnsmgr.net,none]; R_SPF_ALLOW(-0.20)[+ip4:65.75.216.0/23]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4W0Nmk6PH6z47Xs > I propose that we start dropping inbound ICMP REDIRECTs by default, by > setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and > changing the associated rc.conf machinery). I've opened a Phabricator > review at https://reviews.freebsd.org/D45102. > > ICMP REDIRECTs served a useful purpose in earlier networks, but on > balance are more likely to represent a security issue today than to > provide a routing benefit. With the change in review it is of course > still possible to enable them if desired for a given installation. > This change would appear in FreeBSD 15.0 and would not be MFC'd. > > One question raised in the review is about switching the default to > YES but keeping the special handling for "auto" (dropping ICMP > REDIRECT if a routing daemon is in use, honouring them if not). I > don't think this is particularly valuable given that auto was > introduced to override the default NO when necessary; there's no need > for it with the default being YES. That functionality could be > maintained if there is a compelling use case, though. > > If you have any questions or feedback please follow up here or in the review. Discarding ICMP redirects on a internet host is non-conformant with STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. -- Rod Grimes rgrimes@freebsd.org From nobody Thu Jun 13 15:02:50 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0QdN1ZWMz5NpST for ; Thu, 13 Jun 2024 15:03:04 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) (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 4W0QdM6cZXz4K2M for ; Thu, 13 Jun 2024 15:03:03 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-f182.google.com with SMTP id e9e14a558f8ab-375d39a0714so5740555ab.1 for ; Thu, 13 Jun 2024 08:03:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718290982; x=1718895782; 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=COjtQYSOJxUwyHLEo2P9mRVe5L6C3CO3Zs/63eQ3jhY=; b=CSdqmgtZ9Qy6T/xOTHRmNhrRp+RLxlHye9DKOMqX2QAvVRLroSbPzsoO+NhjhCxEXG shEeor3rtjuZY7sPlbShc9FvSJZcYU69mrSxrUXCXUajgbS6WAjZFFX4Az5FZD0w1wyK XGDNutz8aeG9Z2IoEMu9J8W3Hc1rpl6J9DjPjuYmsTMVV/hyUNqWnMKBLdonbwMVTAiD PhlTZQd1dQet43eGt3i7TjzWD3XZAE77rYHk14tumAThJ/hL3W7PTf9FBIOgMBTc3agw I01rrotILTjvdlU+smEsI3dTC+1W5UHMJGBKSHW/mEWvVOzATcBvqNvTD1Av18Ha3tVH lQrg== X-Gm-Message-State: AOJu0Yy4sOlLKdmbYgrK5ew4rigZteWczvU2ZjEOVZPMaq2k2au4EU3f AFVl18HvRqGobzxxl9JKJO0zTvDnGE10QkQLt9yYUSc/R/yThrSQcHk43VSltoD2F2Jx45whxKg EdurWwa3+/fpAhUNR64AghNiadhyvIw== X-Google-Smtp-Source: AGHT+IEQ+D9lYrjkseDaqMGHddJCZXUyAbcAEJcUkA8g8IiCE2+wDm4EGu5c3qlpvWYdwxFLXGKNay4ZTG0pEW5/sIo= X-Received: by 2002:a05:6e02:1a86:b0:375:c394:4344 with SMTP id e9e14a558f8ab-375cd1e44famr54109025ab.21.1718290982508; Thu, 13 Jun 2024 08:03:02 -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: <202406131339.45DDdDma044779@gndrsh.dnsmgr.net> In-Reply-To: <202406131339.45DDdDma044779@gndrsh.dnsmgr.net> From: Ed Maste Date: Thu, 13 Jun 2024 11:02:50 -0400 Message-ID: Subject: Re: Discarding inbound ICMP REDIRECT by default To: "Rodney W. Grimes" Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4W0QdM6cZXz4K2M On Thu, 13 Jun 2024 at 09:39, Rodney W. Grimes wrote: > > Discarding ICMP redirects on a internet host is non-conformant with > STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. In that case our default of "auto" is non-conformant if you have a routing daemon. From nobody Thu Jun 13 17:02:09 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0TGx562qz5P0PM for ; Thu, 13 Jun 2024 17:02:17 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0TGx1qmxz4YJd; Thu, 13 Jun 2024 17:02:17 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 45DH29bE047482; Thu, 13 Jun 2024 10:02:16 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1718298136; x=1718298736; r=y; bh=znYIFesuug++IoLB9CVCkGSdmwhdj0C5YUY4/7dlH2M=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=fKsHBKntoWqHG6NAfgOrN9Uek22zuvb7Mw2oySXWaxb0OJee5M7PC6UIdJdu0sLuv GP8YTJMgvh/SJoR7IjsSw8eYIzQEwEEJO9m9zxBeFIzAs8YFoXGiBeNAJ8Iep+dXgE OJ3GDQYlFL+PX+unfH1wA5saHUJaWxRhbb9610achJp88rjejVCs1SkYchLWAO1B9d u4eeEYyYt60muz4dd9iyMUS5lJCbF4dsGa7jwXlNg7hBhwzbmI3XwIn4EAu+uNKxFX 5D9eN6XLMenbxmHbISdoBjHLw04rrHT5tlQSPJTSFCL3Iz09X080y5t6+9bgYPadup EnIW85/kZF+uw== 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: Thu, 13 Jun 2024 10:02:09 -0700 From: Chris To: "Rodney W. Grimes" Cc: Ed Maste , freebsd-net@freebsd.org Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> References: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> User-Agent: UDNSMS/17.0 Message-ID: <458c91d8529cf1cb2218f8ba62e706ae@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4W0TGx1qmxz4YJd On 2024-06-13 06:34, Rodney W. Grimes wrote: >> On 2024-06-12 15:05, Chris wrote: >> > On 2024-06-12 14:47, Rodney W. Grimes wrote: >> >>> I propose that we start dropping inbound ICMP REDIRECTs by default, by >> >>> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >> >>> changing the associated rc.conf machinery). I've opened a Phabricator >> >>> review at https://reviews.freebsd.org/D45102. >> >> >> >> I propse that we NOT do this. If you need this to protect your end >> >> node your probably doing something really unsafe network wise. The >> >> place that ICMP REDIRECTS should be dropped, and is most places, is >> >> at access routers and firewalls. >> >> >> >> Any one that needs this change to protect there network has larger >> >> issues than an ICMP REDIECT causing some issues. >> >> >> >> ICMP redirectr are very usefull for not having to run routing >> >> protocols on all your end nodes and allowing your edge/access >> >> routers tell your internal hosts via redirects how to get to >> >> places more efficiently. >> >> >> >>> >> >>> ICMP REDIRECTs served a useful purpose in earlier networks, but on >> >> They still serve this very usefull purpose. >> >> >> >>> balance are more likely to represent a security issue today than to >> >>> provide a routing benefit. With the change in review it is of course >> >>> still possible to enable them if desired for a given installation. >> >>> This change would appear in FreeBSD 15.0 and would not be MFC'd. >> >>> >> >>> One question raised in the review is about switching the default to >> >>> YES but keeping the special handling for "auto" (dropping ICMP >> >>> REDIRECT if a routing daemon is in use, honouring them if not). I >> >>> don't think this is particularly valuable given that auto was >> >>> introduced to override the default NO when necessary; there's no need >> >>> for it with the default being YES. That functionality could be >> >>> maintained if there is a compelling use case, though. >> >> >> >> The policy that is there now is exactly how things should be configured >> >> for a host in a network protected by a proper router w/firewall. >> >> The existing "auto" does exactly the right thing. >> >> >> >>> >> >>> If you have any questions or feedback please follow up here or in the >> >>> review. >> > As Rodeney already effectively explains; dropping packets makes routing, >> > and discovery exceedingly difficult. Which is NOT what the average user >> > wants, >> > or expects. I use "set block-policy drop" in pf(4). But as already noted, >> > this is for "filtering" purposes. Your suggestion also has the negative >> > affect >> > of hanging remote ports. Which can result in other negative results by >> > peers. >> > >> > Please don't. :) >> >>> >> >>> >> > --Chris >> OK, now having actually read the (phab) review. I'm of the opposite >> opinion. >> Your review seems to make the right decision. :) > > You do get that the final effect of the change is that by default ALL > freeBSD boxes well be dropping ICMP REDIRECTS, both routers and end > nodes. > > I know first hand that this change WOULD break my network(s) in locations > that have more than 1 router as all of the interior hosts simply depend > on an ICMP redirect to get them using the optimal router after they > wrongly use the default router for a packet. > > A quick check on Ubunty 22.04 and Debian 12 indicate these are stlll > accepted by default on those systems. > > Again, this is gona be one of those "bite someone in the ass" and your > actually not providing any real security to anyone by making this change. > > If this is such a security issue, how come FREEFALL.freebsd.org still > has: > net.inet.icmp.drop_redirect: 0 > > Because it does not need to do that, because it is properly protected > by routers and firewalls that do the dropping for them. > > DOG food Dog FOOD DOG FOOD!!! Firstly, please accept my apology for incorrectly spelling your name. :/ Secondly, my "reversal" of opinion on the matter was based upon my assumption on what would be returned by "auto". Closer examination, and reviewing your reply here, I think you're right, as was my original response. Accepting the new changes, as you say; will bite me in the ass -- well, will make my job (and others) more challenging. While I can appreciate the intent to keep users from getting "spoofed" packets that lead them into trouble. I think this is more a matter of responsible (network) administration. Maybe a better solution could be sent from rc(8) if FreeBSD thinks you've made the wrong decision here? Because the proposed change(s) look to me to only make routing and discovery more problematic. Thanks for commenting, (and correcting me) Rodney. :) --Chris From nobody Thu Jun 13 18:01:22 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0VbL74lBz5P4lK for ; Thu, 13 Jun 2024 18:01:34 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0VbL39BNz4fg0; Thu, 13 Jun 2024 18:01:34 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 45DI1MbI045632; Thu, 13 Jun 2024 11:01:22 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 45DI1MZu045631; Thu, 13 Jun 2024 11:01:22 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202406131801.45DI1MZu045631@gndrsh.dnsmgr.net> Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: To: Ed Maste Date: Thu, 13 Jun 2024 11:01:22 -0700 (PDT) CC: "Rodney W. Grimes" , freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4W0VbL39BNz4fg0 [ Charset UTF-8 unsupported, converting... ] > On Thu, 13 Jun 2024 at 09:39, Rodney W. Grimes > wrote: > > > > Discarding ICMP redirects on a internet host is non-conformant with > > STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. > > In that case our default of "auto" is non-conformant if you have a > routing daemon. NO, because then your not subject to rfc-1122 as your now a router, not a host. -- Rod Grimes rgrimes@freebsd.org From nobody Thu Jun 13 18:18:02 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0VyY03vQz5P6FQ for ; Thu, 13 Jun 2024 18:18:13 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0VyX2drfz4j2Q; Thu, 13 Jun 2024 18:18:12 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 45DII3oq004930; Thu, 13 Jun 2024 11:18:09 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1718302690; x=1718303290; r=y; bh=znYIFesuug++IoLB9CVCkGSdmwhdj0C5YUY4/7dlH2M=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=q8X0MFVrWi2iotvT+WNXgvmKO2SBOM/9VDvcd3s0n3qekXs4mlUqsOVJO9l5TCAm+ +A+zAbbG5d0qb1SH4i51ryPCnG3UFNVj4jn/7AaA5Pq51xhDHf8WHrxe8JNB2bSUp5 5brBu9mKcGoli0CdYKN/FGzoKvhCO47NVRT/M7ezxC8hPpme/Q1arw3TDRPOPQFhgY qp40U49dN5pgieLQMt1BxXk0sr33zjB2iN+rHIPlDZqvezq+MsFxDV3k090olyLCQr dlsyy1E29XCYikdp5xsSGhGiKi/1WjyJSbdVccx0DA6kIT41yA7V/T8QcjgrWJv6on OJqkLZoWVbfhg== 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: Thu, 13 Jun 2024 11:18:02 -0700 From: Chris To: "Rodney W. Grimes" Cc: Ed Maste , freebsd-net@freebsd.org Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> References: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> User-Agent: UDNSMS/17.0 Message-ID: <5ec0abdef603a9bd958ca14df1233f81@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4W0VyX2drfz4j2Q On 2024-06-13 06:34, Rodney W. Grimes wrote: >> On 2024-06-12 15:05, Chris wrote: >> > On 2024-06-12 14:47, Rodney W. Grimes wrote: >> >>> I propose that we start dropping inbound ICMP REDIRECTs by default, by >> >>> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >> >>> changing the associated rc.conf machinery). I've opened a Phabricator >> >>> review at https://reviews.freebsd.org/D45102. >> >> >> >> I propse that we NOT do this. If you need this to protect your end >> >> node your probably doing something really unsafe network wise. The >> >> place that ICMP REDIRECTS should be dropped, and is most places, is >> >> at access routers and firewalls. >> >> >> >> Any one that needs this change to protect there network has larger >> >> issues than an ICMP REDIECT causing some issues. >> >> >> >> ICMP redirectr are very usefull for not having to run routing >> >> protocols on all your end nodes and allowing your edge/access >> >> routers tell your internal hosts via redirects how to get to >> >> places more efficiently. >> >> >> >>> >> >>> ICMP REDIRECTs served a useful purpose in earlier networks, but on >> >> They still serve this very usefull purpose. >> >> >> >>> balance are more likely to represent a security issue today than to >> >>> provide a routing benefit. With the change in review it is of course >> >>> still possible to enable them if desired for a given installation. >> >>> This change would appear in FreeBSD 15.0 and would not be MFC'd. >> >>> >> >>> One question raised in the review is about switching the default to >> >>> YES but keeping the special handling for "auto" (dropping ICMP >> >>> REDIRECT if a routing daemon is in use, honouring them if not). I >> >>> don't think this is particularly valuable given that auto was >> >>> introduced to override the default NO when necessary; there's no need >> >>> for it with the default being YES. That functionality could be >> >>> maintained if there is a compelling use case, though. >> >> >> >> The policy that is there now is exactly how things should be configured >> >> for a host in a network protected by a proper router w/firewall. >> >> The existing "auto" does exactly the right thing. >> >> >> >>> >> >>> If you have any questions or feedback please follow up here or in the >> >>> review. >> > As Rodeney already effectively explains; dropping packets makes routing, >> > and discovery exceedingly difficult. Which is NOT what the average user >> > wants, >> > or expects. I use "set block-policy drop" in pf(4). But as already noted, >> > this is for "filtering" purposes. Your suggestion also has the negative >> > affect >> > of hanging remote ports. Which can result in other negative results by >> > peers. >> > >> > Please don't. :) >> >>> >> >>> >> > --Chris >> OK, now having actually read the (phab) review. I'm of the opposite >> opinion. >> Your review seems to make the right decision. :) > > You do get that the final effect of the change is that by default ALL > freeBSD boxes well be dropping ICMP REDIRECTS, both routers and end > nodes. > > I know first hand that this change WOULD break my network(s) in locations > that have more than 1 router as all of the interior hosts simply depend > on an ICMP redirect to get them using the optimal router after they > wrongly use the default router for a packet. > > A quick check on Ubunty 22.04 and Debian 12 indicate these are stlll > accepted by default on those systems. > > Again, this is gona be one of those "bite someone in the ass" and your > actually not providing any real security to anyone by making this change. > > If this is such a security issue, how come FREEFALL.freebsd.org still > has: > net.inet.icmp.drop_redirect: 0 > > Because it does not need to do that, because it is properly protected > by routers and firewalls that do the dropping for them. > > DOG food Dog FOOD DOG FOOD!!! Firstly, please accept my apology for incorrectly spelling your name. :/ Secondly, my "reversal" of opinion on the matter was based upon my assumption on what would be returned by "auto". Closer examination, and reviewing your reply here, I think you're right, as was my original response. Accepting the new changes, as you say; will bite me in the ass -- well, will make my job (and others) more challenging. While I can appreciate the intent to keep users from getting "spoofed" packets that lead them into trouble. I think this is more a matter of responsible (network) administration. Maybe a better solution could be sent from rc(8) if FreeBSD thinks you've made the wrong decision here? Because the proposed change(s) look to me to only make routing and discovery more problematic. Thanks for commenting, (and correcting me) Rodney. :) --Chris From nobody Thu Jun 13 19:16:39 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0XGH0BM2z5PC2R for ; Thu, 13 Jun 2024 19:16:55 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0XGG2WP1z4rXK; Thu, 13 Jun 2024 19:16:54 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 45DJGeBK020541; Thu, 13 Jun 2024 12:16:46 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1718306207; x=1718306807; r=y; bh=znYIFesuug++IoLB9CVCkGSdmwhdj0C5YUY4/7dlH2M=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=GIuJm6GaUL5S3wzv7lIWbgwpOaWE3Wdx9ZkHfZbtv3VBUZkIKe7fcnxorKY/+nKZo ecWpsdC3UUAbJisOdRoXcwrvc+8gq3itqhb6xBP7DY5RWHomLY75E0yGAewuzB1dF2 tCYn57pXZ8Kq1Bi/UhD0wsd4KDrVLoKr2FWwHMFuGGfI7Vipq3SpG1RUe9dL29MMBN YzjL1plVthuSpXh1ROhRPhxAfF+WG5qXd9OHG+MeFXDTp9tp1RURQGtXfnfzAgeqTq c/mmdwMZK3HyB9eRndmRc2s18B/B19xb4g6yKIm2G34Nrs6PMNgki6tF1Phcq+0yJZ USz2FYnrKRzRg== 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: Thu, 13 Jun 2024 12:16:39 -0700 From: Chris To: "Rodney W. Grimes" Cc: Ed Maste , freebsd-net@freebsd.org Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> References: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4W0XGG2WP1z4rXK On 2024-06-13 06:34, Rodney W. Grimes wrote: >> On 2024-06-12 15:05, Chris wrote: >> > On 2024-06-12 14:47, Rodney W. Grimes wrote: >> >>> I propose that we start dropping inbound ICMP REDIRECTs by default, by >> >>> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >> >>> changing the associated rc.conf machinery). I've opened a Phabricator >> >>> review at https://reviews.freebsd.org/D45102. >> >> >> >> I propse that we NOT do this. If you need this to protect your end >> >> node your probably doing something really unsafe network wise. The >> >> place that ICMP REDIRECTS should be dropped, and is most places, is >> >> at access routers and firewalls. >> >> >> >> Any one that needs this change to protect there network has larger >> >> issues than an ICMP REDIECT causing some issues. >> >> >> >> ICMP redirectr are very usefull for not having to run routing >> >> protocols on all your end nodes and allowing your edge/access >> >> routers tell your internal hosts via redirects how to get to >> >> places more efficiently. >> >> >> >>> >> >>> ICMP REDIRECTs served a useful purpose in earlier networks, but on >> >> They still serve this very usefull purpose. >> >> >> >>> balance are more likely to represent a security issue today than to >> >>> provide a routing benefit. With the change in review it is of course >> >>> still possible to enable them if desired for a given installation. >> >>> This change would appear in FreeBSD 15.0 and would not be MFC'd. >> >>> >> >>> One question raised in the review is about switching the default to >> >>> YES but keeping the special handling for "auto" (dropping ICMP >> >>> REDIRECT if a routing daemon is in use, honouring them if not). I >> >>> don't think this is particularly valuable given that auto was >> >>> introduced to override the default NO when necessary; there's no need >> >>> for it with the default being YES. That functionality could be >> >>> maintained if there is a compelling use case, though. >> >> >> >> The policy that is there now is exactly how things should be configured >> >> for a host in a network protected by a proper router w/firewall. >> >> The existing "auto" does exactly the right thing. >> >> >> >>> >> >>> If you have any questions or feedback please follow up here or in the >> >>> review. >> > As Rodeney already effectively explains; dropping packets makes routing, >> > and discovery exceedingly difficult. Which is NOT what the average user >> > wants, >> > or expects. I use "set block-policy drop" in pf(4). But as already noted, >> > this is for "filtering" purposes. Your suggestion also has the negative >> > affect >> > of hanging remote ports. Which can result in other negative results by >> > peers. >> > >> > Please don't. :) >> >>> >> >>> >> > --Chris >> OK, now having actually read the (phab) review. I'm of the opposite >> opinion. >> Your review seems to make the right decision. :) > > You do get that the final effect of the change is that by default ALL > freeBSD boxes well be dropping ICMP REDIRECTS, both routers and end > nodes. > > I know first hand that this change WOULD break my network(s) in locations > that have more than 1 router as all of the interior hosts simply depend > on an ICMP redirect to get them using the optimal router after they > wrongly use the default router for a packet. > > A quick check on Ubunty 22.04 and Debian 12 indicate these are stlll > accepted by default on those systems. > > Again, this is gona be one of those "bite someone in the ass" and your > actually not providing any real security to anyone by making this change. > > If this is such a security issue, how come FREEFALL.freebsd.org still > has: > net.inet.icmp.drop_redirect: 0 > > Because it does not need to do that, because it is properly protected > by routers and firewalls that do the dropping for them. > > DOG food Dog FOOD DOG FOOD!!! Firstly, please accept my apology for incorrectly spelling your name. :/ Secondly, my "reversal" of opinion on the matter was based upon my assumption on what would be returned by "auto". Closer examination, and reviewing your reply here, I think you're right, as was my original response. Accepting the new changes, as you say; will bite me in the ass -- well, will make my job (and others) more challenging. While I can appreciate the intent to keep users from getting "spoofed" packets that lead them into trouble. I think this is more a matter of responsible (network) administration. Maybe a better solution could be sent from rc(8) if FreeBSD thinks you've made the wrong decision here? Because the proposed change(s) look to me to only make routing and discovery more problematic. Thanks for commenting, (and correcting me) Rodney. :) --Chris From nobody Thu Jun 13 20:38:46 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0Z523G2jz5PK5C for ; Thu, 13 Jun 2024 20:39:02 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4W0Z514zvlz43JX for ; Thu, 13 Jun 2024 20:39:01 +0000 (UTC) (envelope-from brett@lariat.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brett@lariat.net designates 66.62.230.51 as permitted sender) smtp.mailfrom=brett@lariat.net Received: from Toshi.lariat.net (localhost.lariat.org [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id OAA03662 for ; Thu, 13 Jun 2024 14:38:48 -0600 (MDT) Message-Id: <202406132038.OAA03662@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Jun 2024 14:38:46 -0600 To: net@freebsd.org From: freebsd-net@brettglass.com Subject: Overflow or div by 0 in systat -ifstat? 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 [-1.27 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.96)[-0.963]; NEURAL_HAM_SHORT(-0.90)[-0.905]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[freebsd-net@brettglass.com,brett@lariat.net]; R_SPF_ALLOW(-0.20)[+a]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FROM_NO_DN(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:19092, ipnet:66.62.228.0/22, country:US]; R_DKIM_NA(0.00)[]; DMARC_NA(0.00)[brettglass.com]; FROM_NEQ_ENVFROM(0.00)[freebsd-net@brettglass.com,brett@lariat.net]; MLMMJ_DEST(0.00)[net@freebsd.org]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[net@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4W0Z514zvlz43JX Hello! Left systat -ifstat running to watch the bandwidth on a few Netgraph VPN tunnels overnight, and woke up to this today: /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average | Interface Traffic Peak Total ng4 in 0.000 Mb/s 0.001 Mb/s 1.976 MB out 0.000 Mb/s 0.000 Mb/s 5.049 MB ng3 in 0.000 Mb/s 29132214617622.535 M 46.615 MB out 0.000 Mb/s 29132214589474.320 M 1.143 GB ng2 in 0.000 Mb/s 0.384 Mb/s 322.777 MB out 0.000 Mb/s 8.150 Mb/s 9.344 GB ng1 in 0.000 Mb/s 0.000 Mb/s 2.688 MB out 0.000 Mb/s 0.000 Mb/s 12.815 MB ng0 in 0.000 Mb/s 1.467 Mb/s 853.927 MB out 0.000 Mb/s 2.548 Mb/s 3.896 GB Looks like an overflow, a math error (perhaps at the stroke of midnight?), or an uncaught divide-by-zero. Since the peak rate calculation is done in userland, this isn't a critical bug; it won't cause a kernel panic. But it may be a good idea to see what might have caused it. --Brett Glass From nobody Thu Jun 13 20:51:02 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0ZMC0qQcz5PKnS for ; Thu, 13 Jun 2024 20:51:19 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 4W0ZMB2wCJz44xD for ; Thu, 13 Jun 2024 20:51:18 +0000 (UTC) (envelope-from bakul@iitbombay.org) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-704189f1225so1400812b3a.0 for ; Thu, 13 Jun 2024 13:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20230601.gappssmtp.com; s=20230601; t=1718311876; x=1718916676; darn=freebsd.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oTnyIMiDDe7GFvmwoZxKBWInJwAjt5mcNNodTELGmOE=; b=DG7qpoiXbIZ5Lz/9+x3OKZkjRNQ3OYaD3oIaeYqfLVJM5+Ggy6pHj39MzeEfN+L7kV XjFhSyHLmvu6sFYDkPCxljFq5+DUeIK1uD8tKFf5G8/KAnVr82eLPqujjn6IbTCLQCbW THR3B119THQ+z8N8fV8ygs9XAWgxR0IePpIOrza/zG+ozaiJD2Zu1B7yhEZTQYG7MV78 Ko2IGWFS/tSgV2D6RDD6fEIFzPbhCZO9QR7Ab+kn+zBXsuowe9JcrOW05LZUcYnGNAql LWBlKQp+6AFY1FZZztlXB/eZZXNOY1delVLkK6kAQp9GIvPlrrnqdSSWd3ujCBycsG+f HWnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718311876; x=1718916676; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oTnyIMiDDe7GFvmwoZxKBWInJwAjt5mcNNodTELGmOE=; b=u/yKuDxzwhypE/f9UKOxEjx2ofnDmthOYkXy5VgLMT36s41hkbEFunE0cVAgRMdhyJ PPcAFZjJqdMCP1VjtOmNX75isAkbQfzA4RJaPtefa6NGkmj0o+uBDQsiBfDD30lNRNdH ApJprED1ObYiq1Jm68hVl9Tze8hykyAlx1NH0IthgZi/O7fAEgMUxV8dYOYrWTc6jWl8 9+mJ4FDC4dXPg5nuau8wwYrFjQhPHZKzbHI58EATQtgAFcUBO8+RtC2XZsD0vq0kObb8 Zv6tyoTGruNtUNpb7qAmYANrlzo/IYzzdrbFE/OHLMnt2S1gTbRQMHVE2jgvuAZI4Ly3 IgFw== X-Forwarded-Encrypted: i=1; AJvYcCVBGEEkUsxF9Mw2UVKI2yNLG73kuxkydHEQ9bCQJRcEKU7jpXYxEsL2dLvaTq5+++IUXOPFQv/mEKyvZcKyqSVK/Z0YvUDQPA== X-Gm-Message-State: AOJu0YyLGzxzLHUbg6cq86Xv5U9NQb3Oki/v0Ssmrdb5AGToq1LTCDTd 7tjuRwyS2wHcF0PvuwJUduNfxllE+ORyPWxrQrcP462y7wL5XcNu3YBrYbeCqcqUBpATixYZP6w = X-Google-Smtp-Source: AGHT+IHPI9ATw1SnccUWRhocUv6p6pzzh0MJqo5rho54KnNEAbOOdFvcNO4pDJZNHPS0HCAcNbFqoQ== X-Received: by 2002:a05:6a20:3caa:b0:1b7:d5d5:415b with SMTP id adf61e73a8af0-1bae82b8ccamr1142564637.57.1718311876466; Thu, 13 Jun 2024 13:51:16 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-705cc967356sm1759866b3a.63.2024.06.13.13.51.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2024 13:51:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Discarding inbound ICMP REDIRECT by default From: Bakul Shah In-Reply-To: <202406131339.45DDdDma044779@gndrsh.dnsmgr.net> Date: Thu, 13 Jun 2024 13:51:02 -0700 Cc: Ed Maste , FreeBSD Net Content-Transfer-Encoding: quoted-printable Message-Id: References: <202406131339.45DDdDma044779@gndrsh.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3774.600.62) X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4W0ZMB2wCJz44xD On Jun 13, 2024, at 6:39=E2=80=AFAM, Rodney W. Grimes = wrote: >=20 >> I propose that we start dropping inbound ICMP REDIRECTs by default, = by >> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >> changing the associated rc.conf machinery). I've opened a Phabricator >> review at https://reviews.freebsd.org/D45102. >>=20 >> ICMP REDIRECTs served a useful purpose in earlier networks, but on >> balance are more likely to represent a security issue today than to >> provide a routing benefit. With the change in review it is of course >> still possible to enable them if desired for a given installation. >> This change would appear in FreeBSD 15.0 and would not be MFC'd. >>=20 >> One question raised in the review is about switching the default to >> YES but keeping the special handling for "auto" (dropping ICMP >> REDIRECT if a routing daemon is in use, honouring them if not). I >> don't think this is particularly valuable given that auto was >> introduced to override the default NO when necessary; there's no need >> for it with the default being YES. That functionality could be >> maintained if there is a compelling use case, though. >>=20 >> If you have any questions or feedback please follow up here or in the = review. >=20 > Discarding ICMP redirects on a internet host is non-conformant with > STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. Back when we did a router startup, I carefully read significant portions of rfc1122 + rfc1812 several times over. Rodney is 100% right here but the larger issue is following relevant standards or RFCs. Anyone contemplating such changes should become intimately familiar with these two documents (+ any update RFCs). [Not to mention there should be tests checking conformance]= From nobody Thu Jun 13 22:49:56 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0d0F5JQkz5MHZf for ; Thu, 13 Jun 2024 22:50:05 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0d0D6qDBz4Gtj; Thu, 13 Jun 2024 22:50:04 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 45DMnvlE090990; Thu, 13 Jun 2024 15:50:03 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1718319004; x=1718319604; r=y; bh=znYIFesuug++IoLB9CVCkGSdmwhdj0C5YUY4/7dlH2M=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=oQ5bs5qr2SYNrUkbLjHv/m5RKmM28s51LvePF89ls7oH+sU9qsqaMobP9+L7CHPgN 3LXNMCjkbw8FwpB9kR3pKbQMzxu4kTiXd7m+1i1EZanvq4jE7SJYgw868sZSSRezj2 9aKOLA8Rp8ip3i1J9sRDu0PdbCW0DY/z6+d8aMNhD7qCj7/XQhOiY9tMa+rKakYzJS eg/7woq49RwA5LWPMfaG8N5Yc+6HmN+obbsf/7iJfrNljykNY9kXQ1xXmOVc/lxiqz j79/u//R43nysG1w3yB6Ckgr+EldcyWF8RP7y14RlC7tyY4u+XRNf9nSbHjZcTm3cP 4HM/1f0N7FH3A== 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: Thu, 13 Jun 2024 15:49:56 -0700 From: Chris To: "Rodney W. Grimes" Cc: Ed Maste , freebsd-net@freebsd.org Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> References: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> User-Agent: UDNSMS/17.0 Message-ID: <43c5f1fa4aa1471af2c03bbe1877721c@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4W0d0D6qDBz4Gtj On 2024-06-13 06:34, Rodney W. Grimes wrote: >> On 2024-06-12 15:05, Chris wrote: >> > On 2024-06-12 14:47, Rodney W. Grimes wrote: >> >>> I propose that we start dropping inbound ICMP REDIRECTs by default, by >> >>> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >> >>> changing the associated rc.conf machinery). I've opened a Phabricator >> >>> review at https://reviews.freebsd.org/D45102. >> >> >> >> I propse that we NOT do this. If you need this to protect your end >> >> node your probably doing something really unsafe network wise. The >> >> place that ICMP REDIRECTS should be dropped, and is most places, is >> >> at access routers and firewalls. >> >> >> >> Any one that needs this change to protect there network has larger >> >> issues than an ICMP REDIECT causing some issues. >> >> >> >> ICMP redirectr are very usefull for not having to run routing >> >> protocols on all your end nodes and allowing your edge/access >> >> routers tell your internal hosts via redirects how to get to >> >> places more efficiently. >> >> >> >>> >> >>> ICMP REDIRECTs served a useful purpose in earlier networks, but on >> >> They still serve this very usefull purpose. >> >> >> >>> balance are more likely to represent a security issue today than to >> >>> provide a routing benefit. With the change in review it is of course >> >>> still possible to enable them if desired for a given installation. >> >>> This change would appear in FreeBSD 15.0 and would not be MFC'd. >> >>> >> >>> One question raised in the review is about switching the default to >> >>> YES but keeping the special handling for "auto" (dropping ICMP >> >>> REDIRECT if a routing daemon is in use, honouring them if not). I >> >>> don't think this is particularly valuable given that auto was >> >>> introduced to override the default NO when necessary; there's no need >> >>> for it with the default being YES. That functionality could be >> >>> maintained if there is a compelling use case, though. >> >> >> >> The policy that is there now is exactly how things should be configured >> >> for a host in a network protected by a proper router w/firewall. >> >> The existing "auto" does exactly the right thing. >> >> >> >>> >> >>> If you have any questions or feedback please follow up here or in the >> >>> review. >> > As Rodeney already effectively explains; dropping packets makes routing, >> > and discovery exceedingly difficult. Which is NOT what the average user >> > wants, >> > or expects. I use "set block-policy drop" in pf(4). But as already noted, >> > this is for "filtering" purposes. Your suggestion also has the negative >> > affect >> > of hanging remote ports. Which can result in other negative results by >> > peers. >> > >> > Please don't. :) >> >>> >> >>> >> > --Chris >> OK, now having actually read the (phab) review. I'm of the opposite >> opinion. >> Your review seems to make the right decision. :) > > You do get that the final effect of the change is that by default ALL > freeBSD boxes well be dropping ICMP REDIRECTS, both routers and end > nodes. > > I know first hand that this change WOULD break my network(s) in locations > that have more than 1 router as all of the interior hosts simply depend > on an ICMP redirect to get them using the optimal router after they > wrongly use the default router for a packet. > > A quick check on Ubunty 22.04 and Debian 12 indicate these are stlll > accepted by default on those systems. > > Again, this is gona be one of those "bite someone in the ass" and your > actually not providing any real security to anyone by making this change. > > If this is such a security issue, how come FREEFALL.freebsd.org still > has: > net.inet.icmp.drop_redirect: 0 > > Because it does not need to do that, because it is properly protected > by routers and firewalls that do the dropping for them. > > DOG food Dog FOOD DOG FOOD!!! Firstly, please accept my apology for incorrectly spelling your name. :/ Secondly, my "reversal" of opinion on the matter was based upon my assumption on what would be returned by "auto". Closer examination, and reviewing your reply here, I think you're right, as was my original response. Accepting the new changes, as you say; will bite me in the ass -- well, will make my job (and others) more challenging. While I can appreciate the intent to keep users from getting "spoofed" packets that lead them into trouble. I think this is more a matter of responsible (network) administration. Maybe a better solution could be sent from rc(8) if FreeBSD thinks you've made the wrong decision here? Because the proposed change(s) look to me to only make routing and discovery more problematic. Thanks for commenting, (and correcting me) Rodney. :) --Chris From nobody Thu Jun 13 23:36:51 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0f2N4vxbz5MMSD for ; Thu, 13 Jun 2024 23:37:00 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0f2N1kG0z4LHj; Thu, 13 Jun 2024 23:37:00 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 45DNaptS035821; Thu, 13 Jun 2024 16:36:58 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1718321818; x=1718322418; r=y; bh=znYIFesuug++IoLB9CVCkGSdmwhdj0C5YUY4/7dlH2M=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Vf3oTqcq9Odtqi37Uc9tt6/txkRUgef93jFa+lbuKjnlWwuvOsbRLjPHG4dTPk891 fGY/+sjEsEP/6pFXQn4sQ5RPt0InY7XgEDHBuR2hFab4TUB8O3EMQBv4GaNQApeZ5/ 322PtBy0yLO9Hi67pmLrls4GGSOidBphMmEcRPGqKY5SrrYd8veP2PKZFzfQjobPMJ Lrpqau09E09+PKjPPIWND4ST31wMZiMjjvW+g+gldi71uorsVJQZfJ49FqtKJkL7Ps gEPx590CrdQ8kk7ma5c7dR/69/VkgqRHbDPmZSUCz0Um14oGFGg9S1fnoxTyoWdJcR fK1BOM5ov2xlA== 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: Thu, 13 Jun 2024 16:36:51 -0700 From: Chris To: "Rodney W. Grimes" Cc: Ed Maste , freebsd-net@freebsd.org Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> References: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> User-Agent: UDNSMS/17.0 Message-ID: <1980e6be4a958db40bd4fe7b343666e7@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4W0f2N1kG0z4LHj On 2024-06-13 06:34, Rodney W. Grimes wrote: >> On 2024-06-12 15:05, Chris wrote: >> > On 2024-06-12 14:47, Rodney W. Grimes wrote: >> >>> I propose that we start dropping inbound ICMP REDIRECTs by default, by >> >>> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >> >>> changing the associated rc.conf machinery). I've opened a Phabricator >> >>> review at https://reviews.freebsd.org/D45102. >> >> >> >> I propse that we NOT do this. If you need this to protect your end >> >> node your probably doing something really unsafe network wise. The >> >> place that ICMP REDIRECTS should be dropped, and is most places, is >> >> at access routers and firewalls. >> >> >> >> Any one that needs this change to protect there network has larger >> >> issues than an ICMP REDIECT causing some issues. >> >> >> >> ICMP redirectr are very usefull for not having to run routing >> >> protocols on all your end nodes and allowing your edge/access >> >> routers tell your internal hosts via redirects how to get to >> >> places more efficiently. >> >> >> >>> >> >>> ICMP REDIRECTs served a useful purpose in earlier networks, but on >> >> They still serve this very usefull purpose. >> >> >> >>> balance are more likely to represent a security issue today than to >> >>> provide a routing benefit. With the change in review it is of course >> >>> still possible to enable them if desired for a given installation. >> >>> This change would appear in FreeBSD 15.0 and would not be MFC'd. >> >>> >> >>> One question raised in the review is about switching the default to >> >>> YES but keeping the special handling for "auto" (dropping ICMP >> >>> REDIRECT if a routing daemon is in use, honouring them if not). I >> >>> don't think this is particularly valuable given that auto was >> >>> introduced to override the default NO when necessary; there's no need >> >>> for it with the default being YES. That functionality could be >> >>> maintained if there is a compelling use case, though. >> >> >> >> The policy that is there now is exactly how things should be configured >> >> for a host in a network protected by a proper router w/firewall. >> >> The existing "auto" does exactly the right thing. >> >> >> >>> >> >>> If you have any questions or feedback please follow up here or in the >> >>> review. >> > As Rodeney already effectively explains; dropping packets makes routing, >> > and discovery exceedingly difficult. Which is NOT what the average user >> > wants, >> > or expects. I use "set block-policy drop" in pf(4). But as already noted, >> > this is for "filtering" purposes. Your suggestion also has the negative >> > affect >> > of hanging remote ports. Which can result in other negative results by >> > peers. >> > >> > Please don't. :) >> >>> >> >>> >> > --Chris >> OK, now having actually read the (phab) review. I'm of the opposite >> opinion. >> Your review seems to make the right decision. :) > > You do get that the final effect of the change is that by default ALL > freeBSD boxes well be dropping ICMP REDIRECTS, both routers and end > nodes. > > I know first hand that this change WOULD break my network(s) in locations > that have more than 1 router as all of the interior hosts simply depend > on an ICMP redirect to get them using the optimal router after they > wrongly use the default router for a packet. > > A quick check on Ubunty 22.04 and Debian 12 indicate these are stlll > accepted by default on those systems. > > Again, this is gona be one of those "bite someone in the ass" and your > actually not providing any real security to anyone by making this change. > > If this is such a security issue, how come FREEFALL.freebsd.org still > has: > net.inet.icmp.drop_redirect: 0 > > Because it does not need to do that, because it is properly protected > by routers and firewalls that do the dropping for them. > > DOG food Dog FOOD DOG FOOD!!! Firstly, please accept my apology for incorrectly spelling your name. :/ Secondly, my "reversal" of opinion on the matter was based upon my assumption on what would be returned by "auto". Closer examination, and reviewing your reply here, I think you're right, as was my original response. Accepting the new changes, as you say; will bite me in the ass -- well, will make my job (and others) more challenging. While I can appreciate the intent to keep users from getting "spoofed" packets that lead them into trouble. I think this is more a matter of responsible (network) administration. Maybe a better solution could be sent from rc(8) if FreeBSD thinks you've made the wrong decision here? Because the proposed change(s) look to me to only make routing and discovery more problematic. Thanks for commenting, (and correcting me) Rodney. :) --Chris From nobody Thu Jun 13 23:41:31 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0f7j56j5z5MN76 for ; Thu, 13 Jun 2024 23:41:37 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 4W0f7h55d3z4MML for ; Thu, 13 Jun 2024 23:41:36 +0000 (UTC) (envelope-from brett@lariat.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of brett@lariat.net designates 66.62.230.51 as permitted sender) smtp.mailfrom=brett@lariat.net Received: from Toshi.lariat.net (localhost.lariat.org [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id RAA06841 for ; Thu, 13 Jun 2024 17:41:32 -0600 (MDT) Message-Id: <202406132341.RAA06841@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Jun 2024 17:41:31 -0600 To: net@freebsd.org From: freebsd-net@brettglass.com Subject: Re: Overflow or div by 0 in systat -ifstat? In-Reply-To: <202406132038.OAA03662@mail.lariat.net> References: <202406132038.OAA03662@mail.lariat.net> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spamd-Bar: - X-Spamd-Result: default: False [-1.34 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.988]; NEURAL_HAM_SHORT(-0.95)[-0.951]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[freebsd-net@brettglass.com,brett@lariat.net]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; PREVIOUSLY_DELIVERED(0.00)[net@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_NO_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:19092, ipnet:66.62.228.0/22, country:US]; DMARC_NA(0.00)[brettglass.com]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[freebsd-net@brettglass.com,brett@lariat.net]; R_DKIM_NA(0.00)[]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[net@freebsd.org] X-Rspamd-Queue-Id: 4W0f7h55d3z4MML A followup on my earlier message. It appears that the systat program (in ifstat.c) is subtracting the previous time of day from the current time of day when calculating data rates, which works fine... except at the stroke of midnight. Not sure who maintains the utility, but this should be fixed since the error, once it crops up, persists as the program keeps running. --Brett Glass From nobody Fri Jun 14 04:17:56 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0mGX6rV5z5NKYB for ; Fri, 14 Jun 2024 04:17: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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0mGX4Hxqz4lq0 for ; Fri, 14 Jun 2024 04:17:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718338676; a=rsa-sha256; cv=none; b=mVWJfO0+jK1tSEPQ1V6Du1OQVXGXunYFygYxRyroaypzfDJBIJNxJaClAFp0mbtZnkDaHi sbD23qciZHhnvXEQ3dWIsLvoDEdvFzZsWxaO9GfSbUKemTyIUThaZs93YMeqNCGMTskSgo j0siTLui/oP3R4Qm06b/3uZUV3pPrRIL2NS3PRIXyabRM0q3iI1g6/1wfZqViYDhMuBME8 lJ2cU2PYVZM9Y+ivPU0ozUixtZi6UTLZ2/JmgEhhVn3HTbW+yTJlSybs4F8LAc27l6JOwb wuIvkHVSRwkmfm5Jc0XaebRUeugOHECHU0qt+KJOVhXWLT/0dPJUD0UTmHkfFw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718338676; 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=fhcohlvZhs/0PORxBOARtWBn2NZRZPZ1FP1qOaeleIo=; b=Kg/DU633p8cPsaA1o7TshGnHTIZvaBnfisTNFNBD5+lDgwnC0kTEoP/jKiivcwWSfzsBFG F1RAz/FhCJA+CVFe3XRZ/BMKYCx8Vw3eHI34j6UNM8GZz9BTBf4o6IPtG1ZBbCdy2T3M6r hWExFTdGCivenlhqpMLtDDUOKde0I8KqbI5ZHsk0ARKhlgBGPyZ9D5zXPEF/K9nWYfQkYV tl6SeoXEZ3e9Cr65/+YF8SgxZTgiRjOGCBNBtHfZCXtTGsCGphnWiZ0mfXA7hT9GaXl5O6 /MQ4bnwsRRKIwBs8B38fsUkNDUPAk8DALDBshxMqlKP0ddphE1G719K5WWWGMg== 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 4W0mGX3nG1z15R8 for ; Fri, 14 Jun 2024 04:17:56 +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 45E4HuvH056855 for ; Fri, 14 Jun 2024 04:17:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 45E4Hu6m056850 for net@FreeBSD.org; Fri, 14 Jun 2024 04:17:56 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 254596] if_bridge wants LRO turned off, if_vlan insists it remain on Date: Fri, 14 Jun 2024 04:17:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: emaste@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254596 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --- Comment #21 from Mark Linimon --- ^Triage: 12.3 has since gone EOL. The idea of an EN is now OBE. --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Fri Jun 14 07:16:35 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0rDq6pPFz5NZps for ; Fri, 14 Jun 2024 07:16:43 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0rDq3Z6Dz5425; Fri, 14 Jun 2024 07:16:43 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 45E7GZrv074398; Fri, 14 Jun 2024 00:16:42 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1718349402; x=1718350002; r=y; bh=znYIFesuug++IoLB9CVCkGSdmwhdj0C5YUY4/7dlH2M=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=atVwgtLmT7yZ7eisUBh9puf9Ten4GoCpTJcjjl7fVdpbEyXZusi06T/UZDL81C/px jXwcoN3tCCvG1LnBkjwssG3qLtzA4D8s5I6gsU3LWwINSYREPg5ch9bzaeccwzNaKj pwxBKnKTbDl3FFPveG7M+Wff7TuQ7yFGQGCxavLebilxkfq0yRXySwdMmapWK4LZ/O pJ/FBbwNdbrRnNccrDTcbYcslD75DeVYtQ4C1H7WYhgqya2G9CYWcBma+tAh6qIIRs pBJ5aD4FwlRuPzxpOhg60mTxerhqmBb+2vHQIRUbtSCJHhC7fwa46Uwwg6vb5zBW6+ drhXAuupLK5hw== 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: Fri, 14 Jun 2024 00:16:35 -0700 From: Chris To: "Rodney W. Grimes" Cc: Ed Maste , freebsd-net@freebsd.org Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> References: <202406131334.45DDYLg5044761@gndrsh.dnsmgr.net> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4W0rDq3Z6Dz5425 On 2024-06-13 06:34, Rodney W. Grimes wrote: >> On 2024-06-12 15:05, Chris wrote: >> > On 2024-06-12 14:47, Rodney W. Grimes wrote: >> >>> I propose that we start dropping inbound ICMP REDIRECTs by default, by >> >>> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and >> >>> changing the associated rc.conf machinery). I've opened a Phabricator >> >>> review at https://reviews.freebsd.org/D45102. >> >> >> >> I propse that we NOT do this. If you need this to protect your end >> >> node your probably doing something really unsafe network wise. The >> >> place that ICMP REDIRECTS should be dropped, and is most places, is >> >> at access routers and firewalls. >> >> >> >> Any one that needs this change to protect there network has larger >> >> issues than an ICMP REDIECT causing some issues. >> >> >> >> ICMP redirectr are very usefull for not having to run routing >> >> protocols on all your end nodes and allowing your edge/access >> >> routers tell your internal hosts via redirects how to get to >> >> places more efficiently. >> >> >> >>> >> >>> ICMP REDIRECTs served a useful purpose in earlier networks, but on >> >> They still serve this very usefull purpose. >> >> >> >>> balance are more likely to represent a security issue today than to >> >>> provide a routing benefit. With the change in review it is of course >> >>> still possible to enable them if desired for a given installation. >> >>> This change would appear in FreeBSD 15.0 and would not be MFC'd. >> >>> >> >>> One question raised in the review is about switching the default to >> >>> YES but keeping the special handling for "auto" (dropping ICMP >> >>> REDIRECT if a routing daemon is in use, honouring them if not). I >> >>> don't think this is particularly valuable given that auto was >> >>> introduced to override the default NO when necessary; there's no need >> >>> for it with the default being YES. That functionality could be >> >>> maintained if there is a compelling use case, though. >> >> >> >> The policy that is there now is exactly how things should be configured >> >> for a host in a network protected by a proper router w/firewall. >> >> The existing "auto" does exactly the right thing. >> >> >> >>> >> >>> If you have any questions or feedback please follow up here or in the >> >>> review. >> > As Rodeney already effectively explains; dropping packets makes routing, >> > and discovery exceedingly difficult. Which is NOT what the average user >> > wants, >> > or expects. I use "set block-policy drop" in pf(4). But as already noted, >> > this is for "filtering" purposes. Your suggestion also has the negative >> > affect >> > of hanging remote ports. Which can result in other negative results by >> > peers. >> > >> > Please don't. :) >> >>> >> >>> >> > --Chris >> OK, now having actually read the (phab) review. I'm of the opposite >> opinion. >> Your review seems to make the right decision. :) > > You do get that the final effect of the change is that by default ALL > freeBSD boxes well be dropping ICMP REDIRECTS, both routers and end > nodes. > > I know first hand that this change WOULD break my network(s) in locations > that have more than 1 router as all of the interior hosts simply depend > on an ICMP redirect to get them using the optimal router after they > wrongly use the default router for a packet. > > A quick check on Ubunty 22.04 and Debian 12 indicate these are stlll > accepted by default on those systems. > > Again, this is gona be one of those "bite someone in the ass" and your > actually not providing any real security to anyone by making this change. > > If this is such a security issue, how come FREEFALL.freebsd.org still > has: > net.inet.icmp.drop_redirect: 0 > > Because it does not need to do that, because it is properly protected > by routers and firewalls that do the dropping for them. > > DOG food Dog FOOD DOG FOOD!!! Firstly, please accept my apology for incorrectly spelling your name. :/ Secondly, my "reversal" of opinion on the matter was based upon my assumption on what would be returned by "auto". Closer examination, and reviewing your reply here, I think you're right, as was my original response. Accepting the new changes, as you say; will bite me in the ass -- well, will make my job (and others) more challenging. While I can appreciate the intent to keep users from getting "spoofed" packets that lead them into trouble. I think this is more a matter of responsible (network) administration. Maybe a better solution could be sent from rc(8) if FreeBSD thinks you've made the wrong decision here? Because the proposed change(s) look to me to only make routing and discovery more problematic. Thanks for commenting, (and correcting me) Rodney. :) --Chris From nobody Fri Jun 14 12:49:27 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0zd12CVsz5NpnM for ; Fri, 14 Jun 2024 12:49:41 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 4W0zd10XqFz4PSW for ; Fri, 14 Jun 2024 12:49:41 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f47.google.com with SMTP id ca18e2360f4ac-7eb6ca2cd09so81942039f.2 for ; Fri, 14 Jun 2024 05:49:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718369379; x=1718974179; 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=vsW9lRc05D/HXexoq0/P2Z8FrtBgnDeZDNz/GIE7Fa0=; b=wpjMfRJVd23Y0Z5Q7SM1HZ3QE6w4QY8XdzwwytrxLQGljK79s9NX/+RXEDGANP0V8O 71BxqaYdXQroeY73DQsGjx8Y6ATCDrs2S+AsG0ESMFpcRM9YUAe7UIVp7l6g60GoKEgU tJZHB6zSE7RrjB/sSrEnxD889ZFexDN/h9EBVEodpV0oEas2LgpDWUuOLR1EhM9SUwZw EjB/Rxx340kYrxhMw/Z3RlvCQIAVNQ5SKGm2ddlKlLq26dnHVJDrJkFktXsy0JGShac6 EdF099T+6ClVPNzBd8R/mmvOas3rzy2/5eUdOSP0MsOsyPAU10cbkcCT1T0yw/RpOzix rOZw== X-Gm-Message-State: AOJu0Yxns15b7C0FXWscxp5hFreK2npqjvhJ7BA0HZ29pfi9w6RPhUYt S8mJRTPqzkbeykpG/9fti8owwtpnPN1BFVupMwdB9DwSfS65rG/l9VWr6f4wcrjpM6vsWqlXHwI MM2rxI4CABzqLTcG8y1LR8oNtxD0HFA== X-Google-Smtp-Source: AGHT+IEfwv0KRfqJoRoog1vc1o+45Cq1VwhZ3AROj+80E9W2+MTFbxKPatamX4DeoMICOBIfaOfBAMLxZYMpIYGR72Y= X-Received: by 2002:a05:6602:6c0f:b0:7eb:8709:51d6 with SMTP id ca18e2360f4ac-7ebeb65b5a3mr283976739f.19.1718369379207; Fri, 14 Jun 2024 05:49:39 -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: <202406131801.45DI1MZu045631@gndrsh.dnsmgr.net> In-Reply-To: <202406131801.45DI1MZu045631@gndrsh.dnsmgr.net> From: Ed Maste Date: Fri, 14 Jun 2024 08:49:27 -0400 Message-ID: Subject: Re: Discarding inbound ICMP REDIRECT by default To: "Rodney W. Grimes" Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4W0zd10XqFz4PSW > > > Discarding ICMP redirects on a internet host is non-conformant with > > > STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. > > > > In that case our default of "auto" is non-conformant if you have a > > routing daemon. > > NO, because then your not subject to rfc-1122 as your now a router, > not a host. I would argue that having IP forwarding enabled (i.e. net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a router, and ICMP REDIRECT messages are already dropped in kernel in that case. From nobody Fri Jun 14 12:50:09 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0zdp2nyMz5Npqt for ; Fri, 14 Jun 2024 12:50:22 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) (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 4W0zdn4Sf6z4QDq for ; Fri, 14 Jun 2024 12:50:21 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none); spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.45 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com Received: by mail-io1-f45.google.com with SMTP id ca18e2360f4ac-7eb7c5b12e3so82011639f.3 for ; Fri, 14 Jun 2024 05:50:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718369420; x=1718974220; 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=eFZ6RD4g9ZD+1gBz+elt34WUVKfiRwojVRNBQdQ2pqI=; b=tNtT6VweqJqixK52kOlPj50eCSxVZ+UIDWLDOoKgermU8GtKnHFSfpWQO6PIhGDWn2 EE1g1TOjmTY9m2S2hJrkTPb238rzp1LBCYyDwJdBxdwVAEj9MsQB3AiWIVY3J41rNZTL DFXuyQB0YRSKynZu49RGgauTHc6rFp+S2TTt8W+3t2I9/6PFNlUH2WOYspy4IHivfsze ji260ZUeUb8o/bqw3d1PM0r//Tk/dB3+z2jfFX+6HI7djxsNuxozaSeV/BMVIslQrptd X9F1E/mj2N9gBbj6iKIhltVIhX/N334y0t0t1YK885honij+AGK/yD1l8rZhRh/3koxD 2u9Q== X-Forwarded-Encrypted: i=1; AJvYcCVb1m/eHw0WIK/hyZQpcC5IQs+4S+ez5Ly8Y9otQVIr0hx5jZvnxEO1y1hF8MGVUVhLYBwTdaGKYm9RJcUcJRjsy5mCihFngg== X-Gm-Message-State: AOJu0YwCa5xCe3RPgH1DngVyfYw5DL8LYVCE86yonMN35OFotE8+mf3E PtQs4zwnO/2jids3mSOBy5/TG4vVe1Tbg1oE/VVkW0XnQJoY/xGs5bgreC2NntwNZ7JW8ONJNEt afNjAV+FoScyljtvxmgmqPTCz2ug= X-Google-Smtp-Source: AGHT+IE6n556ZFwxXhOMBHpsYvET6Qgr4FCvmBRajurGKvQMMJVjwx9kEpNFfImmu3o7hODC/2CoBmYL5iOF5QwFDrA= X-Received: by 2002:a05:6602:601c:b0:7eb:4d68:a56a with SMTP id ca18e2360f4ac-7ebeb62db57mr331715539f.17.1718369420516; Fri, 14 Jun 2024 05:50:20 -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: <202406122147.45CLlsgN042313@gndrsh.dnsmgr.net> <72ceb2fe26812a237a17bd8de4024b7f@bsdforge.com> In-Reply-To: <72ceb2fe26812a237a17bd8de4024b7f@bsdforge.com> From: Ed Maste Date: Fri, 14 Jun 2024 08:50:09 -0400 Message-ID: Subject: Re: Discarding inbound ICMP REDIRECT by default To: Chris Cc: "Rodney W. Grimes" , freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: / X-Spamd-Result: default: False [-0.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.88)[-0.883]; NEURAL_SPAM_SHORT(0.80)[0.799]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[carpeddiem]; RCVD_COUNT_ONE(0.00)[1]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.45:from]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.45:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3] X-Rspamd-Queue-Id: 4W0zdn4Sf6z4QDq On Wed, 12 Jun 2024 at 18:05, Chris wrote: > > As Rodeney already effectively explains; dropping packets makes routing, > and discovery exceedingly difficult. Which is NOT what the average user > wants, This is on end hosts only, not routers (which already drop ICMP REDIRECT). > or expects. I use "set block-policy drop" in pf(4). But as already noted, > this is for "filtering" purposes. Your suggestion also has the negative > affect > of hanging remote ports. Which can result in other negative results by peers. I don't follow -- how does a host not processing ICMP REDIRECT cause these effects? From nobody Fri Jun 14 13:52:41 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W111q0jR5z5NvMY for ; Fri, 14 Jun 2024 13:52:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4W111p62BPz4XMg; Fri, 14 Jun 2024 13:52:46 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 45EDqfPc049400; Fri, 14 Jun 2024 06:52:41 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 45EDqfjx049399; Fri, 14 Jun 2024 06:52:41 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202406141352.45EDqfjx049399@gndrsh.dnsmgr.net> Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: To: Ed Maste Date: Fri, 14 Jun 2024 06:52:41 -0700 (PDT) CC: "Rodney W. Grimes" , freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4W111p62BPz4XMg > > > > Discarding ICMP redirects on a internet host is non-conformant with > > > > STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. > > > > > > In that case our default of "auto" is non-conformant if you have a > > > routing daemon. > > > > NO, because then your not subject to rfc-1122 as your now a router, > > not a host. > > I would argue that having IP forwarding enabled (i.e. > net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a > router, and ICMP REDIRECT messages are already dropped in kernel in > that case. Yet another mistake by FreeBSD. These ICMP dropping or not dropping are SITE SPECIFIC POLICIES, and should never be hard coded to wrong knobs. One can easily be using FreeBSD as a router inside an AS that has a need for ICMP REDIRECT to pass through that router unfiltered. But I would agree in general that the better detection mechanism for the "auto" keyword of /etc/rc.conf icmp_drop_redirects is probably the value of net.inet.ip.forwarding and net.inet6.ip6.forwarding, but iirc the is an ordering issue. Could use the *GATWEAY_ENABLE rc.conf variables though. -- Rod Grimes rgrimes@freebsd.org From nobody Fri Jun 14 13:57:06 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W11795srSz5NvW1 for ; Fri, 14 Jun 2024 13:57:25 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4W11792qM4z4Y16; Fri, 14 Jun 2024 13:57:25 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 45EDv68F049429; Fri, 14 Jun 2024 06:57:06 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 45EDv686049428; Fri, 14 Jun 2024 06:57:06 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202406141357.45EDv686049428@gndrsh.dnsmgr.net> Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: To: Ed Maste Date: Fri, 14 Jun 2024 06:57:06 -0700 (PDT) CC: Chris , "Rodney W. Grimes" , freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4W11792qM4z4Y16 > On Wed, 12 Jun 2024 at 18:05, Chris wrote: > > > > As Rodeney already effectively explains; dropping packets makes routing, > > and discovery exceedingly difficult. Which is NOT what the average user > > wants, > > This is on end hosts only, not routers (which already drop ICMP REDIRECT). Probably a mistake, see other email. > > or expects. I use "set block-policy drop" in pf(4). But as already noted, > > this is for "filtering" purposes. Your suggestion also has the negative > > affect > > of hanging remote ports. Which can result in other negative results by peers. > > I don't follow -- how does a host not processing ICMP REDIRECT cause > these effects? I am not sure that it would "hang" the port, but by ignoring the rediect your going to place additional burden on the router that is trying to redirect you as all packets would have to be forwarded by that router. I suppose it could hang you if infact the router sent the redirect but did not forward the packet for you expecting that a retransmission with your updated routing table due to the redirect would get the flow going. -- Rod Grimes rgrimes@freebsd.org From nobody Fri Jun 14 14:51:03 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W12KK01ztz5P03J for ; Fri, 14 Jun 2024 14:51:17 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (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 4W12KJ5QjFz4cct for ; Fri, 14 Jun 2024 14:51:16 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f49.google.com with SMTP id ca18e2360f4ac-7eb5dd9f994so90085539f.2 for ; Fri, 14 Jun 2024 07:51:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718376675; x=1718981475; 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=iPSByvDF/rLsziWPvBkuQrPjYfUvlYuHMffQxpU0WHk=; b=bWwjYZU7h5DuyI666V0n/0+gdWE75DIR8COfsM13PH41WtRgE9t0GysVw8CTVt9Gs0 FxeBRNm4zVDAd4VhEqxbD26PnaRvQoCEjPg4ZVuhA/fUTXuHpayhSZ7e+ikPuYUnqflJ qUGYke0heY9cmiovjAKxhQFTKQ8o8I8lHuYO0Sn/vS7R7rVewXcQBXTD/mrYBqiFdIkp KqVxf7NVLoAStJAnPn339fBEotAP7/uPvaS5EW+6x65GZLlI7B74wQ8aw8hdSW3Jmkfl jTWXsbFjgrsG1l4y8bsgrnIEbUHXku3QFh5PkMSQWMKwi21zSxOswZqKZPwayW70QMlD tmTg== X-Gm-Message-State: AOJu0YxaVJi6T1H9KFSCwzR7Xag6gjEIX0cg6mH59B7qnC3PeJooK+tS WJ7QqvA7uPfHSqGeSvwm00054qwnk5w53KRhRVbfNlRJxbTfQqOTlC1AVCyhm1KG+iU0jgn7KHb lYmdjvddLX+rsXgUU57Ui3R0ygEnDP8Ua X-Google-Smtp-Source: AGHT+IFG7AJRkc+JMn3k6xTh5aEJMG/4DXdlITJYq6sRNKk53MVU2GvisCV10TPOscLyW4AyNI6es9Bdf6jXm2OrKjs= X-Received: by 2002:a05:6602:13c2:b0:7eb:b592:6add with SMTP id ca18e2360f4ac-7ebeb637e9emr255551339f.20.1718376675405; Fri, 14 Jun 2024 07:51:15 -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: <202406141352.45EDqfjx049399@gndrsh.dnsmgr.net> In-Reply-To: <202406141352.45EDqfjx049399@gndrsh.dnsmgr.net> From: Ed Maste Date: Fri, 14 Jun 2024 10:51:03 -0400 Message-ID: Subject: Re: Discarding inbound ICMP REDIRECT by default To: "Rodney W. Grimes" Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4W12KJ5QjFz4cct On Fri, 14 Jun 2024 at 09:52, Rodney W. Grimes wrote: > > > > I would argue that having IP forwarding enabled (i.e. > > net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a > > router, and ICMP REDIRECT messages are already dropped in kernel in > > that case. > > Yet another mistake by FreeBSD. These ICMP dropping or not dropping > are SITE SPECIFIC POLICIES, and should never be hard coded to wrong > knobs. This change dates to 2004: commit 87c3bd275523515dc67444b900a8f1d39ae257cd Author: Andre Oppermann Date: Tue Jan 6 23:20:07 2004 +0000 According to RFC1812 we have to ignore ICMP redirects when we are acting as router (ipforwarding enabled). This doesn't fix the problem that host routes from ICMP redirects are never removed from the kernel routing table but removes the problem for machines doing packet forwarding. RFC1812 is not quite that explicit, but: | A router using a routing protocol (other than static routes) MUST NOT | consider paths learned from ICMP Redirects when forwarding a packet. | If a router is not using a routing protocol, a router MAY have a | configuration that, if set, allows the router to consider routes | learned through ICMP Redirects when forwarding packets. From nobody Fri Jun 14 14:57:13 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W12SR01qXz5P0jZ for ; Fri, 14 Jun 2024 14:57:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (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 4W12SQ59r9z4dnq for ; Fri, 14 Jun 2024 14:57:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-f181.google.com with SMTP id e9e14a558f8ab-375e555e13bso1865075ab.0 for ; Fri, 14 Jun 2024 07:57:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718377045; x=1718981845; 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=8eP/g+AKHH8/hwm1oN300dlCZDE4b0+SIaCnBBu12F8=; b=NWvRN/h+/fiYsWmnfRilmasY4YoCplfD7mKxXLvtpAjtZgpzzLtYzQ3XIH/p7mMgbb tAkRztsyJmWhp8fSCmu3M+Mq2rVW7uluPU/d9Xn1vlzG2K2AzmpSkXhCQtJ8i94k4CHS yF5l2JMR6OXIuw+lNoa/TneSaC3mrc7q6Id8sTBwUwDlNIm2bkBG5aU24zDpJiUAK3xZ hIem92FI+ARD7WLnBN4EG5mJHTQKvGxlRXUEN9LSHTQfsQe1ccJALoE9ZUP+ffemXrX0 /v1MGq9yQ/RKYJgZrq7kBJJKcAMRXbVNVlScje3nWsa5g8ZlN1t3MIcqx718MGQJjrvJ sc1Q== X-Forwarded-Encrypted: i=1; AJvYcCUOrSli8PxD0jU9+VRlAtaEyBSTTUZ2LWzsOb2VobrIrVeKTGs+3bRwqbT9bRtyucOc5by5lOMiGzLvC1wVlUnfkdb7nc9Zgw== X-Gm-Message-State: AOJu0YyZm1oBklMQDbdy/jgftsV9oZJAxBqdJJNF3zwn/0KITsI8pZqf j9VR1kgf2g3fInW1h7EkRlgA0w/x89kJnebb1XHGq6CppgjmTGQ3UpiXnGSF26Kchd4eubx+0Pp uS9OPgkvo+vSJe2ON1DL47TgMXvYk1A== X-Google-Smtp-Source: AGHT+IHzm3VAX8dAYACuEUAiWkLfuMIoRBJDMY17hanP9/fKr3HHi3DHljNPTRWBiDdf6hzlskv8Z6mbFiFziS86++0= X-Received: by 2002:a05:6e02:ecc:b0:375:d9e5:fe24 with SMTP id e9e14a558f8ab-375d9e5ff97mr29767855ab.9.1718377045283; Fri, 14 Jun 2024 07:57:25 -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: <202406141357.45EDv686049428@gndrsh.dnsmgr.net> In-Reply-To: <202406141357.45EDv686049428@gndrsh.dnsmgr.net> From: Ed Maste Date: Fri, 14 Jun 2024 10:57:13 -0400 Message-ID: Subject: Re: Discarding inbound ICMP REDIRECT by default To: "Rodney W. Grimes" Cc: Chris , freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4W12SQ59r9z4dnq On Fri, 14 Jun 2024 at 09:57, Rodney W. Grimes wrote: > > I am not sure that it would "hang" the port, but by ignoring the > rediect your going to place additional burden on the router that > is trying to redirect you as all packets would have to be forwarded > by that router. I suppose it could hang you if infact the router > sent the redirect but did not forward the packet for you expecting > that a retransmission with your updated routing table due to the > redirect would get the flow going. The router is required to forward the packet (RFC1812); if an ICMP REDIRECT is necessary it is sent as the final step in unicast forwarding. From nobody Fri Jun 14 15:13:20 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W12pv3QShz5P23t for ; Fri, 14 Jun 2024 15:13:27 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4W12pv1yRRz4hWN; Fri, 14 Jun 2024 15:13:27 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 45EFDKW7049692; Fri, 14 Jun 2024 08:13:20 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 45EFDKKF049691; Fri, 14 Jun 2024 08:13:20 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202406141513.45EFDKKF049691@gndrsh.dnsmgr.net> Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: To: Ed Maste Date: Fri, 14 Jun 2024 08:13:20 -0700 (PDT) CC: "Rodney W. Grimes" , freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4W12pv1yRRz4hWN > On Fri, 14 Jun 2024 at 09:52, Rodney W. Grimes > wrote: > > > > > > I would argue that having IP forwarding enabled (i.e. > > > net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a > > > router, and ICMP REDIRECT messages are already dropped in kernel in > > > that case. > > > > Yet another mistake by FreeBSD. These ICMP dropping or not dropping > > are SITE SPECIFIC POLICIES, and should never be hard coded to wrong > > knobs. > > This change dates to 2004: > > commit 87c3bd275523515dc67444b900a8f1d39ae257cd > Author: Andre Oppermann > Date: Tue Jan 6 23:20:07 2004 +0000 > > According to RFC1812 we have to ignore ICMP redirects when we ^^^^^^^^^^ Incorrect interpretation of ietf keyword "MAY". > are acting as router (ipforwarding enabled). > > This doesn't fix the problem that host routes from ICMP redirects > are never removed from the kernel routing table but removes the > problem for machines doing packet forwarding. > > RFC1812 is not quite that explicit, but: > > | A router using a routing protocol (other than static routes) MUST NOT > | consider paths learned from ICMP Redirects when forwarding a packet. > | If a router is not using a routing protocol, a router MAY have a > | configuration that, if set, allows the router to consider routes > | learned through ICMP Redirects when forwarding packets. That section is about how the router responds to an ICMP redirect set to IT, not one that is going THROUGH it. 5.2.7.2 about generating redirects is also not relavant here, as we are discussing forwarding redirects. As far as I can find RFC1812 does NOT discuss the issue of forwarind ICMP REDIRECTs. -- Rod Grimes rgrimes@freebsd.org From nobody Fri Jun 14 15:20:09 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W12yt4VXfz5P2Wg for ; Fri, 14 Jun 2024 15:20:22 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W12yt2F0Sz4j8t for ; Fri, 14 Jun 2024 15:20:22 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b="bXo6e/b/"; dmarc=pass (policy=quarantine) header.from=plan-b.pwste.edu.pl; spf=pass (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl designates 2001:678:618::40 as permitted sender) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl Received: from [192.168.7.70] (dom.potoki.eu [62.133.140.50]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.18.1/8.17.2) with ESMTPSA id 45EFK9ti060995 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 14 Jun 2024 17:20:09 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1718378410; bh=q4y6Nj5WEk56Vz4ub030x3gMDOCgnaiv06FspWxnT+8=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=bXo6e/b/52hCOPMZ/dsQQPVl2n9dNBlEqWapIldo2BPPHnaxtUFUkIDnBjdapJv+w MlpbOXCLoI27bz6M6dXjg1GXWBUWl49p3FaxnWZvLxWiAWmuF8Al7ouGsHslcfVzAa +77gxteF/7dLEWzoElJFXA2wn1IugqNrgbfYt+vbnZk0p/M4VBoAlGVheU/L1oHkoe 4NXFVPEv+OYX/YO453iXwEjzHjweh/NKi1qtY/dQzVW4TwLbONhtY4GB00TOifY53r 0yvS6BA0DtMtoicLG/eHdAFgRhhN5AZp7iZJzn345v+P2vCjp1cvazx2DFeOL+l2yB SeXl87JlyrYpw== X-Authentication-Warning: plan-b.pwste.edu.pl: Host dom.potoki.eu [62.133.140.50] claimed to be [192.168.7.70] Content-Type: multipart/alternative; boundary="------------Sn4vvhXEe0g82V409dVk0uNm" Message-ID: Date: Fri, 14 Jun 2024 17:20:09 +0200 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Discarding inbound ICMP REDIRECT by default To: Ed Maste Cc: freebsd-net@freebsd.org References: Content-Language: en-US From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; keydata= xsBNBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAHNN01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD7CwHcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgc7ATQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABwsBf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V4= In-Reply-To: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.88 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,quarantine]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ONCE_RECEIVED(0.10)[]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+] X-Rspamd-Queue-Id: 4W12yt2F0Sz4j8t This is a multi-part message in MIME format. --------------Sn4vvhXEe0g82V409dVk0uNm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit W dniu 8.05.2024 o 21:14, Ed Maste pisze: > It may make sense to apply the same default change for IPv6, but I > don't think we need to tie the two discussions / investigations > together. IMHO it is important to link ICMP6 with ICMP in terms of ICMP redirection. I have the impression that we are neglecting the IPv6 field again and this is our common sin. -- Marek Zarychta --------------Sn4vvhXEe0g82V409dVk0uNm Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
W dniu 8.05.2024 o 21:14, Ed Maste pisze:
It may make sense to apply the same default change for IPv6, but I
don't think we need to tie the two discussions / investigations
together.

IMHO it is important to link ICMP6 with ICMP in terms of ICMP redirection. I have the impression that we are neglecting the IPv6 field again and this is our common sin.

-- 
Marek Zarychta
--------------Sn4vvhXEe0g82V409dVk0uNm-- From nobody Fri Jun 14 15:53:22 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W13jD6bn2z5P52P for ; Fri, 14 Jun 2024 15:53:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (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 4W13jD4J60z4pd9 for ; Fri, 14 Jun 2024 15:53:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-7eb75c0d0a7so75802239f.3 for ; Fri, 14 Jun 2024 08:53:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718380415; x=1718985215; 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=K4RMkThTLEIhfCY/Eu5woHTl39pVj7qJrsd9Q5cpppE=; b=HpWeAi2S4vFQSQsTvwqndGSZI1FABsupuv0qhDyvR60s992fMmFwaUjE1n7zlK/Cz/ 5ffO61AIj0QJ3PevGSrZ5I4v+2XPraoyF7/ggc3xoXCS5D4ItdRdpMibl5iVH90Z+gxM vlipPwUxlJJK/V/4BX7tMf1VT5Bp+ai8Xm1nTC+K12Prg+/5oALi6MUspG2iAiZzUrL8 3AxkIgInO0pGRIWU++0Ve0kx2eAFd2BUSvyv90TmaZWafTEp6qkoux7wBG/30qEACOxx pHJh4oALQnIaYJzSqz+1WMoUCcuFDMx5KjjhrSobqTjtAb64OUEA0fucJZN+eZvI8T90 9uww== X-Gm-Message-State: AOJu0YwTUtCOtm9mp/OL4V/glKa8R7VR62lufiJsU4weygLTmT/qWrRY cRKba1c2kJOsI2+8avr4QeD808D3Z270LRY8cmYI6Tukpkcir0QBoVMRS/XA0xWl8ngWOW4Dizi UKeTV44cc42USxbrrIP0EbIst1YroZQ== X-Google-Smtp-Source: AGHT+IFFOSI+oUEKI0XbKug8cNLO5wd3vsNHiMQlCvxTtlSQMl6TUSF7Chu+InsfiRdIeuXO1qu0M/CqkWJhieXdtyU= X-Received: by 2002:a05:6602:150f:b0:7eb:8015:3ee1 with SMTP id ca18e2360f4ac-7ebeb4986dbmr346646639f.1.1718380415180; Fri, 14 Jun 2024 08:53:35 -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: <202406141513.45EFDKKF049691@gndrsh.dnsmgr.net> In-Reply-To: <202406141513.45EFDKKF049691@gndrsh.dnsmgr.net> From: Ed Maste Date: Fri, 14 Jun 2024 11:53:22 -0400 Message-ID: Subject: Re: Discarding inbound ICMP REDIRECT by default To: "Rodney W. Grimes" Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4W13jD4J60z4pd9 On Fri, 14 Jun 2024 at 11:13, Rodney W. Grimes wrote: > > That section is about how the router responds to an ICMP redirect > set to IT, not one that is going THROUGH it. Sorry I wasn't explicit, in all cases I'm talking about ICMP REDIRECTs destined for the machine (as a host or as a router). This is icmp_input dropping when either drop_redirect or ipforwarding is true. From nobody Fri Jun 14 17:26:37 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W15mh1vMWz5PD6F for ; Fri, 14 Jun 2024 17:26:44 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (pdx.rh.CN85.dnsmgr.net [65.75.216.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4W15mg5skbz43nx; Fri, 14 Jun 2024 17:26:43 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Authentication-Results: mx1.freebsd.org; none Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 45EHQboN050039; Fri, 14 Jun 2024 10:26:37 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 45EHQbY7050038; Fri, 14 Jun 2024 10:26:37 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202406141726.45EHQbY7050038@gndrsh.dnsmgr.net> Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: To: Ed Maste Date: Fri, 14 Jun 2024 10:26:37 -0700 (PDT) CC: "Rodney W. Grimes" , freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:10494, ipnet:65.75.216.0/23, country:US] X-Rspamd-Queue-Id: 4W15mg5skbz43nx > On Fri, 14 Jun 2024 at 11:13, Rodney W. Grimes > wrote: > > > > That section is about how the router responds to an ICMP redirect > > set to IT, not one that is going THROUGH it. > > Sorry I wasn't explicit, in all cases I'm talking about ICMP REDIRECTs > destined for the machine (as a host or as a router). This is > icmp_input dropping when either drop_redirect or ipforwarding is true. Ok, so long as we are not dropping ICMP REDIRECTS that are NOT destined for the router we are fine, which is the behavior I expected and observed on my network, though it is a bit older code. -- Rod Grimes rgrimes@freebsd.org From nobody Fri Jun 14 18:15:02 2024 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W16rZ2XBFz5PGqx for ; Fri, 14 Jun 2024 18:15:10 +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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W16rY6P4Kz49YF; Fri, 14 Jun 2024 18:15:09 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 45EIF2rr000719; Fri, 14 Jun 2024 11:15:08 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ultimatedns.net; s=mx99; t=1718388908; x=1718389508; r=y; bh=1lNIf4hKo5Ci/5MQH6iLxuXCku1cTsyfy85fE6bKUwQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=amdbzP/uMcabMiSbMsWSP1FKrKbs+jstkVOQScktryIGlmtgJv3hDK0A8PsDgwYL9 ZwrEo4/8Fq0hAlQy9O59WHrB6eE9RlxBj7qrhUSkSbbpTUHh3pYT34Y+ZPOxkmJCvu Yhs3FVQqPF8Zr10ZhRa9eB7s/xxW3V2nV0nD1+SQexBKMpiG1T9uSEYEtT49EimQu/ 8OnMnW78HOBgoWe3/dNGFnKLSXRdDVhGDBBmVL6qKYPs+mYScm1sIAGkbIH11U8Sgc p78FtKGiwiGiGB2no09JxLIxxqcnGlYbnsgNn/ed6TLbwVBXum9PNfPScNNK6Cp75x ZMxKFYwDg5CqQ== 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: Fri, 14 Jun 2024 11:15:02 -0700 From: Chris To: Ed Maste Cc: "Rodney W. Grimes" , freebsd-net@freebsd.org Subject: Re: Discarding inbound ICMP REDIRECT by default In-Reply-To: References: <202406122147.45CLlsgN042313@gndrsh.dnsmgr.net> <72ceb2fe26812a237a17bd8de4024b7f@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: <3c5aeeae30d6b21b8fa408126bf9230c@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4W16rY6P4Kz49YF On 2024-06-14 05:50, Ed Maste wrote: > On Wed, 12 Jun 2024 at 18:05, Chris wrote: >> >> As Rodeney already effectively explains; dropping packets makes routing, >> and discovery exceedingly difficult. Which is NOT what the average user >> wants, > > This is on end hosts only, not routers (which already drop ICMP REDIRECT). > >> or expects. I use "set block-policy drop" in pf(4). But as already noted, >> this is for "filtering" purposes. Your suggestion also has the negative >> affect >> of hanging remote ports. Which can result in other negative results by >> peers. > > I don't follow -- how does a host not processing ICMP REDIRECT cause > these effects? It appears I may have overstated my point here. Dropping redirects isn't (necessarily) out of line. I was thinking in terms of dropping (all) queries. Which is wrong in this context. Sorry. :) Thanks for taking the time to respond. --Chris From nobody Sat Jun 15 01:12:45 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W1J6Q3Htjz5MQG2 for ; Sat, 15 Jun 2024 01:12:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W1J6Q297rz3x5c for ; Sat, 15 Jun 2024 01:12:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718413966; a=rsa-sha256; cv=none; b=sxCmUHfXt18D3Hr7QMzTUX2culMa2uVVrtszXCqnFPIQoZY9sXHmQ/jGiTCCKo5ZoJ0x6C rrbAZvmAHQOmcSpZuEG8xKf07UPQpgJ0ztBjfonlhyTcIiCYnNChd4BTNmc66xHFn9dgvW pTQvqsch28iRgN4zresjg55EGwjd4xjD/rXKtISKwDCOapfGUY2r75Tazi1WJ87k1qxHzb bBNanjRyjX2HaZUrKupwF+wOwoR37bqXGXZ0pt/gyKevnfsgsq6wdU5wY/+3It2r23iAKS +E7mamNwFcoVsgbNYUfQUEcaszniZmE3Zs6nybmZCkQ8ziYQYRDgyA7A+sqUlA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718413966; 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=5G1lnV1E2zYbhpIS8bR+VRvk+WfUVFInAmiJyU4PNIE=; b=Y5XU+Bq/Bnf0bC7DLcFmMZVAOkgC4x/MNiLiA/i3lu18f171EtE5je8v3qcTVIax1zs3e7 YpcwIPDBuHj/Cwzbol84VlhMzD1RZ3ZwRBo/OoLVz6CiIUkYyoEBhuwg3EwMnTCOc0RXVG 5HF9vbTjbup68wht7kIGWyTgupiiOwNoQDhq8crguZvtDUaQSZIBJlBYmWOUCatp5ooBWe 1TXuRlly3GPRND4YEEQGgkT6MH2eIT7hqRLME6XfuxNsIA0vwsF7kRzp9JJzn5bXy3C05z UxrLElaRMzVBFlkL3c5bOxESCRiGNRKxVOk4wRip2CDa2N8q6y/rGgpSG++vHg== 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 4W1J6Q1m6xzkJ2 for ; Sat, 15 Jun 2024 01:12:46 +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 45F1Cki4032189 for ; Sat, 15 Jun 2024 01:12:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 45F1Ck9f032188 for net@FreeBSD.org; Sat, 15 Jun 2024 01:12:46 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 279653] Page fault in in6_selecthlim Date: Sat, 15 Jun 2024 01:12:45 +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.0-STABLE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: zlei@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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279653 --- Comment #3 from Zhenlei Huang --- (In reply to Andrey V. Elsukov from comment #2) Emm, I guess we have to disassemble the kernel file to figure out what happ= ens behind, if this can not be repeated. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Jun 15 21:28:50 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W1q5Z236bz5PT4Z for ; Sat, 15 Jun 2024 21:28:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W1q5Y6Qtyz4thb for ; Sat, 15 Jun 2024 21:28:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718486929; a=rsa-sha256; cv=none; b=YgdQ7cSLnkCSs2SiBqwA71HDrZuwN/1qMEfMynQNP/CNGvN+YLdLysQ5NSkddpcHqSKy4k gqC0qKYSQNyMKUlA355PeFwSUYyNwudFPlkoWE2ojgxyq/ADSopws3+bV2tF8IQVKsRk4o mbtZJFbS3pSn2t8/20m95ixBAFmeS70YqG5xTQAx8J6W6PUa9Py31OWhlf/v6VyviIRcNp vDjFkievlP1f8AJzp3mAdaubwdben42ldGhfE/SHIU0AcKHs4uVQypYCKndoC1rdVKhdj2 MA13DkG0kX/bbsO3Q4qyjb463RM6qI1xGWDulinEQjDpngcrOykjGGkiyl3DTQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718486929; 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=QPMjqsVUCVvjRcMFiFLjKjglFwUG3PpN7Lv+NJ2MN70=; b=TbO7yyixJb3XTgcD9D+4JiLTgwwtJiodqx9M0fORPcQmTf7beOXYfAZhsFJ43DjutBCr/z LLT0zOUi9EM5v3bYimynKbYpU6dKz4rgYMWibzrZliLI3eq8YY+3F9alZtPkcU99mXiVsW z3IR0F8EPF5lyUlc0ANhNncjyS+JGIf+AhmrgL8M71wFvW8EdpPvyQRz4dU83cK1ZyAh40 GisSPNaVS/0MnpHjI6V5Vmn8C2vZhuAIjrwtx4bIxJz1M2bsA+zQF4Ru1FUE9AI9KrWZt3 5GyAgyS0k2R7PmJFMRRjQuwpgZSbjwjy9W1V0JVW+KYsb5eBBLyaVKfD2jmc3Q== 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 4W1q5Y627YzLTq for ; Sat, 15 Jun 2024 21:28: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 45FLSnXr035029 for ; Sat, 15 Jun 2024 21:28:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 45FLSnTI035028 for net@FreeBSD.org; Sat, 15 Jun 2024 21:28:49 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 279653] Page fault in in6_selecthlim Date: Sat, 15 Jun 2024 21:28: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.0-STABLE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: amigan@gmail.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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279653 --- Comment #4 from Daniel Ponte --- ffffffff80b10380 : ffffffff80b10380: 55 pushq %rbp ffffffff80b10381: 48 89 e5 movq %rsp, %rbp ffffffff80b10384: 41 56 pushq %r14 ffffffff80b10386: 53 pushq %rbx ffffffff80b10387: 48 83 ec 20 subq $0x20, %rsp ffffffff80b1038b: 48 85 ff testq %rdi, %rdi ffffffff80b1038e: 74 74 je 0xffffffff80b10404 ffffffff80b10390: 0f b7 87 04 01 00 00 movzwl 0x104(%rdi), %eax ffffffff80b10397: 66 85 c0 testw %ax, %ax ffffffff80b1039a: 0f 89 9a 00 00 00 jns 0xffffffff80b1043a ffffffff80b103a0: 48 85 f6 testq %rsi, %rsi ffffffff80b103a3: 75 64 jne 0xffffffff80b10409 ffffffff80b103a5: 83 bf 94 00 00 00 00 cmpl $0x0, 0x94(%rdi) ffffffff80b103ac: 75 1b jne 0xffffffff80b103c9 ffffffff80b103ae: 83 bf 98 00 00 00 00 cmpl $0x0, 0x98(%rdi) ffffffff80b103b5: 75 12 jne 0xffffffff80b103c9 ffffffff80b103b7: 83 bf 9c 00 00 00 00 cmpl $0x0, 0x9c(%rdi) ffffffff80b103be: 75 09 jne 0xffffffff80b103c9 ffffffff80b103c0: 83 bf a0 00 00 00 00 cmpl $0x0, 0xa0(%rdi) ffffffff80b103c7: 74 57 je 0xffffffff80b10420 ffffffff80b103c9: 0f b7 9f 8e 00 00 00 movzwl 0x8e(%rdi), %ebx ffffffff80b103d0: 48 81 c7 94 00 00 00 addq $0x94, %rdi ffffffff80b103d7: 4c 8d 75 dc leaq -0x24(%rbp), %r14 ffffffff80b103db: 48 8d 55 ec leaq -0x14(%rbp), %rdx ffffffff80b103df: 4c 89 f6 movq %r14, %rsi ffffffff80b103e2: e8 19 dd 01 00 callq 0xffffffff80b2e100 ffffffff80b103e7: 8b 55 ec movl -0x14(%rbp), %edx ffffffff80b103ea: 89 df movl %ebx, %edi ffffffff80b103ec: 4c 89 f6 movq %r14, %rsi ffffffff80b103ef: 31 c9 xorl %ecx, %ecx ffffffff80b103f1: 45 31 c0 xorl %r8d, %r8d ffffffff80b103f4: e8 07 46 ff ff callq 0xffffffff80b04a00 ffffffff80b103f9: 48 85 c0 testq %rax, %rax ffffffff80b103fc: 74 22 je 0xffffffff80b10420 ffffffff80b103fe: 48 8b 78 20 movq 0x20(%rax), %rdi ffffffff80b10402: eb 08 jmp 0xffffffff80b1040c ffffffff80b10404: 48 85 f6 testq %rsi, %rsi ffffffff80b10407: 74 17 je 0xffffffff80b10420 ffffffff80b10409: 48 89 f7 movq %rsi, %rdi ffffffff80b1040c: be 1c 00 00 00 movl $0x1c, %esi ffffffff80b10411: e8 0a a3 e8 ff callq 0xffffffff8099a720 ffffffff80b10416: 48 8b 40 10 movq 0x10(%rax), %rax ffffffff80b1041a: 0f b6 40 1c movzbl 0x1c(%rax), %eax ffffffff80b1041e: eb 1a jmp 0xffffffff80b1043a ffffffff80b10420: 65 48 8b 04 25 00 00 00 00 movq %gs:0x0, %rax ffffffff80b10429: 48 8b 80 90 06 00 00 movq 0x690(%rax), %rax ffffffff80b10430: 48 8b 40 28 movq 0x28(%rax), %rax ffffffff80b10434: 8b 80 48 5c 33 81 movl -0x7ecca3b8(%rax), %eax ffffffff80b1043a: 48 83 c4 20 addq $0x20, %rsp ffffffff80b1043e: 5b popq %rbx ffffffff80b1043f: 41 5e popq %r14 ffffffff80b10441: 5d popq %rbp ffffffff80b10442: c3 retq ffffffff80b10443: 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 nopw=20=20= =20 %cs:(%rax,%rax) --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Jun 16 00:00:35 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W1tSk0zTRz5MDCn for ; Sun, 16 Jun 2024 00:00:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W1tSj6Zxbz55G1 for ; Sun, 16 Jun 2024 00:00:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718496037; a=rsa-sha256; cv=none; b=cb+khE69cwBhG92Vx55AOC+dpExyoxb/SvNQ0pZ4ayby1Z/Lzt22sLn48CyUL3IuC7nREd u7opoLD764Qy3TQObkfDJutPLaNPDBnr1jFXvWXg7aID/XDq0UdROn7HIFFM4qDONigu/G bDOvZ069KVJh3+azRlCXC/sTSXClSPkc3Za6VYPBIZdP/KY7Tl+er8HW/A1+PL+WMS79rI zgiLn/CEW6stFQNSwQypLSEtm8ZPLV8rSC7TQbFXwUHzpGPFsbd29wqOcfg4qeOifqMvyF Pc7sNn7VxLiBfrAMpAmGfKyb1b41zFFIoYERKy8DeVQ1HmKn43TrhSjJj6pWXw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718496037; 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=xZ6D7MgFZ/sHVRbNM6omyql2S8SWvMCs8fIJGE02FzI=; b=azpkCi20SlqERu2rbesnltFR1QqoEoSr8liZ2XehC3nfBkCKlz4AsZF6p9xT5MCYcRli+p FFZQau7AaO1LtEKmRAAsAtG+LbVuWSLM03Ll03ksOw+qgoy6sVae4Wr+GhMxmQHN/c2Vju jxg56MRkTx8c/2PXC7o+xJVEg6RwDYLWAR/PF1kpyUaB7Qb/94+Gaa/m64ABiG/+1BCMMP TfqByBWLTgkVO5LRq+15ycwW973gTkyfx7BC3ccAAV5wAXH+MvwPi4uVlMPUfJZUiHAWtY 2mjjUFtLkFj/y16opNj6DEo4FW0t1X1GeytbYC4dctWeW1/uMQby3Dee1RhzyQ== 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 4W1tSj69mHzQ9R for ; Sun, 16 Jun 2024 00: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 45G00bww031645 for ; Sun, 16 Jun 2024 00:00:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 45G00bgl031644 for net@FreeBSD.org; Sun, 16 Jun 2024 00:00:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 230807] if_alc(4): Driver not working for Killer Networking E2200 Date: Sun, 16 Jun 2024 00:00:35 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: imp@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? X-Bugzilla-Changed-Fields: assigned_to flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230807 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|net@FreeBSD.org |imp@FreeBSD.org Flags|mfc-stable12? | --- Comment #29 from Mark Linimon --- ^Triage: assign to committer that resolved and drop stale mfc-stable12. To imp: if this is not going to be mfced to 13, please just close this. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From nobody Sun Jun 16 21:01:09 2024 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W2QRB0xjMz5PTQJ for ; Sun, 16 Jun 2024 21:01:10 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W2QR94rw7z4By4 for ; Sun, 16 Jun 2024 21:01:09 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718571669; a=rsa-sha256; cv=none; b=iTQf/70RIMOmpoi6LUK5B9airQus19JDHZDc+EWS6SzIAmWlQqJK4g1C7kBb0ivLfHNQZN XIgdT+kfppuKVnw73VBZd11poIChUBiTkdgyz9pWiKG9XX1qLV21wTaJ7ZTthnTmTrkHL8 xOuNKlkcbrqqa4s2saKFICWexPaIBDc+kLRclriIa9yoJbWuM0OmUY6pSBYI9Qmoq4bXNM y80DZhf2ZJsUn5KySlg5cWvoe1EiRLVcGdcBwULTe4yAvNNP7ZRNuZmixJMggcJJB7j690 x4fHDMBfqLYONip3LQ/CP/bVx8EKu0U0kTwz7+9pvqc1J1w9HS7VcTdcpGd8tA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718571669; 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=OxCiV9Lpnl4sqLKf9UZP4CHm1Sgu1VxjN0iazNuNneQ=; b=VS5vUQ42kALGo6vXWkgqWqQT3miUc5KanpNiY3OOaGNAvAGduW9th23NbnZ8/AtwnuD2+J y8HjAMG4n/cYaBqBIJJtmm79eHQtHjHAEaVPHtVfpAtyTGnVqVuFb+wdbfj3sMInHrBfRG 6j5jU898/dLPE3fLeiwm1kbg4snuIZuqoRaIydteTEZODoq3nxawOLqEmClt8DZeEkiM15 qDzIZAMgjm4tUDn7PXPxeYUiKtG3ehO+hQ1O71pWoYeZxYXDKHzDoP5xTTYkInihKdVTWw NTFxig+bSJKk5ui9ymByUd50WSyc2cs4ibxm+RS4zblBgynEZ73MphDOXDUC4g== 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 4W2QR94T2zz13ZQ for ; Sun, 16 Jun 2024 21:01:09 +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 45GL19sv082110 for ; Sun, 16 Jun 2024 21:01:09 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 45GL19uL082109 for net@FreeBSD.org; Sun, 16 Jun 2024 21:01:09 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202406162101.45GL19uL082109@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, 16 Jun 2024 21:01:09 +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="17185716691.B7E61D0.70896" Content-Transfer-Encoding: 7bit --17185716691.B7E61D0.70896 Date: Sun, 16 Jun 2024 21:01:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 254445 | cloned_interfaces="bridge0" does not respect net. Open | 166724 | if_re(4): watchdog timeout Open | 200836 | iovctl(8): Return descriptions in the returned sc Open | 223824 | Panic in ng_base.c (netgraph) Open | 232472 | ixgbe(4): SR-IOV passthru not working on Hyper-V Open | 234073 | ixl(4): Host X710-DA2 drops connect starting bhyv Open | 241106 | tun/ppp: panic: vm_fault: fault on nofault entry Open | 245981 | bnxt(4): BCM57414 / BCM57416 not initializing: bn Open | 257038 | em(4): Panic on HTTP traffic to or from jail thro Open | 257286 | gateway with `ping -6 -e` is ignored Open | 258623 | cxgbe(4): Slow routing performance: 2 numa domain Open | 258850 | lagg(4): interface vanishes when both member inte Open | 261866 | ixgbe(4): Resets media type -> autoselect after s Open | 262024 | em(4): iflib handles bad packets incorrectly Open | 262093 | ixl(4): RX packet errors on Intel X710 after 12.2 Open | 263568 | ix(4): SR-IOV connection lost after loading VM wi In Progress | 118111 | rc: network.subr Add MAC address based interface 17 problems total for which you should take action. --17185716691.B7E61D0.70896 Date: Sun, 16 Jun 2024 21:01:09 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

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

17 problems total for which you should take action.
--17185716691.B7E61D0.70896--