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-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/