Date: Tue, 16 Dec 2025 23:32:37 +0100 From: Kristof Provost <kp@FreeBSD.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: ks@freebsd.org, freebsd-pf@freebsd.org Subject: Re: IFT_PFLOG and IFT_PFSYNC Message-ID: <2FC96EBC-8C1A-47BA-9CA7-5332515BC8B9@FreeBSD.org> In-Reply-To: <aUHOAePgxI1nJhCq@cell.glebi.us> References: <aUHOAePgxI1nJhCq@cell.glebi.us>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 16 Dec 2025, at 22:24, Gleb Smirnoff wrote: > the IFT_PFLOG and IFT_PFSYNC are the very last interface types > remaining that > should not exist :) I mean should not exist in the interface > namespace of > course! > > Historically, there was a long tradition to create a new interface > type for > whatever is not a network interface. This tradition comes from > OpenBSD, but we > have had our own sins, like IFT_USB for usbdump(8). Usually, the > interface was > created merely for ifp->if_bpf, like USB, ipfwlog and pflog. Another > reason > was lazyness (I speculate here) to implement a configuration path via > ioctl(). > When you create an interface, you just tunnel all configuration into > ifp->if_ioctl() and this way you separate your code from in_control() > that > historically was very entangled in *BSD. I speculate that carp(4) and > pfsync(4) were implemented as interfaces exactly for this reason. > > There is no urgency, but it would be nice to de-ifnet the pflog(4) and > pfsync(4) in the 16.0-CURRENT timeline. For the pflog(4) it is going > to be > super easy, see how ddf4f9eda9c2 did that for ipfw(4). For the > pfsync(4) the > implementation shouldn't be difficult as well, however the difficult > part is > preserving user experience, so that machines boot with obsolete > rc.conf. Good > news is that we have /etc/rc.d/pfsync and supposedly nobody has bare > ifconfig_pffsync0="" in their rc.conf. > > Again, no urgency, but something to think about. > I’ll certainly keep it in mind, but my current priority in refactoring work is to get the control plane converted to netlink. I’d hoped to get that done before 15.0, but it’s still pretty far from complete now. I’m not strictly opposed to this, but I do worry a bit that it’s going to confuse users, even if we have the scripts handle this. Honestly, I’m not quite clear on how it’d all work myself. Presumably we’d build something similar to pflowctl for pfsync, pfsynctl, to set up and configure pfsync. That’s currently done through ifconfig of course. A pretty inevitably user-visible change, but probably manageable. Pflog seems harder. There’s not much to configure, but exporting information is done through `tcpdump -n -e -ttt -i pflog1`, which sort of assumes a network interface. Your ddf4f9eda9c2 change talks about a BPF tap ipfwlog0. Does that mean we can `tcpdump -i ipfwlog0` even if there’s no struct ifnet ipfwlog0? (I don’t have a machine running recent enough main to actually test right now.) That’d probably be fine, even if I’m sure doing `tcpdump -i pflog0` is going to confuse me if ifconfig claims there’s no such interface as pflog0. Best regards, Kristof [-- Attachment #2 --] <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8"> </head> <body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;"> <p dir="auto">On 16 Dec 2025, at 22:24, Gleb Smirnoff wrote:</p> <blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #136BCE; color: #136BCE;"> <p dir="auto">the IFT_PFLOG and IFT_PFSYNC are the very last interface types remaining that<br> should not exist :) I mean should not exist in the interface namespace of<br> course!</p> <p dir="auto">Historically, there was a long tradition to create a new interface type for<br> whatever is not a network interface. This tradition comes from OpenBSD, but we<br> have had our own sins, like IFT_USB for usbdump(8). Usually, the interface was<br> created merely for ifp->if_bpf, like USB, ipfwlog and pflog. Another reason<br> was lazyness (I speculate here) to implement a configuration path via ioctl().<br> When you create an interface, you just tunnel all configuration into<br> ifp->if_ioctl() and this way you separate your code from in_control() that<br> historically was very entangled in *BSD. I speculate that carp(4) and<br> pfsync(4) were implemented as interfaces exactly for this reason.</p> <p dir="auto">There is no urgency, but it would be nice to de-ifnet the pflog(4) and<br> pfsync(4) in the 16.0-CURRENT timeline. For the pflog(4) it is going to be<br> super easy, see how ddf4f9eda9c2 did that for ipfw(4). For the pfsync(4) the<br> implementation shouldn't be difficult as well, however the difficult part is<br> preserving user experience, so that machines boot with obsolete rc.conf. Good<br> news is that we have /etc/rc.d/pfsync and supposedly nobody has bare<br> ifconfig_pffsync0="" in their rc.conf.</p> <p dir="auto">Again, no urgency, but something to think about.</p> </blockquote> <p dir="auto">I’ll certainly keep it in mind, but my current priority in refactoring work is to get the control plane converted to netlink. I’d hoped to get that done before 15.0, but it’s still pretty far from complete now.</p> <p dir="auto">I’m not strictly opposed to this, but I do worry a bit that it’s going to confuse users, even if we have the scripts handle this. Honestly, I’m not quite clear on how it’d all work myself.</p> <p dir="auto">Presumably we’d build something similar to pflowctl for pfsync, pfsynctl, to set up and configure pfsync. That’s currently done through ifconfig of course. A pretty inevitably user-visible change, but probably manageable.</p> <p dir="auto">Pflog seems harder. There’s not much to configure, but exporting information is done through <code style="padding: 0 0.25em; background-color: #E4E4E4;">tcpdump -n -e -ttt -i pflog1</code>, which sort of assumes a network interface.<br> Your ddf4f9eda9c2 change talks about a BPF tap ipfwlog0. Does that mean we can <code style="padding: 0 0.25em; background-color: #E4E4E4;">tcpdump -i ipfwlog0</code> even if there’s no struct ifnet ipfwlog0? (I don’t have a machine running recent enough main to actually test right now.)<br> That’d probably be fine, even if I’m sure doing <code style="padding: 0 0.25em; background-color: #E4E4E4;">tcpdump -i pflog0</code> is going to confuse me if ifconfig claims there’s no such interface as pflog0.</p> <p dir="auto">Best regards,<br> Kristof</p> </div> </div> </body> </html>help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2FC96EBC-8C1A-47BA-9CA7-5332515BC8B9>