On Sun, Sep 09, 2001 at 01:24:10PM +0200, Frank Volf wrote:
> 1) I have no clue how to add support for filtering on the fields in my
> IP filter header. The fields provide additional information on the
> IP packet, such as:
> 1) was it an inbound or an outbound IP packet
There's already support for that in libpcap's grammar.
Unfortunately, it assumes that a packet is either inbound or outbound;
the ipfilter header, however, appears to have both
IPFILTER_DIRECTION_OUT and IPFILTER_DIRECTION_IN flags, so a frame could
conceivably be neither inbound nor outbound (if neither is set) or both
inbound and outbound (if both are set).
> 2) what was the action on the IP packet (passed, blocked, logged)
You'd have to, for example:
add keywords "passed", "blocked", and "logged" to "scanner.l"
(see the entries for "inbound" and "outbound");
add new tokens PASSED, BLOCKED, and LOGGED to "grammar.y"
(again, see INBOUND and OUTBOUND);
add rules to the grammar for those tokens (see INBOUND and
OUTBOUND; I'd add a "gen_ipfilter_action()" routine, and pass
it, say, 0 for PASSED, 1 for BLOCKED, and 2 for LOGGED);
add a routine to handle those actions.
> 3) on which filter rule was the packet matched
I'd add a token "rule" or something such as that (see above), add a
grammar rule such as
RULE NUM { $$ = gen_ipfilter_rule($2); }
and have "gen_ipfilter_rule()" generate code to compare the "ipf_rule"
field against the argument.
> 4) which interface was the packet captured on
That one's tricky - BPF doesn't include string-comparison operators, so
you'd have to compare the string 1, 2, or 4 bytes at a time.
Is that field guaranteed to be null-padded, i.e. is it guaranteed that
*all* the bytes after the last character of the interface name are '\0'?
If not, the comparison becomes more painful, as you'd have to stop
comparing when you found the '\0'.
For all of these, note that the BPF load instructions load *big-endian*
quantities, which means that
1) if the quantities in the link-layer pseudo-header are in host
byte order rather than in network byte order, you'd have to
do something similar to what's done for the protocol type for
DLT_NULL, and, if reading a savefile and it has a byte order
different from the byte order of the machine on which you're
running, byte-swap the values against which you're comparing
fields or with which you're bit-masking fields (see the code
that handles DLT_NULL and DLT_LOOP in "gen_linktype()" in
"gencode.c");
2) if you do string comparisons 4 bytes at a time (which is
probably preferable), you'd have to worry about whether the
machine on which you're running is big-endian or
little-endian, and construct the values against which to
compare the words of that field accordingly.
assume
> etc... How can I add support to this to tcpdump, especially the compiler?
If you add it to the compiler, you've added it to tcpdump (and all other
applications that use libpcap to filter those captures).
-
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
