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. 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
