Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

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

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Frédéric Huet <fhuet@xxxxxxxxxx>
Date: Thu, 13 May 2004 12:04:06 +0200
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
>