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:[EMAIL PROTECTED]?body=unsubscribe
