On Sat, Jul 17, 2004 at 04:34:13PM +0200, Ulf Lamping wrote:
> So I often do the following:
> - Start Ethereal, start a capture, start the test case, but get no input
> packets :-(
> - stop capturing, recognized that I've chosen the wrong interface,
> change interface, start capture again, restart test case, but still no
> input packets :-(
How do you determine what the right interface is?
I'd been thinking of a "Choose interface" dialog, one feature of which
would be that you could give it an IP address and it'd find the
interface corresponding to that address, if any (i.e., look for the
interface for which "interface address & interface mask" equals
"specified address & interface mask"). That might be something useful
to add.
> - recognize that the network cable not attached, ...
Hmm. Perhaps libpcap needs to return some of the status information you
can get from, for example, "ifconfig" - at least some interfaces can
report whether they have carrier (wired) or are associated with a
network (802.11, although if you're going to capture in monitor mode you
don't care whether it's associated). I don't know whether that could be
gotten on all platforms, but it's definitely available on FreeBSD 3.x
and later (and perhaps earlier), and OS X 10.3[.x] (and perhaps
earlier).
(Fortunately, there's already a flag field in the information you get
from "pcap_findalldevs()", which could hold that information;
unfortunately, in current versions of libpcap those flags aren't set,
and the only way to find out whether they're not set because the
interface has no carrier or because libpcap doesn't check whether it has
carrier would be to know which version of libpcap added it and use
"pcap_lib_version()".
I plan to add a new API, at some point, which returns interface
properties as an attribute/value list, so that it's easier to add new
properties; the absence of a property would mean it's not available.)
> So I started to implement a dialog box (window) showing the required
> informations, to clarify which interfaces are "living", meaning which
> interface currently receive packets.
>
> This dialog contains a list of:
>
> - the known interfaces: devicename (unix) *or* description (win32)
Actually, it was trying to display the description on UN*X. It should
check whether the description pointer is null (there *are* some UN*X
interfaces where it's non-null, and future versions of libpcap may try
harder to get descriptions for UN*X interfaces).
> - the currently received number of packets (both summarized from the
> starting of the dialog and of the last second gone)
Note that opening all the interfaces on the system for capturing could
consume significant amounts of CPU time and memory processing those
packets and buffering them up (even though we don't read them).
At least on systems using BPF (the BSDs and, by default, AIX), the
number of BPF devices limits the number of devices you can have open for
capturing. That limit might be small (4, on some systems), so
1) if you have a lot of interfaces, you'll get errors rather
than packet counts;
2) opening all the devices might prevent *other* applications
from being able to open devices for capturing or other
purposes (some daemons on BSD systems use BPF to implement
protocols running atop Ethernet, by reading packets with a
filter for those packets and sending packets by writing to
the BPF device);
so, although those counts might be nice, maintaining them might cause
problems.
> I've tested this on winXP and SuSE9.1 and it worked fine. As I'm using
> standard pcap features, this should work on all supported platforms.
"pcap_findalldevs()" isn't supported with older versions of
libpcap/WinPcap - it first appeared in libpcap 0.7 and WinPcap 3.0.
I've changed it so that it compiles on systems with older libpcaps *and*
gets interface IPv4 addresses from the SIOCGIFCONF list.