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

[Andrew Brown <atatat () atatdot net>]

> > 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).

that seems fair.  oh, but i see that in order to dump the available
dlt values, it needs already to have an open bpf.  hmm...

> > (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.

tcpdump wouldn't.  in fact, users of tcpdump would probably never need
the flag.  sorry, i was a bit confused.  what is wanted is a way for a
"user" of libpcap to tell libpcap to open the bpf r/w so that it can
inject packets.  the simh simulator can use this to make the emulated
network interface work.

> > 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.

that seems reasonable.

> > 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.

bleah.

> 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).

that would probably help me, but i'm not sure the application would
like getting write errors on something it thought it could write to.
i'll check.

> > (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.

yes, the file being written with -w.

> 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.

there are situations where i wish to record the packet capture and
analyze it at the same time (in which case, the number of write()
calls isn't a concern).  for slow packet exchange, it can take a long
while before a buffer flushes and there are packets for me to look at.
this would certainly not be the default, but i would like to see it be
an option.

> 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.

okay...a patch to tcpdump without intruding into/breaking the libpcap
api is good.

> > (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.

i suppose i'll use -y.  y not?  lemme see if i can dig out my code...

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior () daemon org             * "ah!  i see you have the internet
twofsonet () graffiti com (Andrew Brown)                that goes *ping*!"
werdna () squooshy com       * "information is power -- share the wealth."
-
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