https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6898
--- Comment #7 from Michael Mann <mmann78@xxxxxxxxxxxx> 2012-04-13 05:33:37 PDT ---
(In reply to comment #6)
> (In reply to comment #4)
> > Since RTMPT is a TCP protocol, does it make sense to have it use
> > tcp_dissect_pdus() rather than have its own packet reassembly (where presumably
> > the large memory allocation happens)? I think tcp_dissect_pdus may be smarter
> > with the memory usage, although I don't know RTMPT, so I'm not sure if it makes
> > sense for the protocol.
> At least according to
> http://osflash.org/documentation/rtmp
> the initial handshake messages have fixed lengths (1537 bytes - one byte of
> 0x03 followed by 1536 bytes - for the initial client->server message; 3073
> bytes - one byte of 0x03 followed by two 1536-byte blobs - for the
> server->client response; 1536 bytes for the final client->server message).
> Following that, all messages are in the same format; the first byte of the
> packet gives the header length, and, for 8-byte or 12-byte headers, the next 7
> bytes include the object body length. For shorter headers, the body length "is
> the same size as the last AMF sent with the same AMF number".
> So this isn't *quite* what tcp_dissect_pdu() was written to handle - the
> minimum packet length is 1 byte, but once you've determined the header length
> from that, you might not have the full packet length, and might have to get the
> next 6 bytes before you have that.
I was thinking of having a "small state machine" wrapped in dissect_rtmpt_tcp
to call tcp_dissect_pdus() to handle the handshake and subsequent messages, but
RTMPT can go over HTTP as well as TCP and the dissector has been modified to
incorprate both. The "reassembly" is done at the "common" layer above TCP/HTTP.
If the TCP side was fixed with tcp_dissect_pdus() (which would make the
buildbot happy), you'd still have the reassembly issues when going over HTTP.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.