I found the reason, a very simple one.
the MGC encoded the "$" context as a 5 octet integer (00:ff:ff:ff:fe)
so it was not added to the tree as an uint, but just added a text
label. Exact same issue with the termination IDs that did not show as
filterable.
another issue is that in this exact case:
dissect_ber_integer(impl_tag,pinfo,tree,tvb,offset,&val);
does not set val, which might very well used uninitialized afterwards
even if the compiler believe it was and so it doesn't warn.
On 5/12/05, Anders Broman (AL/EAB) <anders.broman@xxxxxxxxxxxx> wrote:
> Hi,
> I had a quick look at a sample I have and could not see the problem. can you send me a file with the problem so I can have a look.
> Best regards
> Anders
>
> -----Original Message-----
> From: ethereal-dev-bounces@xxxxxxxxxxxx
> [mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of LEGO
> Sent: den 11 maj 2005 18:46
> To: Ethereal development
> Subject: [Ethereal-dev] items with and without filterable fields in
> H.248
>
> While analyzing some traces containing BER encoded H.248 I noticed
> that some items are not added to the tree the same way for every
> packet.
>
> For instance, in transactions initiated by the MGC the transactionId
> is filterable while it is not for those initiated by the MGw. They are
> both parsed correctly but just some ones are filterable. Something
> similar happens to terminationIds for some types of terminations they
> are filtrable for some others they aren't.
>
> I'm interested in fixing this, but I don't have yet the knowledge
> about asn.1 generated dissectors to cope with the issue. So, I have
> some questions:
>
> Why this could happen?
> What should I be looking for in order to fix it?
>
> Thanks,
>
> Luis
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan