On Wed, Feb 02, 2000 at 04:56:50PM +1000, Richard Sharpe wrote:
> Hi,
>
> I think it is time to start talking about what the feature set of 1.0 will be.
>
> Here are some things I would like to get finished, before calling it quits
> on Ethereal.
>
> 1. Add a per frame info store so I can do a better job with SMB decodes.
Yes. Other protocols like Socks5 and VNC need better state storage, too.
> Things I want to leave until the next version:
>
> 1. libdencode support so we can separate protocol knowledge from the
> display code.
Yes, I like the idea of creating a separate library to do the decoding.
I was even thinking of trying to push us to do this before 1.0, although
in reality, who care so much about version numbers?
On thing to consider about moving to libdencode, however, is that
if we're not careful, we could end up slower or using more memory.
Right now, as you know, Ethereal runs through the entire trace file
to analyze every packet just enough to get the information to put
in the list of packet (GtkClist). Inside each protocol dissector is
"short-circuit" code avoiding a lot of processing if there's no need
to fill out any proto_tree:
dissector(....)
{
fill in column info
figure out next protocol
if (tree) {
put stuff in tree
}
call next protocol
}
We might want to consider putting similar short-circuit code
into the libdencode routines in order to help apps like Ethereal.
(BTW, have you taken a look at libnet; it does some packet creation,
which is the "encode" part of libdencode). Otherwise we'll end up
spending more time decoding things we don't have to, or end up using
more memory by holding decodes for every packet in memory.
I'd like to see someone take care of IP re-assembly before 1.0. In
future versions of Ethereal, I want to have many protocols be able to
defragment/reassemble transmissions. IP should be able to join fragmented
IP packets, and send them back through the decoder. TCP should show
conversation chunks in the GtkClist much like it shows them in the
TCP Follow window. SMTP should divided TCP sequences into text files
containing e-mail, TFTP/FTP/HTTP/NFS/SMB/NCP should be able to reassemble
their underlying transmissions and provide me a File|Save-As option
so I can sniff a file transmission and recreate the file.
All that is in the far future of course, but I think it would be
a good first step to take care of IP re-assembly before 1.0. It's an
easy reassembly to do, and it would give us the opportunity to try
to make a generic framework for reassembly, and learn from that attempt
before trying to tackle the upper-layer protocols.
> 2. MSRPC support.
>
> Any other comments?
>
> At the end of this month, I should have more time to put into Ethereal and
> libdencode. I have made some progress on libdencode, and will have to post
> something soon.
I'd like to see some more of your libdencode work. I'd like to
try to do run-time checking of packet boundaries, and try to provide
opaque data structures that protocol dissectors can use to place data
in the protocol tree, but cannot use for calculation until the data
is verified (a "tainted data" type system). I'd like to use setjmp/longjmp
to unwind the stack when a packet boundary is passed.... all these things
will help us get rid of the bugs that creep up now and then in the
protocol dissectors, especiall when dissecting bad or short packets.
So, we can work on what libdencode should look like, and limit ourselves
to a few protocols at first. We shouldn't go beyond the few protocols
we decide on, and work those over and over until we have a really good
system. Then we expand.
1.0 also needs a "Protocol" tab in the display optoin notebook
widget. I want to provide an option to turn off the verbose TCP info
that gets put into the GUI protocol tree. Oh, and the pane changes
both you and I thought about putting in (hideable panes/re-arrangable
panes).
Even a new widget to replace GtkCList might be in order before 1.0.
--gilbert