[Biot Olivier <Olivier.Biot@xxxxxxxxxxx>]

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
|> 
|

Attachment: rtcp.diff
Description: Binary data