----- Original Message ----- From: "Gerald Combs Subject: Re: [Ethereal-dev] Tap extensions. Comments please.
> Looks good. Would it be possible to pass the the protocol tree to the > "packet" routine along with the tap data and packet info? Yes it may be possible. I may try to implement this in the next few days. I am going to change tap.c slightly to remove the outer loop in tap_push_tapped_queue() so that instead the proper tap listeners are notified already in the appropriate tap_queue_packet() call. This would get rid of the ugly tap_packet_list_queue. The inner loop will remain but be moved to tap_queue_packet() instead. This will have several benefits: * tap listeners are notified immediately, from inside the stack frame of the dissector where the tap is, which eliminates the need for the third parameter to tap_queue_packet() being static. Thus we can send automatic variables and structures to the listeners using the tap_queue_packet() call. * removing the outer loop will scale better to large number of taps and tap listeners. There is a problem though with tap in that performance is really affected if the tap listeners use filters. I dont know epan_dissect_prime_dfilter() and friends well enough to be able to fix this. Could you look at it? See tap_push_tapped_queue() in the inner loop there is an if-statement checking if the listener had specified a filter and if so it would do a full : epan_dissect_new() epan_dissect_prime_dfilter() epan_dissect_run() <= This one takes quite some time I think. dfilter_apply_edt() For each and every such tap listener. Well, you see the problem, we do a full and expensive dissection of the entire packet just because we only want to apply a filter. Would it be possible to move all the epan_...() thingies outside the loops and only do a really really cheap dfilter_apply_edt() inside the loop instead? Could the epan and dfilter code be changed to allow this? This would then make the filtering really cheap. If this would be possible we could even change the normal display filter filtering to become a tap extension that just happens to set or reset a global passed variable. Then tap listeners using filters would almost become a zero cost operation. (assuming there were a normal display filter applied). This would make color filtering very cheap as well, almost zero cost. Do you know epan and dfilter in enough detail to understand how I mean? Could you look at this (pretty pretty please). I dont know anything at all about epan internals and dfilter so I would just waste time for weeks or so until I would even know how it worked. > Two uses that come to mind immediately are > > - Generalizing the capture progress window, so that you can pick and > choose what protocols are listed. > > - Passing data on to an expert system for higher level analysis, > sort of like what NAI's Sniffer has. Passing an already-dissected > tree to the tap receiver would be helpful in this case. One should also be able to move the TCP SEQ/ACK analysis stuff from packet-tcp.c into a tap extension, removing some clutter from packet-tcp.c . The tcp seq/ack analysis needs to be updated anyway to flag *duplicate acks *fast retransmissions (3 duplicate acks in a row) *calculate rto according to rfc2988 and flag retransmissions taking > this timeout as non-2988 compliant. This could also be used for the "expert" for how long it took to ACK a packet but instead of something braindead as just assuming that if an ACK took longer than some arbitrary random number such as 100ms should be flagged as "ACK took too long" we could flag this based on the measured RTO according to rfc2988. It could also flag "Delayed ACK: delayed too long" based on rfc2988. Im not aware of any other "expert" even trying to estimate the RTO and doing it the proper way.
