On Jan 26, 2004, at 3:00 PM, Sean Schneyer (TX/EUS) wrote:
I tried setting the preferences as you suggested and that didn't
change the behavior.
I.e., even with the preferences off, frame 248 is marked as an MMS
m-send-req?
That's what happens when I read the capture. Frame 248 is the *LAST*
packet with a TCP segment for the MMS m-send-req that starts in frame
147 and includes frame 149.
Frame 147 is the HTTP POST method line and headers. Frame 149 is the
first frame of the body of the HTTP POST, i.e. the first frame of the
MMS m-send-req.
Prior to the addition of support for HTTP reassembly and dissection
based on HTTP media types, the MMSE dissector was a heuristic dissector
atop HTTP, so it would be handed HTTP payload and thus would see frame
149 as the beginning of an MMSE MMS m-send-req.
Now, however, it's registered as a dissector for the
"application/vnd.wap.mms-message" media type, which means the HTTP
dissector will call it only if it knows that the media type is
"application/vnd.wap.mms-message" - which it won't do unless it's
reassembling the HTTP headers and data, because otherwise the headers,
including "Content-Type", are in one frame and the MMSE body is in
another frame.
So MMSE support isn't broken; it's just that HTTP support behaves
differently (and better, as it can now dissect the *entire* MMSE
message, for example).
(BTW, Olivier, should application/smil be handed to the generic
line-based text data dissector?)
(Also, is the MMS message in that capture an indication that when I get
a mobile phone I should consider *not* getting an MMS-capable phone?
Perhaps SMS is to MMS as text-based mail is to multimedia mail - I
guess it's useful to have a multimedia-capable {mail reader, phone},
but I fear it's a capability all too easy to abuse. I can image that
I'd probably even just get pretty tired after a while of having my
phone play a few bars of "Misirlou" or "Romantist" or "London Calling"
every time it rings....)
