Re: Fw: [WinPcap-users] Winpcap/JPcap crashing Java

[Guy Harris <guy () netapp com>]

On Fri, Oct 25, 2002 at 11:28:36AM +0200, Loris Degioanni wrote:
> I forward this mail to the tcpdump-workers list because I think that the
> problem is not winpcap-specific. Actually, pcap_loop (and pcap_read?) don't
> check the validity of the adapter while they are running, therefore problems
> like the ones you describe happen if someone closes it asynchronously.
> Should we adopt some solution for this?

Closing items asynchronously, whether they're pcap_t's or not, is often a
bit of a Bad Idea - especially if the item is then *freed*, as is the
case with a pcap_t that's been closed.  Freeing the item might cause it
to be added to a free list, which might overwrite some data in the
object, possibly causing Bad Things to happen.

Checking the validity of the adapter, in a live capture, isn't an issue
on UNIX - the adapter is referred to by a file descriptor, and that
descriptor is closed by "pcap_close()", so the attempt to read from the
adapter will just get an EBADF error, rather than crashing.

However, as noted above, there are other items that can be invalidated
by freeing the data structure, and there's no simple check for that - if
some free list pointer overwrites some field, or if the "fd" field
happens to get a small integer that's a valid file descriptor written to
it, you're out of luck.

So I don't think the problem can be solved by validity checks, although
the validity check in the Win32 "pcap_read()" might be a good idea
anyway.

Presumably the other thread really wants to terminate the capture,
causing "pcap_loop()" to exit (it'd be silly to continue in
"pcap_loop()" with a closed pcap_t); unfortunately, there's no "break
out of the loop" call in libpcap.

Such a call would be useful elsewhere, e.g. in signal handlers in UNIX
(which act somewhat like interrupts, so you're not supposed to perform
arbitrary function calls, as they might reference a data
structure that's in the middle of being modified or modify a data
structure in the middle of being referenced), and to break out of the
"pcap_read()" loop (which, on some platforms, ignores the "system call
was interrupted" error return for reasons having something to do with
the debugging mechanisms, as per the "Don't choke when we get ptraced"
commnet in "pcap-bpf.c", "pcap-dlpi.c", and "pcap-snoop.c").

That call would set a flag in the pcap_t, which would be checked by
"pcap_read()" (causing it to break out of the loop *even if the read
operation got an EINTR error*, and even if it's still in the middle of
processing packets in the buffer), "pcap_offline_read()" (causing it to
break out of the loop immediately), and "pcap_loop()" (causing it to
break out of the loop immediately), and then clear the flag (so that you
can go back and start reading again).
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe