Ethereal-dev: Re: [Ethereal-dev] Capture interface list dialog in menu "Capture/Interfaces..."
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Ulf Lamping <[email protected]>
Date: Sun, 18 Jul 2004 11:11:46 +0200
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.
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.
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,- 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).
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
- Prev by Date: Re: [Ethereal-dev] packet-*.[ch] file movement imminent
- Next by Date: Re: [Ethereal-dev] packet-*.[ch] file movement imminent
- Previous by thread: Re: [Ethereal-dev] Capture interface list dialog in menu "Capture/Interfaces..."
- Next by thread: Re: [Ethereal-dev] Capture interface list dialog in menu "Capture/Interfaces..."
- Get Wireshark
- Code of Conduct