Wireshark · Wireshark-dev: Re: [Wireshark-dev] Fwd: And again BER errors while decoding H248packets

["Anders Broman" <a.broman@xxxxxxxxx>]

Hi,
I have checked in a fix please verify it with your traces.

Best regards
Anders

-----Ursprungligt meddelande-----
Från: Oleg Kostenko [mailto:oleg.kostenko@xxxxxxxxxxxx] 
Skickat: den 20 september 2006 10:41
Till: Anders Broman; wireshark-dev@xxxxxxxxxxxxx
Ämne: Re[2]: Fwd: And again BER errors while decoding H248packets

Hello Anders,

Here is the fragment from the ASN.1 specification for H.248.

TerminationStateDescriptor ::= SEQUENCE
{
  propertyParms       SEQUENCE OF PropertyParm,
  eventBufferControl  EventBufferControl OPTIONAL,
  serviceState        ServiceState OPTIONAL,
  ...
}

As I understand, "SEQUENCE OF" means zero or more elements, so it is
possible that there will be no propertyParms at all. So in terms of
ASN.1 the packet is correct and no BER errors should occur. Right?

-- 
Best regards,
 Oleg                            mailto:spirent@xxxxxxxxxxxx


Wednesday, September 20, 2006, 12:57:17 AM, you wrote:

AB> Hi,
AB> I think part of the problem is that we are uncertain if this isn't a
AB> protocol error in the stack you are using - zero length items??

AB> Brg
AB> Anders 

AB> -----Ursprungligt meddelande-----
AB> Från: wireshark-dev-bounces@xxxxxxxxxxxxx
AB> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] För Oleg Kostenko
AB> Skickat: den 19 september 2006 20:03
AB> Till: wireshark-dev@xxxxxxxxxxxxx
AB> Ämne: [Wireshark-dev] Fwd: And again BER errors while decoding
H248packets

AB> Hello,

AB> Is there any progress on this issue (see below)?

AB> -- 
AB> Best regards,
AB>  Oleg                            mailto:oleg.kostenko@xxxxxxxxxxxx


AB> This is a forwarded message
AB> From: Oleg Kostenko <oleg.kostenko@xxxxxxxxxxxx>
AB> To: wireshark-dev@xxxxxxxxxxxxx
AB> Date: Tuesday, August 22, 2006, 5:14:59 PM
AB> Subject: And again BER errors while decoding H248 packets

AB> ===8<==============Original message text===============
AB> Hello,

AB>   Some time ago Eugene Tarlovskij posted the message about BER errors
AB>   while decoding H248 packets. Here are the links to his posts:

AB>   http://www.wireshark.org/lists/ethereal-dev/200605/msg01641.html
AB>   http://www.wireshark.org/lists/ethereal-dev/200605/msg01723.html

AB>   The solution he proposed was to change packet-ber.cpp:

AB>       if((len!=0)&&(count==0)&&(seq->flags&BER_FLAGS_OPTIONAL)){

AB>       change to:

 
AB>
if((len!=0)&&(count==0)&&(count!=length_remaining)&&(seq->flags&BER_FLAGS_OP
AB> TIONAL)){

AB>   (This is currently line number 1222).

AB>   However, Eugene's patch was rejected and another patch was proposed
AB>   by Tim Endean.
AB>   http://www.wireshark.org/lists/ethereal-dev/200606/msg01532.html

AB>   Lines 1076-1080:

AB>        if(ind_field && (len == 2)){
AB>            /* disgusting indefinite length zero length field, what are
these
AB> people doing */
AB>          offset = eoffset;
AB>          continue;
AB>        }

AB>   This patch is currently checked in, but doesn't work well enough.
AB>   Please, take a look at this packet that I've captured (in attach).
AB>   Here's a fragment of its decoding:
  
AB>     Item: mediaDescriptor (1)
AB>       mediaDescriptor
AB>         termStateDescr
AB>           BER Error: Wrong field in SEQUENCE  expected class:2 (CONTEXT)
AB> tag:0 but found class:2 tag:2
AB>         streams: oneStream (0)
AB>           oneStream
AB>             localControlDescriptor
AB>               reserveValue: False
AB>               reserveGroup: False

AB>   With Eugene's patch this looks like this:
  
AB>     Item: mediaDescriptor (1)
AB>       mediaDescriptor
AB>         termStateDescr
AB>           propertyParms: 0 items
AB>           serviceState: inSvc (2)
AB>         streams: oneStream (0)
AB>           oneStream
AB>             localControlDescriptor
AB>               reserveValue: False
AB>               reserveGroup: False

AB>   Would you please review both patches again, to see what's wrong with
AB>   them. As for me, the Eugene's patch works just fine, but I don't
AB>   actually understand the code well enough to make any conclusions.
AB>   Probably, you would be able to make another patch, which would be
AB>   better than these two.

AB>   Thanks.

AB>   Attached is the hex dump of the problematic packet.