Wireshark · Ethereal-dev: Re: [ethereal-dev] What should be in version 1.0?

[Laurent Deniel <deniel@xxxxxxxxxxx>]

Gerald Combs - Unicom Communications wrote:
> 
>   I'd also like to give a quick update on the CVS situation.  I intended
> to read up on the CVS documentation this weekend, but it just didn't
> happen.  I got a CVS server up and running recently, and it seems to be
> working OK.

CVS is fine to retrieve the current sources. Thanks.
I suppose you will continue to merge the patches, how we will deliver them
?

> it seems pretty obvious that Gilbert, Hannes,
> Mike, Deniel, and Bobo qualify. 

My first name is Laurent ;-)

> send me private email with your preferred
> username, (crypted) password, shell, etc? 

Sent.

>   - Gilbert and I had a discussion a while back, and we both agree
>     that we need more functionality from libpcap than is currently
>     available.  LBL might accept patches for bug fixes, but they might
>     not want mods to handle other file formats, network hardware, or
>     extended filter directives.

I agree.

>     The idea that Gilbert and I had was to come out with our own
>     modified version of pcap.  We could call it Epcap (short for
>     {Ethereal|Experimental|Enhanced} pcap).

No opinion against that.
 
>   - Mike has been kind enough to start work on TCP connection
>     reconstruction.  This will pave the way for things like real-time
>     connection monitoring and statistics generation.

Good.

>   - There are many things about the current interface that leave a
>     lot to be desired.  To me, a good interface is one that helps a
>     novice novice user along, but doesn't impede a power user.  So many
>     applications fail to do one or both of these; I'm determined not to
>     let it happen with Ethereal.

I agree. See below.
 
>   - There isn't much validation or range checking in the packet dissection
>     routines at the present time.  This needs to be fixed, for reasons
>     of security and stability.

I agree. I will try to handle that carefully in the future packet-xxx.c
files I will write (I let the owners of the existing files to fix their
code ;-)
 
>   Well, enough of my rambling.  What do _you_ think should go into
> version 1.0?
> 

. the most important protocols should be in 1.0 (the existing ones seem
  to be ok, maybe another one: snmp ?)

. the filtering menu should be enhanced (e.g. for a non tcpdump user)
  In an old similar program (see attached gif file), I had the shown
  filtering menu.
  ADDRESS FILTER:
  On click, the OFF button changes to ON.
  ........, the DLC button changes to IP.
  ........, the ANY button opens a popup to enter a hostname or eth/IP
address
  ........, the --> button changes to <--- then <-->
  .........,the INCLUDE button changes to EXCLUDE
  PROTOCOL FILTER:
  You can filter an existing protocol and specify a port name/value for
TCP/UDP.

  "Apply to current" means that the filter is used on the current displayed
packets.
  "Apply to all" means that the filter will be applied to the next capture
session
  (i.e. with tcpdump/libpcap filter). The last case can be made with the
current
  ethereal design.
 
  With this filtering menu, you can filter a particular protocol, a
particular
  src or dst host, ip or eth address as well as TCP/UDP ports.
  I think it should be fine ? maybe I missed some common tcpdump filtering
options ?
  For more complicated filtering commands, the existing menu lets
experienced 
  tcpdump users to specify their own filtering expressions ...

. From the wish list:
  1, 2, 3, 7, 12, 16-17, 18, 23 & 34 (in 2.0 ?), 36

but in fact many items are good, that depends only on the time of 1.0
delivering,
and on the time we will have to work on  :-)

Laurent.

--
Laurent DENIEL            | E-mail: deniel@xxxxxxxxxxx
Paris, FRANCE             |         deniel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
                          | WWW   : http://www.worldnet.fr/~deniel
    All above opinions are personal, unless stated otherwise.