Ethereal-dev: Re: [Ethereal-dev] Capture interface list dialog in menu "Capture/Interfaces..."
Guy Harris wrote:
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.
Well, that would be an interesting feature to add, I agree.
As we could get the netmask from the same mechanism as the IP address,
that could be done that way.
But how to handle the IP addresses outside of your "own networks",
meaning behind a router?
All interfaces might be appropriate as you don't know on which interface
a packet will come from.
I would fear this could be unreliable, but please try to convince me ;-)
However, as I'm usually working in my own "physical private network",
that would be usually no problem for myself.
- 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.)
Well, all that sounds reasonable to me.
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.
Correct.
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).
You've already done that, if I understand your changes correct, btw: thanks.
On Win32 machines (I know), the devicename is pretty useless (for the
user) and would only consume a lot of screen space.
On unix machines the interfaces devicename is (usually) small and
descriptive so it seem's reasonable to display both here.
- 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).
I fear it will do, but I still think it's an invualuable information. It
will not only tell you if the interfaces are alive,
but it will also tell what's going on in your network.
However: It might be a good idea to warn the user that this is the case:
"Warning: Keeping open this dialog might consume a significant amount of
CPU time and memory."
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 understand, but I don't see a good way to fix it.
At least the information from the preferences, about hiding not used
interfaces, should be taking into account when showing the dialog.
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.
Thanks for this!
Regards, ULFL
