[Biot Olivier <Olivier.Biot@xxxxxxxxxxx>]

Title: Message

Edson,

 

I attached the output of Ethereal dissection of the MMSE traffic to this mail. Clearly there are two packets identified as MMSE. However, I have TCP reassembly switched on, and also HTTP reassembly (the 2 first check boxes fot the HTTP protocol preference) switched on.

 

Regards,

 

Olivier

-----Original Message-----
From: Santos Edson-WES051

Oliver,

 

I'm also with version 0.10.4. and the result is different.

But if filter is composed with "mmse and tcp" and there is only one MMSE decoded frame, I'm not surprised that only the MMSE frame will be displayed after applying the filter.

 

Do you have any idea of what is happening?

 

Regards,

 

Edson

-----Original Message-----
From: Biot Olivier

That's really odd. My version of Ethereal (0.10.4) shows both packets 24 and 26 with the "mmse and tcp" display filter, and shows the 3 desired packets with "(mmse and tcp) or tcp.reassembled_in == 24 or tcp.reassembled_in == 26" as display filter.

 

Regards,

 

Olivier

-----Original Message-----
From: Santos Edson-WES051

Oliver,

 

Thanks for your prompt answer.

 

I did what you mentioned but did not work. In fact when I applied the 1st display filter I was able to see only frame #26.

 

Regards,

 

Edson

 

 

Hello Edson,

This is currently not possible "automatically" but you can do it this way:
1. Apply the following display filter:
mmse and tcp
2. Note all packets that match: 24, 26
3. Now create the following display filter:
(mmse and tcp) or tcp.reassembled_in == 24 or tcp.reassembled_in ==
26
4. Prontinho :)

Should you have an MMSE-over-WSP-over-UDP capture, then you replace "tcp"
with "udp" in the previous explanation.

Hope this helps!

Regards,

Olivier

-----Original Message-----
From: Santos Edson-WES051


I'm using Ethereal to decode some MMS messages and I'm able to decode the
MMSE accordingly.

Refer to the file attached, frame #22 is a HTTP Post (sending the MMS
Message) and frame #24 is the MMS message itself. Is there any way to decode
frame #24 as MMSE considering the Content-Type/Content-Legth headers from
frame #22?

Please, could some help me on that?

My Best Regards,

Edson
+55 19 3847-6187

No.     Time        Length Source                Destination           Protocol Info
     24 779.600000  653    10.103.46.241         200.142.130.150       MMSE     MMS m-send-req (application/smil) (text/plain)

Frame 24 (653 bytes on wire, 653 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src Addr: 10.103.46.241 (10.103.46.241), Dst Addr: 200.142.130.150 (200.142.130.150)
Transmission Control Protocol, Src Port: 32771 (32771), Dst Port: http (80), Seq: 423, Ack: 1, Len: 607
Hypertext Transfer Protocol
    POST http://termnat.vivomms.com.br:8088/mms HTTP/1.1\r\n
    Host: termnat.vivomms.com.br:8088\r\n
    X-Wap-Profile: "http://motorolauaprof.vivomms.com.br/v710.rdf"\r\n
    Proxy-Authorization: Basic MTk5NjAzNzQ4NDoxOTk2MDM3NDg0\r\n
        Credentials: 1996037484:1996037484
    Content-Type: application/vnd.wap.mms-message\r\n
    User-Agent: MOT-8700_/00.62 UP.Browser/6.2.3.2 (GUI) MMP/2.0\r\n
    Profile: http://motorolauaprof.vivomms.com.br/v810.rdf\r\n
    X-VIVO-MIN: 1996037484\r\n
    Content-Length: 607\r\n
    \r\n
MMS Message Encapsulation, Type: m-send-req
    X-Mms-Message-Type: m-send-req (0x80)
    X-Mms-Transaction-ID: 1088034351
    X-Mms-MMS-Version: 1.0
    Date: Jun 24, 2004 01:45:51.000000000
    X-Mms-Delivery-Report: Yes (0x80)
    X-Mms-Expiry: 432000.000000000 seconds
    From: +551996037484/TYPE=PLMN
    X-Mms-Priority: Normal (0x81)
    X-Mms-Read-Report: No (0x81)
    Subject: PPP
    To: 1996037303/TYPE=PLMN
    Content-Type: application/vnd.wap.multipart.related; type=application/smil; start=<mmmm>
        Type: application/smil
        Start: <mmmm>
    Data (Post)
        Multipart body
            Part: 1, content-type: application/smil
                Content-Type: application/smil; charset=utf-8; name=mms.smil
                    Charset: utf-8
                    Name: mms.smil
                Headers
                    Content-Id: "mmmm"
                Line-based text data: application/smil
                    <smil><head><layout><root-layout width="240" height="160"/><region id="REGION_1" left="0%" top="0%" height="67%" width="100%" fit="meet"/><region id="REGION_2" left="0%" top="67%" height="33%" width="100%" fit="meet"/></layout></head><body
            Part: 2, content-type: text/plain
                Content-Type: text/plain; charset=utf-8; name=smiltextpartfilename0.txt
                    Charset: utf-8
                    Name: smiltextpartfilename0.txt
                Headers
                    Content-Location: smiltextpartfilename0.txt
                    Content-Id: "smiltextpartfilename0.txt"
                Line-based text data: text/plain
                    D.e.d.d.

No.     Time        Length Source                Destination           Protocol Info
     26 0.700000    380    200.142.130.150       10.103.46.241         MMSE     MMS m-send-conf

Frame 26 (380 bytes on wire, 380 bytes captured)
Point-to-Point Protocol
Internet Protocol, Src Addr: 200.142.130.150 (200.142.130.150), Dst Addr: 10.103.46.241 (10.103.46.241)
Transmission Control Protocol, Src Port: http (80), Dst Port: 32771 (32771), Seq: 1, Ack: 1030, Len: 334
Hypertext Transfer Protocol
    HTTP/1.1 200 OK\r\n
    Date: Thu, 24 Jun 2004 02:43:38 GMT\r\n
    Server: Tomcat Web Server/3.3.1 Final ( JSP 1.1; Servlet 2.2 )\r\n
    Content-Type: application/vnd.wap.mms-message\r\n
    Content-Length: 51\r\n
    Via: 1.0 termwap.vivo.com.br\r\n
    X-Cache: MISS from termwap.vivo.com.br\r\n
    X-Pad: avoid browser bug\r\n
    \r\n
MMS Message Encapsulation, Type: m-send-conf
    X-Mms-Message-Type: m-send-conf (0x81)
    X-Mms-Transaction-ID: 1088034351
    X-Mms-MMS-Version: 1.0
    Response-Status: Ok (0x80)
    Message-Id: dvua602i1lcc72@xxxxxxxxxxxxxxxx