Ethereal-users: Re: [Ethereal-users] Re: RTCP malformed frame
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Guy Harris <gharris@xxxxxxxxx>
Date: Fri, 14 Jan 2005 11:29:06 -0800
Michael Oliveras wrote:
I opened up the RTCP packet with ethereal 0.9.11 and the original h323 plugin, and it is able to decode the packet correctly. It seems that the RTCP packet has a Sender report followed by a Source Descriptoin in the same packet, which seems to be the same issue another user had reported. I included a decode of the RTCP packet with both versions of ethereal if anyone cares to take a look.
To quote a comment in the current version of the routine to dissect a source description, which is in code that has been added since 0.9.11:
/* According to RFC1889 section 6.4: * "The list of items in each chunk is terminated by one or more * null octets, the first of which is interpreted as an item type * of zero to denote the end of the list, and the remainder as * needed to pad until the next 32-bit boundary. * * A chunk with zero items (four null octets) is valid but useless." */From looking at the code, it appears to treat a source description chunk with an all-zero SSRC/CSRC identifier as not having any SDES items in it. From looking at section 6.4 of RFC 1889, it looks as if that might not be a valid interpretation of the quoted section of that RFC, at least as I read it; I read that section as talking about the SDES items (as per the "items" in "The list of items"), *NOT* referring to the SSRC/CSRC identifier.
The mail message that inspired this change was, apparently http://www.ethereal.com/lists/ethereal-users/200405/msg00140.html which included a capture file showing the problem.The packet in question has two RTCP packets in the UDP datagram; the second is a source description, with two chunks, the first of which has 4 bytes of zero at the end.
At least as I read RFC 1889, those 4 bytes are the end-of-list item with a type of zero, followed by what's presumably a length byte with a value of zero, followed by 2 padding bytes - or maybe the end-of-list item has no length byte, just as many padding bytes are necessary, if any.
I've checked in a change that should fix the problem you're seeing, without causing the capture file in the message in question to be dissected incorrectly. You'd have to either send us a capture containing a packet with the problem you reported, or try a future buildbot build with the fix, in order to test the fix.
which is the end-of-list item and the next 3 are padd
Regards, Mike -----Original Message----- From: Michael Oliveras <moliveras@xxxxxxxxxxxxx> Sent: Jan 8, 2005 11:39 AM To: ethereal-users@xxxxxxxxxxxx Subject: RTCP malformed frame All of the RTCP frames from a particular vendor are decoded as ethereal as malformed. Can someone take a look and see if there is a dissection bug? I included a sample. Thanks, Mike ------------------------------------------------------------------------ Frame 1 (126 bytes on wire, 126 bytes captured) Arrival Time: Jan 7, 2005 11:02:44.560240000 Time delta from previous packet: 0.000000000 seconds Time relative to first packet: 0.000000000 seconds Frame Number: 1 Packet Length: 126 bytes Capture Length: 126 bytes Ethernet II, Src: 00:d0:ff:90:98:00, Dst: 00:07:e9:0c:91:52 Destination: 00:07:e9:0c:91:52 (Intel_0c:91:52) Source: 00:d0:ff:90:98:00 (Cisco_90:98:00) Type: IP (0x0800) Internet Protocol, Src Addr: 209.58.84.226 (209.58.84.226), Dst Addr: 209.58.84.42 (209.58.84.42) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 112 Identification: 0x7230 Flags: 0x00 .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0xbdcb (correct) Source: 209.58.84.226 (209.58.84.226) Destination: 209.58.84.42 (209.58.84.42) User Datagram Protocol, Src Port: 7839 (7839), Dst Port: 60823 (60823) Source port: 7839 (7839) Destination port: 60823 (60823) Length: 92 Checksum: 0x0000 (none) Real-time Transport Control Protocol Version: RFC 1889 Version (2) Padding: False Reception report count: 1 Packet type: Sender Report (200) Length: 12 Sender SSRC: 0 Timestamp, MSW: 3314101148 Timestamp, LSW: 3256352768 RTP timestamp: 11040 Sender's packet count: 0 Sender's octet count: 0 Source 1 Identifier: 234312949 SSRC contents Fraction lost: 0 / 256 Cumulative number of packets lost: 0 Extended highest sequence number received: 18267 Sequence number cycles count: 0 Highest sequence number received: 18267 Interarrival jitter: 11 Last SR timestamp: 824463097 Delay since last SR timestamp: 17039 Real-time Transport Control Protocol Version: RFC 1889 Version (2) Padding: False Source count: 1 Packet type: Source description (202) Length: 7 Chunk 1, SSRC/CSRC 0 Identifier: 0 SDES items Type: CNAME (user and domain) (1) Length: 19 Text: [email protected] 0000 00 07 e9 0c 91 52 00 d0 ff 90 98 00 08 00 45 00 .....R........E. 0010 00 70 72 30 00 00 3f 11 bd cb d1 3a 54 e2 d1 3a .pr0..?....:T..: 0020 54 2a 1e 9f ed 97 00 5c 00 00 81 c8 00 0c 00 00 T*.....\........ 0030 00 00 c5 89 2b 9c c2 18 00 00 00 00 2b 20 00 00 ....+.......+ .. 0040 00 00 00 00 00 00 0d f7 54 f5 00 00 00 00 00 00 ........T....... 0050 47 5b 00 00 00 0b 31 24 4e f9 00 00 42 8f 81 ca G[....1$N...B... 0060 00 07 00 00 00 00 01 13 65 30 30 61 39 40 32 30 ........e00a9@20 0070 39 2e 35 38 2e 38 34 2e 32 32 36 00 00 00 9.58.84.226... ------------------------------------------------------------------------ No. Time Source Destination Protocol Info 1 0.000000 209.58.84.226 209.58.84.42 RTCP Sender Report[Malformed Packet] Frame 1 (126 bytes on wire, 126 bytes captured) Arrival Time: Jan 7, 2005 11:02:44.560240000 Time delta from previous packet: 0.000000000 seconds Time since reference or first frame: 0.000000000 seconds Frame Number: 1 Packet Length: 126 bytes Capture Length: 126 bytes Ethernet II, Src: 00:d0:ff:90:98:00, Dst: 00:07:e9:0c:91:52 Destination: 00:07:e9:0c:91:52 (Intel_0c:91:52) Source: 00:d0:ff:90:98:00 (Cisco_90:98:00) Type: IP (0x0800) Internet Protocol, Src Addr: 209.58.84.226 (209.58.84.226), Dst Addr: 209.58.84.42 (209.58.84.42) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 112 Identification: 0x7230 (29232) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 63 Protocol: UDP (0x11) Header checksum: 0xbdcb (correct) Source: 209.58.84.226 (209.58.84.226) Destination: 209.58.84.42 (209.58.84.42) User Datagram Protocol, Src Port: 7839 (7839), Dst Port: 60823 (60823) Source port: 7839 (7839) Destination port: 60823 (60823) Length: 92 Checksum: 0x0000 (none) Real-time Transport Control Protocol 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0001 = Reception report count: 1 Packet type: Sender Report (200) Length: 12 Sender SSRC: 0 Timestamp, MSW: 3314101148 Timestamp, LSW: 3256352768 RTP timestamp: 11040 Sender's packet count: 0 Sender's octet count: 0 Source 1 Identifier: 234312949 SSRC contents Fraction lost: 0 / 256 Cumulative number of packets lost: 0 Extended highest sequence number received: 18267 Sequence number cycles count: 0 Highest sequence number received: 18267 Interarrival jitter: 11 Last SR timestamp: 824463097 Delay since last SR timestamp: 17039 Real-time Transport Control Protocol 10.. .... = Version: RFC 1889 Version (2) ..0. .... = Padding: False ...0 0001 = Source count: 1 Packet type: Source description (202) Length: 7 Padding Chunk 1, SSRC/CSRC 18048304 Identifier: 18048304 SDES items Type: Unknown (48) Length: 97 [Malformed Packet: RTCP] 0000 00 07 e9 0c 91 52 00 d0 ff 90 98 00 08 00 45 00 .....R........E. 0010 00 70 72 30 00 00 3f 11 bd cb d1 3a 54 e2 d1 3a .pr0..?....:T..: 0020 54 2a 1e 9f ed 97 00 5c 00 00 81 c8 00 0c 00 00 T*.....\........ 0030 00 00 c5 89 2b 9c c2 18 00 00 00 00 2b 20 00 00 ....+.......+ .. 0040 00 00 00 00 00 00 0d f7 54 f5 00 00 00 00 00 00 ........T....... 0050 47 5b 00 00 00 0b 31 24 4e f9 00 00 42 8f 81 ca G[....1$N...B... 0060 00 07 00 00 00 00 01 13 65 30 30 61 39 40 32 30 ........e00a9@20 0070 39 2e 35 38 2e 38 34 2e 32 32 36 00 00 00 9.58.84.226... ------------------------------------------------------------------------ _______________________________________________ Ethereal-users mailing list Ethereal-users@xxxxxxxxxxxx http://www.ethereal.com/mailman/listinfo/ethereal-users
- References:
- [Ethereal-users] Re: RTCP malformed frame
- From: Michael Oliveras
- [Ethereal-users] Re: RTCP malformed frame
- Prev by Date: Re: [Ethereal-users] unable to disable promiscuous mode in wireless interface
- Next by Date: RE: [Ethereal-users] Re: RTCP malformed frame
- Previous by thread: [Ethereal-users] Re: [Ethereal-dev] UNIX timestamp
- Next by thread: RE: [Ethereal-users] Re: RTCP malformed frame
- Index(es):