I have checked in the patch.
Please see with teh voip crowd if they have problems with this patch
since it seems they might actually need to have the priority fields
added.
On Fri, 1 Apr 2005 22:12:02 +0200, Lars Ruoff <lars.ruoff@xxxxxxx> wrote:
> 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
> > >
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
