Please don’t monkey patch your sockets unless you actually need to both see the raw data and intervene. This is a feature that sounds fun to implement all kinds of crazy stuff with until it breaks in production and you haven’t documented its use for the poor soul who has to fix it. If you need to do either in isolation just use a non-IPPROTO_DIVERT raw socket or a simple proxy for explicitness. And when you use these, document the hell out of its use. I’d hate to be woken up in the middle of the night for a paging service that a divert socket using process was to blame for without knowing about its presence before-hand.
That said, it sounds like a powerful tool for reverse engineering and synchronous traffic enforcement.
We’ve been using divert(4) sockets (at work) for some time now without any problems. The simplicity and performance benefits of divert(4) sockets, make them ideal for certain cases, such as dnsbl check before passing the connection to a service, temporarily disable certain protocol features (ala heartblead), instant and automatic block for connection attempts to non existent services.
divert sockets are also being used on some of the default daemons of OpenBSD (ftp-proxy(8), tftp-proxy(8)).
We have made public a small set of tools called pf-diverters that demonstrate some of the use cases. Also note that these tools are not meant for production use.