The place to put this functionality is to put it inside libpcap and
winpcap. not in ethereal.
This requires analysis and definition of a capture url format
authentication and authorization.
While there are prototype implementations of such a protocol in
winpcap it can not be used in real world environments unless you find
it acceptable that anyone in the entire world being able to capture
from your box.
(
And since people will comment that it does work : NO an mds
fibrechannel/iscsi-gateway switch sitting on a private network in a
large datacentre is NOT representative for how to define a security
model. All three mds switches in my lab work just fine with this
protocol but i STILL consider it impossible to use in real world
networks.
)
Your task consists of :
1, analyzing the problem space for real applications, in particular
security, authentication and authorization.
2, talk to libpcap and winpcap folks to come up with a solution that
is secure, usable and acceptable to both camps.
(neither of the camps are particularly willing to spend much time to
do this work for you. You have to do it)
3, implement and document the solution.
I would be willing to contribute to defining the protocol used and
documenting it, maybe in an RFC. Contact me off-list if you want to
go that path, but there will be a lot of work involved.
On Thu, 31 Mar 2005 23:36:55 +0200, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> Pilz Rene <rene.pilz@xxxxxx> schrieb am 31.03.05 16:16:23:
> >
> > Hi
> >
> > At the moment I am thinking to implement a capture device, which is
> > remotely able to trace the data. This should enable one to take a look
> > at the data from a capture-bot at a central office.
> >
> > I thought, that this should be added in the capture dialog as an
> > additional device, so that a person can online look which packets passes
> by.
> >
> > As I already looked at the source code, I got some idea how does the
> > code might look like. But still I will need some time to understand the
> > relations beween the parts.
> >
> > As I have seen in the development-list you have already worked in this
> > area of the code. Therefore it would be nice, when you can tell me your
> > thoughts.
> >
>
> Hi Rene!
>
> Discussions about such features should not be done privately, so I'll CC my
> mail on to the list.
>
> Yes, I was doing a major redesign of the capture engine code, as this was
> simply a mess before.
>
> As my main notebook is currently in repair, I won't continue this work in
> the next days until my notebook is back.
>
>
> To your question:
>
> Adding different capture devices were discussed on the list already before.
>
> Some people will argue, that features like this should be added to
> libpcap/Winpcap, so all programs using these libs can use the feature.
>
> I tend to agree with them, as having a lot of different capturing devices in
> Ethereal with different API's might not be the thing I like to see :-)
>
> Please note that WinPcap has already a built in remote capture feature. I
> didn't used it, so I can't tell you how well it's going.
>
> Regards, ULFL
>
> __________________________________________________________
> Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
> weltweit telefonieren! http://freephone.web.de/?mc=021201
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
