If you have to deal with raw sockets, I highly recommend libtins: <a href="https://github.com/mfontanini/libtins" rel="nofollow">https://github.com/mfontanini/libtins</a> Makes it very easy to support multiple platforms.<p>I recently had do support for a Digidesign Pro Control (<a href="https://medias.audiofanzine.com/images/normal/digidesign-pro-control-22275.jpg" rel="nofollow">https://medias.audiofanzine.com/images/normal/digidesign-pro...</a>) that used it's own ethernet protocol. Libtins made it very easy and I didn't need to write my own driver or anything like that.
> Luckily it's easy enough to support IPv6: just replace AF_INET by AF_INET6 and <i>it will work with both IPv4 and IPv6</i>! So don't you dare to ever use AF_INET anymore without a good excuse<p>(emphasis mine)<p>AFAIK, on many systems (think FreeBSD) this is not true:<p><a href="https://www.unix.com/man-page/FreeBSD/4/inet6/" rel="nofollow">https://www.unix.com/man-page/FreeBSD/4/inet6/</a><p>> By default, FreeBSD does not route IPv4 traffic to AF_INET6 sockets. The default behavior intentionally violates RFC2553 for security reasons. Listen to two sockets if you want to accept both IPv4 and IPv6 traffic. IPv4 traffic may be routed with certain per-socket/per-node configuration, however, it is not recommended to do so. Consult ip6(4) for details.
The article doesn't say why I would want to use raw sockets. The only place it comes close to giving a reason is at the end:<p>"<i>This is the lowest we can get: this way ethernet frames are passed from the device driver without any changes to your application, including the full level 2 header. Likewise, when writing to the socket the user-supplied buffer hast to contain all the headers of layer 2 to 4. This is the deepest we can go in userspace – at this point we have full control of the complete ethernet frame. I hope you enjoyed our journey into the rabbit hole.</i>"<p>So, presumably, I'd prefer this to UDP in a situation where I need the complete ethernet frame. But when would that be? It would have been great if the mentioned a few scenarios where this is useful.
Once you create software that processes raw socket data, besides the endianness issues, the next thing you'll realize is the incredible breadth of RFCs that are covered for even "common" network traffic. Write your software to parse just one RFC, and a bunch of software using that protocol still won't work. Don't support the optional network layers that commercial network infrastructure splices into the packets, and you'll again miss a lot of traffic. Modern tcp/ip stacks are really complicated.
Some smart soul archived it: <a href="http://archive.is/nt67c" rel="nofollow">http://archive.is/nt67c</a><p>At this point, there should be a bot running that archives any post that starts getting traction. Or maybe have a HN serve a cached copy to offload the traffic? Who knows, it just seems like every blog post is killed the instant it reaches the front page.
Late to the convo, but I created a go library with no C dependencies that lets you play with raw sockets on Linux:<p><a href="https://github.com/nathanjsweet/zsocket" rel="nofollow">https://github.com/nathanjsweet/zsocket</a>
This is great. Somewhat orthogonal, can anybody venture a guess on if we will ever be able to open raw sockets in AWS Lambda functions or if their continued restriction is necesary for their container security model?