Wireshark · Ethereal-users: RE: [Ethereal-users] Malformed RTCP packet

[Frédéric Huet <fhuet@xxxxxxxxxx>]

Thanks a lot for the quick response.

-Frédéric.

> -----Original Message-----
> From: Biot Olivier [mailto:Olivier.Biot@xxxxxxxxxxx] 
> Sent: Thursday, May 13, 2004 4:00 PM
> To: 'fhuet@xxxxxxxxxx'
> Cc: 'Ethereal user support'; 'Ethereal development'
> Subject: RE: [Ethereal-users] Malformed RTCP packet
> 
> 
> Hi Frédéric,
> 
> Attached patch to current packet-rtcp.c solves the problem.
> 
> I will check it in later tonight.
> 
> FYI your packet is now dissected as follows:
> 
> No. Time      Length  Source           Destination   Protocol Info
>   1 0.000000  114     192.168.105.179  236.24.25.30  RTCP     
> Sender Report
> 
> Frame 1 (114 bytes on wire, 114 bytes captured)
> Ethernet II, Src: 00:04:76:e6:57:34, Dst: 01:00:5e:18:19:1e
> Internet Protocol, Src Addr: 192.168.105.179 (192.168.105.179),
>   Dst Addr: 236.24.25.30 (236.24.25.30)
> User Datagram Protocol, Src Port: 3651 (3651), Dst Port: 7273 (7273)
> Real-time Transport Control Protocol
>     10.. .... = Version: RFC 1889 Version (2)
>     ..0. .... = Padding: False
>     ...0 0000 = Reception report count: 0
>     Packet type: Sender Report (200)
>     Length: 6
>     Sender SSRC: 626857731
>     Timestamp, MSW: 2147484092
>     Timestamp, LSW: 2950642532
>     RTP timestamp: 2288056408
>     Sender's packet count: 0
>     Sender's octet count: 0
> Real-time Transport Control Protocol
>     10.. .... = Version: RFC 1889 Version (2)
>     ..0. .... = Padding: False
>     ...0 0010 = Source count: 2
>     Packet type: Source description (202)
>     Length: 10
>     Chunk 1, SSRC/CSRC 1424429373
>         Identifier: 1424429373
>         SDES items
>             Type: CNAME (user and domain) (1)
>             Length: 14
>             Text: ESS11213044399
>     Padding
>     Chunk 2, SSRC/CSRC 1767708419
>         Identifier: 1767708419
>         SDES items
>             Type: CNAME (user and domain) (1)
>             Length: 10
>             Text: ESS1121304
> 
> Regards,
> 
> Olivier
> 
> |-----Original Message-----
> |From: Frédéric Huet
> |
> |
> |Olivier,
> |
> |Thanks for the answer.
> |The packet I sent is definitely RTCP (I am generating it).
> |I don't know what's wrong with the UDP checksum, I'll 
> investigate that
> |later.
> |
> |About the content of the SDES packet, the first chunk has one item of
> |length 14. Which makes a total of exactly 5 32bits words.
> |
> |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."
> |
> |So, as chunk one is ending on a 32 bit boundary, my understanding is
> |that I could do both options:
> |* no end item
> |Chunk1
> |Chunk2
> |* one null item
> |Chunk1
> |00 00 00 00
> |Chunk2
> |
> |It appears that in the first case, chunk2 is interpreted as a second
> |item of chunk one and in the second case the null item is 
> |interpreted as
> |the SSRC of chunk 2 (this is the file I sent earlier, which explains
> |that lenght and data is wrong).
> |
> |Finally, the question is: how am I supposed to separate the 
> two chunks
> |in the packet ?
> |Regards,
> |-Frederic 
> |
> |> -----Original Message-----
> |> From: Biot Olivier [mailto:Olivier.Biot@xxxxxxxxxxx] 
> |> Sent: Thursday, May 13, 2004 11:21 AM
> |> To: 'fhuet@xxxxxxxxxx'
> |> Cc: 'Ethereal user support'
> |> Subject: RE: [Ethereal-users] Malformed RTCP packet
> |> 
> |> 
> |> Hi Frédéric,
> |> 
> |> When I read the capture file you sent, Ethereal displays a 
> |> pop-up with the
> |> following text:
> |> 
> |> 	"The capture file appears to have been cut short in the 
> |> middle of a
> |> packet"
> |> 
> |> The UDP checksum is also incorrect, so maybe something 
> |> happened to your
> |> capture file (did you transfer it in ASCII mode from a UNIX 
> |> server to your
> |> PC?).
> |> 
> |> When I choose "decode as" and choose RTCP then the packet 
> |> dissection shows
> |> me that the 2nd chunk of the 2nd RTCP entity within the 
> packet in the
> |> capture expects a value with length 93 bytes, however the 
> |> remaining data in
> |> the packet is only 14 bytes (same size as the data portion 
> of the 1st
> |> chunk). The dissector attempts at reading the expected 93 
> |> bytes however it
> |> will reach the end of the packet after 14 bytes and this will 
> |> result in a
> |> "Malformed packet" entry in the protocol tree.
> |> 
> |> So either your packet has been truncated or incorrectly 
> |> transferred from one
> |> system to your PC, or the RTCP implementation you're testing 
> |> has a bug.
> |> Maybe this traffic is not RTCP at all, but that doesn't seem 
> |> to be the case.
> |> 
> |> Regards,
> |> 
> |> Olivier
> |> 
> |> |-----Original Message-----
> |> |From: Frédéric Huet
> |> |
> |> |
> |> |Hi,
> |> |
> |> |I have this RTCP sender report sent from my streaming server 
> |> containing
> |> |an SDES packet with two chunks.
> |> |It is interpreted as malformed by ethereal and, after 
> looking at the
> |> |RFC, I can't figure out why. Nor could I find the appropriate
> |> |modification to have it correctly interpreted by ethereal.
> |> |
> |> |Could you help me on that?
> |> |
> |> |Thanks a lot,
> |> |-Frederic Huet
> |> 
> |
> 
>