Hi All,
attached patch should solve the bug , make small cleanup and add additional sanity
check...
please look in it and vote ...
Am Montag, 3. Februar 2003 19:08 schrieb Michael Mulcahy:
Michael you are right...
should we replace: dlrmsg-sms.msgdata =
octstr_duplicate(emimsg-fields[E50_AMSG]); with:
dlrmsg-sms.msgdata =
octstr_create();
?
I think so, unless other people working with EMI have a better idea!
ANAM Wireless Internet Solutions
http://www.anam.com mailto:[EMAIL PROTECTED]
+353 1 284 7555
Castle Yard, Saint Patrick's Road, Dalkey, County Dublin, Ireland
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Alexander Malysh (by
way of Alexander Malysh [EMAIL PROTECTED])
Sent: 03 February 2003 15:57
To: [EMAIL PROTECTED]
Subject: Re: EMI Driver Bug
Hi All,
Michael you are right...
should we replace: dlrmsg-sms.msgdata =
octstr_duplicate(emimsg-fields[E50_AMSG]); with:
dlrmsg-sms.msgdata =
octstr_create();
?
Am Montag, 3. Februar 2003 16:38 schrieb Michael Mulcahy:
Hi All,
more information for your understanding:
When I submit a message with a dlr mask of 24, the
bearerbox crashes,
Used following sendsms request:
http://127.0.0.1:22022/cgi-bin/sendsms?username=testuserpassw
ord=password
t o=12345676from=987654321text=Test Message (A) is being
sent!smsc=testdlrmask=24dlrurl=http://synge/test.asp?mask=%
25d%26smsc_re
p ly=%25A%26receiver=%25p%26sender=%25P
Here is a stack trace of the problem:
seems_valid_real(Octstr * 0x, const char *
0x10066ffc, long 289,
const char * 0x10066ff4)
octstr_duplicate_real(Octstr * 0x)
emi2_handle_smscreq(smscconn * 0x00d706f0, Connection * 0x00d73420)
emi2_send_loop(smscconn * 0x00d706f0, Connection * * 0x0188ff1c)
emi2_sender(void * 0x00d706f0)
new_thread(void * 0x00d727d0)
dlrmsg-sms.msgdata = octstr_duplicate(emimsg-fields[E50_AMSG]);
is the line in question within the emi2_handle_smscreq function.
corresponding bearerbox trace:
2003-02-03 15:11:28 [22] DEBUG: boxc_receiver: sms received
2003-02-03 15:11:28 [8] DEBUG: EMI2[emi_smsc]: emi2 sending packet:
00/00138/O/51/12345676/2086/3//5465737420
4D65737361676
5202841292030206973206265696E672073656E7421//020111///0F
2003-02-03 15:11:28 [8] DEBUG: Adding DLR smsc=emi_smsc,
ts=emi_smsc-0:45676, src=2086, dst=12345676, mask=24,
boxc=192.168.0.97:62982
2003-02-03 15:11:28 [8] DEBUG: EMI2[emi_smsc]: Got packet
from the main
socket
2003-02-03 15:11:28 [8] DEBUG: EMI2[emi_smsc]: emi2 parsing packet:
00/00041/R/51/A//12345676:030203150828/D3
2003-02-03 15:11:28 [8] DEBUG: Looking for DLR smsc=emi_smsc,
ts=emi_smsc-0:45676, dst=12345676, type=8
2003-02-03 15:11:28 [8] DEBUG: created DLR message for URL
http://synge/test.asp?mask=%dsmsc_reply=%Areceiver=%psende
r=%Pmessage-
n umber=0
This occurs as the EMI driver is accessing a field
(E50_AMSG) that is not
available in an EMI acknowledgement. It is surprising that
no one has
experienced
this problem in Kannel already with dlr_masks set to 24.
ANAM Wireless Internet Solutions
http://www.anam.com mailto:[EMAIL PROTECTED]
+353 1 284 7555
Castle Yard, Saint Patrick's Road, Dalkey, County Dublin, Ireland
-Original Message-
From: Andreas Fink [mailto:[EMAIL PROTECTED]]
Sent: 03 February 2003 14:30
To: [EMAIL PROTECTED]
Subject: Re: EMI Driver Bug
On Montag, Februar 3, 2003, at 03:22 Uhr, Michael Mulcahy wrote:
Hi All,
Comments Below:
You're mixing up the SMSC response with the delivery report.
When you send a message, you send a type 51 message. you will
get a 50ACK back saying the SMSC has accepted the SMS.
Is this a typo on your part? According to the EMI spec 4.0
the response to
the submit short message operation 51 should contain an
operation type of
51 not 50.
the ACK of all type 50 messages are the same. So this is of
course a ACK
for 51.
This is NOT the delivery report. The SMSC response is
acknowledging that
the SMSC has accepted the message but it doesnt say that the message
has been delivered to the handset.
I think there is a misunderstanding of terminology here. I
use the term
submission notification to mean that the message was
submitted to the SMSC
not delivered to the handset.
well this is not a delivery report then and I think the
code snipped you
are showing is not executed in this case.
note: in terms of DLR storage there are two things happening:
when submission report is asked, it is adding a
temporarely DLR record
with the sequence ID to the storage.
when the submission is OK, then it adds a final DLR
