Hi, I think part of the problem is that we are uncertain if this isn't a protocol error in the stack you are using - zero length items??
Brg Anders -----Ursprungligt meddelande----- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Oleg Kostenko Skickat: den 19 september 2006 20:03 Till: [email protected] Ämne: [Wireshark-dev] Fwd: And again BER errors while decoding H248packets Hello, Is there any progress on this issue (see below)? -- Best regards, Oleg mailto:[EMAIL PROTECTED] This is a forwarded message From: Oleg Kostenko <[EMAIL PROTECTED]> To: [email protected] Date: Tuesday, August 22, 2006, 5:14:59 PM Subject: And again BER errors while decoding H248 packets ===8<==============Original message text=============== Hello, Some time ago Eugene Tarlovskij posted the message about BER errors while decoding H248 packets. Here are the links to his posts: http://www.wireshark.org/lists/ethereal-dev/200605/msg01641.html http://www.wireshark.org/lists/ethereal-dev/200605/msg01723.html The solution he proposed was to change packet-ber.cpp: if((len!=0)&&(count==0)&&(seq->flags&BER_FLAGS_OPTIONAL)){ change to: if((len!=0)&&(count==0)&&(count!=length_remaining)&&(seq->flags&BER_FLAGS_OP TIONAL)){ (This is currently line number 1222). However, Eugene's patch was rejected and another patch was proposed by Tim Endean. http://www.wireshark.org/lists/ethereal-dev/200606/msg01532.html Lines 1076-1080: if(ind_field && (len == 2)){ /* disgusting indefinite length zero length field, what are these people doing */ offset = eoffset; continue; } This patch is currently checked in, but doesn't work well enough. Please, take a look at this packet that I've captured (in attach). Here's a fragment of its decoding: Item: mediaDescriptor (1) mediaDescriptor termStateDescr BER Error: Wrong field in SEQUENCE expected class:2 (CONTEXT) tag:0 but found class:2 tag:2 streams: oneStream (0) oneStream localControlDescriptor reserveValue: False reserveGroup: False With Eugene's patch this looks like this: Item: mediaDescriptor (1) mediaDescriptor termStateDescr propertyParms: 0 items serviceState: inSvc (2) streams: oneStream (0) oneStream localControlDescriptor reserveValue: False reserveGroup: False Would you please review both patches again, to see what's wrong with them. As for me, the Eugene's patch works just fine, but I don't actually understand the code well enough to make any conclusions. Probably, you would be able to make another patch, which would be better than these two. Thanks. Attached is the hex dump of the problematic packet. -- Best regards, Oleg mailto:[EMAIL PROTECTED] ===8<===========End of original message text=========== _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
