From nobody Mon Apr 7 19:35:16 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZWfZ95gZJz5s2r0; Mon, 07 Apr 2025 19:35:29 +0000 (UTC) (envelope-from y.jaeyong@gmail.com) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 4ZWfZ86C0Pz3sYR; Mon, 07 Apr 2025 19:35:28 +0000 (UTC) (envelope-from y.jaeyong@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=aeK3NEjU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of y.jaeyong@gmail.com designates 2607:f8b0:4864:20::933 as permitted sender) smtp.mailfrom=y.jaeyong@gmail.com Received: by mail-ua1-x933.google.com with SMTP id a1e0cc1a2514c-86d30787263so2212598241.1; Mon, 07 Apr 2025 12:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744054527; x=1744659327; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ouw79k4tnMl7vTbMjEufJV43AMCPEQw61NNUlnkViUQ=; b=aeK3NEjUBwDc/lqDOP0WLy5sc7Tipm1aOc7+eLpooRUbra5K5Rox4axwjGvbrbzN5u gxISbO8Hphr5PrfD2n18nztfcx5W7DByuHqYIGZ3psSBIcpR3qPKxfTO+oUhuL823s7l +vKGPXokhN2B2wuXvdEK8sLC7dEFCILIcb6UmsVf8MpnBpFTE/ppXN/tYwGz4ucMLWbl REEw7whUvzy1Mc81ZP83KOpVHdPQm4oVvjvH/qWRrDOzwOvgSlw211wMnaPrBTJ17HTZ a/RpmP0Bo6uNgwfedqW+Lccs5ZGnrseE87/rIFo1KWeUORU239teb8Iox9gtxaESkVB1 leIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744054527; x=1744659327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ouw79k4tnMl7vTbMjEufJV43AMCPEQw61NNUlnkViUQ=; b=iNzS/GP0OCsy8PoR24jMuobfcJZ6wk3Fd5m4JgyJMKJKWsW3krxkb+JvjKGntZtsPe dbduAfzDP6s07UsMwLxF1Cx9C6MYxQQ6BeBQpTSZXYTZg7tCJXQXCOIvxvGYUPAkwgEM HZAirYEsItfAXrvoaWxxjE7OxWkE9dKHTkh8whtgY16ZH9qbWhFBnnTub2C5caeIPDhe 11e6fwH7anko1cUhFP+2bt8QVOpTLsObRItFNfVALnbVryZnSXzu12mAHr3ne50LuBCi 5b6v2hKGWktIC9AQ2rbeePnZJ3JZr1ymxRpVbocloEZSrKcpkqnSytj0pMUUPjmJSjVj EFOg== X-Forwarded-Encrypted: i=1; AJvYcCUl7LIPgYtQHWiLigIHqFyhtnti/XANEZrGRrCBtfRkQfSA6oC7NRHVv2N4+IhxqOJqK+BXBCPpDgdq3cYijqhcZQ==@freebsd.org X-Gm-Message-State: AOJu0YwVBonN1kpeHsRDmp+EIBocVGfoRLZyqnFcHt4uOGOgxY8V+cTv GwMnMjkDTMtrXfeOBdxNC887iF1/vs2BvE2CPxeYnLeSu6jasrYhLsMR2/n+V1l2nwqN2zu8Kgp BGS54uIxkFxFIkFACEsDapJH4bRgvzU84 X-Gm-Gg: ASbGnctJb2bZumUQQ3y8u51EVQHEgv0zzp92Va9FYZaYldu6AatJmUmWA4taq74AK84 +pFT2mdAIP0gPdsZHFjntTuT7cKUasg0HnBe9pJ1C5cD/hOkSPaBqJ+na0JFW22XfZC6Y4LHCk6 fRPaGBPP4dpFPDuFfEu/+5WdXJiOnlp7kUZl9ehx3LU8gobAV9FNkPocGhZ5JcJE2iCpnWgA== X-Google-Smtp-Source: AGHT+IHS8UHhnZQL2tRfMm4uVqZ4ZgT7NOl5MqAyYreDB7wd9+XNd7HrCCtlKjK1oTRxuGwVF2lKlkXDSXlV7P3ZNU8= X-Received: by 2002:a05:6102:3c84:b0:4b9:bd00:454b with SMTP id ada2fe7eead31-4c8553d8d2fmr10685849137.13.1744054527671; Mon, 07 Apr 2025 12:35:27 -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: In-Reply-To: From: jaeyong yoo Date: Mon, 7 Apr 2025 15:35:16 -0400 X-Gm-Features: ATxdqUEiC4NhPF1jEH7kUFsIEcJiYOrJfY03XDMhXGfYULj0PEz4vpAx2UxreX4 Message-ID: Subject: Re: HyStart availability in FreeBSD stack To: Cheng Cui Cc: freebsd-net@freebsd.org, freebsd-transport@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.87 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_LONG(-0.97)[-0.974]; NEURAL_HAM_SHORT(-0.90)[-0.904]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::933:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org,freebsd-transport@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZWfZ86C0Pz3sYR X-Spamd-Bar: --- I was taking a look into the code for rttsample and can we add calling that rttsample callback at tcp_xmit_timer: - https://github.com/freebsd/freebsd-src/blob/main/sys/netinet/tcp_input.c#= L3682 Looks like that place is to calculate t_srtt for TCP stack for feeding a new RTT from the recent ACK, which seems right for rttsample for HyStart. Thanks, Jaeyong 2025=EB=85=84 3=EC=9B=94 24=EC=9D=BC (=EC=9B=94) =EC=98=A4=ED=9B=84 4:17, j= aeyong yoo =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > Thanks Cheng, > > Yes it looks like it implements newround callback for HyStart. > But shouldn't it also need for "rttsample" callback? > > Thanks, > Jaeyong > > 2025=EB=85=84 3=EC=9B=94 24=EC=9D=BC (=EC=9B=94) =EC=98=A4=ED=9B=84 3:34,= Cheng Cui =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > > > > > > > On Mar 20, 2025, at 16:14, jaeyong yoo wrote: > > > > Hi net/transport, > > > > We are looking for using HyStart but looks like it is only implemented > > in RACK stack but not in FreeBSD TCP Stack. > > Is there a plan to support this in the near future? > > > > Thanks, > > Jaeyong > > > > > > Hi Jaeyong, > > > > Sorry for the delayed response. There is a patch to enable Hystart++ fo= r the default TCP stack. If you can help test it, I think it would be very = helpful to speed up its acceptance. > > > > https://reviews.freebsd.org/D46425 > > > > > > Best Regards, > > Cheng Cui > > > > > > From nobody Tue Apr 8 01:55:01 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZWq0G62Dkz5sXth; Tue, 08 Apr 2025 01:55:10 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZWq0G5ptJz3XDb; Tue, 08 Apr 2025 01:55:10 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744077310; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H4T0C3CGLETbC4JPJMsXzgJ/5dB76TwQBXxdzlqwvRs=; b=mDUoaXab7t+BvI8Yozq70e4hyKjrR/ZHx2tP34uCKNQZbJk4cCY2NEGFuAsbrSLciw0heK 91QheVii1+e5sYOcTMnqYzVv2+LixJ1iyU2ieaIxobUPvSyUBYS51J4u2ssKbltXAHmmOc 0Qa6mfPqlg+GBpoFPtv833TFEvfEXmddiSI8jdwl2xd7oQCotV0aWnh6yllrWSrBGC75Jk xqeI+eT/SgZFKYgKopJV0A1rKeF5UNIg1a6GJ2maInAw8qb64rR4+JNGurQtlzAeMBPq95 UIZI5yYyFcxKsE3VsteCG7utf1U8jdCheaaDU/bwtWGKAoST4/bglwoYYkmckg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744077310; a=rsa-sha256; cv=none; b=HpqCPA2gjmLP38PudGZsdq8bsgG5g3cnC2ZnZYoh+VJyIEI9VC51IyO1+OcXbMI2r8/TkN zyJOvwYV73tGOpEZwnxDplT/SxSXmeQNx4BYKpOhvqXotNTI08VhgjM8RcfkZaK4ATYJSa sityzDuURShQpTtPKOwYFoF+GgBVnP2kGLBz1AfdeaEELFGithuyLpyC6C10X38VcjCjCk EUKinWIF2zCdKYkmrZXncNznxaUKW6MEuYEjaY6/PS2JOhQIh5dwrd+DpVsfPIRGpnnu3N Asd5qDQyNhIqpoNUp+9jXOwdSWdKk5o3L3pZdnrmKlCtD9QZFxkuRYpzOUjPgA== 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=1744077310; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H4T0C3CGLETbC4JPJMsXzgJ/5dB76TwQBXxdzlqwvRs=; b=u3LObqdviW/taseLRw8WtNip+OJtkVAa4kolq1Makr1LB+AwflXmdPbAgKyDPlWy1VQU9Y Jv/Ixif61I+oTwBX82ahDbpU1E8zOy2unXb+GGijuU1Yt00bF1LDANwIZGELD0N+FKxKh2 o3ASSIn17YtZA+z+kC25mc7oSzVr+NgNZ/9uee/xGLyFdQNPSNTAUYkjegwHLaYITynhkC B554IPh+ilGORXyw9LI9ywL+r90Ce8iS/rS3lNx4zcYfArigUTUtlGOwIIbkpikH6UBvT6 8f9izj5jRFO/8KKzNdcW8qLzZXbbvbFnTiHT8LFM0vceyT6fPkqCCZLnWTwzMg== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZWq0C6qm2zNt9; Tue, 08 Apr 2025 01:55:07 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD" List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: pfil_default_to_drop Date: Tue, 8 Apr 2025 09:55:01 +0800 In-Reply-To: Cc: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost To: Robert Austen References: X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 8, 2025, at 6:36 AM, Robert Austen = wrote: >=20 >=20 >=20 > From: Robert Austen > > Sent: April 7, 2025 4:33 PM > To: freebsd-current@freebsd.org = >; = freebsd-net@freebsd.org = > > Subject: Fw: pfil_default_to_drop > =20 >=20 > From: Robert Austen > Sent: April 7, 2025 4:21 PM > To: freebsd-current@freebsd.org = > > Subject: pfil_default_to_drop > =20 > Hello, > I've been playing with FreeBSD and PF to build myself a new firewall, = as Open/FreeBSD + PF seems to be a common starting point. >=20 > I've noticed a number of people asking questions about = PF_DEFAULT_TO_DROP and the like, with the observations that it's hard > to ensure that packets all default to drop if the rule file(s) for = whatever reason fail to load.=20 Hi Robert, So why not defining the compile option PF_DEFAULT_TO_DROP, and preload = pf.ko ( via the loader(8), /boot/loader.conf ) ? With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 = ), you can turn the loader tunable net.pf.default_to_drop to 1, and = preload pf.ko. See also = https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f991322680= 1f3073bd = . >=20 > After looking thru the online documentation, forums and scripts, I = came to the conclusion that it's not a PF problem or IPFW etc > or really a problem with any of the filters or scripts, the problem is = at the level of PFIL, the kernel packet filtering code: If no > filter is loaded, i.e. if the heads are unhooked, then PFIL sends = everything thru to its destination. So my thought=20 > was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version = of PF_DEFAULT_TO_DROP) that drops all the > IPv4 and IPv6 packets that would otherwise go thru the = yet-to-be-loaded chosen filter (PF or whatever) at any given time the=20 > hooks are unhooked.=20 If no firewalls loaded, then the system should behave as is. I do not = think PFIL_DEFAULT_TO_DROP is the right way to handle your case. >=20 > [No one filters on local loopback nor the link layer, so I've left = those hooks untouched. I suppose one could add them, > maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I = doubt there's much demand for it.] >=20 > Normally I'm an embedded linux kernel basher. > I'm not entirely sure where to send this patch. Most of the threads = asking the above PF questions are closed to changes, > so that doesn't seem a good place. Sir Dice seems to be a common = answerer of questions; I would have sent it to him/her=20 > if I could... >=20 > I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = patch"... > I've simply diff -rdpNU 5 a copy of the @old folder with a copy of = @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64, > but I suspect the kernel code in the networking core doesn't change = much from platform to platform, or version to version. >=20 > But it works, it's pretty simple, pretty small and so just in case it = might be useful, I'm passing it along. >=20 > thanks! >=20 >=20 > Robert >=20 >=20 >=20 >=20 > --Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@willowglensystems.com> wrote:



From: Robert Austen <robert.austen@willowglensystems.com>
Sent: April 7, 2025 4:33 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@freebsd.org <freebsd-net@freebsd.org>
Subject: Fw: pfil_default_to_drop
 

From: Robert Austen
Sent: April 7, 2025 4:21 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>
Subject: pfil_default_to_drop
 
Hello,
I've been playing with FreeBSD and PF to = build myself a new firewall, as Open/FreeBSD + PF seems to be a common = starting point.

I've noticed a = number of people asking questions about PF_DEFAULT_TO_DROP and the like, = with the observations that it's hard
to ensure that packets all default to drop = if the rule file(s) for whatever reason fail to = load. 

Hi = Robert,

So why not defining the = compile option PF_DEFAULT_TO_DROP, and preload pf.ko= ( via the loader(8), /boot/loader.conf ) = ?

With 13.5, or upcoming 14.3 ( you can = also experiment latest stable/14 ), you can turn = the loader tunable net.pf.default_to_drop to 1, = and preload pf.ko.


After looking thru = the online documentation, forums and scripts, I came to the conclusion = that it's not a PF problem or IPFW etc
or really a problem with any of the filters = or scripts, the problem is at the level of PFIL, the kernel packet = filtering code: If no
filter is loaded, i.e. if the heads are = unhooked, then PFIL sends everything thru to its destination. So my = thought 
was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL = version of PF_DEFAULT_TO_DROP) that drops all the
IPv4 and IPv6 = packets that would otherwise go thru the yet-to-be-loaded chosen filter = (PF or whatever) at any given time the 
hooks are  = unhooked. 

If = no firewalls loaded, then the system should behave as is. I do not = think PFIL_DEFAULT_TO_DROP is the right way to handle your = case.


[No one filters on local loopback nor the = link layer, so I've left those hooks untouched. I suppose one could add = them,
maybe PFIL_DEFAULT_LOCAL_TO_DROP or = PFIL_DEFAULT_LINK_TO_DROP, but I doubt there's much demand for = it.]

Normally I'm an embedded linux kernel = basher.
I'm not entirely sure where to send this patch. Most of the = threads asking the above PF questions are closed to changes,
so that doesn't seem = a good place. Sir Dice seems to be a common answerer of questions; I = would have sent it to him/her 
if I could...

I'm not a user of = GIT, so I'm not sure how to submit a "GIT formatted patch"...
I've simply diff = -rdpNU 5 a copy of the @old folder with a copy of @new folder. The code = was written against FreeBSD-14.1-RELEASE-amd64,
but I suspect the = kernel code in the networking core doesn't change much from platform to = platform, or version to version.

But it works, it's = pretty simple, pretty small and so just in case it might be useful, I'm = passing it along.

thanks!


Robert




<FreeBSD-14.1-RELEASE-a= md64-pfil_default_to_drop.patch.zip>


= --Apple-Mail=_3490E1A7-EF10-4B15-9949-3A6A0A9A09FD-- From nobody Tue Apr 8 16:36:50 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXBYZ4nLRz5scnh for ; Tue, 08 Apr 2025 16:36: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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXBYZ43DNz41St for ; Tue, 08 Apr 2025 16:36:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744130210; 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=FRKyN8Hhc+AGcE2OKCJhRToZrd+u/OcJHZ599aSphtc=; b=x4KZg9+/iLnU76zUHhG+KECglsKhnC1vHZW9WLEgPNEeljmlne5TNJ/91eObfquVUgL6Aj SwuOco9LjVAC5SiBjHllFkI6r4duXYKgVqhMr5SxvJZEo33nS7qqha6V1gwQKQ24QI2m2D cDtk59TMtvGXHT8qPbfYJebV/9EwQE4tYSI9RG4I51DK7/N7kUQKXE83Ey09HneRqFhvkT NfWlERkZiIV97VPpdxHs6yL2l2nB6itG4ArifiwkCoaIDbF7LAi7nUsLphpi5FTQjOfu8p fFTQYB1Qd0i9OPwEwP1INRFr7w5DnedbYRFMv84uKJ1WKM+qSBqROGzbyXVF8w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744130210; a=rsa-sha256; cv=none; b=u5X5tX7j1oO/ayAzhVXb9iWVJoE8u4BZrCtB0th/VSq2yPrfu3spEzGmY0iwZlfUKGSfK0 SbVh6b6WjMqRsOBsx8TE7lAvXluCV/3pgrZDvpzGphDwn8unYo/48DvdODA9YFl5toEdHQ AyjPHSAzAZaXBTUZryy0xKEmiaJEpGQbY6aoV80+c++q6mwKc6XPMi+uJOv/wy9G9DYhSr JZU094GpBXvRkfApAXsTvQyGv4yh1ZpegpcX+rf+JaSg2ZSdmPTGiOm9RzvcglD4puceWx mVC9Z01U97AFYddYkKQpD+wB7YuQBNl6vhgIy29Wn+CIzet5tOaZSD/vgnkBCg== 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=1744130210; 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=FRKyN8Hhc+AGcE2OKCJhRToZrd+u/OcJHZ599aSphtc=; b=FEZMnvFaXtDs73fz1kMYkvjhM74dwbnhoDclOib4xka1BJFhtyH/n3n2FUkDjrg6tgDCsJ PteTRQc1a+JeSWo2bTyQgW0DDSBC25F+w0w36V8t9oilMrdfiXlDuCm9W7oU7Fzeddvb6D PApgVOdujzJP/lAhujoAr5caIffucjIo1QSEqW1s78Ko64O7TcNsh8u+oG8NAuLk3Bbuau h/uvcevJcTEHTOtzo/32ltXsuuob8SU8BHNX7waioS0vJuaTxjdtm3cVfZCGYaxZO+hBmF mujzJJXDcJJprVjkySSX3b67ky/Y3iUYSPaQ2ypHEKjvBt/c3QSWYo/dUpCL8g== 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 4ZXBYZ3HJ6zgPQ for ; Tue, 08 Apr 2025 16:36:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 538GaoIg018724 for ; Tue, 8 Apr 2025 16:36:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 538GaocR018723 for net@FreeBSD.org; Tue, 8 Apr 2025 16:36:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 285961] Kernel panic by iwlwifi0 Date: Tue, 08 Apr 2025 16:36:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: slw@zxy.spb.ru X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285961 Bug ID: 285961 Summary: Kernel panic by iwlwifi0 Product: Base System Version: 15.0-CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: wireless Assignee: wireless@FreeBSD.org Reporter: slw@zxy.spb.ru CC: bz@FreeBSD.org, net@FreeBSD.org Created attachment 259392 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D259392&action= =3Dedit core.txt Kernel panic in iwlwifi0 driver at random time #14 0xffffffff8553aaf6 in iwl_mvm_bt_notif_per_link (mvm=3D0xfffffe01a317b5= 08, vif=3D0xfffffe01a3903ec0, data=3D0xfffffe01099fad10, link_id=3D0) at /poudriere/jails/15base/usr/src/sys/contrib/dev/iwlwifi/mvm/coex.c:359 359 chanctx_conf->def.chan->band !=3D NL80211_BAND_2GHZ)) { (kgdb) p chanctx_conf->def $3 =3D {chan =3D 0xdeadc0dedeadc0de, width =3D 3735929054, center_freq1 =3D= 3735929054, center_freq2 =3D 3735929054, punctured =3D 49374} --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Apr 8 16:40:11 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXBdS5bPkz5sdPl for ; Tue, 08 Apr 2025 16:40:12 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXBdS3mm4z42lN for ; Tue, 08 Apr 2025 16:40:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744130412; 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=7t5LXy0hJZmbF5vSdQInNPK7JnefYfMFDUCMHCn+hOw=; b=F3+yLwbcU/MGrV1z4pHBBita82yDPixhu66nyhm53pzMr6EL/3LvHHXvN5eONPkJ7WLOmM p46GPkFiMP/sspErEf8/jaz2JrD60JjTNbzfrkM3h1gEozExYpoF/4SZ3NS6iPqW1KqLjt ukfgpfZBgLtrY4rbGCa7vZgMKIdfa4o4iZ296w9ul10bfsLX//FeyptqVVvwJgz5D9uz/i ubCuKRkuyhIaRbTae8hHJpAkynfTorNhUf8zpnA1VNlUsK0tgHS18PK20gP3L24PGqjhm6 qTMwAfOAj7afps5nmIgSdfUaEK937YKlRypkOtIgdrndRJc0vgJgMDsBcWTnWQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744130412; a=rsa-sha256; cv=none; b=O2wHmB9+I16yfsl41rNwSMgRw12r73HrhNtv0GRt3q2Icgg2P7e09zrgD0SXE+1bxXXA1N 51xVl2V04mdUpYdqmX7LcMO/iM2zOE5eYJayuIt+tNfCBqPBFekvFBO5rLeEe6DrG0LKjR /0EoTm4FZPiw4PJsy5gMO6Wt6fm31yEzTZnOtaPXgsZQxqVpDDHGbQV7TkbhgSbuodtFN6 CRmUGtiaTTUbSQVbikkqN9Jor8wZjrhyxim8alkFM7KxUV6/zhoWePCDfP+ckBNWXaoELF xh2Zj9uhvEIvBIC+ZG1+sd/jPEOCFaPpT0p8j4IX9uS6NEGFkvyIRbBqTXWF/w== 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=1744130412; 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=7t5LXy0hJZmbF5vSdQInNPK7JnefYfMFDUCMHCn+hOw=; b=CItGRwqduQK5JoKbkat7wX12OMXgrocYNVcXOyxz9Ty8rxDIhiVuxNmby2lgl2sneHVRwu Uj/4bxvXl2InVAZtVv7UTIjrGzs3BwncJx+5L0fkrtUOlBZi4+xxEFCO6MzsqU4V6aNs8E vT7d5zsqiMHs1K8g21dcmajBuppasUwr7D/LAuqNj/NElAqF3ni9PACKCLdzzhj2wsMQ4A QXgBwgl2UixqN0SPVR7XGoxBo1bu7D/WBXPVP7uMj5ZKXw+45tbIi+KGa5boc6GfkIDeAl rY7MGuBGiW3NPyXmRNDCBMHjr1NVDmZqrKcL9NGLWeWFp7t1Bm+kFKQY7I0Grg== 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 4ZXBdS2CTMzgPR for ; Tue, 08 Apr 2025 16:40:12 +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 538GeC5X021944 for ; Tue, 8 Apr 2025 16:40:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 538GeCmZ021943 for net@FreeBSD.org; Tue, 8 Apr 2025 16:40:12 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 285961] Kernel panic by iwlwifi0 Date: Tue, 08 Apr 2025 16:40:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285961 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|New |Closed --- Comment #1 from Bjoern A. Zeeb --- I am working on that as I type. *** This bug has been marked as a duplicate of bug 280546 *** --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Apr 8 16:40:52 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXBfD6XnQz5sdMv for ; Tue, 08 Apr 2025 16:40:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXBfD5pqzz43q4 for ; Tue, 08 Apr 2025 16:40:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744130452; 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=aWF3rVHNldbOCfyC2OFn8V9iXerIcpP3cLZQcx9gB9A=; b=WwjpS25tQrmhxNUYLtuzRr3EF2DN0EYmyihjEbjiHWDEWWnfkptKg2hFUOi5OpcBJsI1hP Dkjow93hLEOyD51HmQRYIUha/pRk1aZiY2MdHwbJuVNd3K2JV2yiDHu/IdzJ6Qi3vwvVx9 hPBA3AZrMhdI9gK0F+wJbKcaYTsPc7Crr0qDGTCNvB5WpbiIKO6vQMfp+GHnvLwnnypVdJ 6CY2cc8cVLFbwJ9RMM9Jpv2Z++LROvTcP/pRdWiZ/yOlf4WBwc2BGE4SyGI3O8xXENELTj BnWabv9AgpCP0JQAAZ3pEshaj4HuIBcn/6fMXSUYgzhFNJWQrqq06sMudXgEjw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744130452; a=rsa-sha256; cv=none; b=WImbYxLouHlS0O7eVl0RatDE/rh2awRrnIYAWGWYJ/vSQsL1yVBYsURjBHTwM3tfstkdXa AVViJ/mfIv8aCBecICzv2cc7KMnxfMv9KkIWq/pUzF5uKhFpVcZnmXhSZ37S0+uHCCnVpt 2Li+mIyxjlc+DxpZh4AjufqcmsidDLxA6HiKTjo8Wr/fldRgd4JKpZEDv5llYfCrbFvAVz OzOl4lT5vYmQxN0Y+axDZero8/KOI1ZJ5E1WYwADqmombq/l2lbpp+KwSo2LFLAN+MIeBm U0fw0GlSaNIBVB89e5h+VjJmZvVGVt2+Ir3R213POa2bZ3PijpDbJ9OokNiFVw== 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=1744130452; 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=aWF3rVHNldbOCfyC2OFn8V9iXerIcpP3cLZQcx9gB9A=; b=TBnURC7nlIPy5J0y2SZZo2G+BFLSAoO0nm7iEH4BL07E1Wl9175vNdJMc8MoPDvWbf5oOa r0HkstAOLYUHWvgkBjAmEj1febN0YdAxiNaY0QpvT/2KuwFk7OKG72M/IC02A91LrQAMFo lAdKyonov1mtKHG/8s6AevxCbemROjE/A0xRZN6DgMqvox3pZpjBwXGAs3xzh5Kv8nD7Kx X4dZPYb3rkzV6kMKRHYBGZGnPhR8swEuc1DHoLjf/lfYgdzXx4eHPWg8Hhh31QK3Rg+/6J SBIqGNJQsZMIwq7kaHZjkYGN2cmTJjwA2b8J1tNqDZqDmg2R1jo+h2N4LJBneQ== 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 4ZXBfD5Qj3zgc8 for ; Tue, 08 Apr 2025 16:40:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 538GeqEP023474 for ; Tue, 8 Apr 2025 16:40:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 538GeqZb023473 for net@FreeBSD.org; Tue, 8 Apr 2025 16:40:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 285961] Kernel panic by iwlwifi0 Date: Tue, 08 Apr 2025 16:40:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: blocked Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285961 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |273620 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273620 [Bug 273620] iwlwifi meta-bug --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Wed Apr 9 07:48:11 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXZnG74qXz5shdp; Wed, 09 Apr 2025 07:48:18 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXZnG6SPlz3RDn; Wed, 09 Apr 2025 07:48:18 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744184898; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Bve4yGyu1TEMucTKSXCLe+oUkHpkIsJ6geY6aVTZJOU=; b=qLc7VHSQaqMzzuw0rgG/ZuZWtwNnGcuhZQu+XkEHKKq6KJVlH+NerftE5e5hyDv7O/toTs Wq8x7d0XmLBDP7/kXqTBGBRI1tdBMCI+Wx7p03SBF7i+OO77wE8GVyDU8nit4uZ8KBxlyy b6de3ZujSmLQinC4TLcMmCZAfrEIOwNdPGGiNKfPVju/YB7XxJF7NFliXFC9aIiy+dtulF 30iRbrrySMvgPjbGVlmp3y4XIV0aGo3MA85CfP7jMtMFAsSLn9uFkFbharoGCNTZfMQInp 1iRikEIJ5Fe6a8w9SoZUoJWDeocENiha5kpgxm6br/dIy/HfgEOfRiqYmaZ9Bg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744184898; a=rsa-sha256; cv=none; b=XaoUtN0cXUoD0tqqOOJKZ61uayd7OVJIHUxxyNTlPGZwloYx+wmKz7oZmHDevuPl8o/mcD vo9EAYaptB5s1wp1TMD8XVrK87BEIsXdutTTQLw1Idln/kCID4i86ZrEyZfLh9nFD1riDy fqgllBgf575OIfm4Wsg+7mkLPAscikg+dmVrMK10E2m77GeZ209nFhXW0wWBIfCA5qr+MQ N/9FXXtEOFurcq1M/3eXykhoUCRdpUmzqhqRCtKISB4+elM5BRY8OSozzqBPY47mps7iOc vVag6KHmEn1TPkriCiwjqm/sSuhiSwGWeyTWpwKO7unCl+41WV7CA8EVkwUaMg== 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=1744184898; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Bve4yGyu1TEMucTKSXCLe+oUkHpkIsJ6geY6aVTZJOU=; b=AWtokODFPtxgp+r+4SU4rcMkwngcNDvxkRepCTml+SLJaUionrhJ40WXOmn3K/WpfGT6kB psGhuv8PeWCUrY9G62OJ87JK9peVFHjtqtjq2GXNyPdK3ilUedblbgqJTQ50FWHuvyQ0XZ qI+oGjU0Kh4MPHFVlCRHXcj8FX0Bbhuqdvf9sES41nkHDFhksQzPp+yGukeHllsBzT8yxx uchcwlLK/sEYffTjmEp5EvDgRoITpm/v/LMAtNMazS6IOzTODlvDmOudGZL2vuuq0uu8n0 ChUdjKeDZPhIs+OLNzYriAoaBfgIbIkBJp56CwAyM9bB685mLnB6W0czt/YZ4g== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZXZnD5CwFz53k; Wed, 09 Apr 2025 07:48:16 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE" List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: pfil_default_to_drop Date: Wed, 9 Apr 2025 15:48:11 +0800 In-Reply-To: Cc: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert To: Robert Austen References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 9, 2025, at 1:01 AM, Robert Austen = wrote: >=20 > I respectfully disagree. >=20 > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl = call to enable itself, ie. to apply any hooks. > if pfctl fails, then the hooks are left unhooked, and EVERYTHING = defaults to PASS, which is not what most people would intend using = PF_DEFAULT_TO_DROP. Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( = DIOCSTART ) or netlink command to enable it. @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? >=20 > consider this: until pf or ipf or ipfw makes an ioctl to hook = themselves, the pfil layer in the kernel has no idea what the filter = will be, > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect = (and likewise the equivalents from the other filters). As for ipfw(4), by default it enables filtering on load, unless you = disable it via loader tunable `net.inet.ip.fw.enable`, = `net.inet6.ip6.fw.enable` and `net.link.ether.ipfw`. The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable = `net.inet.ip.fw.default_to_accept` controls the default behavior to drop = or accept. See also = https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60e598498d= f6f9e2bd = . >=20 > as I said, this is because there's no mechanism within PFIL to drop by = default, which is why I proposed (and am using on my system) the = PFIL_DEFAULT_TO_DROP, > because it handles ALL of the 'no filter installed (yet)' cases. if = PFIL_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no = effect at all, > so it's a simple mechanism for those that want more than = PF_DEFAULT_TO_DROP can ever provide. It appears ipf(4) unconditionally enable filtering on load, and does not = have any tunables to control that. CC @Cy who is more familiar with = ipf(4). >=20 > thanks! > From: Zhenlei Huang > > Sent: April 7, 2025 7:55 PM > To: Robert Austen > > Cc: freebsd-current@freebsd.org = >; = freebsd-net@freebsd.org = >; Kristof = Provost > > Subject: Re: pfil_default_to_drop > =20 > You don't often get email from zlei@freebsd.org = . Learn why this is important = =09 >=20 >=20 >> On Apr 8, 2025, at 6:36 AM, Robert Austen = > wrote: >>=20 >>=20 >>=20 >> From: Robert Austen > >> Sent: April 7, 2025 4:33 PM >> To: freebsd-current@freebsd.org = >; = freebsd-net@freebsd.org = > >> Subject: Fw: pfil_default_to_drop >> =20 >>=20 >> From: Robert Austen >> Sent: April 7, 2025 4:21 PM >> To: freebsd-current@freebsd.org = > >> Subject: pfil_default_to_drop >> =20 >> Hello, >> I've been playing with FreeBSD and PF to build myself a new firewall, = as Open/FreeBSD + PF seems to be a common starting point. >>=20 >> I've noticed a number of people asking questions about = PF_DEFAULT_TO_DROP and the like, with the observations that it's hard >> to ensure that packets all default to drop if the rule file(s) for = whatever reason fail to load.=20 >=20 > Hi Robert, >=20 > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload = pf.ko ( via the loader(8), /boot/loader.conf ) ? >=20 > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 = ), you can turn the loader tunable net.pf.default_to_drop to 1, and = preload pf.ko. > See also = https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f991322680= 1f3073bd = . >=20 >>=20 >> After looking thru the online documentation, forums and scripts, I = came to the conclusion that it's not a PF problem or IPFW etc >> or really a problem with any of the filters or scripts, the problem = is at the level of PFIL, the kernel packet filtering code: If no >> filter is loaded, i.e. if the heads are unhooked, then PFIL sends = everything thru to its destination. So my thought=20 >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version = of PF_DEFAULT_TO_DROP) that drops all the >> IPv4 and IPv6 packets that would otherwise go thru the = yet-to-be-loaded chosen filter (PF or whatever) at any given time the=20 >> hooks are unhooked.=20 >=20 > If no firewalls loaded, then the system should behave as is. I do not = think PFIL_DEFAULT_TO_DROP is the right way to handle your case. >=20 >>=20 >> [No one filters on local loopback nor the link layer, so I've left = those hooks untouched. I suppose one could add them, >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I = doubt there's much demand for it.] >>=20 >> Normally I'm an embedded linux kernel basher. >> I'm not entirely sure where to send this patch. Most of the threads = asking the above PF questions are closed to changes, >> so that doesn't seem a good place. Sir Dice seems to be a common = answerer of questions; I would have sent it to him/her=20 >> if I could... >>=20 >> I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = patch"... >> I've simply diff -rdpNU 5 a copy of the @old folder with a copy of = @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64, >> but I suspect the kernel code in the networking core doesn't change = much from platform to platform, or version to version. >>=20 >> But it works, it's pretty simple, pretty small and so just in case it = might be useful, I'm passing it along. >>=20 >> thanks! >>=20 >>=20 >> Robert >>=20 >>=20 >>=20 >>=20 >> --Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willowglensystems.com> wrote:

I respectfully disagree.

PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its = ioctl call to enable itself, ie. to apply any hooks.
if pfctl fails, then = the hooks are left unhooked, and EVERYTHING defaults to PASS, which is = not what most people would intend using = PF_DEFAULT_TO_DROP.

Ahh, I see your problem. Yes, you're right. pf(4) = requires ioctl ( DIOCSTART ) or netlink command to enable = it.

@Kristof Maybe we also want a = loader tunable to enable pf(4) on load ?


consider this: until = pf or ipf or ipfw makes an ioctl to hook themselves, the pfil layer in = the kernel has no idea what the filter will be,
assuming there even is = one. thus PF_DEFAULT_TO_DROP  has zero effect (and likewise the = equivalents from the other filters).

As for ipfw(4), by default it enables filtering on = load, unless you disable it via loader tunable `net.inet.ip.fw.enable`, = `net.inet6.ip6.fw.enable` and `net.link.ether.ipfw`.

The compile = option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable = `net.inet.ip.fw.default_to_accept` controls the default behavior to drop = or accept.


as I said, this is = because there's no mechanism within PFIL to drop by default, which is = why I proposed (and am using on my system) the = PFIL_DEFAULT_TO_DROP,
because it handles ALL of the 'no filter = installed (yet)' cases. if PFIL_DEFAULT_TO_DROP isn't in the kernel = config file, my patches have no effect at all,
so it's a simple = mechanism for those that want more than PF_DEFAULT_TO_DROP can ever = provide.

It = appears ipf(4) unconditionally enable filtering on load, and does not = have any tunables to control that. CC @Cy who is more familiar with = ipf(4).


thanks!
From: Zhenlei Huang <zlei@FreeBSD.org>
Sent: April 7, 2025 7:55 PM
To: Robert Austen <robert.austen@willowglensystems.com>
Cc: freebsd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@freebsd.org <freebsd-net@freebsd.org>; Kristof Provost <kp@FreeBSD.org>
Subject: Re: = pfil_default_to_drop
 
You don't often get email from zlei@freebsd.org. Learn why this is important


On Apr 8, 2025, at 6:36 AM, = Robert Austen <robert.austen@willowglensystems.com> wrote:



From: Robert Austen <robert.austen@willowglensystems.com>
Sent: April 7, 2025 4:33 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@freebsd.org <freebsd-net@freebsd.org>
Subject: Fw: pfil_default_to_drop
 

From: Robert Austen
Sent: April 7, 2025 4:21 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>
Subject: pfil_default_to_drop
 
Hello,
I've been playing with FreeBSD = and PF to build myself a new firewall, as Open/FreeBSD + PF seems to be = a common starting point.

I've noticed a number of people = asking questions about PF_DEFAULT_TO_DROP and the like, with the = observations that it's hard
to ensure that packets all default to drop if the rule file(s) = for whatever reason fail to load. 

Hi Robert,

So why not defining the = compile option PF_DEFAULT_TO_DROP, and preload pf.ko ( via the loader(8), /boot/loader.conf ) ?

With 13.5, or upcoming 14.3 ( you can also experiment = latest stable/14 ), you can turn the loader tunable net.pf.default_to_drop to 1, = and preload pf.ko.
See = also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de= 4f9913226801f3073bd .


After looking thru the online documentation, forums = and scripts, I came to the conclusion that it's not a PF problem or IPFW = etc
or really a problem with any of the = filters or scripts, the problem is at the level of PFIL, the kernel = packet filtering code: If no
filter is loaded, i.e. if the heads are unhooked, then PFIL = sends everything thru to its destination. So my = thought 
was to add an option = PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_DEFAULT_TO_DROP) = that drops all the
IPv4 and IPv6 packets that = would otherwise go thru the yet-to-be-loaded chosen filter (PF or = whatever) at any given time the 
hooks are  = unhooked. 

If no firewalls loaded, then the system = should behave as is. I do not think PFIL_DEFAULT_TO_DROP is the = right way to handle your case.


[No one filters on local loopback nor the link layer, = so I've left those hooks untouched. I suppose one could add = them,
maybe = PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.]

Normally I'm an embedded linux = kernel basher.
I'm not entirely sure where to send this patch. Most of the = threads asking the above PF questions are closed to changes,
so that doesn't seem a good = place. Sir Dice seems to be a common answerer of questions; I would have = sent it to him/her 
if I could...

I'm not a user of GIT, so I'm = not sure how to submit a "GIT formatted patch"...
I've simply diff -rdpNU 5 a copy of the @old folder = with a copy of @new folder. The code was written against = FreeBSD-14.1-RELEASE-amd64,
but I suspect the kernel code in the networking core doesn't = change much from platform to platform, or version to version.

But it works, it's pretty = simple, pretty small and so just in case it might be useful, I'm passing = it along.

thanks!


Robert




<FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip&g= t;


= --Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE-- From nobody Wed Apr 9 10:17:14 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXf595ndYz5srnk; Wed, 09 Apr 2025 10:17:17 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXf593phDz45Sy; Wed, 09 Apr 2025 10:17:17 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744193837; 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:autocrypt:autocrypt; bh=F0y52mw6PvNIVwhytfp5RRDdyqKgbY14pQ2zSV8ob0c=; b=skj72Pltyihp7edIxK4wpuzTw4Pbw77t7xAgUkMecswmj4mb1mYvZs2AToH+FkT7LsyK3V rRxthSWTq2P3OFuZROZthO6XN0cyFqWiAoEvK7C8Kclf5/bfrC4Dnan4z/ejApExBukMnK Eigt9jm144LhcvGOHvuTve77oP5wd/DIeWzvM52Y6IV8p38Fk1DKBkGmVPDzqjPbF6o1UO d6h3kwuzLAfIYmy5uOPY35VunCCT3tjy1cx9Ep8pYhVNrAkoXIhM5HMfYjkvGcZQvcH4rS gnuFl7E8O7PhgkEtntU7QzNOH4rMTmDtZ/iUnK0eCNP2zsWhK7ltLLimLe3WpA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744193837; a=rsa-sha256; cv=none; b=aCvUfdER8wBFlxc2x7stasQua9kq4/nGpAl2GhkENI0c+y8FdfORVjaAKDq3Izo5vCfOcG HUdpoajViNd3A0dIV+9al1SJzliAM5NuqY8Jdzj5dpuzoPlOHtTpniGlh8PPhCh9QqlL1a VJlIPE7St1TMVMX3u9Tu3blTVdi09jDFl+GFAmCGHfoxFsjPv0mekQg83koxSx22o/vK0Y vksUyuRZhpZ5MHD01JdE0ft7rOfFkxb05w4s8seQAlWBCylqTLmXmSjWkAhEH4RRBJz9Cb dHySacc1W/zI85L1fgOQx3Pu2F2+fbGe//kB1PnfbZJSmPPnju7+33gKyj2WcQ== 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=1744193837; 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:autocrypt:autocrypt; bh=F0y52mw6PvNIVwhytfp5RRDdyqKgbY14pQ2zSV8ob0c=; b=tMo3GXufJ3K6/mt8bjlgIMqbYegwFc/ODgHAODXAKpI5v06cudkPeyeX+EAcB5kIaIAlas 8TtpcHXk9WHp5XLZZNnVLkTejtw7kCiT9+ffOZJ73IxJlbMOElN0j8obsvFeudMFF8HM7r 90uR0oGKetfLGL2kMXFaH98wafMz5SD4dJEhsJ4/mO1wg/ULJzxl+W+u8r67q9GoO8GG8d atpRLfggeyeMZe57q3JBJ2vONLnkIqJQN+RpvSfI8SIB8DotQzCoUJwk0XSyrIeL2mn4kK wI7ZmAZsRTVlwWUu31fiD5qfhO2omoAGmjDQhstRv6JuH6U1oAejgO/uLWAoTA== Received: from [IPV6:2a01:e11:2002:4280::13:1] (unknown [IPv6:2a01:e11:2002:4280::13:1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZXf5906xtz8KY; Wed, 09 Apr 2025 10:17:16 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <1b9603d8-7128-4809-9926-048426db122e@FreeBSD.org> Date: Wed, 9 Apr 2025 12:17:14 +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: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] To: Marek Zarychta , FreeBSD Current , net@FreeBSD.org References: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> Content-Language: en-US, it, en-GB From: Guido Falsi Autocrypt: addr=madpilot@FreeBSD.org; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNIkd1aWRvIEZhbHNpIDxtYWRwaWxvdEBGcmVlQlNELm9yZz7CwHgEEwECACIFAk+G+3MC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEBrmhg5Wy9KT2uIIAIrawQ89TnqEhi2C OEQAhx3uqWZuNoS6NyiSgsRCmtSnT2GOgH4Ucbr/I37SkV1B3K6HkoL6lwN8Gjf5KOgLqmTi E1W3RTwS7l8PSvdnjM9i7g351R4mTijtxawB/JcQf/Kge3Yqr1V4g6H+wQXHUStmHThbupuN trzRphvR/e5ekT0FTyVfPmpcbm68i2bwZnKUex/TNIECBykYh8b+SYMLhENf2ayRjCIWS2Ad 7tnTKhMtnS5jtW6qjBy4RoTpQD6oR1xIgkTRlQ49roVCUfdHb+Y/kh+U9G1IcoNy4vkg9IfP dwpSfnP+a8j0AZ1hMnOLZ1fYoQrs+4gVLy8Fs7TOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj 6SQYisvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef +WE75M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ube T3XwQO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr 8OEQfOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB 2i6A/xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45 qfyhMiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0 xpNiUilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWA dlKCNTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanC YrAg+8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNR gow3kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCk X/qwEVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7F jfrV+dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxA lZ/7i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+ lQMZ9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8 LkQdrQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/6/25 23:38, Marek Zarychta wrote: > W dniu 6.04.2025 o 16:49, Guido Falsi pisze: >> Hi! >> >> I have recently implemented and tested the patch at [1], which >> implements RFC 7217, about generating IPv6 addresses that are constant >> through reboots, but do not expose the MAC address of the machine, not >> being in any way derived by those. >> >> I'd like to get comments, testing and review for this patch, with the >> objective of getting approval to commit it to head once it is >> streamlined enough. >> >> BTW I'd like to thank cognet for his suggestions and help with the >> patch, in particular his help in finding the correct way to implement >> the dad_failures counter. >> >> >> And thanks in advance to anyone willing to give feedback! >> >> >> [1] https://reviews.freebsd.org/D49681 >> > This is great news for the community ! > > I've already started testing it on both a desktop and a laptop - which > is probably even more valuable, especially since the laptop will be > connecting to various networks. If I encounter any issues, I will post > comments in the review. I posted an updated patch, addressing feedback and containing some more improvements. If testing this new patch, the flag needs to be activated per interface with ifconfig(8) now, or via tunable in loader.conf. Should generate the same addresses it was generating before, with the only exception of the (relatively improbable) case that the previous patch was generating a reserved IPv6 address, which is now checked for and another one generated in such a case. -- Guido Falsi From nobody Wed Apr 9 10:51:26 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXfrm2rQDz5stYg; Wed, 09 Apr 2025 10:51:36 +0000 (UTC) (envelope-from SRS0=NHG6=W3=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int-backup.realworks.nl (smtp-relay-int-backup.realworks.nl [87.255.56.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXfrm0k6xz3GQp; Wed, 09 Apr 2025 10:51:36 +0000 (UTC) (envelope-from SRS0=NHG6=W3=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Received: from smtp-relay-int-backup.realworks.nl (crmlive3.colo2.realworks.nl [10.2.52.23]) by mailrelayint2.colo2.realworks.nl (Postfix) with ESMTP id 4ZXfrb2cDRz1M6; Wed, 9 Apr 2025 12:51:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1744195887; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=h1UpUvlmWYJBK5VTD+Djh7eUoMlc/cieTmia4j9K1N0=; b=UhdBjXRxO5DC5p5mT7uwHoAVBLzH+SlKzhNbRXnzllEekMkCmcd4ydCDbTSb89QZveQNuQ LvQ61ribQPsbmFo7NgwiVDaaLfsJccGzLmaXdXF1K3CJn9v7tfgl/0C3nZ29X0v7qfrz2i nz7adFiqttoGIXe6+4OC0JuZI1cX4FFRLkmImE6opSCbfIvsBsLvjTp2dmanzR7JG2k9zv 9BHZn62oGcoijNCgYolU8iAAROinWrDBThhIGcSRLVKudYMUw8bgs6bRetyCaO6UhtPfKT SXUbn/Ml0PeXeIvc+031A/3qArBwUqUr6lCQ+NTz3rlQE46XLMoEMnWJsUMhcw== Received: from crmlive3.colo2.realworks.nl (localhost [127.0.0.1]) by crmlive3.colo2.realworks.nl (Postfix) with ESMTP id 453E52A0716; Wed, 9 Apr 2025 12:51:26 +0200 (CEST) Date: Wed, 9 Apr 2025 12:51:26 +0200 (CEST) From: Ronald Klop To: Guido Falsi Cc: Marek Zarychta , FreeBSD Current , net@FreeBSD.org Message-ID: <1699210246.52160.1744195886991@localhost> In-Reply-To: <1b9603d8-7128-4809-9926-048426db122e@FreeBSD.org> References: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> <1b9603d8-7128-4809-9926-048426db122e@FreeBSD.org> Subject: Re: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_52159_965958018.1744195886988" X-Mailer: Realworks (744.6) X-Originating-Host: from (89-20-164-210.static.ef-service.nl [89.20.164.210]) by crmlive3 [10.2.52.23] with HTTP; Wed, 09 Apr 2025 12:51:26 +0200 Importance: Normal X-Priority: 3 (Normal) X-Originating-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:137.0) Gecko/20100101 Firefox/137.0 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:38930, ipnet:87.255.32.0/19, country:NL] X-Rspamd-Queue-Id: 4ZXfrm0k6xz3GQp X-Spamd-Bar: ---- ------=_Part_52159_965958018.1744195886988 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Next to hostuuid you could add a jailname in the mix. That is what ether_gen_addr(9) does to make it easier to prevent collisions while copying jails around or run a jail on a readonly shared base filesystem. Regards, Ronald. Van: Guido Falsi Datum: woensdag, 9 april 2025 12:17 Aan: Marek Zarychta , FreeBSD Current , net@FreeBSD.org Onderwerp: Re: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] > > On 4/6/25 23:38, Marek Zarychta wrote: > > W dniu 6.04.2025 o 16:49, Guido Falsi pisze: > >> Hi! > >> > >> I have recently implemented and tested the patch at [1], which >> implements RFC 7217, about generating IPv6 addresses that are constant >> through reboots, but do not expose the MAC address of the machine, not >> being in any way derived by those. > >> > >> I'd like to get comments, testing and review for this patch, with the >> objective of getting approval to commit it to head once it is >> streamlined enough. > >> > >> BTW I'd like to thank cognet for his suggestions and help with the >> patch, in particular his help in finding the correct way to implement >> the dad_failures counter. > >> > >> > >> And thanks in advance to anyone willing to give feedback! > >> > >> > >> [1] https://reviews.freebsd.org/D49681 > >> > > This is great news for the community ! > > > > I've already started testing it on both a desktop and a laptop - which > is probably even more valuable, especially since the laptop will be > connecting to various networks. If I encounter any issues, I will post > comments in the review. > > I posted an updated patch, addressing feedback and containing some more improvements. > > If testing this new patch, the flag needs to be activated per interface with ifconfig(8) now, or via tunable in loader.conf. > > Should generate the same addresses it was generating before, with the only exception of the (relatively improbable) case that the previous patch was generating a reserved IPv6 address, which is now checked for and another one generated in such a case. > > -- > Guido Falsi > > > > ------=_Part_52159_965958018.1744195886988 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Next to hostuuid you could add a jailname in the mix.

That is what ether_gen_addr(9) does to make it easier to prevent collisions while copying jails around or run a jail on a readonly shared base filesystem.

Regards,
Ronald.

 

Van: Guido Falsi <madpilot@FreeBSD.org>
Datum: woensdag, 9 april 2025 12:17
Aan: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>, FreeBSD Current <freebsd-current@freebsd.org>, net@FreeBSD.org
Onderwerp: Re: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)]

On 4/6/25 23:38, Marek Zarychta wrote:
> W dniu 6.04.2025 o 16:49, Guido Falsi pisze:
>> Hi!
>>
>> I have recently implemented and tested the patch at [1], which >> implements RFC 7217, about generating IPv6 addresses that are constant >> through reboots, but do not expose the MAC address of the machine, not >> being in any way derived by those.
>>
>> I'd like to get comments, testing and review for this patch, with the >> objective of getting approval to commit it to head once it is >> streamlined enough.
>>
>> BTW I'd like to thank cognet for his suggestions and help with the >> patch, in particular his help in finding the correct way to implement >> the dad_failures counter.
>>
>>
>> And thanks in advance to anyone willing to give feedback!
>>
>>
>> [1] https://reviews.freebsd.org/D49681
>>
> This is great news for the community !
>
> I've already started testing it on both a desktop and a laptop - which > is probably even more valuable, especially since the laptop will be > connecting to various networks. If I encounter any issues, I will post > comments in the review.

I posted an updated patch, addressing feedback and containing some more improvements.

If testing this new patch, the flag needs to be activated per interface with ifconfig(8) now, or via tunable in loader.conf.

Should generate the same addresses it was generating before, with the only exception of the (relatively improbable) case that the previous patch was generating a reserved IPv6 address, which is now checked for and another one generated in such a case.

-- 
Guido Falsi <madpilot@FreeBSD.org>
 

  ------=_Part_52159_965958018.1744195886988-- From nobody Wed Apr 9 11:10:47 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXgGy2TQTz5svRr; Wed, 09 Apr 2025 11:10:50 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXgGx6WdYz3NND; Wed, 09 Apr 2025 11:10:49 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744197049; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Q/t52UBMYqQH+uJC42Gh7+dlz+EODIHiSLLWTk9BW5Y=; b=d90svDCPakkfSK46N8FUs4h/45Q0f55bVcS72PpzCtM8leexBgKGXbibDavVO0OwtTjPId +tsq1W/vqAGAZPgNuZQvyOvYbHwf1W/WUMxS7KbHPh5ii6hCmyMJ+npnOc0aqaaK2fubIq TzqI6Igr8MuIrjjJPA/RzMoEOLCRSlRugUqKwlgGKA06L3o/nOSqL3lVz0xsbEBP0vKd8P n2oC4/mtw1sxg8mOjBojNJztZHR5XNSmMFc3flu30WGyIqV7j6UZalXc7tXOEdkmMlQaNy rYlA7DMxw73qc3sNWViWhVEo0lgmeAYF1tarxZnBRMA8NLGJbXIR0jWzlgnBIw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744197049; a=rsa-sha256; cv=none; b=tSypkZ0TA4IL8n+4LrQOdl7OE0N7NmbJDe8wixknivE12JRxsDjxXRBVApTX3KVSFiipxM lq5KtwJ2TFYQ14N2o7/VAa/CnXbf1YBufkClEu0yklGBjsuLdyBFOP3HSq+Ha2pJ2bUSve tbocpoDsx0ZIZOW7W1JO21hOUMv4/gYr9Y8gAD5lJQyBz/SXKCnW8zUYgrhyhta3D1UOC6 ej6xdJU7fV9Dxr9vTyHU5HVhjtmHF8CKPY3GbJXhCIHhvPFbJc05I6GmMkItShAm/K554D tBnS/NfPOVEcZ0fGdSh668mP84f9HtzAxGs27vYp+e0Q5uQbbA6L9sJKBMnaJw== 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=1744197049; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=Q/t52UBMYqQH+uJC42Gh7+dlz+EODIHiSLLWTk9BW5Y=; b=ByofJQ5P3S2cpO9rmJmJW7HeA2fKhegDF1HuwEHhSHV9P9Kq9GZfEmiTClqGbcGGLEQNuE x/LkWWh+qOCQ6Ffh/9Car+E2IA7XbpIeeJB5Vvk2z/1x/6+n2GTuO5yNMMdjipiEk1ErpM IeLImf8lnc7B7ISO+h3cPLddQ4Asa2t12+a/bus0+tHsxINZi5ZVyGEgiw0XXD18JoKtFj yZoFlwI8aPr6smgPaHfnaM7lpI3+R0jRgpy0ZcCoCBUBihyZOAgr+riFTheLFja8JOffEL B4A8CxAdgUqQYlCUjogL5D8p2kmovUjgOwa7x0AjBuX4z0Qp+JbC0yx8V8+PJA== Received: from [IPV6:2a01:e11:2002:4280::13:1] (unknown [IPv6:2a01:e11:2002:4280::13:1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZXgGx20qBz969; Wed, 09 Apr 2025 11:10:49 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <6e3dd061-f377-4f20-bcd1-f1a5afeaa36f@FreeBSD.org> Date: Wed, 9 Apr 2025 13:10:47 +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: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] To: Ronald Klop Cc: Marek Zarychta , FreeBSD Current , net@FreeBSD.org References: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> <1b9603d8-7128-4809-9926-048426db122e@FreeBSD.org> <1699210246.52160.1744195886991@localhost> Content-Language: en-US, it, en-GB From: Guido Falsi Autocrypt: addr=madpilot@FreeBSD.org; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNIkd1aWRvIEZhbHNpIDxtYWRwaWxvdEBGcmVlQlNELm9yZz7CwHgEEwECACIFAk+G+3MC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEBrmhg5Wy9KT2uIIAIrawQ89TnqEhi2C OEQAhx3uqWZuNoS6NyiSgsRCmtSnT2GOgH4Ucbr/I37SkV1B3K6HkoL6lwN8Gjf5KOgLqmTi E1W3RTwS7l8PSvdnjM9i7g351R4mTijtxawB/JcQf/Kge3Yqr1V4g6H+wQXHUStmHThbupuN trzRphvR/e5ekT0FTyVfPmpcbm68i2bwZnKUex/TNIECBykYh8b+SYMLhENf2ayRjCIWS2Ad 7tnTKhMtnS5jtW6qjBy4RoTpQD6oR1xIgkTRlQ49roVCUfdHb+Y/kh+U9G1IcoNy4vkg9IfP dwpSfnP+a8j0AZ1hMnOLZ1fYoQrs+4gVLy8Fs7TOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj 6SQYisvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef +WE75M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ube T3XwQO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr 8OEQfOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB 2i6A/xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45 qfyhMiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0 xpNiUilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWA dlKCNTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanC YrAg+8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNR gow3kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCk X/qwEVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7F jfrV+dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxA lZ/7i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+ lQMZ9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8 LkQdrQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: <1699210246.52160.1744195886991@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/9/25 12:51, Ronald Klop wrote: > Hi, > > Next to hostuuid you could add a jailname in the mix. > > That is what ether_gen_addr(9) does to make it easier to prevent > collisions while copying jails around or run a jail on a readonly shared > base filesystem. The RFC is very clear on what should be used to derive the address, so I'm not very keen on adding things around. The UUID should be changed when copying jails that run in parallel, they ARE different machines. although I am also at fault here. But the jailname is the correct parameter? This would change the address if the name is changed, which could be ok I guess. I'd also add this parameter only if actually jailed, skipping it for the host. My real issue with this approach is, the RFC is quite detailed on hash parameters. Will the implementation still be conforming if adding local ones? -- Guido Falsi From nobody Wed Apr 9 11:19:30 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXgT16yFMz5svT5; Wed, 09 Apr 2025 11:19:33 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXgT160Q4z3RRm; Wed, 09 Apr 2025 11:19:33 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744197573; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=RLE4Mth0RyFPrADRLz+MQ8izEShd+xcxwv7hgwoR6RU=; b=p75GqcLfEEUXfIvmmadMgilvzuCUQmNXXZjraXbwgdYeWHU2VDEVHme3dBM3RthTW7q2k3 rWh+bU42fTePcLzWIKKrxQpRFUceZbVseH0Drf0aufsGtm5haLhdYm+3oV33RHFGs+xnTv 7sh/RgQEKWz5XfJEMXIgUp2R6ZVus8eVgXAndzzz4K2xgTkOXEDEPwxQDA5Me0YWbnBMLc FCTV6axKuWLg9/uRySP8c04y96eUNVWve5KvfwfDvxRqwW4QCkUj0D+dlhlOLhoezBxZWP twYGzpzij/X4PJeDm3/IoBQPv/751PacwizUwz7IG4FU4scTV6FN88MNdexPYw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744197573; a=rsa-sha256; cv=none; b=KozEPYLl0wCrif2+xG0e1W8vXMEdK/T0cRwr3kmEsR4taCOQFaKwnsWkR5EcNyxD5KS+Jz IEkQn5jRAIArCOC9/kgrVVkjT74U/yJXqrKsyxwk81d1b/0qyimj/+Yw1ZLXsifzSfz0ZW slmAgVLRuFz7cNl1hTLCmhNG1puykm/z3rdBBIpTW9S3nT57aXIzWAwqUsAFI7I7KjSUxw GlV43d6faJPd1FGUNakoI9C396n3i+HSxtT0PnBMekl6mmBT8d20nPucRQkhEwyi7ySaL/ 9SnMnm+rCqVDbRcGQeUlq/dOVwt2CnATKcT45KQpSByIxQfd4tDO7w1FDCVEzw== 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=1744197573; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=RLE4Mth0RyFPrADRLz+MQ8izEShd+xcxwv7hgwoR6RU=; b=RNGcl2BXWk0angfWV8LzoCWJNRqw8bnCAU0YNRhTgUqCdg4/MMPxIo2jpQ39205ZuvSAlb gXHMEkiGBUplrd71IUlM21rShoIvKlebtJo7ervKGtNfZZwFOhB7da1qYCU/CAjEdjCadt vBQBWv8mGNAQr0UaXUXhIZUIpTg8zsGtef+A2mREMopjYo7LmyYDTIr+jeWrlPvia7yEuH gca6wlx2IRjnqvbtOf9IgYDv2z+uQdlzYPPvTjQrgmXlwMtGugVtgUyCQffbGDBcCjZ89O 3W91k8Z4VgPHUUMBC7iHrLUFve1qGplhJpiNFCOxnVT5NB05v+IzOceHu9iwmA== Received: from [IPV6:2a01:e11:2002:4280::13:1] (unknown [IPv6:2a01:e11:2002:4280::13:1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZXgT11ksvz9Tb; Wed, 09 Apr 2025 11:19:33 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Message-ID: <0a6709f8-275c-4c18-b195-1333a44fd1a7@FreeBSD.org> Date: Wed, 9 Apr 2025 13:19:30 +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: RFC: Implementation of RFC 7217 [A Method for Generating Semantically Opaque Interface Identifiers, with IPv6 Stateless Address Autoconfiguration (SLAAC)] From: Guido Falsi To: Ronald Klop Cc: Marek Zarychta , FreeBSD Current , net@FreeBSD.org References: <45b17684-75ef-4953-b59a-3c3b483ba21b@FreeBSD.org> <61dfdcac-4893-4c4b-b7e2-48164f1f0c80@plan-b.pwste.edu.pl> <1b9603d8-7128-4809-9926-048426db122e@FreeBSD.org> <1699210246.52160.1744195886991@localhost> <6e3dd061-f377-4f20-bcd1-f1a5afeaa36f@FreeBSD.org> Content-Language: en-US, it, en-GB Autocrypt: addr=madpilot@FreeBSD.org; keydata= xsBNBE+G+l0BCADi/WBQ0aRJfnE7LBPsM0G3m/m3Yx7OPu4iYFvS84xawmRHtCNjWIntsxuX fptkmEo3Rsw816WUrek8dxoUAYdHd+EcpBcnnDzfDH5LW/TZ4gbrFezrHPdRp7wdxi23GN80 qPwHEwXuF0X4Wy5V0OO8B6VT/nA0ADYnBDhXS52HGIJ/GCUjgqJn+phDTdCFLvrSFdmgx4Wl c0W5Z1p5cmDF9l8L/hc959AeyNf7I9dXnjekGM9gVv7UDUYzCifR3U8T0fnfdMmS8NeI9NC+ wuREpRO4lKOkTnj9TtQJRiptlhcHQiAlG1cFqs7EQo57Tqq6cxD1FycZJLuC32bGbgalABEB AAHNIkd1aWRvIEZhbHNpIDxtYWRwaWxvdEBGcmVlQlNELm9yZz7CwHgEEwECACIFAk+G+3MC GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEBrmhg5Wy9KT2uIIAIrawQ89TnqEhi2C OEQAhx3uqWZuNoS6NyiSgsRCmtSnT2GOgH4Ucbr/I37SkV1B3K6HkoL6lwN8Gjf5KOgLqmTi E1W3RTwS7l8PSvdnjM9i7g351R4mTijtxawB/JcQf/Kge3Yqr1V4g6H+wQXHUStmHThbupuN trzRphvR/e5ekT0FTyVfPmpcbm68i2bwZnKUex/TNIECBykYh8b+SYMLhENf2ayRjCIWS2Ad 7tnTKhMtnS5jtW6qjBy4RoTpQD6oR1xIgkTRlQ49roVCUfdHb+Y/kh+U9G1IcoNy4vkg9IfP dwpSfnP+a8j0AZ1hMnOLZ1fYoQrs+4gVLy8Fs7TOwU0EUxB7QQEQAKFhrDceoPdK/IHDSmoj 6SQYisvM7VdhcleS7E9DoEAVt7yMbf6HbbMVTTY6ckvwTWQssywLBXNVqxgc4WLJjzfUhgef +WE75M3+WFYlOVQLGZY/zEVgma1raYnOHNAOzeHLDmEXjbZP6vGAeDyBbGfQPpE7qGYZ7ube T3XwQO+PklcCrvOPj2ZPcAxGNS2xVU/LzONqCrJqLMJSIcCdsbiSP4G5PnDFHtMokaTY6OEr 8OEQfOAerhcHUa/z7Uu8YtmaqKH+QGkE/WEgaRqSiTnv0JOTD+DxehaqvoKPPZ++2NpCZMHB 2i6A/xifmQwEiIjEXtcueBRzkNUQkxhqZyS13SrhocL9ydtaVPBzZatAEjUDDEJmAMLVFs45 qfyhMiNapHJo2n3MW/E5omqCvEkDdWX/en3P7CK2TemeaDghMsgkNKax/z0wNo5UZCkOPOz0 xpNiUilOVbkuezZZNg65741qee2lfXhQIaZ66yT7hphc/N/z3PIAtLeze4u1VR2EXAuZ2sWA dlKCNTlJMsaU/x70BV11Wd/ypnVzM68dfdQIIAj1iMFAD/lXGlEUmKXg5Ov2VQDlTntQoanC YrAg+8CttPzjrydgLZFq3hrtQmfc0se5yv1WHS69+BsUOG09RvvawUDZxUjW19kyeN9THaNR gow3kSuArUp6zSmJABEBAAHCwF8EGAEIAAkFAlMQe0ECGwwACgkQGuaGDlbL0pMN5wgA4bCk X/qwEVC06ToeR6C2putmSWQMgpDaqrv65Hubo+QGmg2P4ewTYQQ4g6oYWS03qHxqVVWhKz7F jfrV+dH8qbCLfSgIcvdBha7ayGZVrsiuMLKGbw36fcmkZPpSDOfHcP0XH8Z+u9CWj0xUkTxA lZ/7i6gYSUpG2JWNtdmE/X8VVEyXusCLwy0K0BI60A/4dRTIX3C4QKrJ3ZbUXegz70ynjHf+ lQMZ9IZKASoRMuS5FozPQh6abvmwZEPdf5I9riUElzvHrqJ8Bx0t3Pujdoth+yNHpnBxrtO8 LkQdrQ58P0SwcaIX33T2U9pG8bhu5YVR88FQ8OQ0cEsPBpDncg== In-Reply-To: <6e3dd061-f377-4f20-bcd1-f1a5afeaa36f@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/9/25 13:10, Guido Falsi wrote: > On 4/9/25 12:51, Ronald Klop wrote: >> Hi, >> >> Next to hostuuid you could add a jailname in the mix. >> >> That is what ether_gen_addr(9) does to make it easier to prevent >> collisions while copying jails around or run a jail on a readonly >> shared base filesystem. > > The RFC is very clear on what should be used to derive the address, so > I'm not very keen on adding things around. > > The UUID should be changed when copying jails that run in parallel, they > ARE different machines. although I am also at fault here. > > But the jailname is the correct parameter? This would change the address > if the name is changed, which could be ok I guess. > > I'd also add this parameter only if actually jailed, skipping it for the > host. > > My real issue with this approach is, the RFC is quite detailed on hash > parameters. Will the implementation still be conforming if adding local > ones? > > BTW, this is easy to add and also add conditionally on being jailed or not, I'd just like some consensus on this before adding, especially the RFC compliance issue. -- Guido Falsi From nobody Wed Apr 9 14:39:06 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXlvM06Hkz5rt9X; Wed, 09 Apr 2025 14:39:11 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXlvL3J9wz3LM7; Wed, 09 Apr 2025 14:39:10 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTPS id 2VhiuklXK5Mqy2Wa5us5lf; Wed, 09 Apr 2025 14:39:09 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id 2Wa3uqVlol5eG2Wa4uhI6L; Wed, 09 Apr 2025 14:39:09 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=EO6l0EZC c=1 sm=1 tr=0 ts=67f6868d a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=XR8D0OoHHMoA:10 a=6I5d2MoRAAAA:8 a=_EeEMxcBAAAA:8 a=EkcXrb_YAAAA:8 a=HIpOd3htAAAA:8 a=YxBL1-UpAAAA:8 a=K8lFCU26Szz-7fEI1asA:9 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=kmlo3kNSEkcePd_NiW6t:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 468B4C24; Wed, 09 Apr 2025 07:39:07 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (Postfix) with ESMTP id 1E7831A1; Wed, 09 Apr 2025 07:39:07 -0700 (PDT) Date: Wed, 9 Apr 2025 07:39:06 -0700 From: Cy Schubert To: Zhenlei Huang Cc: Robert Austen , "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop Message-ID: <20250409073906.43e4282e@slippy> In-Reply-To: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> Organization: KOMQUATS X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfAeSq7tWLzZDNBPYzHzF+ULcPpAwc0DFFGXHGMjKg6oda+iV2O77EgacdS4CIEyb7f6Hmq7eSN7Yop5RLN1RQlne6edbUeNnrLsDpexYZjO3Kd3yTmph 5q2tHHYTAww1V+om7uW8ckLxhqCQiSBtoJ+IqcSpUHZo6F5QBIY1Stkb3E68SLV//0TKYlsHNyZT5mGzu8bjza94h1AWY9IteeYUsAMTvPkxKPYCPC+u/ShI aEmm1uxmvz3JuMEI0u0nPJCX+JDregJbnMkf16nmJFaB1OoRyAq5uAQ7d/zLQmRfzEpb9BSiAkVjGTXV2MTOtC/y+mZ7nqiGABatahRUFedN1YnoNUQVxlH9 tB//G1PGv9CifLXhA8OeFL2zRm/Dxg== X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4ZXlvL3J9wz3LM7 X-Spamd-Bar: ---- On Wed, 9 Apr 2025 15:48:11 +0800 Zhenlei Huang wrote: > > On Apr 9, 2025, at 1:01 AM, Robert Austen wrote: > > > > I respectfully disagree. > > > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call to enable itself, ie. to apply any hooks. > > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults to PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP. > > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIOCSTART ) or netlink command to enable it. > > @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? > > > > > consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, the pfil layer in the kernel has no idea what the filter will be, > > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (and likewise the equivalents from the other filters). > > As for ipfw(4), by default it enables filtering on load, unless you disable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enable` and `net.link.ether.ipfw`. > > The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net.inet.ip.fw.default_to_accept` controls the default behavior to drop or accept. > See also https://cgit.freebsd.org/src/commit/?id=5f17ebf94db5ebbc7fdcff60e598498df6f9e2bd . > > > > > as I said, this is because there's no mechanism within PFIL to drop by default, which is why I proposed (and am using on my system) the PFIL_DEFAULT_TO_DROP, > > because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no effect at all, > > so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP can ever provide. I don't know whether it should default drop or not. In the case of ipfilter, default drop will drop with or without a log message depending whether IPFILTER_LOG is defined in the kernel config or in the module's Makefile -- both are default. There's something to be said about default block in that there is absolutely no chance any packets will get through without a rule permitting them. OTOH, the packet filters (PF, IPFW, IPF) are enabled and loaded before any interfaces are brought up so the point is mostly moot. However in unattended situations there is a better chance you could be able to remotely log in to fix any brokenness whereas with a default block you'd have to travel, possibly thousands of kilometres, to fix any problem. Both scenarios should be considered before making the decision whether to default block or default open. Then again, a badly conceived firewall rule, regardless of the default block setting, can make for a very bad day. IIRC -- it's been a couple of decades since I used IPFW -- IPFW is default block while IPFILTER is default open (unless otherwise configured). Considering that firewall rules are loaded before interfaces are brought up -- just run rcorder(8) to see the startup order for yourself -- this argument is moot. > > It appears ipf(4) unconditionally enable filtering on load, and does not have any tunables to control that. CC @Cy who is more familiar with ipf(4). This is not entirely correct. If IPFILTER_DEFAULT_BLOCK is defined IPF will block by default. Otherwise by default it will not block by default. This can be adjusted at runtime in two ways. First through the sysctl net.inet.ipf.ipf_pass and alternatively through ipf -T default_pass. The value is not intuitive. It's a hex value representing internal flags. If the hex value contains 0x2, ipfilter operates in default pass mode. If the hex value contains 0x1, it operates in default block mode. It will tell you at boot which mode is default: stinky# dmesg | grep IP\ Filter IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled stinky# Though the sysctl net.inet.ipf.ipf_pass exists, using ipf -T default_pass to adjust the flag is preferred. Setting the default_block or ipf_pass is not entirely intuitive. > > > > > thanks! > > From: Zhenlei Huang > > > Sent: April 7, 2025 7:55 PM > > To: Robert Austen > > > Cc: freebsd-current@freebsd.org >; freebsd-net@freebsd.org >; Kristof Provost > > > Subject: Re: pfil_default_to_drop > > > > You don't often get email from zlei@freebsd.org . Learn why this is important > > > > > >> On Apr 8, 2025, at 6:36 AM, Robert Austen > wrote: > >> > >> > >> > >> From: Robert Austen > > >> Sent: April 7, 2025 4:33 PM > >> To: freebsd-current@freebsd.org >; freebsd-net@freebsd.org > > >> Subject: Fw: pfil_default_to_drop > >> > >> > >> From: Robert Austen > >> Sent: April 7, 2025 4:21 PM > >> To: freebsd-current@freebsd.org > > >> Subject: pfil_default_to_drop > >> > >> Hello, > >> I've been playing with FreeBSD and PF to build myself a new firewall, as Open/FreeBSD + PF seems to be a common starting point. > >> > >> I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP and the like, with the observations that it's hard > >> to ensure that packets all default to drop if the rule file(s) for whatever reason fail to load. > > > > Hi Robert, > > > > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload pf.ko ( via the loader(8), /boot/loader.conf ) ? > > > > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 ), you can turn the loader tunable net.pf.default_to_drop to 1, and preload pf.ko. > > See also https://cgit.freebsd.org/src/commit/?id=c531c1d1462c45f7ce5de4f9913226801f3073bd . > > > >> > >> After looking thru the online documentation, forums and scripts, I came to the conclusion that it's not a PF problem or IPFW etc > >> or really a problem with any of the filters or scripts, the problem is at the level of PFIL, the kernel packet filtering code: If no > >> filter is loaded, i.e. if the heads are unhooked, then PFIL sends everything thru to its destination. So my thought > >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_DEFAULT_TO_DROP) that drops all the > >> IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded chosen filter (PF or whatever) at any given time the > >> hooks are unhooked. > > > > If no firewalls loaded, then the system should behave as is. I do not think PFIL_DEFAULT_TO_DROP is the right way to handle your case. > > > >> > >> [No one filters on local loopback nor the link layer, so I've left those hooks untouched. I suppose one could add them, > >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt there's much demand for it.] > >> > >> Normally I'm an embedded linux kernel basher. > >> I'm not entirely sure where to send this patch. Most of the threads asking the above PF questions are closed to changes, > >> so that doesn't seem a good place. Sir Dice seems to be a common answerer of questions; I would have sent it to him/her > >> if I could... > >> > >> I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted patch"... > >> I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64, > >> but I suspect the kernel code in the networking core doesn't change much from platform to platform, or version to version. > >> > >> But it works, it's pretty simple, pretty small and so just in case it might be useful, I'm passing it along. > >> > >> thanks! > >> > >> > >> Robert > >> > >> > >> > >> > >> > > > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Wed Apr 9 16:50:24 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXppr5F2Xz5s3HK; Wed, 09 Apr 2025 16:50:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXppr0SCKz3xwM; Wed, 09 Apr 2025 16:50:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTPS id 2VE7ukkCS5Mqy2Yd8ux14M; Wed, 09 Apr 2025 16:50:26 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id 2Yd6u15p3QwcX2Yd7uzCS7; Wed, 09 Apr 2025 16:50:26 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=DaW0qetW c=1 sm=1 tr=0 ts=67f6a552 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=XR8D0OoHHMoA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=_EeEMxcBAAAA:8 a=UqCG9HQmAAAA:8 a=YxBL1-UpAAAA:8 a=HIpOd3htAAAA:8 a=kUCByv9wAAAA:8 a=HewfmIXYAAAA:8 a=jiAvY12EAAAA:8 a=NMM7OKYrAAAA:8 a=wdBCWTejAAAA:8 a=7deo3vJLAAAA:8 a=SxfSXtOaAAAA:8 a=0VOg8hKvAAAA:8 a=EG9UZMYjAAAA:8 a=Ds8RGfT2AAAA:8 a=E2BN4GkIBzMGMZPVlf4A:9 a=VPyG4jiE2XtzpiXk:21 a=CjuIK1q_8ugA:10 a=iss7NtdUcmcA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=kmlo3kNSEkcePd_NiW6t:22 a=bu_5hG6eGWxBxPYBRUjp:22 a=viMdiLGMexgI2yRc-QGl:22 a=vH9twmSOgBVYSauSXlDl:22 a=isrg6BwTYk6I_F0B0DtW:22 a=E6RPhFkzuBHyj9NHzc04:22 a=N19YUjM5w2xS2h45dEdy:22 a=WO70gR-9rc0EB5-JkeQN:22 a=I-efbNKAaAt4Mg394dr-:22 a=amkjWIeD4s3-_WS3cuQ1:22 a=0afPCejbyZHll-xH3H2j:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 130C7E5; Wed, 09 Apr 2025 09:50:24 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 0C165304; Wed, 09 Apr 2025 09:50:24 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Robert Austen cc: Cy Schubert , Zhenlei Huang , "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop In-reply-to: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> <20250409073906.43e4282e@slippy> Comments: In-reply-to Robert Austen message dated "Wed, 09 Apr 2025 16:29:16 -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: text/plain; charset=us-ascii Date: Wed, 09 Apr 2025 09:50:24 -0700 Message-Id: <20250409165024.0C165304@slippy.cwsent.com> X-CMAE-Envelope: MS4xfDC7iwedH6RyvdvsCpiZ0BWPvdsQEjXjDBqGnD8P8NgIvXxpKH/q584fG5w6E9eNsy2GlwNplFEzxIQsEe2j6RIlnfHX3uGNqTCoWxpThpPjyqPJrjqB RmQlWFVA5vrByWNitHGbwgVR00cnBV6bv+9QuDG/mEKvYkZWjX8PiyQ2Dad3vKLdbGuiF63Ob7hrlDN9xRc5dUqZA3lifb7hdAW+fGnjm3WfhK+pxV5kKzqn hsWXthsac82aoFRvKOYojgppTeZxONfiOQt71dYkSnNhrwzcstOsPNcYUTrh3Sb0dtTVaukSiW9vUFRi1Fa138F3pJiwwRDcGtsXZJMbv7a/pUA0d0srLl7X eMMdBhEGseFE43Ygar0rwObXcANZoA== X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4ZXppr0SCKz3xwM X-Spamd-Bar: ---- In message , Robert Austen writes: > --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > "Considering that firewall rules are loaded before interfaces" > > I don't believe that's true. > > I used rcorder, and played around with things, because I noted that the int= > erfaces (esp if static) > came up first, then the forwarding, then pf log, and finally pf was last. Interfaces are started by the netif rc script. I use ipfilter here. netif is started after ipfilter. I had assumed all were the same but apparently not. slippy$ rcorder /etc/rc.d/* | egrep 'ipfilter|netif|pf|ipfw' /etc/rc.d/ipfilter /etc/rc.d/ipfs /etc/rc.d/netif /etc/rc.d/pflog /etc/rc.d/pfsync /etc/rc.d/ipfw /etc/rc.d/ipfw_netflow /etc/rc.d/pf slippy$ We should probably look at moving netif after pf's start. > > There are also issue with PF_DEFAULT_TO_DROP, for instance, it breaks "rdr = > pass" rules. > > Anyways, rather than debating what might work better in situation A vs B, a= > nd dictating what > users of freeBSD can or cannot do, why not give options? > > isn't that the whole point of options and conf files? > let sysadmin use whatever option they see fit? Agreed. There should always be options. But, what should the default be? Personally, I don't care what the default is. I will set my own options. But most people don't configure their systems as much. Most use the defaults. What works for most people? If default block, then lets do that. > > they shouldn't have to write something to get the result they want (or need= > ), like I had to.. Give people the default and let them change it. I think default block might be preferable. It avoids most people shooting themselves in the foot by not reviewing and changing the default if necessary. Consider most consumers don't change the passwords for their network appliances. Professionals I've worked with do but I'm sure there are many companies where defaults are not reviewed. What offers the average end-user the best protection? Also, what avoids a POLA violation. Balance these two and you will have your answer. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 > > ________________________________ > From: Cy Schubert > Sent: April 9, 2025 8:39 AM > To: Zhenlei Huang > Cc: Robert Austen ; freebsd-current@fr= > eebsd.org ; freebsd-net@freebsd.org et@freebsd.org>; Kristof Provost ; Cy Schubert org> > Subject: Re: pfil_default_to_drop > > [You don't often get email from cy.schubert@cschubert.com. Learn why this i= > s important at https://aka.ms/LearnAboutSenderIdentification ] > > On Wed, 9 Apr 2025 15:48:11 +0800 > Zhenlei Huang wrote: > > > > On Apr 9, 2025, at 1:01 AM, Robert Austen ems.com> wrote: > > > > > > I respectfully disagree. > > > > > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl ca= > ll to enable itself, ie. to apply any hooks. > > > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaul= > ts to PASS, which is not what most people would intend using PF_DEFAULT_TO_= > DROP. > > > > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIOCST= > ART ) or netlink command to enable it. > > > > @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? > > > > > > > > consider this: until pf or ipf or ipfw makes an ioctl to hook themselve= > s, the pfil layer in the kernel has no idea what the filter will be, > > > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (a= > nd likewise the equivalents from the other filters). > > > > As for ipfw(4), by default it enables filtering on load, unless you disab= > le it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enable`= > and `net.link.ether.ipfw`. > > > > The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net.in= > et.ip.fw.default_to_accept` controls the default behavior to drop or accept= > . > > See also https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff= > 60e598498df6f9e2bd bbc7fdcff60e598498df6f9e2bd> . > > > > > > > > as I said, this is because there's no mechanism within PFIL to drop by = > default, which is why I proposed (and am using on my system) the PFIL_DEFAU= > LT_TO_DROP, > > > because it handles ALL of the 'no filter installed (yet)' cases. if PFI= > L_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no effec= > t at all, > > > so it's a simple mechanism for those that want more than PF_DEFAULT_TO_= > DROP can ever provide. > > I don't know whether it should default drop or not. In the case of > ipfilter, default drop will drop with or without a log message > depending whether IPFILTER_LOG is defined in the kernel config or in > the module's Makefile -- both are default. > > There's something to be said about default block in that there is > absolutely no chance any packets will get through without a rule > permitting them. OTOH, the packet filters (PF, IPFW, IPF) are enabled > and loaded before any interfaces are brought up so the point is mostly > moot. However in unattended situations there is a better chance you > could be able to remotely log in to fix any brokenness whereas with a > default block you'd have to travel, possibly thousands of kilometres, > to fix any problem. Both scenarios should be considered before making > the decision whether to default block or default open. > > Then again, a badly conceived firewall rule, regardless of the default > block setting, can make for a very bad day. > > IIRC -- it's been a couple of decades since I used IPFW -- IPFW is > default block while IPFILTER is default open (unless otherwise > configured). > > Considering that firewall rules are loaded before interfaces are > brought up -- just run rcorder(8) to see the startup order for yourself > -- this argument is moot. > > > > > It appears ipf(4) unconditionally enable filtering on load, and does not = > have any tunables to control that. CC @Cy who is more familiar with ipf(4). > > This is not entirely correct. > > If IPFILTER_DEFAULT_BLOCK is defined IPF will block by default. > Otherwise by default it will not block by default. > > This can be adjusted at runtime in two ways. First through the sysctl > net.inet.ipf.ipf_pass and alternatively through ipf -T default_pass. > The value is not intuitive. It's a hex value representing internal > flags. If the hex value contains 0x2, ipfilter operates in default pass > mode. If the hex value contains 0x1, it operates in default block mode. > It will tell you at boot which mode is default: > > stinky# dmesg | grep IP\ Filter > IP Filter: v5.1.2 initialized. Default =3D pass all, Logging =3D enabled > IP Filter: v5.1.2 initialized. Default =3D pass all, Logging =3D enabled > stinky# > > Though the sysctl net.inet.ipf.ipf_pass exists, using ipf -T > default_pass to adjust the flag is preferred. Setting the default_block > or ipf_pass is not entirely intuitive. > > > > > > > > thanks! > > > From: Zhenlei Huang > > > > Sent: April 7, 2025 7:55 PM > > > To: Robert Austen usten@willowglensystems.com>> > > > Cc: freebsd-current@freebsd.org reebsd-current@freebsd.org >; freebsd-n= > et@freebsd.org ailto:freebsd-net@freebsd.org>>; Kristof Provost @FreeBSD.org>> > > > Subject: Re: pfil_default_to_drop > > > > > > You don't often get email from zlei@freebsd.org g>. Learn why this is important ion> > > > > > > > > >> On Apr 8, 2025, at 6:36 AM, Robert Austen tems.com > wrote: > > >> > > >> > > >> > > >> From: Robert Austen t.austen@willowglensystems.com>> > > >> Sent: April 7, 2025 4:33 PM > > >> To: freebsd-current@freebsd.org <= > freebsd-current@freebsd.org >; freebsd-= > net@freebsd.org mailto:freebsd-net@freebsd.org>> > > >> Subject: Fw: pfil_default_to_drop > > >> > > >> > > >> From: Robert Austen > > >> Sent: April 7, 2025 4:21 PM > > >> To: freebsd-current@freebsd.org <= > freebsd-current@freebsd.org > > > >> Subject: pfil_default_to_drop > > >> > > >> Hello, > > >> I've been playing with FreeBSD and PF to build myself a new firewall, = > as Open/FreeBSD + PF seems to be a common starting point. > > >> > > >> I've noticed a number of people asking questions about PF_DEFAULT_TO_D= > ROP and the like, with the observations that it's hard > > >> to ensure that packets all default to drop if the rule file(s) for wha= > tever reason fail to load. > > > > > > Hi Robert, > > > > > > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload = > pf.ko ( via the loader(8), /boot/loader.conf ) ? > > > > > > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 = > ), you can turn the loader tunable net.pf.default_to_drop to 1, and preload= > pf.ko. > > > See also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5d= > e4f9913226801f3073bd c45f7ce5de4f9913226801f3073bd> . > > > > > >> > > >> After looking thru the online documentation, forums and scripts, I cam= > e to the conclusion that it's not a PF problem or IPFW etc > > >> or really a problem with any of the filters or scripts, the problem is= > at the level of PFIL, the kernel packet filtering code: If no > > >> filter is loaded, i.e. if the heads are unhooked, then PFIL sends ever= > ything thru to its destination. So my thought > > >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version o= > f PF_DEFAULT_TO_DROP) that drops all the > > >> IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loade= > d chosen filter (PF or whatever) at any given time the > > >> hooks are unhooked. > > > > > > If no firewalls loaded, then the system should behave as is. I do not t= > hink PFIL_DEFAULT_TO_DROP is the right way to handle your case. > > > > > >> > > >> [No one filters on local loopback nor the link layer, so I've left tho= > se hooks untouched. I suppose one could add them, > > >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I d= > oubt there's much demand for it.] > > >> > > >> Normally I'm an embedded linux kernel basher. > > >> I'm not entirely sure where to send this patch. Most of the threads as= > king the above PF questions are closed to changes, > > >> so that doesn't seem a good place. Sir Dice seems to be a common answe= > rer of questions; I would have sent it to him/her > > >> if I could... > > >> > > >> I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = > patch"... > > >> I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @ne= > w folder. The code was written against FreeBSD-14.1-RELEASE-amd64, > > >> but I suspect the kernel code in the networking core doesn't change mu= > ch from platform to platform, or version to version. > > >> > > >> But it works, it's pretty simple, pretty small and so just in case it = > might be useful, I'm passing it along. > > >> > > >> thanks! > > >> > > >> > > >> Robert > > >> > > >> > > >> > > >> > > >> > > > > > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > > > > >
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; color: rgb(0, 0, 0= > );"> > " t;">Considering that firewall rules are loaded before interfaces" n>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > I don't believe that's true.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > I used rcorder, and played around with things, because I noted that the int= > erfaces (esp if static)
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > came up first, then the forwarding, then pf log, and finally pf was last.&n= > bsp;
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > There are also issue with PF_DEFAULT_TO_DROP, for instance, it breaks "= > ;rdr pass" rules.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > Anyways, rather than debating what might work better in situation A vs B, a= > nd dictating what
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > users of freeBSD can or cannot do, why not give options? 
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > isn't that the whole point of options and conf files?
>
margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, C= > alibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"> > let sysadmin use whatever option they see fit?
>
margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, C= > alibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > they shouldn't have to write something to get the result they want (or need= > ), like I had to..
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
>
>
yle=3D"font-size:11pt" color=3D"#000000">From: Cy Schubert <Cy.Sc= > hubert@cschubert.com>
> Sent: April 9, 2025 8:39 AM
> To: Zhenlei Huang <zlei@FreeBSD.org>
> Cc: Robert Austen <robert.austen@willowglensystems.com>; freeb= > sd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@fre= > ebsd.org <freebsd-net@freebsd.org>; Kristof Provost <kp@FreeBSD.or= > g>; Cy Schubert <cy@freebsd.org>
> Subject: Re: pfil_default_to_drop >
 
>
>
"> >
[You don't often get email from cy.schubert@cschub= > ert.com. Learn why this is important at > https://aka.ms/Le= > arnAboutSenderIdentification ]
>
> On Wed, 9 Apr 2025 15:48:11 +0800
> Zhenlei Huang <zlei@FreeBSD.org> wrote:
>
> > > On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willo= > wglensystems.com> wrote:
> > >
> > > I respectfully disagree.
> > >
> > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its io= > ctl call to enable itself, ie. to apply any hooks.
> > > if pfctl fails, then the hooks are left unhooked, and EVERYTHING = > defaults to PASS, which is not what most people would intend using PF_DEFAU= > LT_TO_DROP.
> >
> > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIO= > CSTART ) or netlink command to enable it.
> >
> > @Kristof Maybe we also want a loader tunable to enable pf(4) on load ?= >
> >
> > >
> > > consider this: until pf or ipf or ipfw makes an ioctl to hook the= > mselves, the pfil layer in the kernel has no idea what the filter will be,<= > br> > > > assuming there even is one. thus PF_DEFAULT_TO_DROP  has zer= > o effect (and likewise the equivalents from the other filters).
> >
> > As for ipfw(4), by default it enables filtering on load, unless you di= > sable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enab= > le` and `net.link.ether.ipfw`.
> >
> > The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net= > .inet.ip.fw.default_to_accept` controls the default behavior to drop or acc= > ept.
> > See also 4db5ebbc7fdcff60e598498df6f9e2bd"> > https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60e598498df= > 6f9e2bd < f94db5ebbc7fdcff60e598498df6f9e2bd">https://cgit.freebsd.org/src/commit/?id= > =3D5f17ebf94db5ebbc7fdcff60e598498df6f9e2bd> > .
> >
> > >
> > > as I said, this is because there's no mechanism within PFIL to dr= > op by default, which is why I proposed (and am using on my system) the PFIL= > _DEFAULT_TO_DROP,
> > > because it handles ALL of the 'no filter installed (yet)' cases. = > if PFIL_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no= > effect at all,
> > > so it's a simple mechanism for those that want more than PF_DEFAU= > LT_TO_DROP can ever provide.
>
> I don't know whether it should default drop or not. In the case of
> ipfilter, default drop will drop with or without a log message
> depending whether IPFILTER_LOG is defined in the kernel config or in
> the module's Makefile -- both are default.
>
> There's something to be said about default block in that there is
> absolutely no chance any packets will get through without a rule
> permitting them. OTOH, the packet filters (PF, IPFW, IPF) are enabled
> and loaded before any interfaces are brought up so the point is mostly
> moot. However in unattended situations there is a better chance you
> could be able to remotely log in to fix any brokenness whereas with a
> default block you'd have to travel, possibly thousands of kilometres,
> to fix any problem. Both scenarios should be considered before making
> the decision whether to default block or default open.
>
> Then again, a badly conceived firewall rule, regardless of the default
> block setting, can make for a very bad day.
>
> IIRC -- it's been a couple of decades since I used IPFW -- IPFW is
> default block while IPFILTER is default open (unless otherwise
> configured).
>
> Considering that firewall rules are loaded before interfaces are
> brought up -- just run rcorder(8) to see the startup order for yourself
> -- this argument is moot.
>
> >
> > It appears ipf(4) unconditionally enable filtering on load, and does n= > ot have any tunables to control that. CC @Cy who is more familiar with ipf(= > 4).
>
> This is not entirely correct.
>
> If IPFILTER_DEFAULT_BLOCK is defined IPF will block by default.
> Otherwise by default it will not block by default.
>
> This can be adjusted at runtime in two ways. First through the sysctl
> net.inet.ipf.ipf_pass and alternatively through ipf -T default_pass.
> The value is not intuitive. It's a hex value representing internal
> flags. If the hex value contains 0x2, ipfilter operates in default pass
> mode. If the hex value contains 0x1, it operates in default block mode.
> It will tell you at boot which mode is default:
>
> stinky# dmesg | grep IP\ Filter
> IP Filter: v5.1.2 initialized.  Default =3D pass all, Logging =3D enab= > led
> IP Filter: v5.1.2 initialized.  Default =3D pass all, Logging =3D enab= > led
> stinky#
>
> Though the sysctl net.inet.ipf.ipf_pass exists, using ipf -T
> default_pass to adjust the flag is preferred. Setting the default_block
> or ipf_pass is not entirely intuitive.
> >
> > >
> > > thanks!
> > > From: Zhenlei Huang <zlei@FreeBSD.org < ei@FreeBSD.org">mailto:zlei@FreeBSD.org>>
> > > Sent: April 7, 2025 7:55 PM
> > > To: Robert Austen <robert.austen@willowglensystems.com < href=3D"mailto:robert.austen@willowglensystems.com">mailto:robert.austen@wi= > llowglensystems.com>>
> > > Cc: freebsd-current@freebsd.org < rent@freebsd.org">mailto:freebsd-current@freebsd.org> <freebsd-cu= > rrent@freebsd.org <mailto= > :freebsd-current@freebsd.org>>; freebsd-net@freebsd.org > <mailto:freebsd-net@freebsd.= > org> <freebsd-net@freebsd.org < reebsd.org">mailto:freebsd-net@freebsd.org>>; Kristof Provost <= > ;kp@FreeBSD.org <mailto:kp@FreeBSD.org= > >>
> > > Subject: Re: pfil_default_to_drop
> > >
> > > You don't often get email from zlei@freebsd.org < ilto:zlei@freebsd.org">mailto:zlei@freebsd.org>. Learn why this is i= > mportant <http= > s://aka.ms/LearnAboutSenderIdentification>
> > >
> > >
> > >> On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@w= > illowglensystems.com < com">mailto:robert.austen@willowglensystems.com>> wrote:
> > >>
> > >>
> > >>
> > >> From: Robert Austen <robert.austen@willowglensystems.com &= > lt;mailto:robert.aus= > ten@willowglensystems.com>>
> > >> Sent: April 7, 2025 4:33 PM
> > >> To: freebsd-current@freebsd.org < -current@freebsd.org">mailto:freebsd-current@freebsd.org> <freebs= > d-current@freebsd.org <ma= > ilto:freebsd-current@freebsd.org>>; freebsd-net@freebsd.org > <mailto:freebsd-net@freebsd.= > org> <freebsd-net@freebsd.org < reebsd.org">mailto:freebsd-net@freebsd.org>>
> > >> Subject: Fw: pfil_default_to_drop
> > >>
> > >>
> > >> From: Robert Austen
> > >> Sent: April 7, 2025 4:21 PM
> > >> To: freebsd-current@freebsd.org < -current@freebsd.org">mailto:freebsd-current@freebsd.org> <freebs= > d-current@freebsd.org <ma= > ilto:freebsd-current@freebsd.org>>
> > >> Subject: pfil_default_to_drop
> > >>
> > >> Hello,
> > >> I've been playing with FreeBSD and PF to build myself a new f= > irewall, as Open/FreeBSD + PF seems to be a common starting point.
> > >>
> > >> I've noticed a number of people asking questions about PF_DEF= > AULT_TO_DROP and the like, with the observations that it's hard
> > >> to ensure that packets all default to drop if the rule file(s= > ) for whatever reason fail to load.
> > >
> > > Hi Robert,
> > >
> > > So why not defining the compile option PF_DEFAULT_TO_DROP, and pr= > eload pf.ko ( via the loader(8), /boot/loader.conf ) ?
> > >
> > > With 13.5, or upcoming 14.3 ( you can also experiment latest stab= > le/14 ), you can turn the loader tunable net.pf.default_to_drop to 1, and p= > reload pf.ko.
> > > See also 1c1d1462c45f7ce5de4f9913226801f3073bd"> > https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9913226801= > f3073bd < d1462c45f7ce5de4f9913226801f3073bd">https://cgit.freebsd.org/src/commit/?id= > =3Dc531c1d1462c45f7ce5de4f9913226801f3073bd> > .
> > >
> > >>
> > >> After looking thru the online documentation, forums and scrip= > ts, I came to the conclusion that it's not a PF problem or IPFW etc
> > >> or really a problem with any of the filters or scripts, the p= > roblem is at the level of PFIL, the kernel packet filtering code: If no
> > >> filter is loaded, i.e. if the heads are unhooked, then PFIL s= > ends everything thru to its destination. So my thought
> > >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL = > version of PF_DEFAULT_TO_DROP) that drops all the
> > >> IPv4 and IPv6 packets that would otherwise go thru the yet-to= > -be-loaded chosen filter (PF or whatever) at any given time the
> > >> hooks are  unhooked.
> > >
> > > If no firewalls loaded, then the system should behave as is. I do= > not think PFIL_DEFAULT_TO_DROP is the right way to handle your case.
> > >
> > >>
> > >> [No one filters on local loopback nor the link layer, so I've= > left those hooks untouched. I suppose one could add them,
> > >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP= > , but I doubt there's much demand for it.]
> > >>
> > >> Normally I'm an embedded linux kernel basher.
> > >> I'm not entirely sure where to send this patch. Most of the t= > hreads asking the above PF questions are closed to changes,
> > >> so that doesn't seem a good place. Sir Dice seems to be a com= > mon answerer of questions; I would have sent it to him/her
> > >> if I could...
> > >>
> > >> I'm not a user of GIT, so I'm not sure how to submit a "= > GIT formatted patch"...
> > >> I've simply diff -rdpNU 5 a copy of the @old folder with a co= > py of @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64,= >
> > >> but I suspect the kernel code in the networking core doesn't = > change much from platform to platform, or version to version.
> > >>
> > >> But it works, it's pretty simple, pretty small and so just in= > case it might be useful, I'm passing it along.
> > >>
> > >> thanks!
> > >>
> > >>
> > >> Robert
> > >>
> > >>
> > >>
> > >>
> > >> <FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip= > >
> >
> >
> >
>
> --
> Cheers,
> Cy Schubert <Cy.Schubert@cschubert.com>
> FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  =3D"https://FreeBSD.org">https://FreeBSD.org
> NTP:           <cy@nwt= > ime.org>    Web:  htt= > ps://nwtime.org
>
>             &nb= > sp;           e^(i*pi)+1= > =3D0
>
>
> > > > --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_-- From nobody Wed Apr 9 16:51:18 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXpqs67Ylz5s3SP; Wed, 09 Apr 2025 16:51:21 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXpqr4d6Jz40fd; Wed, 09 Apr 2025 16:51:20 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTPS id 2G6dukAjb5Mqy2Ye0ux36k; Wed, 09 Apr 2025 16:51:20 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id 2YdyuvZs5WbOa2YdzuYATt; Wed, 09 Apr 2025 16:51:20 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=Q5lx4J2a c=1 sm=1 tr=0 ts=67f6a588 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=XR8D0OoHHMoA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=_EeEMxcBAAAA:8 a=UqCG9HQmAAAA:8 a=YxBL1-UpAAAA:8 a=HIpOd3htAAAA:8 a=NMM7OKYrAAAA:8 a=wwbO4EBcAAAA:8 a=kUCByv9wAAAA:8 a=vUPWEWiMAAAA:8 a=0VOg8hKvAAAA:8 a=sDLHkD9wShOpoRjQhgoA:9 a=XqS8QqoS1rPLgu61:21 a=CjuIK1q_8ugA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=kmlo3kNSEkcePd_NiW6t:22 a=isrg6BwTYk6I_F0B0DtW:22 a=jx9uv8QTLkEiLr58aJp2:22 a=bu_5hG6eGWxBxPYBRUjp:22 a=s3Yi14Of9AgBIP63TAoC:22 a=I-efbNKAaAt4Mg394dr-:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 97DF713E; Wed, 09 Apr 2025 09:51:18 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 93B072B; Wed, 09 Apr 2025 09:51:18 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Robert Austen cc: Zhenlei Huang , "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop In-reply-to: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> Comments: In-reply-to Robert Austen message dated "Wed, 09 Apr 2025 16:44:17 -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: text/plain; charset=us-ascii Date: Wed, 09 Apr 2025 09:51:18 -0700 Message-Id: <20250409165118.93B072B@slippy.cwsent.com> X-CMAE-Envelope: MS4xfNyUJHtugA92F84EfVxm351CwUvtssOlzzWlmUtW9HaVRe0UXN024joHO0RuY1U5Ih/kcbegeum1ZOptNYxQu7ugfYhmSVcBwslanfk0b581Jrippx1B +1D2YAPgwj7sm0eRsp3wmUxYqGOzDXKhLWYqWVUvcbT1MxFd9u5qDvzozvBh4VctplBi8OWHsm6w1++3GFv+M2kmZjo2SA7NzvXPr60c6VSNipvsiPpWyX1l 5SG2L0GtHUWiFfU7p3uGOrkRFU2QwJ/iFlqZwtpvpgSaXdj4r/qF17/7PQWb4kD4fFtnU0tjEHLjziEVpS1If8xcohxf8M7vEIaeJJRTlaAC8J0IO02fiWoE 5xNxsHMBEYpd1cF1huckuNCHB0kyyA== X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4ZXpqr4d6Jz40fd X-Spamd-Bar: ---- In message , Robert Austen writes: > --_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > "Maybe we also want a loader tunable to enable pf(4) on load" > > Seems a complicated way to do a simple thing. imho. > > Did you happen to look at my tiny patch? > There are already a bunch of macros (PFIL_HOOKED_IN, PFIL_HOOKED_OUT) defi= > ned depending on the inclusion of INET v4 or 6. > I just cloned them as ... _UNHOOKED_ ..., and made them the NOT of the HOOK= > ED_ one, or FALSE when INET v4 or 6 is excluded > or if PFIL_DEFAULT_TO_DROP isn't defined. > > Then whereever the existing PFIL_HOOKED_IN/OUT_46 macros are used, prior to= > calling the filter hook, I just > inserted a PFIL_UNHOOKED_IN/OUT_46 check, and a 'goto drop' instead of the = > 'goto passin/out' for the 7 occurances > in if_gateway and the 3 in the NETINET code (ip_input, ip_output, ip_fastfw= > d) and the 4 in the NETINET6 code (same as netinet4 plus ip6_foward). > > easy peasy. Easy? Patches please. > I spend 10x more time messing with the kernel Makefile + CONF structure tha= > n with my changes lol. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 > > > ________________________________ > From: Zhenlei Huang > Sent: April 9, 2025 1:48 AM > To: Robert Austen > Cc: freebsd-current@freebsd.org ; freebsd-net@= > freebsd.org ; Kristof Provost ; Cy= > Schubert > Subject: Re: pfil_default_to_drop > > You don't often get email from zlei@freebsd.org. Learn why this is importan= > t > > > On Apr 9, 2025, at 1:01 AM, Robert Austen com> wrote: > > I respectfully disagree. > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= > o enable itself, ie. to apply any hooks. > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= > o PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP= > . > > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIOCSTAR= > T ) or netlink command to enable it. > > @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? > > > consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, t= > he pfil layer in the kernel has no idea what the filter will be, > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect (and l= > ikewise the equivalents from the other filters). > > As for ipfw(4), by default it enables filtering on load, unless you disable= > it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enable` a= > nd `net.link.ether.ipfw`. > > The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable `net.inet= > .ip.fw.default_to_accept` controls the default behavior to drop or accept. > See also https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60= > e598498df6f9e2bd . > > > as I said, this is because there's no mechanism within PFIL to drop by defa= > ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= > O_DROP, > because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= > FAULT_TO_DROP isn't in the kernel config file, my patches have no effect at= > all, > so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP= > can ever provide. > > It appears ipf(4) unconditionally enable filtering on load, and does not ha= > ve any tunables to control that. CC @Cy who is more familiar with ipf(4). > > > thanks! > ________________________________ > From: Zhenlei Huang > > Sent: April 7, 2025 7:55 PM > To: Robert Austen @willowglensystems.com>> > Cc: freebsd-current@freebsd.org d-current@freebsd.org>; freebsd-net@fre= > ebsd.org eebsd-net@freebsd.org>>; Kristof Provost org>> > Subject: Re: pfil_default_to_drop > > You don't often get email from zlei@freebsd.org. L= > earn why this is important > > > On Apr 8, 2025, at 6:36 AM, Robert Austen com> wrote: > > > > ________________________________ > From: Robert Austen en@willowglensystems.com>> > Sent: April 7, 2025 4:33 PM > To: freebsd-current@freebsd.org d-current@freebsd.org>; freebsd-net@fre= > ebsd.org eebsd-net@freebsd.org>> > Subject: Fw: pfil_default_to_drop > > > ________________________________ > From: Robert Austen > Sent: April 7, 2025 4:21 PM > To: freebsd-current@freebsd.org d-current@freebsd.org> > Subject: pfil_default_to_drop > > Hello, > I've been playing with FreeBSD and PF to build myself a new firewall, as Op= > en/FreeBSD + PF seems to be a common starting point. > > I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= > nd the like, with the observations that it's hard > to ensure that packets all default to drop if the rule file(s) for whatever= > reason fail to load. > > Hi Robert, > > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload pf.k= > o ( via the loader(8), /boot/loader.conf ) ? > > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 ), y= > ou can turn the loader tunable net.pf.default_to_drop to 1, and preload pf.= > ko. > See also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9= > 913226801f3073bd . > > > After looking thru the online documentation, forums and scripts, I came to = > the conclusion that it's not a PF problem or IPFW etc > or really a problem with any of the filters or scripts, the problem is at t= > he level of PFIL, the kernel packet filtering code: If no > filter is loaded, i.e. if the heads are unhooked, then PFIL sends everythin= > g thru to its destination. So my thought > was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= > DEFAULT_TO_DROP) that drops all the > IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= > sen filter (PF or whatever) at any given time the > hooks are unhooked. > > If no firewalls loaded, then the system should behave as is. I do not think= > PFIL_DEFAULT_TO_DROP is the right way to handle your case. > > > [No one filters on local loopback nor the link layer, so I've left those ho= > oks untouched. I suppose one could add them, > maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = > there's much demand for it.] > > Normally I'm an embedded linux kernel basher. > I'm not entirely sure where to send this patch. Most of the threads asking = > the above PF questions are closed to changes, > so that doesn't seem a good place. Sir Dice seems to be a common answerer o= > f questions; I would have sent it to him/her > if I could... > > I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted patch= > "... > I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= > der. The code was written against FreeBSD-14.1-RELEASE-amd64, > but I suspect the kernel code in the networking core doesn't change much fr= > om platform to platform, or version to version. > > But it works, it's pretty simple, pretty small and so just in case it might= > be useful, I'm passing it along. > > thanks! > > > Robert > > > > > > > > > > --_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > > > > >
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > "Maybe we also want a loader tunable to enable pf(4) on load" v> >
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > Seems a complicated way to do a simple thing. imho.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > Did you happen to look at my tiny patch?
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > There are already a bunch of macros  (PFIL_HOOKED_IN, PFIL_HOOKED_OUT)= > defined depending on the inclusion of INET v4 or 6.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > I just cloned them as ... _UNHOOKED_ ..., and made them the NOT of the H= > OOKED_ one, or FALSE when INET v4 or 6 is excluded 
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > or if PFIL_DEFAULT_TO_DROP isn't defined. 
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > Then whereever the existing PFIL_HOOKED_IN/OUT_46 macros are used, prior to= > calling the filter hook, I just
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > inserted a PFIL_UNHOOKED_IN/OUT_46 check, and a 'goto drop' instead of the = > 'goto passin/out' for the 7 occurances
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > in if_gateway and the 3 in the NETINET code (ip_input, ip_output, ip_fastfw= > d) and the 4 in the NETINET6 code (same as netinet4 plus  ip6_foward).= >
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > easy peasy.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> > I spend 10x more time messing with the kernel Makefile + CONF structure tha= > n with my changes lol.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= > olor: rgb(0, 0, 0);"> >
>
>
>
>
yle=3D"font-size:11pt" color=3D"#000000">From: Zhenlei Huang <zle= > i@FreeBSD.org>
> Sent: April 9, 2025 1:48 AM
> To: Robert Austen <robert.austen@willowglensystems.com>
> Cc: freebsd-current@freebsd.org <freebsd-current@freebsd.org>;= > freebsd-net@freebsd.org <freebsd-net@freebsd.org>; Kristof Provost &= > lt;kp@FreeBSD.org>; Cy Schubert <cy@freebsd.org>
> Subject: Re: pfil_default_to_drop >
 
>
>
"> > n=3D"left" style=3D"background:revert!important; border:revert!important; b= > ottom:revert!important; color:revert!important; direction:revert!important;= > display:revert!important; font-size:revert!important; height:revert!import= > ant; letter-spacing:revert!important; line-height:revert!important; margin:= > revert!important; opacity:revert!important; order:revert!important; outline= > :revert!important; overflow:revert!important; padding:revert!important; pos= > ition:revert!important; tab-size:revert!important; table-layout:revert!impo= > rtant; text-align:revert!important; text-indent:revert!important; text-orie= > ntation:revert!important; text-overflow:revert!important; text-transform:re= > vert!important; top:revert!important; vertical-align:revert!important; visi= > bility:revert!important; white-space:revert!important; width:revert!importa= > nt; word-break:revert!important; word-spacing:revert!important; writing-mod= > e:revert!important; zoom:revert!important; border:0!important; display:tabl= > e!important; width:100%!important; table-layout:fixed!important; border-col= > lapse:seperate!important; float:none!important; border-spacing:0px 0px!impo= > rtant"> > m:revert!important; color:revert!important; direction:revert!important; dis= > play:revert!important; font-size:revert!important; height:revert!important;= > letter-spacing:revert!important; line-height:revert!important; margin:reve= > rt!important; opacity:revert!important; order:revert!important; outline:rev= > ert!important; overflow:revert!important; padding:revert!important; positio= > n:revert!important; tab-size:revert!important; table-layout:revert!importan= > t; text-align:revert!important; text-indent:revert!important; text-orientat= > ion:revert!important; text-overflow:revert!important; text-transform:revert= > !important; top:revert!important; vertical-align:revert!important; visibili= > ty:revert!important; white-space:revert!important; width:revert!important; = > word-break:revert!important; word-spacing:revert!important; writing-mode:re= > vert!important; zoom:revert!important; display:block!important"> > evert!important; color:revert!important; direction:revert!important; displa= > y:revert!important; font-size:revert!important; height:revert!important; le= > tter-spacing:revert!important; line-height:revert!important; margin:revert!= > important; opacity:revert!important; order:revert!important; outline:revert= > !important; overflow:revert!important; padding:revert!important; position:r= > evert!important; tab-size:revert!important; table-layout:revert!important; = > text-align:revert!important; text-indent:revert!important; text-orientation= > :revert!important; text-overflow:revert!important; text-transform:revert!im= > portant; top:revert!important; vertical-align:revert!important; visibility:= > revert!important; white-space:revert!important; width:revert!important; wor= > d-break:revert!important; word-spacing:revert!important; writing-mode:rever= > t!important; zoom:revert!important"> > > > > > >
2px 7px 2px" style=3D"background:revert!important; border:revert!important;= > bottom:revert!important; color:revert!important; direction:revert!importan= > t; display:revert!important; font-size:revert!important; height:revert!impo= > rtant; letter-spacing:revert!important; line-height:revert!important; margi= > n:revert!important; opacity:revert!important; order:revert!important; outli= > ne:revert!important; overflow:revert!important; padding:revert!important; p= > osition:revert!important; tab-size:revert!important; table-layout:revert!im= > portant; text-align:revert!important; text-indent:revert!important; text-or= > ientation:revert!important; text-overflow:revert!important; text-transform:= > revert!important; top:revert!important; vertical-align:revert!important; vi= > sibility:revert!important; white-space:revert!important; width:revert!impor= > tant; word-break:revert!important; word-spacing:revert!important; writing-m= > ode:revert!important; zoom:revert!important; padding:7px 2px 7px 2px!import= > ant; background-color:#A6A6A6!important; width:0px!important"> > 5px 7px 15px" color=3D"#212121" style=3D"background:revert!important; bord= > er:revert!important; bottom:revert!important; color:revert!important; direc= > tion:revert!important; display:revert!important; font-size:revert!important= > ; height:revert!important; letter-spacing:revert!important; line-height:rev= > ert!important; margin:revert!important; opacity:revert!important; order:rev= > ert!important; outline:revert!important; overflow:revert!important; padding= > :revert!important; position:revert!important; tab-size:revert!important; ta= > ble-layout:revert!important; text-align:revert!important; text-indent:rever= > t!important; text-orientation:revert!important; text-overflow:revert!import= > ant; text-transform:revert!important; top:revert!important; vertical-align:= > revert!important; visibility:revert!important; white-space:revert!important= > ; width:revert!important; word-break:revert!important; word-spacing:revert!= > important; writing-mode:revert!important; zoom:revert!important; width:100%= > !important; background-color:#EAEAEA!important; padding:7px 5px 7px 15px!im= > portant; font-family:wf_segoe-ui_normal,Segoe UI,Segoe WP,Tahoma,Arial,sans= > -serif!important; font-size:12px!important; font-weight:normal!important; c= > olor:#212121!important; text-align:left!important; word-wrap:break-word!imp= > ortant"> >
revert!important; color:revert!important; direction:revert!important; displ= > ay:revert!important; font-size:revert!important; height:revert!important; l= > etter-spacing:revert!important; line-height:revert!important; margin:revert= > !important; opacity:revert!important; order:revert!important; outline:rever= > t!important; overflow:revert!important; padding:revert!important; position:= > revert!important; tab-size:revert!important; table-layout:revert!important;= > text-align:revert!important; text-indent:revert!important; text-orientatio= > n:revert!important; text-overflow:revert!important; text-transform:revert!i= > mportant; top:revert!important; vertical-align:revert!important; visibility= > :revert!important; white-space:revert!important; width:revert!important; wo= > rd-break:revert!important; word-spacing:revert!important; writing-mode:reve= > rt!important; zoom:revert!important"> > You don't often get email from zlei@freebsd.org. LearnAboutSenderIdentification" style=3D"background:revert!important; color= > :revert!important; direction:revert!important; display:revert!important; fo= > nt-size:revert!important; opacity:revert!important; visibility:revert!impor= > tant"> > Learn why this is important
> 		lpadding=3D"7px 5px 7px 5px" color=3D"#212121" style=3D"background:revert!i= > mportant; border:revert!important; bottom:revert!important; color:revert!im= > portant; direction:revert!important; display:revert!important; font-size:re= > vert!important; height:revert!important; letter-spacing:revert!important; l= > ine-height:revert!important; margin:revert!important; opacity:revert!import= > ant; order:revert!important; outline:revert!important; overflow:revert!impo= > rtant; padding:revert!important; position:revert!important; tab-size:revert= > !important; table-layout:revert!important; text-align:revert!important; tex= > t-indent:revert!important; text-orientation:revert!important; text-overflow= > :revert!important; text-transform:revert!important; top:revert!important; v= > ertical-align:revert!important; visibility:revert!important; white-space:re= > vert!important; width:revert!important; word-break:revert!important; word-s= > pacing:revert!important; writing-mode:revert!important; zoom:revert!importa= > nt; width:75px!important; background-color:#EAEAEA!important; padding:7px 5= > px 7px 5px!important; font-family:wf_segoe-ui_normal,Segoe UI,Segoe WP,Taho= > ma,Arial,sans-serif!important; font-size:12px!important; font-weight:normal= > !important; color:#212121!important; text-align:left!important; word-wrap:b= > reak-word!important"> >
>

>

>
>
On Apr 9, 2025, at 1:01 AM, Robert Austen < ilto:robert.austen@willowglensystems.com" class=3D"">robert.austen@willowgl= > ensystems.com> wrote:
>
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > I respectfully disagree.
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= > o enable itself, ie. to apply any hooks.
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= > o PASS, which is not what most people would intend using PF_DEFAULT_TO_DROP= > .
>
>
>

>
>
Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl (&nbs= > p;DIOCSTART ) or netlink command to enable it.
>

>
>
@Kristof Maybe we also want a loader tunable to enable pf(4) on load ?= >
>
>
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > consider this: until pf or ipf or ipfw makes an ioctl to hook themselves, t= > he pfil layer in the kernel has no idea what the filter will be,
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > assuming there even is one. thus PF_DEFAULT_TO_DROP  has zero effect (= > and likewise the equivalents from the other filters).
>
>
>

>
>
As for ipfw(4), by default it enables filtering on load, unless you di= > sable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enab= > le` and `net.link.ether.ipfw`.
>

>
>
The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable= > `net.inet.ip.fw.default_to_accept` controls the default behavior to drop o= > r accept.
> >
>
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > as I said, this is because there's no mechanism within PFIL to drop by defa= > ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= > O_DROP,
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= > FAULT_TO_DROP isn't in the kernel config file, my patches have no effect at= > all,
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > so it's a simple mechanism for those that want more than PF_DEFAULT_TO_DROP= > can ever provide.
>
>
>

>
>
It appears ipf(4) unconditionally enable filtering on load, and does n= > ot have any tunables to control that. CC @Cy who is more familiar with ipf(= > 4).
>
>
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
ps:normal; font-weight:400; letter-spacing:normal; text-align:start; text-i= > ndent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-= > decoration:none; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,C= > alibri,Helvetica,sans-serif; font-size:12pt"> > thanks!
>
size:13px; font-style:normal; font-variant-caps:normal; font-weight:400; le= > tter-spacing:normal; text-align:start; text-indent:0px; text-transform:none= > ; white-space:normal; word-spacing:0px; text-decoration:none"> >
>
px; font-style:normal; font-variant-caps:normal; font-weight:400; letter-sp= > acing:normal; text-align:start; text-indent:0px; text-transform:none; white= > -space:normal; word-spacing:0px; text-decoration:none; display:inline-block= > ; width:563.5px"> > :normal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; = > text-align:start; text-indent:0px; text-transform:none; white-space:normal;= > word-spacing:0px; text-decoration:none; float:none; display:inline!importa= > nt"> >
vetica; font-size:13px; font-style:normal; font-variant-caps:normal; font-w= > eight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-t= > ransform:none; white-space:normal; word-spacing:0px; text-decoration:none"> > lass=3D"">From: Zhe= > nlei Huang <zlei@FreeBSD.= > org>
> Sent:  >April 7, 2025 7:55 PM
> To: R= > obert Austen < ss=3D"">robert.austen@willowglensystems.com>
> Cc: <= > a href=3D"mailto:freebsd-current@freebsd.org" class=3D"">freebsd-current@fr= > eebsd.org < ef=3D"mailto:freebsd-current@freebsd.org" class=3D"">freebsd-current@freebs= > d.org>;  =3D"mailto:freebsd-net@freebsd.org" class=3D"">freebsd-net@freebsd.org<= > span class=3D"x_Apple-converted-space"> < reebsd-net@freebsd.org" class=3D"">freebsd-net@freebsd.org>; > Kristof Provost <kp@FreeBS= > D.org>
> Subject:  pan>Re: pfil_default_to_drop >
 
>
>
normal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; t= > ext-align:start; text-indent:0px; text-transform:none; white-space:normal; = > word-spacing:0px; text-decoration:none; word-wrap:break-word; line-break:af= > ter-white-space"> > n=3D"left" class=3D"" style=3D"background-image:revert!important; backgroun= > d-size:revert!important; background-attachment:revert!important; background= > -origin:revert!important; background-clip:revert!important; background-colo= > r:revert!important; bottom:revert!important; color:revert!important; direct= > ion:revert!important; font-size:revert!important; height:revert!important; = > letter-spacing:revert!important; line-height:revert!important; margin:rever= > t!important; opacity:revert!important; order:revert!important; outline:reve= > rt!important; overflow:revert!important; padding:revert!important; position= > :revert!important; tab-size:revert!important; text-align:revert!important; = > text-indent:revert!important; text-orientation:revert!important; text-overf= > low:revert!important; text-transform:revert!important; top:revert!important= > ; vertical-align:revert!important; visibility:revert!important; white-space= > :revert!important; word-break:revert!important; word-spacing:revert!importa= > nt; writing-mode:revert!important; zoom:revert!important; border:0px!import= > ant; display:table!important; width:575px; table-layout:fixed!important; fl= > oat:none!important; border-spacing:0px!important; background-position:rever= > t!important; background-repeat:revert!important"> > ze:revert!important; background-attachment:revert!important; background-ori= > gin:revert!important; background-clip:revert!important; background-color:re= > vert!important; border:revert!important; bottom:revert!important; color:rev= > ert!important; direction:revert!important; font-size:revert!important; heig= > ht:revert!important; letter-spacing:revert!important; line-height:revert!im= > portant; margin:revert!important; opacity:revert!important; order:revert!im= > portant; outline:revert!important; overflow:revert!important; padding:rever= > t!important; position:revert!important; tab-size:revert!important; table-la= > yout:revert!important; text-align:revert!important; text-indent:revert!impo= > rtant; text-orientation:revert!important; text-overflow:revert!important; t= > ext-transform:revert!important; top:revert!important; vertical-align:revert= > !important; visibility:revert!important; white-space:revert!important; widt= > h:revert!important; word-break:revert!important; word-spacing:revert!import= > ant; writing-mode:revert!important; zoom:revert!important; display:block!im= > portant; background-position:revert!important; background-repeat:revert!imp= > ortant"> > revert!important; background-attachment:revert!important; background-origin= > :revert!important; background-clip:revert!important; background-color:rever= > t!important; border:revert!important; bottom:revert!important; color:revert= > !important; direction:revert!important; display:revert!important; font-size= > :revert!important; height:revert!important; letter-spacing:revert!important= > ; line-height:revert!important; margin:revert!important; opacity:revert!imp= > ortant; order:revert!important; outline:revert!important; overflow:revert!i= > mportant; padding:revert!important; position:revert!important; tab-size:rev= > ert!important; table-layout:revert!important; text-align:revert!important; = > text-indent:revert!important; text-orientation:revert!important; text-overf= > low:revert!important; text-transform:revert!important; top:revert!important= > ; vertical-align:revert!important; visibility:revert!important; white-space= > :revert!important; width:revert!important; word-break:revert!important; wor= > d-spacing:revert!important; writing-mode:revert!important; zoom:revert!impo= > rtant; background-position:revert!important; background-repeat:revert!impor= > tant"> > > > > > >
2px 7px 2px" class=3D"" style=3D"background-image:revert!important; backgro= > und-size:revert!important; background-attachment:revert!important; backgrou= > nd-origin:revert!important; background-clip:revert!important; border:revert= > !important; bottom:revert!important; color:revert!important; direction:reve= > rt!important; display:revert!important; font-size:revert!important; height:= > revert!important; letter-spacing:revert!important; line-height:revert!impor= > tant; margin:revert!important; opacity:revert!important; order:revert!impor= > tant; outline:revert!important; overflow:revert!important; position:revert!= > important; tab-size:revert!important; table-layout:revert!important; text-a= > lign:revert!important; text-indent:revert!important; text-orientation:rever= > t!important; text-overflow:revert!important; text-transform:revert!importan= > t; top:revert!important; vertical-align:revert!important; visibility:revert= > !important; white-space:revert!important; word-break:revert!important; word= > -spacing:revert!important; writing-mode:revert!important; zoom:revert!impor= > tant; padding:7px 2px!important; background-color:rgb(166,166,166)!importan= > t; width:0px!important; background-position:revert!important; background-re= > peat:revert!important"> > 5px 7px 15px" class=3D"" style=3D"background-image:revert!important; backg= > round-size:revert!important; background-attachment:revert!important; backgr= > ound-origin:revert!important; background-clip:revert!important; border:reve= > rt!important; bottom:revert!important; direction:revert!important; display:= > revert!important; height:revert!important; letter-spacing:revert!important;= > line-height:revert!important; margin:revert!important; opacity:revert!impo= > rtant; order:revert!important; outline:revert!important; overflow:revert!im= > portant; position:revert!important; tab-size:revert!important; table-layout= > :revert!important; text-indent:revert!important; text-orientation:revert!im= > portant; text-overflow:revert!important; text-transform:revert!important; t= > op:revert!important; vertical-align:revert!important; visibility:revert!imp= > ortant; white-space:revert!important; word-break:revert!important; word-spa= > cing:revert!important; writing-mode:revert!important; zoom:revert!important= > ; width:541px; background-color:rgb(234,234,234)!important; padding:7px 5px= > 7px 15px!important; font-family:wf_segoe-ui_normal,"Segoe UI",&q= > uot;Segoe WP",Tahoma,Arial,sans-serif!important; font-size:12px!import= > ant; font-weight:normal!important; color:rgb(33,33,33)!important; text-alig= > n:left!important; word-wrap:break-word!important; background-position:rever= > t!important; background-repeat:revert!important"> >
:revert!important; background-attachment:revert!important; background-origi= > n:revert!important; background-clip:revert!important; background-color:reve= > rt!important; border:revert!important; bottom:revert!important; color:rever= > t!important; direction:revert!important; display:revert!important; font-siz= > e:revert!important; height:revert!important; letter-spacing:revert!importan= > t; line-height:revert!important; margin:revert!important; opacity:revert!im= > portant; order:revert!important; outline:revert!important; overflow:revert!= > important; padding:revert!important; position:revert!important; tab-size:re= > vert!important; table-layout:revert!important; text-align:revert!important;= > text-indent:revert!important; text-orientation:revert!important; text-over= > flow:revert!important; text-transform:revert!important; top:revert!importan= > t; vertical-align:revert!important; visibility:revert!important; white-spac= > e:revert!important; width:revert!important; word-break:revert!important; wo= > rd-spacing:revert!important; writing-mode:revert!important; zoom:revert!imp= > ortant; background-position:revert!important; background-repeat:revert!impo= > rtant"> > You don't often get email from = > ;zlei@freebsd.org= > .  a.ms/LearnAboutSenderIdentification" class=3D"" style=3D"background-image:r= > evert!important; background-size:revert!important; background-attachment:re= > vert!important; background-origin:revert!important; background-clip:revert!= > important; background-color:revert!important; color:revert!important; direc= > tion:revert!important; display:revert!important; font-size:revert!important= > ; opacity:revert!important; visibility:revert!important; background-positio= > n:revert!important; background-repeat:revert!important">Learn > why this is important
> 		lpadding=3D"7px 5px 7px 5px" class=3D"" style=3D"background-image:revert!im= > portant; background-size:revert!important; background-attachment:revert!imp= > ortant; background-origin:revert!important; background-clip:revert!importan= > t; border:revert!important; bottom:revert!important; direction:revert!impor= > tant; display:revert!important; height:revert!important; letter-spacing:rev= > ert!important; line-height:revert!important; margin:revert!important; opaci= > ty:revert!important; order:revert!important; outline:revert!important; over= > flow:revert!important; position:revert!important; tab-size:revert!important= > ; table-layout:revert!important; text-indent:revert!important; text-orienta= > tion:revert!important; text-overflow:revert!important; text-transform:rever= > t!important; top:revert!important; vertical-align:revert!important; visibil= > ity:revert!important; white-space:revert!important; word-break:revert!impor= > tant; word-spacing:revert!important; writing-mode:revert!important; zoom:re= > vert!important; width:75px!important; background-color:rgb(234,234,234)!imp= > ortant; padding:7px 5px!important; font-family:wf_segoe-ui_normal,"Seg= > oe UI","Segoe WP",Tahoma,Arial,sans-serif!important; font-si= > ze:12px!important; font-weight:normal!important; color:rgb(33,33,33)!import= > ant; text-align:left!important; word-wrap:break-word!important; background-= > position:revert!important; background-repeat:revert!important"> >
>

>

>
>
On Apr 8, 2025, at 6:36 AM, Robert Austen < ilto:robert.austen@willowglensystems.com" class=3D"">robert.austen@willowgl= > ensystems.com> wrote:
>
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica= > ,sans-serif; font-size:12pt"> >
>
>
>
t-size:13px; font-style:normal; font-variant-caps:normal; font-weight:400; = > letter-spacing:normal; text-align:start; text-indent:0px; text-transform:no= > ne; white-space:normal; word-spacing:0px; text-decoration:none"> >
>
ormal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; te= > xt-align:start; text-indent:0px; text-transform:none; white-space:normal; w= > ord-spacing:0px; text-decoration:none; display:inline-block; width:576.2343= > 75px"> > :normal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; = > text-align:start; text-indent:0px; text-transform:none; white-space:normal;= > word-spacing:0px; text-decoration:none; float:none; display:inline!importa= > nt"> >
elvetica; font-size:13px; font-style:normal; font-variant-caps:normal; font= > -weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text= > -transform:none; white-space:normal; word-spacing:0px; text-decoration:none= > "> > <= > b class=3D"">From: Robert Austen < en@willowglensystems.com" class=3D"">robert.austen@willowglensystems.com >>
> Sent: April 7, 2025 4:33 PM
> To:  lass=3D"">freebsd-current@freebsd.org -space"> < ss=3D"">freebsd-current@freebsd.org>; ted-space">  "">freebsd-net@freebsd.org&nb= > sp;<freebsd= > -net@freebsd.org>
> Subject: Fw: pfil_default_to_drop >
 
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
ont-size:13px; font-style:normal; font-variant-caps:normal; font-weight:400= > ; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:= > none; white-space:normal; word-spacing:0px; text-decoration:none"> >
>
ormal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; te= > xt-align:start; text-indent:0px; text-transform:none; white-space:normal; w= > ord-spacing:0px; text-decoration:none; direction:ltr; display:inline-block;= > width:576.234375px"> > :normal; font-variant-caps:normal; font-weight:400; letter-spacing:normal; = > text-align:start; text-indent:0px; text-transform:none; white-space:normal;= > word-spacing:0px; text-decoration:none; float:none; display:inline!importa= > nt"> >
:Helvetica; font-size:13px; font-style:normal; font-variant-caps:normal; fo= > nt-weight:400; letter-spacing:normal; text-align:start; text-indent:0px; te= > xt-transform:none; white-space:normal; word-spacing:0px; text-decoration:no= > ne"> > <= > b class=3D"">From: Robert Austen
> Sent: April 7, 2025 4:21 PM
> To:  lass=3D"">freebsd-current@freebsd.org -space"> < ss=3D"">freebsd-current@freebsd.org>
> Subject: pfil_default_to_drop >
 
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > Hello,
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > I've been playing with FreeBSD and PF to build myself a new firewall, as Op= > en/FreeBSD + PF seems to be a common starting point.
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= > nd the like, with the observations that it's hard
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > to ensure that packets all default to drop if the rule file(s) for whatever= > reason fail to load. 
>
>
>

>
>
Hi Robert,
>

>
>
So why not defining the compile option PF_DEFAULT_TO_D= > ROP, and preload pf.ko ( via the loader(8)= > , /boot/loader.conf ) ? > >

>
>
With 13.5, or upcoming 14.3 ( you can also= >  experiment latest stable/14 ), you can d-space"> turn the loader tu= > nable net.pf.default_to_drop to 1, and  yle=3D"">preload pf.ko. > >
See also  t/?id=3Dc531c1d1462c45f7ce5de4f9913226801f3073bd" class=3D"">https://cgit.f= > reebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9913226801f3073bd&nb= > sp;.
>

>
>
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > After looking thru the online documentation, forums and scripts, I came to = > the conclusion that it's not a PF problem or IPFW etc
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > or really a problem with any of the filters or scripts, the problem is at t= > he level of PFIL, the kernel packet filtering code: If no
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > filter is loaded, i.e. if the heads are unhooked, then PFIL sends s=3D"x_x_Apple-converted-space"> everything&n= > bsp;thru to its destination. So my thought 
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_= > DEFAULT_TO_DROP) that drops all the
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loaded cho= > sen filter (PF or whatever) at any given time the 
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > hooks are  unhooked. 
>
>
>

>
>
If no firewalls loaded, then the system should behave as is= > . I do not think PFIL_DEFAULT_TO_DROP is the right way to handle your = > case.
>
>
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > [No one filters on local loopback nor the link layer, so I've left those ho= > oks untouched. I suppose one could add them,
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = > there's much demand for it.]
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > Normally I'm an embedded linux kernel basher.
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > I'm not entirely sure where to send this patch. Most of the threads asking = > the above PF questions are closed to changes,
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > so that doesn't seem a good place. Sir Dice seems to be a common answerer o= > f questions; I would have sent it to him/her 
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > if I could...
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = > patch"...
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > I've simply diff -rdpNU 5 a copy of the @old folder with a copy of @new fol= > der. The code was written against FreeBSD-14.1-RELEASE-amd64,
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> > but I suspect the kernel code in the networking core doesn't change much fr= > om platform to platform, or version to version.
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > But it works, it's pretty simple, pretty small and so just in case it might= > be useful, I'm passing it along.
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > thanks!
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> > Robert
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-indent:0px; text-transform:none; wh= > ite-space:normal; word-spacing:0px; text-decoration:none; direction:ltr; te= > xt-align:left; margin:0px; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFon= > tService,Calibri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
>
weight:400; letter-spacing:normal; text-align:start; text-indent:0px; text-= > transform:none; white-space:normal; word-spacing:0px; text-decoration:none;= > direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Ca= > libri,Helvetica,sans-serif; font-size:12pt"> >
>
> <Fr= > eeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip>
>
>
>
>
>
>
>
>
>
>

>
>
>
>
>
> > > > --_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_-- From nobody Wed Apr 9 20:04:47 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXv781CNLz5sJbW for ; Wed, 09 Apr 2025 20:04:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXv780XZ1z3M0l for ; Wed, 09 Apr 2025 20:04:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744229092; 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=DlqOt6vBUU2gkV2YfT8OUBtQh6FJCld1a1naRuKWwcs=; b=jA2kCXOtip3pUGJSvjV628rqwdlissAusITH3yWVxNti+ePaHaIyRCgoUqMwRsaFaY/Y8T 8ikTMZuGuW1pAfKWTBqqEdGF2AQtC6/38DEDEnzRMGi0acRNXXcFD+hqgKtE/1wcsse1vk pE1mtyuyzetj89vTL8p3+7ridOEBQvL7tyBJg2EcE2W60JIdXPtL56LNUguKsZL3aR4i1Z SDCvFjXu6v7ebbTIxMKAZcA+f2eTygqAuiNME0/CMKLSqQJM+sWdtNjXBzwEHEJvVaQhYw ctM/2rok4QCybvKTnJiRSBbSAvBmwj52cNNvhsC1MwHHAHnGC8npThkfdIAqRg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744229092; a=rsa-sha256; cv=none; b=eiz9eZ9ZGMEYrVyMnLn2+EBpvr11VC2U0DqfkuycWerMsXg7E3LTw6Ivy7GnNzNz09LOF2 e/WpRLIDTFqrjlS0MMN5VsF9eF+DFulFRlyRX3oMb02+lCAd0u7qNA51oXrgY6x01Z8eYH DiYUA4etWHuT1nBjvxwP1fFg680Z6nVmVM6LO9jeEpuwEZbPMoN8eJWxRHrITk7Snz1Hl5 y+xHYYNAHlVJgOGef3OuKdRSVv7tnrwQ3UTmLUsqez/LhM56/mNaT8oicgHqAsXgPGxXax z/m/lcZqAX15ymEIuMixzXA15pSZlANcQeJIpG5ycORgGlr/KWRjwgwx4ya34w== 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=1744229092; 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=DlqOt6vBUU2gkV2YfT8OUBtQh6FJCld1a1naRuKWwcs=; b=g2E8n/4IuwKBB13pa2uZbp8gOVaSiURjEhGBjSjm0NrQH4K3QnCI4JbgPCe7G8RJqA/pjw 3uPqpbPvBiMTL1/yoOX0RPT+K+IL3AzC2dNlYOu/v1kPdpcb8+nozDt5lEmLEoX9fTdzyi BpFdwV4mIJ6M11FTCWDDgyYhQthmg1bGV+2yXtGgrXQaq8QQWLvmR7yu8PvX1x9WIyrSfN sewy5lyCOcGtav72BC5v/TjAWOgChhK0RwGvcd5jFYFwWaBRauinMENMknOV767w4vcH9s tGfVsYTfjaQ9tjD8vtcHpRYMySFBc0hJzre/suwOeCHFHbo+OCwhtDDrxUeyZg== 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 4ZXv7806yXzXph for ; Wed, 09 Apr 2025 20:04:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 539K4pNo047565 for ; Wed, 9 Apr 2025 20:04:51 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 539K4phf047564 for net@FreeBSD.org; Wed, 9 Apr 2025 20:04:51 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 166724] if_re(4): watchdog timeout Date: Wed, 09 Apr 2025 20:04:47 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: needs-patch, needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: fbsd@opal.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D166724 J.R. Oldroyd changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fbsd@opal.com --- Comment #128 from J.R. Oldroyd --- The "watchdog timeout" also bit me here last night. Host is several years old, runs 24x7, never had a problem until yesterday. re0: port 0xc000-0xc0ff mem 0xa1104000-0xa1104fff,0xa1100000-0xa1103fff at device 0.0= on pci2 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x54000000 re0: MAC rev. 0x00100000 miibus0: on re0 re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: d8:5e:d3:xx:xx:xx re0: netmap queues/slots: TX 1/256, RX 1/256 re1: port 0xc000-0xc0ff mem 0xa1104000-0xa1104fff,0xa1100000-0xa1103fff at device 0.0= on pci3 re1: Using 1 MSI-X message re1: ASPM disabled re1: Chip rev. 0x54000000 re1: MAC rev. 0x00100000 miibus1: on re1 re1: Using defaults for TSO: 65518/35/2048 re1: Ethernet address: d8:5e:d3:xx:xx:xx re1: netmap queues/slots: TX 1/256, RX 1/256 Per advice here, I've switched to the vendor 1.100 driver. Immediately nee= ded the -rxcsum -txcsum -rxcsum6 -txcsum6 as advised in the pkg-message. It's = been running fine for almost about 20 hours now. --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.= From nobody Wed Apr 9 20:44:58 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXw1Z71MWz5sMTv for ; Wed, 09 Apr 2025 20:45:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXw1Z56jjz3dXS for ; Wed, 09 Apr 2025 20:45:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744231506; 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=3OVwqM5xVFyAheZ3PZk8iX+5mSsKkNq1KlUtw/aWTs4=; b=Jwh6TGwOqMjyFRAVHrABQDjMXWDb61bR/MvMOzkhVeiOSnfsPc2RG1utKcgCjbIKoyV7EI GtJDRGKNVgCSERLpQSXCEIxvOpkdqpUvVTgKtcaJg3HwEQlBZwabTU66PVyI0JVPUNlu7U NQdEpoeLyTcmMCi49k7qxo8Jjt4kptR9wVpPM20w0qI9AdVVZUCQPauIxSb9/o5O6bR/6o D2YUJe9/fRZ5TDNfoVFlULeI9SviWJN+Q/WjtQ6sI5uU86bY6+kawz8Qfkvg1Okxgo1p8s f8VSRb2ATIwTfaxWLQzBY81ocJbuvYaO5Sn3A0SIu2iCiGiNSiAj+T1Zu93L8Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744231506; a=rsa-sha256; cv=none; b=KK/RGOOz0rd4gDolxloEKbo6+1ieIMkLzeBlW4V1BOiTdNIm4ewoU89g+DcYkBbVvPqofn STblOD2FX4g9UpD5jLcR6hO44pWMxhMNWeKK9UXteue5Q/TSuOHR1Fwst6ny1hNb6E6peN CqgW6RonGuOczz1oKR6ljmnvh+96+y40lXqGU6X3U54Z4xx+DPWjuI20lngLfbBNPyCLfx ZHPYRpNs5X7eI0kU1CneOgar1ngrbDioWR7fPe2jDB816hHxvjiz1OG48LefLdNjqoWu32 iSXPe4jHvqOYapkRqsCaTROut+DUkafSEuMARCqHI+wYnQerQxSP3Yabu9szfA== 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=1744231506; 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=3OVwqM5xVFyAheZ3PZk8iX+5mSsKkNq1KlUtw/aWTs4=; b=DFbCIP564G+ZGl43ies/DRRyFt0vCrqNiU0WNdjvr6kITcKPP+da78rUE9U6eMwAW6w3Uf 1SjT6+RTkVQW3rQVy1gChVPEBv13wXIdGRe2x4PPVsXn8Kc3NllddLlVfErTDyPt1PGP9D vlUsbjxNo2PkxUXscQ5nLXry/59PVmGcDQpHc1GTrxeE3eARRlPOOlBvadudE/Ag1gaaeM tFgihZhbXeUUdHHOs0zxc8KzJ6vmPzy3C4wxbk2qDKFjZ9UoOzS3Yv0V+FXn3zJu2ZTAor z1K6Cz96G+pJ9mqUfUHDNCOiqcINLAQTChuwIMON5oSU5s4WXSIEYAZ1LwhStQ== 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 4ZXw1Z4dH7zZQJ for ; Wed, 09 Apr 2025 20:45:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 539Kj6BX021223 for ; Wed, 9 Apr 2025 20:45:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 539Kj6mm021222 for net@FreeBSD.org; Wed, 9 Apr 2025 20:45:06 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 166724] if_re(4): watchdog timeout Date: Wed, 09 Apr 2025 20:44:58 +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: 11.1-RELEASE X-Bugzilla-Keywords: needs-patch, needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: fbsd@opal.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D166724 --- Comment #129 from J.R. Oldroyd --- Meant to add above that the watchdog timeout hit re1. There had been occasional timeouts in the log for a few days but no problems. Last night there was a series of timeouts in short order and re1 stopped working. No amount of interface down/up or netif restart re1 helped. Had to reboot to = get it going again. All the while re1 was not working, re0 was still working fine. --=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 Thu Apr 10 17:19:21 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZYRPm4g7Bz5tDFj for ; Thu, 10 Apr 2025 17:19:24 +0000 (UTC) (envelope-from lexi@hemlock.eden.le-fay.org) Received: from fuchsia.eden.le-fay.org (fuchsia.eden.le-fay.org [81.187.47.195]) by mx1.freebsd.org (Postfix) with ESMTP id 4ZYRPl2qZPz4NhS for ; Thu, 10 Apr 2025 17:19:23 +0000 (UTC) (envelope-from lexi@hemlock.eden.le-fay.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of lexi@hemlock.eden.le-fay.org has no SPF policy when checking 81.187.47.195) smtp.mailfrom=lexi@hemlock.eden.le-fay.org Received: from hemlock.eden.le-fay.org (hemlock.eden.le-fay.org [IPv6:2001:8b0:aab5:c401::1:5]) by fuchsia.eden.le-fay.org (Postfix) with ESMTP id 2F092239C8 for ; Thu, 10 Apr 2025 17:19:22 +0000 (UTC) Received: by hemlock.eden.le-fay.org (Postfix, from userid 10006) id EA5674B540; Thu, 10 Apr 2025 18:19:21 +0100 (BST) Date: Thu, 10 Apr 2025 18:19:21 +0100 From: Lexi Winter To: freebsd-net@freebsd.org Subject: merge traceroute6 into traceroute Message-ID: Mail-Followup-To: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [1.64 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_SPAM_LONG(0.99)[0.994]; NEURAL_SPAM_SHORT(0.75)[0.746]; RCVD_IN_DNSWL_LOW(-0.10)[81.187.47.195:from]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:20712, ipnet:81.187.0.0/16, country:GB]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[le-fay.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4ZYRPl2qZPz4NhS X-Spamd-Bar: + hello, i have proposed a patch to merge traceroute6 into traceroute, so that traceroute supports both IPv4 and IPv6 addresses: https://github.com/freebsd/freebsd-src/pull/1647 jlduran@ has proposed an alternative approach to achieve the same thing which is mentioned in the PR comments. any feedback or review on this (with a view to getting it committed) would be appreciated. thank you in advance! From nobody Fri Apr 11 10:09:44 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZYsqX2KJbz5sy1Q for ; Fri, 11 Apr 2025 10:09:44 +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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZYsqX1dSSz3Yn6 for ; Fri, 11 Apr 2025 10:09:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744366184; 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=pcdXC5IkeWBULAwj0dUcEcsXR0JAJ7U4SF4kt4+bXVg=; b=HEBLmV22r9dd+PnjuVprAj1f6mfiXzFmHAF8eGV4A0QN6rm8l/k3/nmc9zkqpslpzJEIEm 3I0cPUdlaUUZxkHF6ahpmkx95rZxhz8D8dfS1d5uB9411dh7fZz1aCJF+StZHIbCNlpVCO bV7eCOts8CAYT6WWlxI/x2EW0aN5wSfKR5liQwUgYfLe6GqDRcWuh/jqck1WBBix2sK9Xp 5hmThM7/S+Vzr0kwy5+lB8RU/dg/PMsluujGYOMjI0PpAsB5KW7f1CYqhsetOJkeRvH7Zf ZbIcPddwM48bGm0vH6rLe0LkRCBADBBIruRBodFSpXYtddnHt50hI7FEinmxGg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744366184; a=rsa-sha256; cv=none; b=Bx+OtC/ZrzD+vyFmWrofN/5b1oLjKqPRWZQtUex1Sc/JuNLCszi/yf/x0RMeqWE1mnUJVK ivf6utweeVf+u17Y8QsRDz2mfWCy4pXMyssJ2exjj7Gf2rZGNfjJvXe3LQmhAd8XjiPwSZ 9sZ450kCZD6qpw+uglbHpRRPnzxheqjYnxPTfXJcn5S6EbmkvN9vJ0G6Hhi6JF84UIzOmF BeZ+9InNMWMpmhnylmj/SKA7K8VMBreGDMgj/yh5PkqRHnO3GJvURo8xp/T4nL/0KsMGN0 qytiHZbVwvOxRGYLH+4IGe2a5i/qck1CmCiCB9aB80/sMpB+iwHX3mlYfpCa2g== 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=1744366184; 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=pcdXC5IkeWBULAwj0dUcEcsXR0JAJ7U4SF4kt4+bXVg=; b=qRcq2+2prN7iDjtxBCv9slV86eW/SxSx0Od+f0Lox3x01BHpKu8m9YIOmUbvoQjrxu4X3B peSYAPih5GJ7J6kBSSW52tNsHqYRpvhouharTbAd4hSxPpTF0SsysRN2RxGjL3CYOGQzZM fJ3EgiDqulM16S9N3YEkJmowbVRWmQh4HKcJTQvirVfDdCQEgx96v+7mB+ZQzBfA3v6RXo P50RIDUQUnUion2/CQ6MUP+1fqd09K0iBzlbKJJ1QvqaDTowGSMlzq3F8bLefqONQnK6Kx PqXRQM6UuqyhmfnmQymb/LYnhHYZ3S5FNxZ0PaScQQh7raWK5s501QFRaCRTZw== 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 4ZYsqX0nLjzCY6 for ; Fri, 11 Apr 2025 10:09:44 +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 53BA9h6X006444 for ; Fri, 11 Apr 2025 10:09:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 53BA9hxr006443 for net@FreeBSD.org; Fri, 11 Apr 2025 10:09:43 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 218959] routed(8) closes socket 0 when /etc/gateways in use Date: Fri, 11 Apr 2025 10:09:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: webpages@sprow.co.uk X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218959 Sprow changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|routed closes socket 0 when |routed(8) closes socket 0 |/etc/gateways in use |when /etc/gateways in use --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Apr 12 09:55:47 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZZTT11xXGz5tDSL for ; Sat, 12 Apr 2025 09:55:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZZTT0558hz3mRk for ; Sat, 12 Apr 2025 09:55:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744451748; 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=U+HloNpbt9P9wbcbGeTGvOS6J/bik1XV2aI+M3WBST4=; b=vz/yqYov2rCKEj0aEGyWUwEvRtamUwMlEI0/oiSZ75xwWUU+p4BsUIhkRjRBS8w2MtzIoA EEsj56hNbBTlOws8MMLxCXMYwiV32JDxLOWIQ4w8bQnRiHBtVNZ+D/xw31N9P171n2NZQ7 hE89ptu3FOnWrRGlY/AonwTjw0Hiyhl/WhH+SilmGcs+VDiz7i/hHrvOgSg4vflYUbmTww yBDQR4AWxg2moVX+KPaRfiG4SRk8QzPBKdj9WknRukQSJvWfo+2yfzpUcyLPUMWU5teQz5 jFtnhb7s4vGo7jnUCOAVBD8uox7jMP+HMadf+4g8EuEDHjXziU7K84ZEvkEdlQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744451748; a=rsa-sha256; cv=none; b=lWSTx+no1gljNkc7Q52lEGAT5sBiqQAeAIPl6gw8G3qTTsvvV26w0IWmwuxDw20nGtJhXM y30MLh2Lva7H6t6u15Worwzc/vbIKxl7EsCbjz9ir/sFHNSB/6UeVbjgmIX+jXK9x9blfF HyFg5iwoQ8mfa3dgQmPQzBZRHzkSeOLs4RxUMc0ozq085cJBy7LQF3jPElc3uQhB1xprx1 ZZcur9ZdliGMllUwxt3f+Neu79LZheZwtS09I2gwG1njoiqCh9I+EQMOlrEWuQF1p0sP1G yx8ZEmXAfdGQnV48VrycPBxxw7UYujP4e6KxRjnw/taasNN/Yeu0RkPiVyQtQA== 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=1744451748; 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=U+HloNpbt9P9wbcbGeTGvOS6J/bik1XV2aI+M3WBST4=; b=dXZoIXaSybu4gPWXY/zCJQVMZa7Oiv+zLOaIdja0dtPCnxeZwwdLRg4KxFoILQUVOIZiEq YoNYJLTPnONf243Kzh3HQjBLa7FyJ9tjMbVuVRBp4V7Da6Hpsbl7f6oLhqEsGfU+3yT03I /qhajcDeXcajFAQ8KGukqk5CXdPdovOVSzKqHWPQRLwIZ2liGUpEQjodGBZQF3iYHBbd8/ ipdvK7N1wrPOsX7T/rZtKqTfqiDE68vNqpIvUlZp+34Dlz3zwqJgjTgRyKdoTmICqyX+7g RYzBeXN65MaDxImiYr3AgafgIE1V7ahT4LHCdfTnOLbwzFP3WiPvP6Zi6sGpyQ== 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 4ZZTT04TMSz1BWT for ; Sat, 12 Apr 2025 09:55:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 53C9tmnm059113 for ; Sat, 12 Apr 2025 09:55:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 53C9tmUJ059112 for net@FreeBSD.org; Sat, 12 Apr 2025 09:55:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 277029] Invalid source address selection for IPv4 Date: Sat, 12 Apr 2025 09:55:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hrs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: hrs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc assigned_to Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277029 Hiroki Sato changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |hrs@FreeBSD.org Assignee|net@FreeBSD.org |hrs@FreeBSD.org --- Comment #1 from Hiroki Sato --- Take. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Apr 12 21:47:20 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZZnG04y94z5skQS for ; Sat, 12 Apr 2025 21:47: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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZZnG04JCmz3b7Y for ; Sat, 12 Apr 2025 21:47:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744494440; 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=VqdvBJ/l5qNMsQnC/yIW3NTaK6dD2YdJ0wkOgv6f3rs=; b=WOSe+fJh+4CDvXGvrgw5KSZB3lywCNwO7LPtF3WYlK0leMZeodf9qJdZ3owDKLqk1RcSRu tuu78AJ7nfu1TPsofTjH8Lo61jXUeRauDQ3QweBxVZ322trZu6hWv9Hvd84pRXkqogRQXQ zQ3CNaEwqt6ai6Q9zs0ZvjANdLnLloQfnYT1CGSxzKkmYm20EkyTKlIMmDIxkf0YifNbOn cbOLb1PFZ5YIxXNzz5KQA076tsMkGWA/RxuZxl/kil0ncGlD4d1o8bcRRVZLVDjCKhiXQp ruMfpj9sptiGit3Tj8acpNk+qUwXnTd1NnXE6futD/MWk8I+kpHGsraggwnkiQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744494440; a=rsa-sha256; cv=none; b=mjs+s9FaYFe8Y10q1/AXvcFPVV5zFRgbm0ieHlcsImLLZ58G5dtijXHKF1yaYzcLYnOk63 fqLeLvXwBVk/2mmaYfiYjV4igg5SX7d3BkBjZQmLXNAXsVDEiMyvDz+Q7YdtLqowzG32FD RHESfEKqjBCYLdfBD2fpVhMbUWHKCvepM1++IArW4XqGK5RoHtVYTSESyw1aKA4svZG7CA /mze+BNWV8MNXp3VcR82QnKUe119jnt9vH18dUBZB+RECu3fvulgL7lHDsrldCQqIjKRH4 X3u61a/8TSUAAQH5VKu1qiMPkNVwmNN/POXKWKxUuwdco0XBM6X2HTMKTeP5tg== 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=1744494440; 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=VqdvBJ/l5qNMsQnC/yIW3NTaK6dD2YdJ0wkOgv6f3rs=; b=kbPP1QTUB6VH9mhuRe9AVOtZJH25s1u+x5b0gpm3lKfgSU/GJsODwb5GyyreFcyxv6LVfu V08+knFo9veVSUmDKxGfNlsV0ly1NEbLWNaHAqhNu0ZonSdBRLA1Msejk53d24cCCKx0u9 gEckeGAAaMn3xpt1J3ivzOLdVrCT1XTOY+if6H1UteUo4ckuEkyO+18mmMoyI36oQPywjg UG4k4aBEmw+bgxNNN2JmwRAILGaftT6O2D4DpwC/hnmFSy0H8RmGlN2ZFb4Gy/Db5v+WHm fmkPr1WBPBe3nF3Gs8iopjOUXW4eQ9grDKgtzSB3bBQ7X7iSPRt+g+vsSCsySQ== 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 4ZZnG03LBYzbbk for ; Sat, 12 Apr 2025 21:47: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 53CLlKVA072914 for ; Sat, 12 Apr 2025 21:47:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 53CLlKEQ072913 for net@FreeBSD.org; Sat, 12 Apr 2025 21:47: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 280390] NPTv6 not working Date: Sat, 12 Apr 2025 21:47:20 +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: 13.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tatsuki_makino@hotmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D280390 --- Comment #20 from Tatsuki Makino --- (In reply to Tatsuki Makino from comment #19) An example of my comment #19 is a bad example. There is no problem with the communication of the created dynamic rules. However, if a packet that passes through that dynamic rule has to pass thro= ugh a packet of another protocol (e.g. icmpv6 packet too big message), there is= no path for the translation that would allow it to pass. Therefore, such settings should not be made. NPTV6 instances can be identified by name and used separately, but they see= m to be usable only under conditions where multiple upstreams switch due to failover. Since my upper stream is already /64, there is no room to divide it into multiple lines. I have to think of another way to separate the upstream while keeping the prefix length that allows temporary address auto-configuration downstream..= . :) --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Sun Apr 13 21:00:57 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZbNB12q2Kz5shXd for ; Sun, 13 Apr 2025 21:00: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 "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZbNB126bCz3yBK for ; Sun, 13 Apr 2025 21:00:57 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744578057; 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=hAknE4KkhtBlZZo/8DfbeX72edKBzr3FZQOZXWCxhXg=; b=XhGXNIpHc7SurTgmOD/bbvfTNSOOfA1/OFc3zBArbmoFxsItN5yORPi8098rzs2iKiQyUi S4n/nEiTWl0EAjA/YXxgPhrE7UWYKUrGOiMXqV9NTx8DYOinyeUIozt93Tc4z3woYW5BMJ a6nrZ7UfrWMi4pP9juFcYM0vytOxCuc+8r1Pe1klQ0/PVxzH/io+zzLo9BN0pkL9YHEL0H Z1TEfdPTLk4g22T4/CSVWekZYBz8r2z3FLPrKlys4LvNE+jEMPCQdBUU58sN4Mm5oi1Vni vpgl7hGLGW/kOdfWInUyajp43UZ7cOtZT+kEhoBfP62zrKXAywhq4Spz/WV9Gg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744578057; a=rsa-sha256; cv=none; b=ROHpfJB6SpgwCW2SQTSg4HCPoAait7W455+ngSZDBs6zJoUGsSaudZKZK0shzKzgtwkUzH tQLAz6Ue1Cqxs8qQQjiszWJ6FIoEW09DCk7YyIhreWhsxxuATefF6kWyiR9UYPeqKbP2Gz XquG6FUMU7X7EBx//dun/N/u8qOMBKnb6roACBMGTZYTi4lZZKjP2Dc5EoPw5ekU4X/tpN L8tq2RxBB9ajArpiivOGZeIUNkEOR3vxtjV7p4nkhc6j+fT7rFd0yu4+ED07zFmHHy6Pqr sFobLigc126nPfe/9sZYVFIh9w2P/53U+d1kWuitIlX/lDcfEvL6fsSXcUT6Ag== 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=1744578057; 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=hAknE4KkhtBlZZo/8DfbeX72edKBzr3FZQOZXWCxhXg=; b=UhaaNfM757PtVACcZbvFZf1wpdOedGC9axQVLiUoj03nhtyt3HbEMW5czC5klLB+CCy6VN AagmKvZ9n81tgBhjBI3rReSCo+cTSACRY1u8Pp3YMO52IsxaR+nPr9IMPe13MbrgUwEdeC RQJZDTjrgH6X03z62BDva9sntDkBK2LgJNMDO5jufZI5i3wzgocHN1/pL/stJd4EDS4fxt udjh/uAuDJjsaJ8kKhiGcSwgjHyrq0ch9H8g5QbJyqVmWteSReX2Rq6kaF/xNQ6QjXYRjy xJqDnv46sMnTaayr9/TXuYfrqbMIZPsaSuEHNFF2jMERIEm9+RNXjn2x3vFoQg== 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 4ZbNB11hdQz3qm for ; Sun, 13 Apr 2025 21:00: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 53DL0vl4091415 for ; Sun, 13 Apr 2025 21:00:57 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 53DL0v66091414 for net@FreeBSD.org; Sun, 13 Apr 2025 21:00:57 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202504132100.53DL0v66091414@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, 13 Apr 2025 21:00:57 +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="17445780571.99Aae.84363" Content-Transfer-Encoding: 7bit --17445780571.99Aae.84363 Date: Sun, 13 Apr 2025 21:00:57 +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. In Progress | 118111 | rc: network.subr Add MAC address based interface 2 problems total for which you should take action. --17445780571.99Aae.84363 Date: Sun, 13 Apr 2025 21:00:57 +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.
In Progress |    118111 | rc: network.subr Add MAC address based interface 

2 problems total for which you should take action.
--17445780571.99Aae.84363--