Ethereal-dev: [Ethereal-dev] Re: capture IF tcp

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

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Pilz Rene <rene.pilz@xxxxxx>
Date: Fri, 01 Apr 2005 16:35:22 +0200
From the logical point of view it makes sense to put this functionality into libpcap. But in the next step it would be necessary to change the format aswell, because it is too weak. Something like ERF 
is already better, but still not there where I want to be.
So I ask myself if it is still a good place to put it.

ronnie sahlberg wrote:


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.
This is of course a very important issue. There I would ask myself if there is already something existing 
which can be used. Can the openssl library do it for me?


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.
)
I don't want to have a lengthy process to develop the stuff. This means only that I don't want to run 
into length discussions due to too many partipiants.



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)
I do not expect anything. For me the situations is quiet simple. If the work to maintain the code is less, when it I put it into the commuity, then I will do it. Otherwise I will send it 
only to these once, which request 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.
From my point of view, the protocol itself should be specified in every detail anyway. The question there is, where you are doing a overkill and which features are really required.
If the outcome should be a RFC, then development process will be done in parallel. I need this feature wihin the next 2-3 months. This simply means, that I have to hurry up anyway. 

Regrads

Rene



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






--
Dipl-Ing (FH) MSc. C.E René Pilz
ftw. Telekommunications Research Center Vienna http://www.ftw.at
Tech Gate Vienna, Donaucitystraße 1, A-1220 Wien
Mobile: +43 664 8269871 Office: +43 1 5052830-13  Fax: +43 1 5052830-99