ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 2153] Bugs in the RTMP(T) decoder

Date: Sat, 5 Jan 2008 07:32:55 +0000 (GMT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2153





------- Comment #2 from metatech@xxxxxxxxxxxxx  2008-01-05 07:32 GMT -------
Hello,
Mark, I am far from a RTMP/AMF expert, actually the only capture I generated to
write the dissector was a video streaming from a server (the one in the Wiki),
so I have no knowledge with writing code related to the RTMP/AMF protocol (nor
on the client nor on the server).
Which funtionality do use ? do you use your own client (flash, ...) or your own
server code (flex, ...) ?
Do you have a capture exhibiting those problems ?
For your second problem, I am aware that the length can be something else than
128 for "one byte headers PDU", but I think to solve it I have to keep in
memory the headers of *all* PDU of all RTMP conversation (because with
Wireshark you can go "backwards" by opening a previously dissected packet and
these information must still be available.  To my understanding it is not
sufficient to store a "state" with the headers of only the last PDU (for the
particular ObjectID).  The initial dissector was only a starting point for
other people more expert than me at RTMP to start building on top of that, so I
kept it simple and "hard-coded" 128.  IMHO the RTMP protocol cannot have been
designed by a proper network engineer (sorry Macromedia, refer also to people
of Red5 with the same complaint) because for the sake of saving a few bytes in
some PDU it makes the whole protocol stateful ("PDU length same as previous PDU
length") which is a nightmare.  Also the length is never accurately announced
at the beginning of a PDU (plenty of exception cases).
Which length other than 128 do you get ? For which kind of PDU ?
Any sample capture for that ?
Thanks.
metatech


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.