Re: New APIs to support multiple DLT_'s on an interface

[Guy Harris <guy () netapp com>]

On Thu, Dec 12, 2002 at 10:50:14AM -0500, Andrew Brown wrote:
> since netbsd's -D and -L seem instrinsically related, yet the official
> tcpdump -D doesn't seem that far off, and since the netbsd change is
> rather recent, how about merging/switching the two functionalities?
> this would mean that -D would give me (for example):
>
>       % tcpdump -D
>       1.lo0   NULL
>       8.ep0   EN10MB
>       9.wi0   EN10MB IEEE802_11

Yes, that might be a good idea, although that doesn't offer an option to
display just the link-layer types for one particular interface - I guess
we could allow "-i" and "-D" to be used together, and have that display
the link-layer types for the interface specified with "-i" (and maybe
leave out the interface number if that's done).

> i usually end up writing a small program to do just that.  i've
> encountered enough systems that don't have ifconfig -a to get upset
> enough to write such a program.

So far, the only ones I've dealt with are HP-UX (it's time SRCM finally
got around to fixing that, given that their *other* UNIX *does* support
"ifconfig -a":

        hostname$ uname -sr 
        OSF1 V4.0
        hostname$ ifconfig -a
        alt0: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,SIMPLEX>
             inet XXX.XXX.XXX.XXX netmask XXXXXXXX broadcast XXX.XXX.XXX.XXX ipmtu 1500

        alt1: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,SIMPLEX>
             inet XXX.XXX.XXX.XXX netmask XXXXXXXX broadcast XXX.XXX.XXX.XXX ipmtu 1500 

                ...

) and Windows (which doesn't have "ifconfig", much less "ifconfig -a" -
NT 4.0, as I remember, shows the interface name, but NT
5.0^H^H^H^H^H^HWindows 2000 doesn't, but the names in NT 5.x are ugly
strings containing GUIDs so maybe that was considered uninteresting).

> that's a shame.  especially since i'd like to burn...three of those.
> somehow.  here's my "plan".  you tell me if you hate it.
>
> (1) use -W to indicate "open the underlying network tap device in
> read/write mode".

Why would tcpdump do that?  It doesn't transmit packets.

> jason thorpe has done a bit of this to the netbsd
> copy of the libpcap code, but only insofar as the bpf unconditionally
> gets opened read/write.  his reasoning:
>
>       Open the BPF file descriptor as read-write.  Some pcap-using
>       programs (notably, simulators) expect to be able to send
>       packets on the descriptor, as well as receive.
>
> but that sucks for me, since i like to give special purpose accounts
> read-only access to the bpf so that they can monitor, but not write to
> the network.

You are correct - I would not advocate having libpcap open BPF devices
read-write by default, for that very reason.  I guess it could try
opening each device read-write and, if that fails with EACCES, try
opening it read-only.

> being able to tell pcap_open_live() to use read-only or
> read/write would be a big win (i get what i want and jason gets what
> he wants), and i think i can see how to do it.  pcap_open_live() has a
> promisc argument that could be "altered" to be flags.  promisc could
> then become 0x01 and read/write could be 0x02.  etc.

Unfortunately, as the man page only speaks of "promisc" specifying if
the interface is to be put in promiscuous mode, I don't think we can
assume that applications using promiscuous mode will necessarily pass 1
as the value meaning "promiscuous" - most of them probably do, but I
wouldn't count on all of them doing so.

My inclination would be to do the "try read-write and, if that fails
with EACCESS, try read-only" - that might not do the right thing if some
BPF devices are read-write by the user trying to open them and some are
read-only, but all the BPF devices should, if accessible by a user at
all, be accessible with the same permissions (I guess somebody might
want to make some of them accessible only be root to reserve them for
use by root).

> (2) use -U to tell tcpdump to write the dump to the output file in an
> unbuffered manner.  packets that dribble in take a long time to fill
> the stdio buffer and get flushed to the file.  this can be incredibly
> annoying, especially if you're impatient.

Are you talking about a file being written to with "-w"?  If tcpdump is
just printing text, "-l" makes the output line-buffered.

For a file being written to with "-w", you probably don't want
unbuffered output, you probably just want the output written out before
tcpdump blocks again - that'd do fewer "write()"/"WriteFile()" calls,
and be more efficient.

That could be done by adding a "pcap_dump_flush()" call, to force the
stdio buffer to be flushed, and have tcpdump's main loop be a loop using
"pcap_dispatch()" rather than just being "pcap_loop()", and have it do
the "pcap_dump_flush()" call after "pcap_dispatch()" returns.

> (3) use another letter (there aren't any really good mnemonics left
> off the top of my head, so i'm open to suggestions) to tell tcpdump to
> dump the link layer data as well when using -x or -X.  when printing
> ip datagrams using -X (or -x), the link layer stuff is skipped.  call
> me crazy, but i'd like to be able to see that somewhere.  i initially
> used -L for this (to indicate link layer), but that got used by
> someone else because i was lazy.  -E was already gone at that point.

Yes, that'd be useful.
-
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