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=testuser&password=password& >t o=12345676&from=987654321&text=Test Message (A) is being > sent!&smsc=test&dlrmask=24&dlrurl=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 * 0xdddddddd, const char * 0x10066ffc, long 289, > const char * 0x10066ff4) > octstr_duplicate_real(Octstr * 0xdddddddd) > 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/20860000/////////////////3//54657374204D65737361676 > 5202841292030206973206265696E672073656E7421//////////020111///0F> > 2003-02-03 15:11:28 [8] DEBUG: Adding DLR smsc=emi_smsc, > ts=emi_smsc-0:45676, src=20860000, 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=%d&smsc_reply=%A&receiver=%p&sender=%P&message- >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 > 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. > > > Well, while you are talking to an EMI emulator, does kannel fail in any > way? In other words, do you get a panic or such? > > > 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 -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___________________________________________ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de msn: [EMAIL PROTECTED] ------------------------------------------------------- -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___________________________________________ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de msn: [EMAIL PROTECTED]