Mike Kershaw wrote:
I have code which does this already for wireless (sending a modified pcap stream basically).
Wrapping it in SSL would be trivial (already on the list of stuff to support).
Moving this to pure pcap would also be trivial. This seems more application layer than pcap layer -- by the time you're talking about remote sniffing and shipping the data over a network, you're not talking about needing super-timestamping or many of the other stuff recently discussed.
...although having it in libpcap does mean that applications might, in theory, be able to capture remotely without having to be changed.
However, if authentication is required for remote capture - which I suspect a lot of sites would want - that might call for application changes anyway, unless some form of single sign-on, wherein an identity token of some sort obtained when you log in can also be used to authenticate yourself to a remote capture device, can be used.
There are a number of remote capture protocols already: RMON, the Tazmen Sniffer Protocol used by Network Chemistry's Neutrino Sensors, the protocol Microsoft uses in Network Monitor (I don't know whether anybody's reverse-engineered that or not), and the one that the WinPcap people are working on:
http://winpcap.polito.it/docs/man/html/group__remote__help.html
Libpcap should probably have a mechanism by which support for multiple protocols can be added, so that multiple such protocols, including yours (and presumably including "ssh to the remote machine and start up tcpdump with the capture going to the standard output"), could be supported.
There'd be a new API for opening captures; it'd include a mechanism for supplying information necessary for authenticating yourself with a remote capture device.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
