Wireshark-dev: [Wireshark-dev] Fwd: And again BER errors while decoding H248 packets
From: Oleg Kostenko <oleg.kostenko@xxxxxxxxxxxx>
Date: Tue, 19 Sep 2006 22:02:44 +0400
Hello, Is there any progress on this issue (see below)? -- Best regards, Oleg mailto:oleg.kostenko@xxxxxxxxxxxx This is a forwarded message From: Oleg Kostenko <oleg.kostenko@xxxxxxxxxxxx> To: wireshark-dev@xxxxxxxxxxxxx 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_OPTIONAL)){ (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:oleg.kostenko@xxxxxxxxxxxx ===8<===========End of original message text===========
0000 30 80 A1 80 80 01 02 A1 80 A2 80 80 0C 63 6F 6D 0010 70 61 6E 79 31 2E 63 6F 6D 81 02 0B 81 00 00 00 0020 00 A2 80 A1 80 A2 80 80 01 09 A2 80 A1 80 30 80 0030 80 02 03 E9 A2 80 00 00 A3 80 A5 80 A2 80 A0 08 0040 A0 00 81 04 00 00 00 02 A1 80 A1 80 A0 80 A0 80 0050 00 00 82 01 02 00 00 A1 80 A0 80 A0 80 81 01 00 0060 82 01 00 A3 80 00 00 00 00 00 00 00 00 00 00 A4 0070 80 80 01 00 A1 80 00 00 00 00 A5 80 00 00 A6 80 0080 00 00 AB 80 80 03 06 FD C0 00 00 00 00 00 00 00 0090 00 A5 80 A2 80 A0 08 A0 00 81 04 80 00 00 02 A1 00A0 80 A1 80 A0 80 A0 80 00 00 00 00 A1 80 A0 80 A0 00B0 80 80 01 02 81 01 00 82 01 00 A3 80 00 00 00 00 00C0 A1 80 A0 80 30 80 30 80 80 04 00 00 B0 01 A1 80 00D0 04 04 16 02 30 0D 00 00 00 00 30 80 80 04 00 00 00E0 B0 03 A1 80 04 0B 16 09 49 43 47 20 43 61 6C 6C 00F0 0D 00 00 00 00 30 80 80 04 00 00 B0 0D A1 80 04 0100 06 16 04 30 20 30 0D 00 00 00 00 30 80 80 04 00 0110 00 B0 0F A1 80 04 17 16 15 61 75 64 69 6F 20 36 0120 30 30 30 20 52 54 50 2F 41 56 50 20 30 0D 00 00 0130 00 00 30 80 80 04 00 00 B0 08 A1 80 04 14 16 12 0140 49 4E 20 49 50 34 20 31 30 2E 32 2E 31 36 2E 31 0150 31 0D 00 00 00 00 30 80 80 04 00 00 B0 0C A1 80 0160 04 0B 16 09 70 74 69 6D 65 3A 32 30 0D 00 00 00 0170 00 00 00 00 00 00 00 A2 80 A0 80 30 80 30 80 80 0180 04 00 00 B0 01 A1 80 04 04 16 02 30 0D 00 00 00 0190 00 30 80 80 04 00 00 B0 03 A1 80 04 0B 16 09 49 01A0 43 47 20 43 61 6C 6C 0D 00 00 00 00 30 80 80 04 01B0 00 00 B0 0D A1 80 04 06 16 04 30 20 30 0D 00 00 01C0 00 00 30 80 80 04 00 00 B0 0F A1 80 04 17 16 15 01D0 61 75 64 69 6F 20 36 30 30 30 20 52 54 50 2F 41 01E0 56 50 20 30 0D 00 00 00 00 30 80 80 04 00 00 B0 01F0 08 A1 80 04 14 16 12 49 4E 20 49 50 34 20 31 30 0200 2E 32 2E 31 36 2E 31 32 0D 00 00 00 00 30 80 80 0210 04 00 00 B0 0C A1 80 04 0B 16 09 70 74 69 6D 65 0220 3A 32 30 0D 00 00 00 00 00 00 00 00 00 00 00 00 0230 00 00 00 00 A4 80 80 01 00 A1 80 00 00 00 00 A5 0240 80 00 00 A6 80 00 00 A9 80 30 80 80 04 00 0B 00 0250 01 A1 80 04 04 02 02 4C 6F 00 00 00 00 30 80 80 0260 04 00 0B 00 03 A1 80 04 05 02 03 02 91 C4 00 00 0270 00 00 30 80 80 04 00 0B 00 02 A1 80 04 05 02 03 0280 02 91 C4 00 00 00 00 30 80 80 04 00 0C 00 08 A1 0290 80 04 03 02 01 14 00 00 00 00 30 80 80 04 00 0C 02A0 00 07 A1 80 04 03 02 01 14 00 00 00 00 30 80 80 02B0 04 00 0C 00 06 A1 80 04 03 02 01 00 00 00 00 00 02C0 30 80 80 04 00 0C 00 05 A1 80 04 04 02 02 03 D3 02D0 00 00 00 00 30 80 80 04 00 0C 00 04 A1 80 04 04 02E0 02 02 03 D3 00 00 00 00 00 00 AB 80 80 03 06 FF 02F0 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0310 00 00 00
- Follow-Ups:
- Re: [Wireshark-dev] base64.x & crypt-md5.x; linking issues using them.
- From: Brian Vandenberg
- Re: [Wireshark-dev] Fwd: And again BER errors while decoding H248packets
- From: Anders Broman
- Re: [Wireshark-dev] base64.x & crypt-md5.x; linking issues using them.
- Prev by Date: Re: [Wireshark-dev] newbie build problem with python ->gnutls/openssl.h
- Next by Date: Re: [Wireshark-dev] base64.x & crypt-md5.x; linking issues using them.
- Previous by thread: Re: [Wireshark-dev] newbie build problem with python ->gnutls/openssl.h
- Next by thread: Re: [Wireshark-dev] base64.x & crypt-md5.x; linking issues using them.
- Index(es):