Ethereal-dev: Re: [Ethereal-dev] Tap extensions. Comments please.
----- 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.
