["Olivier Biot" <ethereal@xxxxxxxxxx>]

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