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
