On Wed, Dec 20, 2000 at 05:41:33PM -0500, Michael Richardson wrote:
> >>>>> "Guy" == Guy Harris <[EMAIL PROTECTED]> writes:
> Guy> 1) a new DLT_LINUX_COOKED (or whatever) link-layer type, for use
> Guy> when using PF_PACKET/SOCK_DGRAM rather than
> Guy> PF_PACKET/SOCK_RAW - it'd provide a link-layer header that
> Guy> includes an Ethernet type and, perhaps the one link-layer
> Guy> address you get, plus a flag indicating whether it's the
> Guy> sender or recipient link-layer address (the flag should *NOT*
> Guy> be a #define from a Linux header - the code to handle it
> Guy> should compile and run on non-Linux systems, so that captures
> Guy> done on Linux systems can be read on non-Linux systems);
>
> At this point, where are we with this?
> Is there another volunteer to attempt to work on the BPF code for this?
I've just checked that in and slipped the tags.
> Guy> so the BPF code run in userland would be different from the BPF code
> Guy> handed to the kernel.
>
> Ick. Anyway that this might change in the kernel at some point?
I suspect not - the problem is, at least as I understand it, that
the offsets in BPF instructions are relative to the beginning of
the packet as it'll be handed up to userland;
if you're reading from a SOCK_DGRAM socket, the link-layer
header doesn't go up to userland.
In addition, the filter needs to act on a "standardized" link-layer
header, as if the PF_PACKET/SOCK_DGRAM socket isn't bound to a
particular interface, different packets arriving on that socket may have
different link-layer headers.
> Guy> This might have to be done by, for example, generating BPF code under
> Guy> the assumption that it's intended for userland, and fixing it up before
> Guy> handing it to the kernel; as the attempt to hand it to may fail if, for
> Guy> example, socket filters aren't supported by the kernel, either a copy
> Guy> would have to be made of the filter and that copy fixed up, or the
> Guy> fixed-up copy would have to be unfixed if the attempt to hand it to the
> Guy> kernel failed.
>
> This is an interesting way to do it.
> Again, any volunteers?
Also checked in, and the tags slipped.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
