> 1) How can I prevent copies of certain packets (for example, those
> that satisfy libpcap's capture filter) from being forwarded to and
> processed by the kernel's protocol stack?
You can't do that with libpcap. Think of "libpcap" as being "open()"
and "read()" for raw network devices; that's all it is, it doesn't
affect what gets fed to the kernel's protocol stack. (Actually, it's
more like "fopen()" and "fread()", in that it's a library that sits atop
the raw system call layer.)
> I want to process incoming TCP
> segments on a given port myself using libpcap with no interference from
> the kernel; for example, if a SYN segment is received, I want to build
> and send the SYN ACK reply (including headers) myself without the
> kernel's TCP generating its own SYN ACK. However, I don't want to
> process any other ports and protocols myself so these should be handled
> normally by the kernel. Is there a way to do this using libpcap?
No.
There *might* be some way to do that with the aid of some other kernel
mechanisms, but libpcap (and the underlying OS packet capture mechanisms
it uses) can't do that.
There might be some "packet filtering" mechanism in your OS, or some
mechanism that could be added on to your OS, that does that, e.g.
ipfilter or ipchains - or whatever the latest filtering mechanism for
Linux is called - but I know relatively little about them and can't say
whether they'd let you do that or not (or what mechanisms are available,
or where to find information about them).
> The Raw IP Networking FAQ suggests using firewall software to block
> the desired TCP port(s), which would prevent the kernel from processing
> the incoming TCP segments, but wouldn't this also prevent libpcap from
> getting the segments?
It might.
Libpcap gets packets from networking code in the kernel, so if the
filter prevents the packets from even getting to the part of the
networking code that would hand the packets to libpcap, libpcap won't
see them either.
If the filtering mechanism is in the OS on your machine (rather than in
a separate firewall box, *and* if it discards packets *after* they get
to the part of the networking code that would hand them to libpcap but
*before* they get to TCP, that'd work.
I don't know what firewall software is available, or where it would
filter out the packets, so I can't help you any further on that.
> 2) What exactly is the difference between pcap_disaptch() and
> pcap_loop()?
"pcap_dispatch()", when reading from a raw network device rather than a
savefile, processes only as many packets as libpcap gets from the kernel
in one operation, i.e. one bufferful of packets.
"pcap_loop()" keeps reading until an error occurs (or until it's
interrupted by a signal, e.g. typing control-C to tcpdump) or until the
count runs out.
> The man page is unclear about this: it states that for
> pcap_dispatch(), "a cnt of 0 processes all packets until [...] the read
> times out (when doing live reads and a non-zero read timeout is
> specified)". This implies that if a zero read timeout _is_ specified in
> the call to pcap_open_live(), pcap_dispatch() won't stop for timeouts,
> so does pcap_dispatch() with timeout=0 work the same as pcap_loop()?
The current CVS version of the man page says
pcap_dispatch() is used to collect and process packets. cnt
specifies the maximum number of packets to process before
returning. This is not a minimum number; when reading a
live capture, only one bufferful of packets is read at a
time, so fewer than cnt packets may be processed. A cnt of
-1 processes all the packets received in one buffer when
reading a live capture, or all the packets in the file when
reading a ``savefile''. callback specifies a routine to be
called with three arguments: a u_char pointer which is
passed in from pcap_dispatch(), a pointer to the pcap_pkthdr
struct (which precede the actual network headers and data),
and a u_char pointer to the packet data.
The number of packets read is returned. 0 is returned if no
packets were read from a live capture (if, for example, they
were discarded because they didn't pass the packet filter,
or if, on platforms that support a read timeout that starts
before any packets arrive, the timeout expires before any
packets arrive, or if the file descriptor for the capture
device is in non-blocking mode and no packets were available
to be read) or if no more packets are available in a ``save-
file.'' A return of -1 indicates an error in which case
pcap_perror() or pcap_geterr() may be used to display the
error text.
NOTE: when reading a live capture, pcap_dispatch() will not
necessarily return when the read times out; on some plat-
forms, the read timeout isn't supported, and, on other plat-
forms, the timer doesn't start until at least one packet
arrives. This means that the read timeout should NOT be
used in, for example, an interactive application, to allow
the packet capture loop to ``poll'' for user input periodi-
cally, as there's no guarantee that pcap_dispatch() will
return after the timeout expires.
pcap_loop() is similar to pcap_dispatch() except it keeps
reading packets until cnt packets are processed or an error
occurs. It does not return when live read timeouts occur.
Rather, specifying a non-zero read timeout to
pcap_open_live() and then calling pcap_dispatch() allows the
reception and processing of any packets that arrive when the
timeout occurs. A negative cnt causes pcap_loop() to loop
forever (or at least until an error occurs).
which is more accurate.
> 3) When pcap_lookupdev() is called with more than 1 network adapter
> installed in the host computer, which one is returned?
The one with the lowest unit number of the interfaces that are up, have
IP addresses asigned to them, and that aren't loopback devices.
-
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
