["Olivier Biot" <ethereal@xxxxxxxxxx>]

For your information, I used a post-0.10.8 SVN build on Win32 (XP SP2).

The bug does not reside in the dissector, it resides in the client code 
where an extraneous 0x00 byte fools the dissector and it basically sees a 
premature end of To header value, then it tries to dissect the "/TYPE=PLMN" 
string and remaining bytes as WSP header-value information, which of course 
doesn't make sense.

Maybe the MMS code in the handset expects an even (or odd) number of digits 
in the phone number and then incorrectly pads the resulting telephone number 
with a zero octet.

Best regards,

Olivier

----- Original Message ----- 
From: Ronnie Sahlberg

did you try it with a recent post-0.10.8 version of ethereal that had
some of the mmse related crashed fixed?
the packets were still wrong  but ethereal at least did not crash.


do you have new captures that crash even the current SVN version of 
ethereal?


win32 svn pre-prereleases containing the fix for the crashes i checked
in two days ago are available from:
http://www.ethereal.com/distribution/buildbot-builds/




On Thu, 23 Dec 2004 08:34:41 +0100, CHARBONNIER Christophe
<christophe.charbonnier@xxxxxxxxxxxx> wrote:
> Well, I also tried to open the capture-file with ethereal (GUI), but it 
> stops at 4% of loading with a first popup window:
> +--------------------------------------------------------------+
> | *** ERROR ***: file proto.c: line 1315: assertion failed...  |
> +--------------------------------------------------------------+
>
> And then a 2nd popup window saying:
> +-------------------------------------------------------------------------------+
> | Microsoft Visual C++ Runtime Library 
> |
> | Runtime Error! 
> |
> | Program: C:\Program Files\Ethereal\ethereal.exe 
> |
> | 
> |
> | This application has requested the Runtime to terminate it in an unusual 
> way. |
> | Please contact the application's support team for more information 
> |
> +-------------------------------------------------------------------------------+
>
> It then exit... I am unable to open it in any way...
> I tried on Windows XP Pro SP2 with ethereal 0.10.8
>
> Oups, never mind, I just tried on a Linux-box, ethereal version 0.9.15, 
> and it opens without complaining... Surely the MMSE dissector has evolved 
> between 0.9.15 and 0.10.8...
>
> Well, now I got it, I can go further on...
>
> Thank you anyway for your answers...
> Christophe
>
> -----Original Message-----
> From: Olivier Biot [mailto:ethereal@xxxxxxxxxx]
> Sent: mercredi 22 d�cembre 2004 19:58
> To: Ethereal development
> Subject: MMSE problem (was Re: [Ethereal-dev] Strange assertion)
>
> Hello Christophe,
>
> As a matter of fact, I looked at the packet with Ethereal, not tethereal. 
> i could then jump to the reassembled packet and peek into it.
>
> this way I could spot several errors, like the erratic address and an 
> incorrect MMS version (the X-Mms-Previously-Sent-Date header was first 
> defined in MMS 1.1). I could not find the User-Agent string of the MMS 
> phone in the provided capture (the WSP Connect PDU was not present).
>
> And I just realized I incorrectly formulated the address format error in 
> my previsous post: the problem is the extraneous 0x00 octet between the 
> MSISDN and the address type qualifier "/TYPE=PLMN" in the "To" header 
> value.
>
> Please note that it is normal that Ethereal takes lots of time dissecting 
> this packet, as reassembly occurs over 92 packets!
>
> [For the people having compiled Ethereal with profiling enabled, it would 
> be interesting to see the profiling results with this packet capture, when 
> the user repeatedly clicks on frame 112's WSP or MMSE content!]
>
> Best regards,
>
> Olivier
>
> ----- Original Message -----
> From: CHARBONNIER Christophe
>
> Thank you for your answer
>
> But could you tell me how you "take a closer look" ??
> I try to dissect the file with tethereal, with the "-V" option set to go 
> deep inside the packets, but the only thing I can see is all the preceding 
> packets well decoded, and then, the assertion raises on decoding of frame 
> 112. But I have no information at all about this particular frame !
>
> Without the -V option, I can see it's a MMS m-send-req frame, but that's 
> all...
>
> Anyway, I tried to understand a little closer about the code which raises 
> the assertion:
> I found that the "dissect_mmse" function is guilty, when dissecting the 
> "X-Mms-Previously-Sent-Date" header... But now, I cannot go any further 
> because, as I told before, I am not able to see any of the already 
> dissected information... (I suspect the phone used to send the MMS to not 
> correctly format its MMSE-packets)
>
> Any help on that would be appreciated
>
> -----Original Message-----
> From: Olivier Biot
>
> Christophe,
>
> This packet looks very odd. Upon closer inspection I suspect some code 
> incorrectly translates the address from WAP Puah format (as used over PAP) 
> to MSISDN format: take a closer look at the extraneous string "/TYPE=PLMN"
> after the trailing zero octet.
>
> Probably this is a capture of a prototype system. Anyway, the 500 server 
> error in packet 114 confirms my findings (malformed MMSE packet). Try 
> fixing that address isssue, and then perform another capture. Hopefully 
> that one will yield positive results!
>
> Best regards,
>
> Olivier
>
> ----- Original Message -----
> From: ronnie sahlberg
>
> > there were a couple of things wrong in the dissector which caused it
> > to dump core.
> > i have checked in fixes for the dissector so it does not dump core any
> > more.
> >
> > thanks for the example capture.
> >
> >
> >
> > On Tue, 21 Dec 2004 16:24:23 +0100, CHARBONNIER Christophe Christophe
> > Charbonnier wrote:
> >> Hi everyone,
> >>
> >> I have a MMSE transaction which makes (t)ethereal to stop on an
> >> assertion:
> >> =====================================================================
> >> ===
> >> =======
> >> ** ERROR **: file proto.c: line 1296 (proto_tree_add_string):
> >> assertion
> >> failed: (hfinfo->type == FT_STRING || hfinfo->type == FT_STRINGZ)
> >> =====================================================================
> >> ===
> >> =======
> >>
> >> With some little investigations, I figured out that hfinfo->type is
> >> set to 15 (FT_ABSOLUTE_TIME [date/time]) on this particular frame
> >> (number 112). The assertion is then understood.
> >> But why is this packet wrong ??
> >>
> >> Could some-one tell me more about it ???
> >>
> >> The capture-file is attached...
> >>
> >> Thank you for your help
> >> Christophe
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev