Wireshark · Ethereal-dev: Re: [Ethereal-dev] [Patch] revised: tap-tcp_close

[Jason House <jhouse@xxxxxxxxx>]

Ronnie Sahlberg wrote:

> See my other mail about what needs to be changed in the tap system.   The
> cahnges woudl fix this problem as well. The flaw is in the design of the tap
> system. It will be rectified as soon the new release is out.

Just trying to follow up on the ability to accept tap-tcp_close
patches...

> I dont have any problems with it.
> But maybe, it is very specific to a certain task?

You are right that I designed it for a very specific reason... but it
still may be useful to others.  If nothing else, it will help blaze a
trail for exporting tcp sequence number analysis to a tap (or multiple
taps).

> Maybe, once I change the tap api and we push the packet-tcp.c changes in (so
> that Pavels tcp code can use it as well)
> we can add an extra parameter to the tcp_header struct?
>  a pointer to (if present) the TCP ACK/SEQ analysis struct?

Well, I don't like that approach...  It makes TCP specific structures
have knowledge of each and every tap that can exist for it (that follows
conversations, at least).  The question of having multiple tap listeners
(w/ different filter strings?) that want to follow the same
conversation, and potentially will step on each other...

When I thought about this before, I had concluded that I would like it
best if conversations included an extra field to separate a protocol
dissector and distinct instances of tap listeners... basically a tap
listener ID would solve this nicely...  And by appending to the
conversation structure, and comparing it last, the performance impact
would be minimal.  There were some small API tweaks though... (like void
return type becoming int, and adding a new function call)

> 
> That way your analysis could also keep track of the number of
> retransmissions/delayed-acks etc etcv
> on a per conversation basis?