Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: RE: [Ethereal-dev] ERTSP: Ethereal's RemoTe Sniffing Protocol

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Fulvio Risso" <fulvio.risso@xxxxxxxxx>
Date: Wed, 16 Feb 2005 20:40:45 +0100

> -----Original Message-----
> From: ethereal-dev-bounces@xxxxxxxxxxxx
> [mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Lars Roland
> Sent: mercoledì 16 febbraio 2005 11.01
> To: Ethereal development
> Subject: Re: [Ethereal-dev] ERTSP: Ethereal's RemoTe Sniffing Protocol
>
>
> 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.

I'm completely open to suggestions for this.

	fulvio


> 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
> >
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev