> >>>>> "Guy" == Guy Harris <[EMAIL PROTECTED]> writes:
>     Guy> At this point, the two things I think should go into it before we do a
>     Guy> release are
> 
>     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?

I have that code working, and it should be ready to check in.

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

I have that working as well.

>     Guy> It Might Be Nice to have the BPF compiler generate code, for Token
> 
>   Perhaps someone with token ring hardware.

Actually, all that should be necessary is a token ring capture file, as
the filtering code can be tested in userland, and I have some of them.

However, it turns out that to generate correct code for arbitrary
expressions, you'd probably need to do some dataflow analysis in the
code generator or optimizer, as there are some expressions that could
require that, for example, the IP header be tested (requiring that the
length of the Token Ring header be in the X register), and that the TCP
header then be tested (requiring that the sum of the lengths of the
Token Ring and IP header be in the X register), and that the IP header
then be tested (requiring that you get the length of the Token Ring
header back).
-
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

Reply via email to