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-6666333 Fax: +41-61-6666334 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/
