On Thu, Aug 29, 2002 at 02:14:03PM -0700, Gillick, John B wrote:
> I am writing a little program that directly calls bpf_filter() (that as you
> know is in bpf_filter.c of the libpcap)
> As you know also bpf_filter() wants you to give it:
> register struct bpf_insn, register u_char, u_int, register u_int
> I want/need to create fake packets of this nature to send into bpf_filter.
> But I find myself with a serious lack of understanding of what kinds of data
> would be acceptable to put in these four things before I send them to
> bpf_filter() to be "processed."
The type of data acceptable to put into the array of "struct bpf_insn *"
pointed to by the first argument to "bpf_filter()", is, well, a valid
BPF program. That's what "bpf_compile()" generates, for example.
The type of data acceptable to put into the array of "u_char" pointed to
by the second argument to "bpf_filter()", is, well, a raw network
packet, beginning with the appropriate link-layer type for the BPF
program you're running.
The type of data acceptable to supply as the third argument to
"bpf_filter()" is the number of bytes in packet, which might be *greater
than* the number of bytes in the array a pointer to which is passed as
the second argument if, for example, a program doing packet capture is
calling "bpf_filter()", and that program specified to "pcap_open_live()"
a snapshot length shorter than the maximum packet length on the network.
The type of data acceptable to supply as the fourth argument to
"bpf_filter()" is the number of bytes in the array a pointer to which
was passed as the second argument.
> I installed linux RH7.3pro, libpcap, and tcpdump. tcpdump is working in
> that it show some printout that I don't quite understand of packets that it
> read for the network (I'm not sure that's worded correctly). My goal was to
> get inside tcpdump somewhere that it has variables similar to the ones
> mentioned above (ex: when it has a call to bpf_filter(w,x,y,z) then
> obviously those four things are similar to the above mentioned variables
> (even though tcpdump (if I understand correctly) hardly ever uses that call
> to bpf_filter))
Tcpdump doesn't call "bpf_filter()" at all; it relies on libpcap to do
packet filtering.
Whether that packet filtering is done in user mode, with libpcap's
"bpf_filter()", or in the OS kernel depends on
1) whether you're doing a live capture or reading a saved
capture (if you're reading a saved capture, the filtering is
done in user mode, with libpcap's "bpf_filter()")
and
2) whether, if you're doing a live capture, the OS's packet
capture mechanism supports filtering with BPF programs (if it
doesn't, the filtering is done in user mode, with libpcap's
"bpf_filter()".)
> and print out their values, therefor getting a feel for the
> values those four things have (and the values of the individual parts of the
> struct that is the first one mentioned).
The individual parts of a "struct bpf_insn" are described in the USENIX
paper on BPF; a copy of that paper can be found at
http://www.tcpdump.org/papers/bpf-usenix93.pdf
A "struct bpf_insn" is an instruction for a pseudo-machine; the paper
explains that.
However, you can just use "bpf_compile()" to generate the program, given
a tcpdump-style filter expression, which would obviate the need to
understand the BPF pseudo-machine. (I don't have time to teach the
workings of the BPF pseudo-machine, and, besides, all I'd say on the
topic can be found in the USENIX paper.)
> One can you tell me about those four things so I can make my own sets of
> them?
See above.
> Two if you can't and you think it's not an unreasonable thing to try, can
> you tell me which methode of tcpdump I should add print statements too to
> look at the packet data when it's in the 4 part form mentioned above?
What "4 part form"?
If you're referring to the 4 arguments to "bpf_filter()":
the first argument is *NOT* packet data, it's a program, in a
pseudo-machine language, that is run to decide whether a packet
matches or doesn't match a filter expression;
the second argument points to the packet data;
the third argument indicates how long the packet really was on
the network;
the fourth argument indicates how much packet data was captured.
> (I ask because I've tried it in several tcpdump.c methodes and nothing
> happend so I'm not sure which methods are commonly used on the linux
> system.)
What do you mean by "methods"?
> Three if you think this is stupid do you have any suggestions on how I can
> genorate fake data in the form of those 4 above mentioned variables to
> "pump" into bpf_filter()?
Generating fake data for the first argument won't work, and makes no
sense whatsoever; it has to be a real program.
Generating fake data for the third and fourth arguments also makes no
sense; they have to match the size of the packet.
To generate fake packet data:
1) decide whether the data has to look more-or-less like a valid
packet or not;
2) if not, just fill up an array with bytes from some random
number generator function;
3) if so, read a bunch of protocol specs, starting with the spec
for some link-layer protocol (e.g., Ethernet), and the specs
for higher-layer protocols (e.g., IPv4 and ARP) and the specs
for how those protocols are encapsulated in lower-layer
protocols, and write code to fill in a packet that's valid
according to those specs. (I don't have time to provide any
help on that.)
-
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
