On Sun, Aug 05, 2001 at 03:50:55AM -0400, Scott Gifford wrote:
> The structure used to store the interface looks like this:
>
> struct pcap_inet_if {
> #ifdef IF_NAMESIZE
> char name[IF_NAMESIZE+1];
> #else
> char name[sizeof(unused_ifreq->ifr_name)+1];
> #endif
> u_int instance;
> struct sockaddr *addr, *netmask;
> u_int is_up, is_loopback;
> };
>
> name is the interface name (as used elsewhere in libpcap), instance is
> the instance number (IE, 0 for "eth0", 1 for "eth1"),
Note that, on NT 5.0^H^H^H^H^H^HWindows 2000, interfaces have Really
Ugly Names that don't consist of a name and an instance number (unlike
NT 4.0, where they have UNIX-style names, except that they're 1-origin
rather than 0-origin). I don't know what Windows OT (95, 98, ME) does.
I'd like WinPcap to pick up this interface, so that applications can get
a list of interfaces in the same way on both platforms.
The "instance" member isn't used by your modified libpcap; I'd be
inclined to let applications extract it from the name, if they really
want it, rather than having libpcap supply it.
In addition, I might be tempted to add a "description" field, which I'd
make a "char *", and set either to null or to a pointer to a
"malloc()"ed string. On Windows, a description of the type of interface
is available, and people have asked for that information in Ethereal
(because, at least on W2K, the interface name doesn't tell you
anything). On UNIX systems, we could just make it null for now.
> for the class of an address and netmask are stored in addr and netmask,
What about interfaces with multiple addresses? I might be inclined to
supply a list of addresses - or, at minimum, the first IPv4 address/mask
and the first IPv6 address/mask - for the benefit of programs that might
want to supply them in a dialog box for selecting interfaces (most of
the time, when I'm on a multi-homed machine, neither the interface name
nor the interface description tells me what I need in order to know
which interface to choose; I need to know the networks the interfaces
are on, so that I know which interface to use to capture traffic on a
particular network).
> and is_up and is_loopback are boolean values indicating whether the
> interface is up and is a loopback interface, respectively.
Is there any reason to bother listing interfaces that aren't up? If an
interface isn't up, I don't think any traffic will show up on it, so I'm
not sure there'd be any point to capture traffic on it.
I might also be inclined to skip interfaces that can't be opened with
"pcap_open_live()", as you can't capture on them.
You might also want to sort loopback interfaces so that they appear at
the end of the list, rather than explicitly flagging them.
"pcap_lookupdev()" wouldn't bother checking for loopback interfaces, as
it'd only pick one if no non-loopback interfaces existed.
-
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
