Ethereal-users: [Ethereal-users] LCF decode from Vocaltec GK does not display 2ndalternate endpo
Title: LCF decode from Vocaltec GK does not display 2ndalternate endpoint - challenge string
Ronnie,
Thanks very much for your patch! I compiled ehtereal from cvs and the LCF is now decoded properly. It seems however that the patch introduced a problem. There is a "challengestring" present in the token section of several h225 messages - ARQ, RRQ, and SETUP.
Before your patch ethereal simply ignored this section; in the cvs version, ethereal is trying to decode the clear token and does not know how to decode this. The packet is reported as malformed, and the rest of the packet is not decoded. Could you add support for the challenge string?
I attached a capture file that contains an ARQ, RRQ, and SETUP message.
Thanks for all your help,
Mike Oliveras
-----Original Message-----
From: Ronnie Sahlberg [mailto:ronnie_sahlberg@xxxxxxxxxxxxxx]
Sent: Thursday, April 08, 2004 8:10 PM
To: Ethereal user support
Subject: Re: [Ethereal-users] LCF decode from Vocaltec GK does not
display 2ndalternate endpoi nt
LCF decode from Vocaltec GK does not display 2nd alternate endpointHi,
Many thanks for your bugreport.
I have checked in a patch that will make ethereal decode that packet
properly.
It will be avaialble in the next version of ethereal.
Ethereal when decoding that packet should have printed something like "NOT
DECODED YET[ClearToken]" to the console which means
that ethereal encountered a PER contrust (cleartoken in this case) ewthereal
did not know how to decode and thus
everything from that point further in that packet was just decoded as
garbage data.
The problem with your packet was that no one had even bothered enough about
H.235 to even attempt to decode these
ClearToken fields. Maybe H.235 is very rare so almost no one had encountered
it previously? I dont know, Im not a VoIP person.
Since no one had implemented decoding of ClearTokens previously ethereal
failed to decode your packet
properly (since it contained ClearTokens).
I implemented a limited support for ClearTokens and its fields so it will at
least decode your packet properly.
There are though still a lot of other contrustcs, mainly related to H.235
that no one has cared enough about to implement and which
can/will cause similar problems.
Please report any other problems you see and encounter. I dont use VoIP
myself, dont have access to VoIP and also lack interest in VoIP so it
is impossible for me to create required captures to test those unimplemented
fields.
Please keep sending captures and bugreports to the list and myself or
someone else can implement the missing parts.
Thanks again for the bugreport (missing functionality) and for the capture
that allowed me to implement decodes for these fields.
best regards
ronnie sahlberg
----- Original Message -----
From: Michael Oliveras
To: 'ethereal-users@xxxxxxxxxxxx'
Sent: Thursday, April 08, 2004 9:34 AM
Subject: [Ethereal-users] LCF decode from Vocaltec GK does not display
2ndalternate endpoi nt
I noticed a decode issue on ethereal 0.10.3
I attached a trace of an LCF that was sent from a Vocaltec GK. The LCF
contains a total of three endpoints (an endpoint and two alternate
endpoints).
When I look at the decode on ethereal, it only displays the 1st alternate
endpoint and not the 2nd. I can actually see the h323ID of the 2nd
alternate endpoint in the text decode of the hex pane
(5350-t1-13@xxxxxxxxxxxxxxxxxxx), so it seems that the information was
captured but not decoded.
Any help would be appreciated.
Thanks,
Mike Oliveras
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users
Attachment:
challengestring.cap
Description: Binary data
