
Linux Raw Sockets - nudin
https://www.schoenitzer.de/blog/2018/Linux%20Raw%20Sockets.html
======
FigBug
If you have to deal with raw sockets, I highly recommend libtins:
[https://github.com/mfontanini/libtins](https://github.com/mfontanini/libtins)
Makes it very easy to support multiple platforms.

I recently had do support for a Digidesign Pro Control
([https://medias.audiofanzine.com/images/normal/digidesign-
pro...](https://medias.audiofanzine.com/images/normal/digidesign-pro-
control-22275.jpg)) 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.

~~~
FraKtus
"libtins depends on libpcap and OpenSSL, although the latter is not necessary
if some features of the library are disabled."

Would you know something lighter to play with RAW sockets?

~~~
bb88
I've used libpcap in the past, and it's been rather nice.

[https://www.tcpdump.org/pcap.html](https://www.tcpdump.org/pcap.html)

It abstracts all the hard work, gives you a handle that you can poll on, and
then handles giving you a stream of packets to process.

------
nemanjaboric
> Luckily it's easy enough to support IPv6: just replace AF_INET by AF_INET6
> and _it will work with both IPv4 and IPv6_! So don't you dare to ever use
> AF_INET anymore without a good excuse

(emphasis mine)

AFAIK, on many systems (think FreeBSD) this is not true:

[https://www.unix.com/man-page/FreeBSD/4/inet6/](https://www.unix.com/man-
page/FreeBSD/4/inet6/)

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

~~~
ChrisSD
I've consulted ip6(4) but I'm still unclear on exactly why they break with the
rfc here. Do you know where they detail the security implications?

~~~
segmondy

         >However, RFC2553 does not define the ordering constraint between calls to
         bind(2), nor how IPv4 TCP/UDP port	numbers	and IPv6 TCP/UDP port numbers
         relate to each other (should they be integrated or	separated).  Imple-
         mented behavior is	very different from kernel to kernel.  Therefore, it
         is	unwise to rely too much	upon the behavior of AF_INET6 wildcard bind
         sockets.  It is recommended to listen to two sockets, one for AF_INET and
         another for AF_INET6, when	you would like to accept both IPv4 and IPv6
         traffic.
    
         >It should also be noted that malicious parties can	take advantage of the
         complexity	presented above, and are able to bypass	access control,	if the
         target node routes	IPv4 traffic to	AF_INET6 socket.  Users	are advised to
         take care handling	connections from IPv4 mapped address to	AF_INET6 sock-
         ets.

------
lkrubner
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:

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

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.

~~~
jandrese
One use is if you need to replay captured traffic. Another is if you are doing
protocol development or WAN acceleration.

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

~~~
sigjuice
What are "optional network layers"? Do you have any examples? Thanks!

~~~
jzwinck
VLAN is a popular one.

~~~
peterwwillis
VLAN and MPLS are common, as well as .1P/.1Q and DSCP. Then you can find
hybrids like MPLS-VPN and S-VLAN, and then the tunneling protocols like GRE,
L2TP, VXLAN, DOVE, QinQ, OTV, NVGRE, PBB-TE, SPB, VLL, etc. And most of this
is just Ethernet, there are often similar standards for different L2s like
wireless networks.

------
stagbeetle
Some smart soul archived it:
[http://archive.is/nt67c](http://archive.is/nt67c)

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.

~~~
adrianratnapala
Didn't HTTP once have this cache thingy feature?

~~~
deathanatos
It does. But unless you have a CDN, caching is going to be per client. Since
I've now visited the site, I have it cached, but that doesn't help the next
unique visitor.

The site makes use of and respects cache headers, too. (And, I'll add, only
makes 1¹ request aside from the main HTML, for some CSS; the site is
refreshingly minimal, yet still looks nice.)

¹it also makes a request for MathJax, but that gets blocked b/c it's made over
HTTP, and the site is HTTPS.

------
ibotty
Aside: Can someone has any pointers on HIP? What it solves, who is behind it
(is there a chance to have it supported in mainstream OSs).

~~~
bewo001
HIP stands for Host Identity Protocol. The idea is to separate a host's
identity from its location. An IP address does both. It could be argued that
DNS already achieves the ID/locator split: The DNS name of your host
identifies it, the resolved IP address gives its current location.

~~~
nudin
Well DNS does not really split this because of the way TCP-connections are
defined: The are the pair of IP and Ports of both sides. So TCP-connections
are always between two locations not between two identities. That's the reason
why connections get lost when changing from one network to another.

Also updating DNS entries is to slow to do it whenever you walk with your
smartphone from one cell/wifi to another.

~~~
bewo001
You are right. I simply wanted to illustrate the idea of id/locator split. The
mapping of a fixed id to a quickly changing locator is a problem of all those
schemes.

------
majewsky
Just in case the author is reading this: I can literally not read the article
on my phone due to low contrast.

~~~
nudin
Author here: the normal text is basically black on white. Do you mean the
inline code parts? There contrast might be a bit to low, yes. I'm not happy in
general with it's formatting and will change it in the future. (It's the
default of the template I used) Thanks for the input!

~~~
chrisseaton
When you're picking colours you can use an online tool to test contrast
against accessibility standards.

Your inline code parts still meet the double A level of the accessibility
standard for contrast.

[http://leaverou.github.io/contrast-
ratio/#rgb%2882%2C89%2C93...](http://leaverou.github.io/contrast-
ratio/#rgb%2882%2C89%2C93%29-on-rgb%28249%2C249%2C249%29)

------
hacknat
Late to the convo, but I created a go library with no C dependencies that lets
you play with raw sockets on Linux:

[https://github.com/nathanjsweet/zsocket](https://github.com/nathanjsweet/zsocket)

------
encoderer
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?

~~~
jacbq6
Other serverless platforms like CoherenceApi.com block raw sockets too.

I think there's probably too many security issues like ARP poisoning.

~~~
bthornbury
Not to mention raw sockets bypass docker's default inter-container-
communication blocking.

[https://github.com/brthor/docker-
layer2-icc](https://github.com/brthor/docker-layer2-icc)

