Well, I started the road to do that...
My RAID-0 had a hard drive failure and I've lost the code :(
I had gone into the conversations code, and added an extra integer
field (which would default to 0 when not supplied). The idea was to
have taps use a different number for that field, so that a tap could
maintain it's own conversation data without stepping on the protocol
dissector or other taps (especially the same tap with possibly different
display filters...).
I had also modified the tap registration to pass an instance id to
taps... basically so that they had a value to pass to the conversations
code if they tried to create their own conversation. I believe that I
reversed the logic so that 0 was an error (actually <=0), and >0 was the
tap's own instance id. (This required a quick mod to all taps at that
time)
Now that I'm thinking about it again, maybe a call to to something
like "int conversation_new_instance_id(int protocol_id)" would be a
better approach?
Those 2 steps hadn't taken all that long...
The next step was to pull the tcp sequence number analysis out of the
tcp dissector and have it use its own conversation instead of TCP's
conversation.
My last step was to go back and fix up my tcp tap code to work in a
similar fashion...
ethereal-dev-request@xxxxxxxxxxxx wrote:
>
> Message: 4
> From: "J.Smith" <lbalbalba@xxxxxxxxxxx>
> To: <ethereal-dev@xxxxxxxxxxxx>
> Date: Sat, 19 Apr 2003 15:20:23 +0200
> Subject: [Ethereal-dev] TCP sequence analysis - convert to a tap ?
>
> Hi.
>
> I seem to remember that a while back, there was some talk on this list about
> the TCP stream analysis code, and the fact that it does its parsing of the
> link layer and the network layer itself, causing the TCP graphing code to be
> link-layer dependent in that it can only handle ethernet as the link layer.
>
> There also was some discussing about the possibility of recoding the part of
> TCP stream analysis that extracts the TCP header to use a TAP instead
> (effectively converting it to a tap) and thus make it link layer agnostic.
>
> I was wondering if this is still the case, or if anyone on this list has had
> enough time to both study the code and implement such changes ?
>
> Sincerely,
>
> John Smith
