Hi Jason,
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?
I am travelling this week so I can not check it in.
Unless someone else reviews it and checks it in I can look at it early next
week.
When I looked at it, the only issue was the one Guy pointed out with
possiblility of multiple TCP headers in the same packet.
Since you changed that by a simple workaround I think it should go in
asap, at least the packet-tcp.c patch.
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).
We can check it in now, even if it is very specialized.
Maybe sometime later, when TCP sequence analysis is changed into a tap as
well, we can merge the two, or make the tcp-close tap depend on
the tcp sequence analysis tap.
I really do think that the tcp-close tap could become much more generic and
useful for much wider audiences if it would become more generic:
"list all tcp sessions and interesting data for them"
If it were also collecting (from the tcp sequence analysis stuff) data
and presented for each session like for total and for each direction
number of retransmissions, number of duplicate acks etc
then at least myself and several i know would use it daily.
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...
You are right, one should not pollute the tcp header structure unless it
is nessecary.
The TCP sequence analysis should still be converted to a tap, but it will
just have to deal with not being allowed extending the tcp header struct.
Pavels extension should I think be converted into using the "tcp" tap to
extract data from sessions instead of inspecting the packets directly. To
make it link layer agnostic.
This should be investigated in the future when the tcp tap is in.
I will prepare/propose design document on the tap listener part for pavels
extension next week.
best regards
ronnie sahlberg
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
