Wireshark · Ethereal-users: Re: [Ethereal-users] Re: RTCP malformed frame

[Guy Harris <gharris@xxxxxxxxx>]

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: e00a9@209.58.84.226
>
> 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