Re: [PATCH] Re: EMI Driver Bug
On Sonntag, Februar 16, 2003, at 04:31 Uhr, Stipe Tolj wrote: Alexander Malysh wrote: Hi All, attached patch should solve the bug , make small cleanup and add additional sanity check... please look in it and vote ... ok, we had positive votes on this, so I'm commiting this. AFAIS, Andreas was the only one with objections?! If he doesn't veto the patch, we'll leave it in. No. its ok now. the code was only called in a specific case where it really made no sense to do what it was doing. Andreas Fink Global Networks Switzerland AG -- Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association
Re: [PATCH] Re: EMI Driver Bug
Alexander Malysh wrote: Hi All, attached patch should solve the bug , make small cleanup and add additional sanity check... please look in it and vote ... ok, we had positive votes on this, so I'm commiting this. AFAIS, Andreas was the only one with objections?! If he doesn't veto the patch, we'll leave it in. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: EMI Driver Bug
Ok, I'm a bit confused now. What is the consensus of the discussion? I currently see only Alexander's patch here. Any votes? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: EMI Driver Bug
Citando Michael Mulcahy [EMAIL PROTECTED]: 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. Indeed 51/R 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. I guess you are right, although old versions didn't have this problem - I use dlr=255 to activate every kind of dlr in my some-month-old kannel in production. This code handles only receiving and 'R' packets. It's an if( OR=R OT=51) then, so there's no 50_AMSG field available. Then there's a different code to handle OR=O, OT=53 at line 721, and there is an if((emimsg-fields[E50_AMSG]) == NULL) msg-sms.msgdata = octstr_create(Delivery Report without text); else msg-sms.msgdata = octstr_duplicate(emimsg-fields[E50_AMSG]); This looks like a copy-paste to me. Your patch is cleaner that doing something like this lines because, indeed, there's no 50_AMSG in OR=R I'm +1 for it Look forward to hearing from you, Warm Regards, Michael. 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 13:19 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: EMI Driver Bug On Montag, Februar 3, 2003, at 01:23 Uhr, Michael Mulcahy wrote: Hi All, Summary: The assigning of a nonexistent field in the EMI driver when creating a submission report results in an out of bounds read. Scenario: The EMI driver checks for a DLR when a response is received for a submitted message. If there is a DLR requested for that message then the driver does the following: /* * Recode the msg structure with the given msgdata. * Note: the DLR URL is delivered in msg-sms.dlr_url already. */ dlrmsg-sms.msgdata = octstr_duplicate(emimsg-fields[E50_AMSG]); octstr_hex_to_binary(dlrmsg-sms.msgdata); dlrmsg-sms.sms_type = report; Why does the driver assign the value of the E50_AMSG field to the msgdata of the dlr message? The AMSG field does contain the delivery report text of the SMSC. This is a text of style The message to 12345 with referenfce number 1847127 has been delivered on 12.1.2003 14:25 This field is not available in the EMI response. The response EMI message only has three fields so the above code accesses data beyond the array bounds as E50_AMSG has a value of 20. 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. 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. When the message has been delivered to the handset, the SMSC generates an incoming message of type Delivery Report which has all fields, much similar to an incoming SMS. Andreas Fink Global Networks Switzerland AG -- Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association -- br/ - This mail sent through IMP: http://horde.org/imp/
Re: EMI Driver Bug
On Montag, Februar 3, 2003, at 01:23 Uhr, Michael Mulcahy wrote: Hi All, Summary: The assigning of a nonexistent field in the EMI driver when creating a submission report results in an out of bounds read. Scenario: The EMI driver checks for a DLR when a response is received for a submitted message. If there is a DLR requested for that message then the driver does the following: /* * Recode the msg structure with the given msgdata. * Note: the DLR URL is delivered in msg->sms.dlr_url already. */ dlrmsg->sms.msgdata = octstr_duplicate(emimsg->fields[E50_AMSG]); octstr_hex_to_binary(dlrmsg->sms.msgdata); dlrmsg->sms.sms_type = report; Why does the driver assign the value of the E50_AMSG field to the msgdata of the dlr message? The AMSG field does contain the delivery report text of the SMSC. This is a text of style "The message to 12345 with referenfce number 1847127 has been delivered on 12.1.2003 14:25" This field is not available in the EMI response. The response EMI message only has three fields so the above code accesses data beyond the array bounds as E50_AMSG has a value of 20. 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. 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. When the message has been delivered to the handset, the SMSC generates an incoming message of type "Delivery Report" which has all fields, much similar to an incoming SMS. Andreas Fink Global Networks Switzerland AG -- Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association
RE: EMI Driver Bug
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.
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.
The EMI2 driver does the following when a response to a submit operation is
received:
Some code removed for brevity
if (emimsg-ot == 51) {
if (PRIVDATA(conn)-slots[emimsg-trn].dlr) {
...
dlrmsg = dlr_find(octstr_get_cstr((conn-id ? conn-id :
privdata-name)),
octstr_get_cstr(ts), /* timestamp */
octstr_get_cstr(origmsg-sms.receiver), /*
destination */
(octstr_get_char(emimsg-fields[0], 0) ==
'A' ?
DLR_SMSC_SUCCESS : DLR_SMSC_FAIL));
octstr_destroy(ts);
if (dlrmsg != NULL) {
...
/*
* Recode the msg structure with the given msgdata.
* Note: the DLR URL is delivered in msg-sms.dlr_url
already.
*/
dlrmsg-sms.msgdata =
octstr_duplicate(emimsg-fields[E50_AMSG]);
octstr_hex_to_binary(dlrmsg-sms.msgdata);
dlrmsg-sms.sms_type = report;
This is the code for handling a response to a submit short message operation
and
checking if the user requested notification that the message was submitted
to
the SMSC.
So as per my original mail why does the driver try to reference the E50_AMSG
field from the
response of submitted message?
I have checked CVS and it appears our emi2 module is up to date. I can
understand the
driver doing this for a delivery report as the field exists in a delivery
report message
but not for an acknowledgement to a submitted message. Does your SMSC send
acknowledgements
that include the E50_AMSG field?
We have being testing with an EMI emulator that claims to implement the EMI
standard, version 4.
Look forward to hearing from you,
Warm Regards,
Michael.
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 13:19
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: EMI Driver Bug
On Montag, Februar 3, 2003, at 01:23 Uhr, Michael Mulcahy wrote:
Hi All,
Summary:
The assigning of a nonexistent field in the EMI driver when creating a
submission
report results in an out of bounds read.
Scenario:
The EMI driver checks for a DLR when a response is received for a submitted
message.
If there is a DLR requested for that message then the driver does the
following:
/*
* Recode the msg structure with the given msgdata.
* Note: the DLR URL is delivered in msg-sms.dlr_url already.
*/
dlrmsg-sms.msgdata = octstr_duplicate(emimsg-fields[E50_AMSG]);
octstr_hex_to_binary(dlrmsg-sms.msgdata);
dlrmsg-sms.sms_type = report;
Why does the driver assign the value of the E50_AMSG field to the msgdata of
the
dlr message?
The AMSG field does contain the delivery report text of the SMSC.
This is a text of style The message to 12345 with referenfce number 1847127
has been delivered on 12.1.2003 14:25
This field is not available in the EMI response. The response EMI message
only has three fields so the above code accesses data beyond the array
bounds as
E50_AMSG has a value of 20.
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. 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. When
the message has been delivered to the handset, the SMSC generates an
incoming message of type Delivery Report which has all fields, much
similar to an incoming SMS.
Andreas Fink
Global Networks Switzerland AG
--
Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333
Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland
Web: http://www.global-networks.ch/ [EMAIL PROTECTED
RE: EMI Driver Bug
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=testuserpassword=passwordt
o=12345676from=987654321text=Test Message (A) is being
sent!smsc=testdlrmask=24dlrurl=http://synge/test.asp?mask=%25d%26smsc_rep
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//54657374204D65737361676
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=%psender=%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 record with the full
data to the storage. This one is the one being searched when the message
finally gets delivered.
The EMI2 driver does the following when a response to a submit operation is
received:
Some code removed for brevity
if (emimsg-ot == 51) {
if (PRIVDATA(conn)-slots[emimsg-trn].dlr) {
...
dlrmsg = dlr_find(octstr_get_cstr((conn-id ? conn-id :
privdata-name)),
octstr_get_cstr(ts), /* timestamp */
octstr_get_cstr(origmsg-sms.receiver), /* destination */
(octstr_get_char(emimsg-fields[0], 0) == 'A' ?
DLR_SMSC_SUCCESS : DLR_SMSC_FAIL));
octstr_destroy(ts);
if (dlrmsg != NULL) {
...
/*
* Recode the msg structure with the given msgdata.
* Note: the DLR URL is delivered in msg-sms.dlr_url
already.
*/
dlrmsg-sms.msgdata =
octstr_duplicate(emimsg-fields[E50_AMSG]);
octstr_hex_to_binary(dlrmsg-sms.msgdata);
dlrmsg-sms.sms_type = report;
This is the code for handling a response to a submit short message operation
and checking if the user requested notification that the message was
submitted
to the SMSC.
I have to look into the code but it might be simply a non-fatal bug here.
So as per my original mail why does the driver try to reference the E50_AMSG
field from the response of submitted message?
I have checked CVS and it appears our emi2 module is up to date. I can
understand the driver doing this for a delivery report as the field exists
in a delivery
report message but not for an acknowledgement to a submitted message. Does
Fwd: Re: EMI Driver Bug
Subject: Re: EMI Driver Bug
Date: Montag, 3. Februar 2003 16:56
From: Alexander Malysh [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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=testuserpassword=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//54657374204D65737361676
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=%psender=%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 record with the full
data to the storage. This one is the one being searched when the message
finally gets delivered.
The EMI2 driver does the following when a response to a submit operation is
received:
Some code removed for brevity
if (emimsg-ot == 51) {
if (PRIVDATA(conn)-slots[emimsg-trn].dlr) {
...
dlrmsg = dlr_find(octstr_get_cstr((conn-id ? conn-id :
privdata-name)),
octstr_get_cstr(ts), /* timestamp */
octstr_get_cstr(origmsg-sms.receiver), /* destination */
(octstr_get_char(emimsg-fields[0], 0) == 'A' ?
DLR_SMSC_SUCCESS : DLR_SMSC_FAIL));
octstr_destroy(ts);
if (dlrmsg != NULL) {
...
/*
* Recode the msg structure with the given msgdata.
* Note: the DLR URL is delivered in msg-sms.dlr_url
already.
*/
dlrmsg-sms.msgdata =
octstr_duplicate(emimsg-fields[E50_AMSG]);
octstr_hex_to_binary(dlrmsg-sms.msgdata);
dlrmsg-sms.sms_type = report;
This is the code for handling a response to a submit short message
operation and checking if the user requested notification that the message
was submitted
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=testuserpassword=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//54657374204D65737361676
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=%psender=%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 record with the full
data to the storage. This one is the one being searched when the message
finally gets delivered.
The EMI2 driver does the following when a response to a submit operation is
received:
Some code removed for brevity
if (emimsg-ot == 51) {
if (PRIVDATA(conn)-slots[emimsg-trn].dlr) {
...
dlrmsg = dlr_find(octstr_get_cstr((conn-id ? conn-id :
privdata-name)),
octstr_get_cstr(ts), /* timestamp */
octstr_get_cstr(origmsg-sms.receiver), /* destination */
(octstr_get_char(emimsg-fields[0], 0) == 'A' ?
DLR_SMSC_SUCCESS : DLR_SMSC_FAIL));
octstr_destroy(ts);
if (dlrmsg != NULL) {
...
/*
* Recode the msg structure with the given msgdata.
* Note: the DLR URL is delivered in msg-sms.dlr_url
already.
*/
dlrmsg-sms.msgdata =
octstr_duplicate(emimsg-fields[E50_AMSG]);
octstr_hex_to_binary(dlrmsg-sms.msgdata);
dlrmsg-sms.sms_type = report;
This is the code for handling a response to a submit short message
operation and checking if the user requested notification that the message
was submitted
to the SMSC.
I have to look into the code but it might be simply a non-fatal bug here.
So as per my original mail why
RE: EMI Driver Bug
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
record with the full
data to the storage. This one is the one being searched
when the message
finally gets delivered.
The EMI2 driver does the following when a response to a
submit operation is
received:
Some code removed for brevity
if (emimsg-ot == 51) {
if (PRIVDATA(conn)-slots[emimsg-trn].dlr) {
...
dlrmsg = dlr_find(octstr_get_cstr((conn-id ? conn-id :
privdata-name
[PATCH] Re: EMI Driver Bug
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
Re: EMI Driver Bug
Hello! this patch helps me: --- smsc_emi2.c.origWed Nov 13 15:06:39 2002 +++ smsc_emi2.c Wed Nov 13 15:08:25 2002 @@ -976,7 +976,7 @@ static int emi2_handle_smscreq (SMSCConn * Recode the msg structure with the given msgdata. * Note: the DLR URL is delivered in msg-sms.dlr_url already. */ -dlrmsg-sms.msgdata = octstr_duplicate(emimsg-fields[E50_AMSG]); + dlrmsg-sms.msgdata = octstr_create(); octstr_hex_to_binary(dlrmsg-sms.msgdata); dlrmsg-sms.sms_type = report; with best wishes German Aksenov phone: (095)258-7258 ext. 7836
