If no one objects, could we apply the following patch to tap.c, which brings
the tapping in order with the packet dissection?
tap.c:
- Replaced fixed length linked list of tap_packet_t with static array.
We advance in the array with every call to tap_queue_packet.
In tap_push_tapped_queue we iterate over all queued packets in the same
order.
=> The order of which the tap listeners will be called is the same as the
order of which the corresponding dissectors for the packet have been
called. (README.tapping to be updated).
Attached is relevant output of 'svn diff'.
regards,
Lars Ruoff
> README.tapping says:
> "After each individual packet has been completely dissected and all
> dissectors have returned, all the tap listeners that has been flagged
> to receive tap data during the dissection of the frame will be called in
> sequence.
> The order of which the tap listeners will be called is not defined."
>
> Why can't we just define the order as the same order of the sequential
calls
> to tap_queue_packet, at least for a given tap listener?
> That would help a lot with a statefull tap listeners that inspect multiple
> packets beeing transported in the same frame.
> Currently, i'm trying to tap on RTP packets over a Wifi-Connection where
> multiple RTP packets are encpasulated in a radio transport protocol. But
the
> RTP tap listener sees the order mangled up and wrongly detects sequence
> errors.
>
> regards,
> Lars Ruoff
>
Attachment:
tap.c.diff
Description: Binary data
