[openbeosnetteam] Re: link level protocol
- From: "Andrew Galante" <haiku.galante@xxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Fri, 21 Jul 2006 10:41:46 -0400
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.
- References:
- [openbeosnetteam] link level protocol
- From: Axel Dörfler
Other related posts:
- » [openbeosnetteam] link level protocol
- » [openbeosnetteam] Re: link level protocol
- » [openbeosnetteam] Re: link level protocol
- » [openbeosnetteam] Re: link level protocol
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.
- [openbeosnetteam] link level protocol
- From: Axel Dörfler