undefined | Better HN

0 pointstptacek2y ago0 comments

Acting like the whole networking stack doesn't exist is the whole purpose of packet sockets, because sometimes you want to override the things the networking stack does.

You need privileges to open a raw socket (or a packet socket, or anything else that would let you program at the IP layer) because otherwise unprivileged processes could hijack traffic for other applications on the system.

0 comments

3 comments · 1 top-level

zamadatix2y ago· 2 in thread

Packet sockets as-is are a great option if that's your use case but if I just want to bind to ethertype 0x88CC I shouldn't need to ask for the same permissions I can use to bind to 0x0800 or to capture all traffic. Sure, that's how things like AF_PACKET are implemented but there is nothing about being lower level that requires this all or nothing game of read/write-full-access-to-all-packets-ignoring-the-rest-of-the-os-stack-state vs bind-a-single-TCP/UDP-port. Just look at the way shared binds and privileged ports are handled for TCP, there is no reason the same concepts couldn't be applied to lower layers for more granularity.

All of that aside, none of this would explain why I need to write a custom network driver in Windows to send more than a couple predefined ethertypes from user space at all or why, in Linux, the network filter layer can't apply to any family used in the sendto() syscall instead of just sendto() calls with AF_INET set. These kinds of decisions aren't rooted in a limited scope of what packet sockets can be for or how they must interact with the rest of the network stack, it's just how they are currently built and exposed. This is great if your use case is to ignore the OS stack, but that doesn't mean doing so is the only conceivable way of packet sockets being built.

If BPF were treated slightly differently in terms of how/when certain abilities were exposed it could be a great answer to all of this. As of right now, it's just a better way to ignore the OS network stack even more than normal though.

tptacekOP2y ago

I think your problem isn't so much packet sockets or BPF, but how bad direct socket support is for things like ICMP or DHCP or ARP.

zamadatix2y ago

What is a "direct" socket in this context? If it's something that gives me a restricted packet socket context from a user space context then sure, call it what you'd like as long as it does that. If it's not that then I'm not sure it really helps. E.g. my last problem was with implementing 802.1Qcj draft extensions in a cross platform daemon, so some predefined concept about how to send/receive anything more than that EtherType with custom payloads doesn't really help (particularly if it lets other things bind to that EtherType at the same time, as LLDP is a "what the last packet said" protocol).

It's a similar story in the ARP use case you mention when maybe you want to e.g. anonymously probe if a VIP is actively in use by using a 0.0.0.0 source (useful for redundant responder setups). DHCP and ICMP I could see the case for similar improvements to the RAW IP sockets (AF_INET in Linux) type as packet sockets (e.g. ability to request and permit limited scope sockets or the other enhancements mentioned above). Just that is still too limited though as the world has more than IP protocols, e.g. AF_INET gets you OSPF but not ISIS.

The idea that "no, you can't possibly mean you'd like to send Ethernet packets while still caring about what the rest of the OS network stack is doing as if you mean to just extend it instead of take its place" is precisely the issue I've found myself annoyed with. No, I don't want to use DPDK to make a custom IP forwarding stack, I just want to be registered as the app to send and receive a certain EtherType without saying I want full rights to all packets.

1 more reply

j / k navigate · click thread line to collapse