I've had recently a look at the rpcap documentation. It looks like it
can authenticate requests using a login and a password. However,
ethereal doesn't support this authentication scheme. We would have to
rewrite the windows version of ethereal's capture dialog, using
winpcap's new api. It would be good, if the libpcap and winpcap
developers could agree on a common api for this.
Regarding Luis' idea of using display filters on the remote site,
perhaps tethereal can be used for that. Can tethereal write the captured
file to a pipe? Then a perl script running on the remote host (the ERTSP
server) could take the capture file from tethereal and send it to the
local client.
ronnie sahlberg schrieb:
i belive rpcap takes a pcap style capture filter which it applies
locally before transmitting all packets that passes across to the
capture client.
problem is that rpcap is totally insecure and can not be used in any
production environments for that reason.
adding an authentication phase with some simple mechanism such as chap
should not be too difficult.
On Mon, 14 Feb 2005 18:27:51 +0100, LEGO <luis.ontanon@xxxxxxxxx> wrote:
Again, my intention is not just to remotize the capture process, it is
to create intelligent probes.
Probes that might be able even to filter transactions (for example using MATE).
I think in telephony (my field) where I could put few different probes
arround the network and be able to trace a sigle call's signalling
without transporting more frames than necessary.
On Mon, 14 Feb 2005 17:46:16 +0100, Gianluca Varenni <varenni@xxxxxxxxx> wrote:
Hi.
What about the remote capture features of WinPcap? WinPcap is able to
capture from remote machines, and the code for the remote capture runs on
windows and Linux (I'm not sure about BSD).
More details can be found here
http://winpcap.polito.it/docs/man/html/group__remote__help.html
Have a nice day
GV
----- Original Message -----
From: "John McDermott" <jjm@xxxxxxxxxx>
To: "LEGO" <luis.ontanon@xxxxxxxxx>
Cc: <jjm@xxxxxxxxxx>; "Ethereal development" <ethereal-dev@xxxxxxxxxxxx>
Sent: Monday, February 14, 2005 5:25 PM
Subject: Re: [Ethereal-dev] ERTSP: Ethereal's RemoTe Sniffing Protocol
The Idea is a protocol to have sniffing clients and a sniffing servers
communicate. Part like RTSP, and part like RTP+RTCP with
retransmissions.
This sounds really cool and well thought out. Maybe I'm missing
something, though. What about RMON? Yes, it has another filtering
language and yes, it is not "real time" in the sense that Ethereal is,
but
mightn't it be an appropriate solution? Then, Ethereal could
inter-operate with existing probes and so forth.
The point is to be able to use display filters on the remote probe
before packets are transmitted.
Well, RMON does that, but it uses its own filtering language, and if we
want true Ethereal display filters, then, of course RMON is out (unless we
were to create a private filter MIB, I suppose...). I just thought
interoperability might be useful. I'm not convinced RMON is better than
your proposal, BTW, I just wanted to offer the thought.
We discussed this in 1999/2000 so you might want to check the archives for
that discussion, too.
--john
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
