Ethereal-dev: [Ethereal-dev] Re: Order of tap listeners (PATCH)

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Lars Ruoff" <lars.ruoff@xxxxxxx>
Date: Fri, 1 Apr 2005 22:12:02 +0200
Ok. Perhaps we can have everyone satisfied in the long term.
Let's apply the patch which settles the problem for me (same tap listener on multiple instances of the same protocol on the same packet). And if it makes things too hard for you, we can still implement Ronnie's suggestion with tap-defined priorities in the case of different tap listeners on different protocol levels on the same packet.

regards,
Lars

Date: Fri, 01 Apr 2005 08:55:51 -0700
From: Alejandro Vaquero <alejandrovaquero@xxxxxxxxx>
Subject: Re: [Ethereal-dev] Re: Order of tap listeners (PATCH)
To: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
Message-ID: <424D6F07.70701@xxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Agree with Francisco, after this patch we'll definitely have problems
with the Voip analysis, but I agree to have this new order. For example,
now the SIP tap is called  before the SDP tap. But in MGCP, the MGCP tap
is called after the SDP (we use the frame number to correlate both).
Once the patch is applied, I'll also take a look to fix the Voip issues.

Regards
Alejandro

Francisco Alcoba (TS/EEM) wrote:

>>Since most dissectors call tap_queue_packet at the very end
>>of dissection
>>(after having called sub-dissectors) that might brake some
>>code that uses
>>taps at different protocol levels and shares state
>>information among these
>>(and relies on taps of higher level protocols beign called
>>*before* lower
>>level protocols).
>>Again, if this is the case, the code *was* already broken
>>with regard to the
>>current documentation in which the order of tap listeners is
>>explicitly
>>stated as "undefined".
>>Could you check if that might be a problem for VoIP calls?
>>
>>
>
>It definitely might be a problem, but I find no reason for that to
>be an obstacle; I agree that it is better to have a rule than to have
>none. Being capable to impose that order from the code that performs
>the tapping seems to me more practical than depending on the dissection
>order, but I guess this is not good for your case, where it is the
>same tap which is called successively -if I understand it correctly-.
>We might need to change something in the voip calls, so I'd like to
>have a bit of time to do that after your patch has been applied and
>before a new release is created.
>
>Regards,
>
>  Francisco
>