Re: rpcap support?

[Guy Harris <guy () alum mit edu>]

On Jul 9, 2011, at 7:43 PM, Michael Richardson wrote:

> Up until somewhat recently, pcap methods were basically decided at
> compile time based upon the OS that one was on.  There was little in the
> way of decisions in the code as to what was going to go on.
>
> We now have half-dozen methods on Linux (if you include pfring, etc.),
> I think two or three on Solaris, and now every system will grow the
> "remote" method.
>
> Can we make it a bit more oop-ish with a few more pointer to functions
> in pcap_t rather than if(p->rmt_clientside) everywhere?

Yes, that's how it should be done, especially given that we should not restrict ourselves to rpcap - one possible 
remote capture protocol is "run tcpdump over ssh", for example.

In addition, it should use the new pcap_create()/pcap_{modify various parameters}/pcap_activate() model, so that 
setting things such as credentials is done between pcap_create() and pcap_activate() (although in some cases you might 
not know what authentication information is needed until you try authenticating - consider ssh-based protocols, for 
example).

I'm working on a version of the remote capture stuff that works that way.

> It's also time for pcapng, which is supposed to be file format only.
> It would be nice if the wire protocol for remote pcap was in fact remote
> pcapng.
>
> The question is now:
>  is reading remote pcapng a job of *PCAP* (the library that acquires
>  packets from the network interface) 
>
>  or a job of pcapng (the library that reads/writes files to "storage")?

For historical reasons, the pcap library also supports reading from and writing to savefiles.  If we split them, with a 
new library supporting reading from and writing to savefiles, the new library should transparently support reading from 
pcap files as well as pcap-ng files (just as the pcap library now supports transparently reading from some pcap-ng 
files as well as from pcap files), and perhaps from other file formats as well (Sniffer formats, Microsoft Network 
Monitor, etc.; I have some code I did a long time ago to do that, although if we have a new library with a more 
pcap-ng-oriented API, it'd have to be changed to handle that).  It should perhaps support writing, at minimum, pcap 
(when possible) as well as pcap-ng, and perhaps some other formats as well.

(Unlike Wireshark's wiretap library, this library needs to support reading from pipes, so it might be restricted to 
capture file formats that have magic numbers early in the file.)

I'd say that the same APIs should be used for capturing from local and remote interfaces, so programs can take "en0" or 
"eth0" or "fxp0" or whatever as arguments to capture from a local device or "rpcap://example.com/en0" (at least until 
example.com has to replace their Xserves :-)) or "tcpdump+ssh://example.com/eth0" or... as arguments to capture from a 
remote device.

In addition, the capture APIs should probably expand to support stuff useful for pcap-ng; that will also add other 
capabilities, e.g. a pcap_stats() replacement that returns something like an Interface Statistics Block could omit 
statistics that aren't supported by the platform (rather than sticking bogus values into a fixed structure) and could 
add new statistics, and a pcap_findalldevs() replacement that returns, for each interface, something like an Interface 
Description Block could supply the link-layer address and other attributes not currently provided.

So perhaps there should still be one library for live capture (local and remote) and savefile reading and writing.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.