Loïc Minier wrote:
Hey,
I crashed mbuni 1.0.0 today as follow:
2006-01-06 15:42:45 [21530] [371] WARNING: Unexpected field value type 3 for
header X-Mms-Transaction-Id
2006-01-06 15:42:45 [21530] [371] WARNING: Skipping faulty header [code = 24,
val=-1]!
2006-01-06 15:42:45 [21530] [371] PANIC: gwlib/octstr.c:2326: seems_valid_real:
Assertion `ostr != NULL' failed. (Called from
gwlib/octstr.c:975:octstr_search_char.)
2006-01-06 15:42:45 [21530] [371] PANIC: /usr/bin/mmsproxy(gw_panic+0x19a)
[0x808b9d7]
2006-01-06 15:42:45 [21530] [371] PANIC: /usr/bin/mmsproxy [0x8093860]
2006-01-06 15:42:45 [21530] [371] PANIC:
/usr/bin/mmsproxy(octstr_search_char+0x29) [0x808fc2e]
2006-01-06 15:42:45 [21530] [371] PANIC:
/usr/bin/mmsproxy(mms_getqf_fromtransid+0x21) [0x8069eeb]
2006-01-06 15:42:45 [21530] [371] PANIC: /usr/bin/mmsproxy [0x805597d]
2006-01-06 15:42:45 [21530] [371] PANIC: /usr/bin/mmsproxy [0x8081a7e]
2006-01-06 15:42:45 [21530] [371] PANIC: /lib/tls/libpthread.so.0 [0xb7eb0b63]
2006-01-06 15:42:45 [21530] [371] PANIC: /lib/tls/libc.so.6(__clone+0x5a)
[0xb7c7018a]
I have a capture of the MMS (I'm afraid I can't disclose the content to
the list, but I can provide some headers or other data on request)
before it reached Mbuni, and I still have a copy of the queue files.
This was while sending a message from MM3 to MM1, at the time a phone
was Fetching the message.
I tried sending the same data over SMTP again, to the same phone and to
other phones, but mbuni didn't crash anymore.
The phone that triggered this is a Motorola Razor with the following UA:
UA:MOT-V3/0E.40.3CR MIB/2.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.0
The WAP GW is a pure HTTP proxy (this phone uses WAP 2.0).
This is the relevant access log.
2006-01-06 15:42:13 Received MMS [INT:MM3] [ACT:] [MMSC:] [from:XXX]
[to:+336XXX/TYPE=PLMN] [msgid:<XXX>] [size=-1] [UA:] [MMBox:]
2006-01-06 15:42:19 Notify MMS [INT:MM1] [ACT:] [MMSC:] [from:system]
[to:+336XXX/TYPE=PLMN] [msgid:[EMAIL PROTECTED] [size=-1] [UA:] [MMBox:]
2006-01-06 15:42:39 Fetched MMS [INT:MM1] [ACT:] [MMSC:] [from:XXX]
[to:y/TYPE=PLMN] [msgid:[EMAIL PROTECTED] [size=2661] [UA:MOT-V3/0E.40.3CR
MIB/2.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.0] [MMBox:]
I'm in the process of moving to a CVS snapshot of Mbuni, but I couldn't
spot anything obviously related in the cvs log, so I can't tell whether
that would solve the issue.
now, 2 points here:
1) The MMS header is malformed. Mbuni unpacks the header and wsp_field_value()
returns WSP_FIELD_VALUE_DATA instead of WSP_FIELD_VALUE_NUL_STRING, which causes
the first WARNING message.
For the X-Mms-Transaction-Id header we have the following for it's value in the
WAP-209-MMSEncapsulation-20020105-a.pdf spec: section 7.2.26:
Transaction-id-value = Text-string, which means it should be a NUL terminated
string and hence indicated via the first octet while wsp_field_value() does it's
parsing.
Obiously the header looks like this:
X-Mms-Transaction: <0x1F><0xXX..data..0xYY>
and wsp_field_value() interprets corretly the 0x1F as WSP_FIELD_VALUE_DATA.
Hence it's not a well known field and the value is -1 indicating that there is
no "well known" value for that type.
From my interpretation, the MMS should have a WSP_FIELD_VALUE_NUL_STRING there,
which Mbuni also does expect.
2) since point 1) obviously does not process any transaction ID for the message
the upcoming call to mmlib/mms_util.c:mms_getqf_fromtransid() which gets the
value for it passed (NULL at that time) runs into PANIC, since
octstr_search_char() expects in it's assertion check that a non-NULL value is
passed.
We can fix point 2) via the attached patch. But there may be more PANICs
following, since Mbuni assumes pretty straight forward that the transaction ID
is given and hence that the patched function returns always a non-NULL value.
@Paul: can you please commit the obvious fix.
Also in addition to the patch, we need to check __after__ decoding the headers
that all "mandatory" headers are present for further processing. If there is a
mandatory header missing for the required PDU type, Mbuni should discard the PDU
and keep processing other PDUs, dropping the malformed one.
This can be done using Kannel's c-pre-processor magic very elegantly, by
defining which headers are required by which PDU type.
BTW, would be a good chance to announce mantis, in order to keep these kind of
bugs tracked? ;)
Stipe
Index: mms_util.c
===================================================================
RCS file: /cvsroot/mbuni/mbuni/mmlib/mms_util.c,v
retrieving revision 1.33
diff -u -r1.33 mms_util.c
--- mms_util.c 6 Nov 2005 08:56:13 -0000 1.33
+++ mms_util.c 7 Jan 2006 03:00:58 -0000
@@ -186,6 +186,11 @@
extern Octstr *mms_getqf_fromtransid(Octstr *transid)
{
+ int i;
+
+ if (transid == NULL)
+ return NULL;
+
int i = octstr_search_char(transid, '@', 0);
return (i >= 0) ? octstr_copy(transid, 0, i) : octstr_duplicate(transid);
_______________________________________________
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org
