Ethereal-dev: Re: [ethereal-dev] Picking up info along the way and making it available later
At 05:17 AM 3/28/99 +0200, Lars Gaarden <Lars.Gaarden@xxxxxxx> wrote:
>
>
>"Gilbert Ramirez Jr." wrote:
>
>> The NCP dissect code would be able to take advantage of this. I need IPX to
>> pass certain values down to the NCP layer. Right now I pass them through
>> global variables. yuck! Would your list be permanent? That is, would you
>> keep a list in memory for every packet? Or would you free the memory after
>> the packet is dissected? IPX/NCP only needs them temporarily, during the
>> packet-dissection. It uses the variables to make a key into the NCP
>> hashtable.
>
>It seems to me that many protocol analyzers have to implement some kind
>of state machine to properly decode sessions. Instead of implementing all
>this separately for each single protocol, wouldn't it be better to make a
>generic facility to keep state? That is - make it possible for the dissect-*
>routines to save state to a structure, and later retrieve it.
This is my ultimate goal. My thinking at the moment is that I need two
structures around:
1. A hash table containing the n tuple <SIP, DIP, SP, DP, dissect routine>
and maybe more. This allows us to handle some protocols like tftp that
change port numbers as well as providing a table driven dissect structure.
However, given that I now understand more of Ethereal, and that the source
will always be available, I am not so sure that I want to dynamically add
dissect routines.
2. A list of name-value pairs for each packet where we can stash info. Some
that is needed is:
Source IP, Dest IP, Source Port, Dest Port, State ...
Of course, not all protocols need state. It seems that POP, FTP, and nany
others can be decoded without state. However, smtp needs state (for the
packets following the DATA statement up to the CRLF.CRLF).
Well, having said that, it is easier in decoding many if you have the
Source Port and Dest Port around, as that helps you decide which are
commands and which are responses, which you want to usually display.
At the moment, I think that it is enough to use ENUMs or some such for the
names in the name value pairs, rather than strings. This is because the
source will always be available, and it is simple to add a new entry to the
enum and recompile ...
>LarsG
>
>
>
Regards
-------
Richard Sharpe, sharpe@xxxxxxxxxx, NIC-Handle:RJS96
NS Computer Software and Services P/L,
Ph: +61-8-8281-0063, FAX: +61-8-8250-2080,
Samba (Team member), Linux, Apache, Digital UNIX, AIX, C, ...
