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
