On 7/21/06, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
Hi there,
in BONE, the AF_LINK domain is registered by the "peeper" module. AFAICT, it's thought usage is for packet capturing only. As you can see in BONE's struct ifnet, there is a direct pointer to that peeper - and that's needed, because that peeper doesn't eat packets, and the AF_LINK domain is not a real domain that receives any packets. Since the datalink module is no longer a protocol module, we need some kind of protocol module that represents the AF_LINK domain.
It makes actually sense to have a "peeper" like functionality in there, though, since reading the socket can directly give you access to the link level buffer data (deframed, though).
Would you think it makes sense to have a link protocol that can also send and receive buffers at link level, though? In that case, a "link" protocol would just give you raw access to the link level, just like an IP socket would do. It would get any packet where there was no other handler for. However, you could still get the monitoring functionality when you start packet capturing on that socket.
Do you think that additional functionality makes sense? It would give you the possibility to implement home-brewn (or proprietary) protocols in userland, even though receiving data would be pretty inefficient with more than one link level socket at a time - unless we implement some additional filtering capabilities for that (which could more or less easily be done, too, if we want to).
Bye, Axel.
You mean something similar to Linux's PF_PACKET domain? I know of at least one program that uses PF_PACKET to send data - it sends Ethernet wake-on-lan magic packets. I don't know for sure, but I would imagine thats what tcpdump and the like use to capture incoming packets as well.
