----- Original Message -----
From: "Jason House"
Sent: Wednesday, November 20, 2002 9:34 AM
Subject: [Ethereal-dev] [Patch] tethereal -z tcp,close
> Here's something I coded up while on travel when I had issues with TCP
> session closings.
> It has some IPv6 issues (I was working with IPv4, but still tried to do
> IPv6 stuff too)
>
> It basically does a quick online summary of how well, each side
> considers itself to be closed.
> The issue I had hit was the receiver was responding to a fin with 2
> packets (ack only, and fin-ack).
> When the fin was lost, but the ack made it, another piece of software
> was choking on it.
> The output of this tap was used as an alternative for analyzing TCP
> sessions.
> (grep for "<->" worked well for grabbing the one line summaries)
>
> I'm sure there is plenty of room for improvement...
Very interesting work.
Though you access the tap : "tap" which have not been implemented yet, did
you forget to attache the diff to packet-tcp.c?
One comment, right now you seem not to use the facility for providing tap
specific data using the
fourth parameter to _packet().
For much better performance and also to provide a mechanism for others that
want to use the "tcp"
tap point, maybe you should consider to change packet-tcp.[c|h] so that they
have a
definition of a tcp_header struct which is filled in by the tcp dissector.
Then a pointer to this (static, must not live on the stack) structure could
be passed to any tap-listeners
listening on the "tcp" tap.
You would then not need to do those find_first_integer() things in _packet()
anymore, you could just cast
the void*pri parameter to tcp_header* and just access the fields
directly.
Similar to what the rpc and dcerpc taps do.
It would simplify the code and make it easier for your dissector, it would
also make it easier
for other future users of "tcp".
Can you provide a patch for packet-tcp.[ch] that implements a tcp_header
structure
and that dissect_tcp() fills it in and then passes it to the tap system for
listeners to access?
Remember that the struct in dissect_tcp() holding the header must not live
on the stack since the stackframe of dissect_tcp() does no longer exist when
the tap listeners are called.
(tcp_header i guess could just ignore any and all the options of the header)
The second patch could be your current one for tcp,close reworked to utilize
the fourth parameter
in _packet().
?