Re: Suggestion: Pcap-over-IP client support in

[Francois Goudal <francois () goudal net>]

Le 14/09/11 08:16, Erik Hjelmvik a écrit :
> The reason for why it would be great to have in tcpdump is because
> tcpdump is an ubiquitous tool that is available practically everywere.
> Besides, there's nothing that would prevent tcpdump from being at the
> receiving end of a "Pcap-over-IP" TCP socket.
>
> However, I fully understand if you feel implementing a TCP listener or
> TCP client in tcpdump would be a digression from the intended
> functionality of tcpdump.
Hi,

I just wanted to say that I disagree with that fact. tcpdump is a tool 
which is available practically everywhere, true. So is ssh, and ssh will 
let you pipe a stream to a remote computer.
The usual philosophy in Unix is that a tool does one thing, and does it 
well, and if you want to do fancy things, then you can combine several 
tools.

Here is the perfect example of such a combination. You capture frames 
with tcpdump, and you send them live with ssh. Tcpdump can output the 
pcap stream on its standard output, and this has not been made for 
humans, since a pcap binary stream is not something a human can read. So 
if this feature is there, it must have an interest, like for example, 
being able to pipe it to another tool, such as ssh.
So the remote feature you are seeking is actually already there, it's 
just not 100% built-in, but tcpdump's goal is to capture frames, not to 
send them over the network, while ssh purpose is to establish a secure 
data stream over a network.

Netcat (nc) is not always installed on a computer, but it's very rare 
ssh is not installed. It may be too much because it doesn't only streams 
over tcp, but also ciphers, but it works well.

Implementing a TCP sender in tcpdump might look easy at a first glance, 
but it's first of all reinventing the wheel since there are already ways 
to get the same result, also it's more source code to maintain, and 
which has nothing to do with the purpose of tcpdump which is capturing 
frames to a pcap stream, and it may also be a source of bugs, crashes, 
security issues, etc... and I think the tcpdump developers should focus 
on what they are good at while some other devs can build powerful and 
secure tools to stream over a network.

That's just my point of view, but I think that's how Unix tools have 
been designed so far, and I think it's great, and I don't see any 
advantage in getting away from that model, especially when computers 
nowadays have no problems in running 2 processes to perform a task, 
instead of doing it all in one. (and it may even be better to do it this 
way since the industry has moved to multi-core architectures, so 2 
processes would be more efficient than one single-threaded process).

You can take a look at this page, if you want to do what I described 
(pipe tcpdump to ssh) :
http://www.looke.ch/wp/monitoring-a-remote-network-interface-with-tcpdump-and-wireshark

Best regards

-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.