On Fri, Dec 19, 2025 at 09:48:00AM -0800, Gleb Smirnoff wrote: > On Fri, Dec 19, 2025 at 10:12:42AM -0500, Mark Johnston wrote: > M> > > All known software in ports had been addressed three years ago and > the > M> > > shim stays in stable/14 and stable/15 for another couple years > with its > M> > > printf(), so all ourliers are expected to conform before > 16.0-RELEASE. > M> > > See 8624f4347e8133911b0554e816f6bedb56dc5fb3 for details. > M> > So why breaking the binaries that users might have lingering around? > M> > M> Aside from that, with a PF_DIVERT socket sd it's not possible to call > M> sd.recvfrom() in python (because python doesn't know which sockaddr > M> subtype to use), whereas with a PF_INET divert socket it gives a > M> sockaddr_in with an interface address, for inbound packets. > > This means my submission to python back in 2022 was missing couple lines. The > Modules/socketmodule.c:makesockaddr() is missing a case. :( > > If people were not ignoring the warning message and switched to PF_DIVERT > earlier, I would learn that my patch to python was missing a bit earlier. > > I will start a new submission to python. Usually they are very slow to > accept. > I'm fine if you revert e967a2a03677. But let's plan to remove it before > stable/17. Why?
Apparently, the feature is widely used by applications. It is even present in python. Breaking it is abrupt and must be reverted. > > M> So some > M> applications cannot be quickly repaired. In fact, I'd find it useful to > M> go the other way and add support for > M> socket(PF_INET6, SOCK_RAW, IPPROTO_DIVERT). > > How this will help? The divert(4) is actually not tied to any protocol. > If you use ipfw layer 2 divert, the socket will receive Ethernet frames. > > -- > Gleb Smirnoff
