>
> We also use the Distributed Sniffer and I have considered the
> client/server model for Ethereal. I have toyed with the design of such
> a system but I haven't gotten much beyond that.
>
> Currently you can impliment a master/slave environment using tunnels
> and pipes. It's not an elegant solution nor something I would want to
> do over a small WAN connection, but it does work.
>
Yah. Not quite usable for this corporate environment... they'd rather
pay for Sniffer Distributed, hehe.
> I'm more interested in a more complete client/server model. It should
> include:
>
> 1) User authentication
>
> A flexible model including local (on server) authentication or
> external authentication server.
>
> 2) Data encryption
>
> The client/server communications must support encryption. In
> addition non-encrypted traffic should be an option.
I need some help here... not exactly sure how to implement the
encryption. Any ideas?
>
> 3) Client/Server Traffic
>
> The traffic should be kept to a minimum for usage over small
> WAN connections. This should include filters based upon the
> the current display filter options. In addition the server
> should store a transfer flag for each packet. This flag would
> be set when the contents of the data packet has been sent to
> the client.
>
> In addition the client should be able to request truncated
> packets from server I.E. request the first 64 bytes from each
> captured packet.
>
> 4) Filters
>
> The client should be able to set capture and display filters
> on the server.
>
When you start a capture in ethereal and the "capture options" window
pops up, if we could simply enter an IP instead of a device then
"connect" with the options and/or filters specified in the "capture
options" window then we would not need to re-develop some of the
interface, but transfer the options to the server.
The filters could be defined in this initial "capture options" window as
they are already done. As for defining filters on the live data, or
data already sent across the wire, I believe we can still use what is
already implemented.
>
> Other long term goals -
>
>
> Multiple client connections on a server.
> Multiple server connections from a client.
>
Definitely would be nice to have and almost necessary to have.
Some soft of "hosts" list that could be saved would be ideal.
Mainly, I think that a version of ethereal that sent the capture_file
structure to the client, then allowed for the same functions to be
re-used on the client side would possibly work....Just some ideas.
-Donnie
http://www.darthik.com
>
> I think the client could be created by modifing the capture dialog to
> support connecting to the remote unit, then create a wiretap
> package(?) to support reading from the remote unit. The server would
> be a modified tethereal with a section of code added to handle
> communications from the client.
>
>
>
>
>> From: donnie@xxxxxxxxxxx [mailto:donnie@xxxxxxxxxxx]
>> Sent: Friday, January 09, 2004 8:46 AM
>>
>> I just joined this list, and I would like to help with the
>> development of ethereal. I work for a very large corporation, and
>> for our
>> network, we like to put in place sniffers to check certain
>> connections. We currently use Sniffer Distributed as our sniffer
>> software. The main ability of that software that we like is how it
>> can be used as a client/server. Thus allowing for us to place a
>> sniffer on remote locations then connect to that sniffer and analyze
>> the packets.
>>
>> I was wondering, if anyone would be interested in helping to
>> implement this type of client/server model for ethereal? I am not
>> extremely familiar with the code for ethereal, but I would be willing
>> to help as much as I can.
>>
>> Thanks,
>>
>> Donnie
>
>
>
>
> ***
> The information in this email is confidential and intended solely for
> the individual or entity to whom it is addressed. If you have received
> this email in error please notify the sender by return e-mail, delete
> this email, and refrain from any disclosure or action based on the
> information. ****
