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
