RE: [BUG] failure to send DLR with SMPP
-Original Message- From: Alan McNatty [mailto:[EMAIL PROTECTED]] I experience the same problem but haven't been working on it lately (dlr's on back burner at present). I have patched local copy to get working though, my patch does something simple like ... from handle_pdu - deliver_sm if ( pdu-u.deliver_sm.destination_addr != NULL ) tmp_addr = pdu-u.deliver_sm.destination_addr; else tmp_addr = pdu-u.deliver_sm.source_addr; So rather than changing the dlr_find I have not did that - simply commented that the change to dlr_find() which has no correlation with SMPP caused this bug to surface we work around a smpp bug from smsc by building the *right* pdu (it is really a break in protocol standard so IMHO this is the better place to do it). I didn't understand your patch - are you suggesting that getting the receiver of the original message in the source_addr field of the DLR report is not compliant with the SMPP protocol ? -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. The biggest lies: 23. Now, I'm going to tell you the truth Cheers, Alan On Wed, 2002-09-25 at 05:00, Oded Arbel wrote: Hi list. we found a problem with SMPP in one of out connections - when a deliver_sm of type DLR is received, Kannel will fetch a dlr with the sms.receiver set to the destination_addr from the deliver_sm. at least on the connection we checked, this is wrong as the deliver_sm message has the source_addr set to the MSISDN of the receiver of the original message and the destination_addr set to the sender of the original address - as if the message is an MO in response to the MT we sent. of course, the result is that in the created DLR message, the sender and receiver numbers are identical and so smsbox rejects the message. I think it can only happen in the CVS version of Kannel, as only lately a change has been made to the DLR scheme to remeber also the sender of the original message and fill it in the DLR message. Did anyone else encounter this problem, and do you think its safe to fix it by changing the call to dlr_find() to use source_addr instead of destination_addr - the dlr_find() function does not do anything interesting with that value, except putting it into the receiver field of the DLR msg. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Wasting time is an important part of living.
Re: [BUG] failure to send DLR with SMPP
Hi Oded, I experience the same problem but haven't been working on it lately (dlr's on back burner at present). I have patched local copy to get working though, my patch does something simple like ... from handle_pdu - deliver_sm if ( pdu-u.deliver_sm.destination_addr != NULL ) tmp_addr = pdu-u.deliver_sm.destination_addr; else tmp_addr = pdu-u.deliver_sm.source_addr; So rather than changing the dlr_find we work around a smpp bug from smsc by building the *right* pdu (it is really a break in protocol standard so IMHO this is the better place to do it). Cheers, Alan On Wed, 2002-09-25 at 05:00, Oded Arbel wrote: Hi list. we found a problem with SMPP in one of out connections - when a deliver_sm of type DLR is received, Kannel will fetch a dlr with the sms.receiver set to the destination_addr from the deliver_sm. at least on the connection we checked, this is wrong as the deliver_sm message has the source_addr set to the MSISDN of the receiver of the original message and the destination_addr set to the sender of the original address - as if the message is an MO in response to the MT we sent. of course, the result is that in the created DLR message, the sender and receiver numbers are identical and so smsbox rejects the message. I think it can only happen in the CVS version of Kannel, as only lately a change has been made to the DLR scheme to remeber also the sender of the original message and fill it in the DLR message. Did anyone else encounter this problem, and do you think its safe to fix it by changing the call to dlr_find() to use source_addr instead of destination_addr - the dlr_find() function does not do anything interesting with that value, except putting it into the receiver field of the DLR msg. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Wasting time is an important part of living.
RE: [BUG] failure to send DLR with SMPP
Sorry Oded I misread your original post - the deliver_sm pdu I receive from smsc has source addr not destination, no relation to result of dlr_find. Ignore me it's late here ;-) On Wed, 2002-10-02 at 21:00, Oded Arbel wrote: -Original Message- From: Alan McNatty [mailto:[EMAIL PROTECTED]] I experience the same problem but haven't been working on it lately (dlr's on back burner at present). I have patched local copy to get working though, my patch does something simple like ... from handle_pdu - deliver_sm if ( pdu-u.deliver_sm.destination_addr != NULL ) tmp_addr = pdu-u.deliver_sm.destination_addr; else tmp_addr = pdu-u.deliver_sm.source_addr; So rather than changing the dlr_find I have not did that - simply commented that the change to dlr_find() which has no correlation with SMPP caused this bug to surface we work around a smpp bug from smsc by building the *right* pdu (it is really a break in protocol standard so IMHO this is the better place to do it). I didn't understand your patch - are you suggesting that getting the receiver of the original message in the source_addr field of the DLR report is not compliant with the SMPP protocol ? -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. The biggest lies: 23. Now, I'm going to tell you the truth Cheers, Alan On Wed, 2002-09-25 at 05:00, Oded Arbel wrote: Hi list. we found a problem with SMPP in one of out connections - when a deliver_sm of type DLR is received, Kannel will fetch a dlr with the sms.receiver set to the destination_addr from the deliver_sm. at least on the connection we checked, this is wrong as the deliver_sm message has the source_addr set to the MSISDN of the receiver of the original message and the destination_addr set to the sender of the original address - as if the message is an MO in response to the MT we sent. of course, the result is that in the created DLR message, the sender and receiver numbers are identical and so smsbox rejects the message. I think it can only happen in the CVS version of Kannel, as only lately a change has been made to the DLR scheme to remeber also the sender of the original message and fill it in the DLR message. Did anyone else encounter this problem, and do you think its safe to fix it by changing the call to dlr_find() to use source_addr instead of destination_addr - the dlr_find() function does not do anything interesting with that value, except putting it into the receiver field of the DLR msg. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Wasting time is an important part of living. -- Alan McNatty [ [EMAIL PROTECTED] ] 29a Washington Av, Brooklyn, Wellington -- [ Phone: 21-312136/4-3850759 ] --
RE: [BUG] failure to send DLR with SMPP
-Original Message- From: Alan McNatty [mailto:[EMAIL PROTECTED]] Sorry Oded I misread your original post - the deliver_sm pdu I receive from smsc has source addr not destination, Ok - and for DLR - does the source address contain the number of the original message receiver or sender ? no relation to result of dlr_find. Ignore me it's late here ;-) That's ok :-) -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. If you can't win by reason, go for volume. -- Calvin and Hobbes On Wed, 2002-10-02 at 21:00, Oded Arbel wrote: -Original Message- From: Alan McNatty [mailto:[EMAIL PROTECTED]] I experience the same problem but haven't been working on it lately (dlr's on back burner at present). I have patched local copy to get working though, my patch does something simple like ... from handle_pdu - deliver_sm if ( pdu-u.deliver_sm.destination_addr != NULL ) tmp_addr = pdu-u.deliver_sm.destination_addr; else tmp_addr = pdu-u.deliver_sm.source_addr; So rather than changing the dlr_find I have not did that - simply commented that the change to dlr_find() which has no correlation with SMPP caused this bug to surface we work around a smpp bug from smsc by building the *right* pdu (it is really a break in protocol standard so IMHO this is the better place to do it). I didn't understand your patch - are you suggesting that getting the receiver of the original message in the source_addr field of the DLR report is not compliant with the SMPP protocol ? -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. The biggest lies: 23. Now, I'm going to tell you the truth Cheers, Alan On Wed, 2002-09-25 at 05:00, Oded Arbel wrote: Hi list. we found a problem with SMPP in one of out connections - when a deliver_sm of type DLR is received, Kannel will fetch a dlr with the sms.receiver set to the destination_addr from the deliver_sm. at least on the connection we checked, this is wrong as the deliver_sm message has the source_addr set to the MSISDN of the receiver of the original message and the destination_addr set to the sender of the original address - as if the message is an MO in response to the MT we sent. of course, the result is that in the created DLR message, the sender and receiver numbers are identical and so smsbox rejects the message. I think it can only happen in the CVS version of Kannel, as only lately a change has been made to the DLR scheme to remeber also the sender of the original message and fill it in the DLR message. Did anyone else encounter this problem, and do you think its safe to fix it by changing the call to dlr_find() to use source_addr instead of destination_addr - the dlr_find() function does not do anything interesting with that value, except putting it into the receiver field of the DLR msg. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Wasting time is an important part of living. -- Alan McNatty [ [EMAIL PROTECTED] ] 29a Washington Av, Brooklyn, Wellington -- [ Phone: 21-312136/4-3850759 ] --
RE: DLR and SMPP fixed yet?
That part was fixed in CVS. you must either define smsc-id, or update to the latest CVS which has this fixed. --Oded Arbelm-Wise Mobile Solutions [EMAIL PROTECTED]Mobile: +972-67-340014Tel: +972-9-9581711 (ext: 116) ::..[Debby surveys Bannion's undistinguished hotel room]Debby: "Hey, I like this. Early nothing."-- from 'The Big Heat' -Original Message-From: erick.fuentes [mailto:[EMAIL PROTECTED]]Sent: Thursday, June 06, 2002 4:49 PMTo: Patrick Mignott; [EMAIL PROTECTED]Subject: RE: DLR and SMPP fixed yet? If I remember well you must define the smsc-id in your config file. Erick -Original Message-From: Patrick Mignott [mailto:[EMAIL PROTECTED]]Sent: jueves, 06 de junio de 2002 8:41To: [EMAIL PROTECTED]Subject: DLR and SMPP fixed yet? hello is the problem bellow fixed in the latest CVS yet? i am getting crashes with 1.1.6 2001-12-31 21:42:27 [9] DEBUG: ** SMPP handle_pdu Got DELIVER REPORT 2001-12-31 21:42:27 [9] PANIC: gwlib/octstr.c:2032: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gwlib/octstr.c:728:octstr_compare.) it seems that there is a octstr_compare() call within smsc_smpp.c at line 449-450 that cause this assertion.
DLR and SMPP fixed yet?
hello is the problem bellow fixed in the latest CVS yet? i am getting crashes with 1.1.6 2001-12-31 21:42:27 [9] DEBUG: ** SMPP handle_pdu Got DELIVER REPORT2001-12-31 21:42:27 [9] PANIC: gwlib/octstr.c:2032: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gwlib/octstr.c:728:octstr_compare.) it seems that there is a octstr_compare() call within smsc_smpp.c at line 449-450 that cause this assertion.
Re: DLR and SMPP..
It is kind of weird that this problem exists in smpp, cimd AND emi/ucp ? I'm gonna look through the source and do some packetscannning to see what might be the problem.. On Sun, 6 Jan 2002, Andreas Fink wrote: Stefan Cars wrote: The same thing happens when connecting through EMI2.., so something must be broken in the DLR implementation. Andreas, any hints from your side?! Please?! DLR might fail if empty strings or NULL are passed as things like timestamp etc. Actually this shouldnt happen unless the SMSC does for example return timestamp as empty. So its more like a SMSC driver problem than anything else. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: DLR and SMPP..
It is kind of weird that this problem exists in smpp, cimd AND emi/ucp ? I'm gonna look through the source and do some packetscannning to see what might be the problem.. one possibility is if lets say the EMI driver returns a timestamp being NULL and then an incoming message from CIMD is checked. In that case it would go through the list of messages being sent and might compare the EMI timestamp wit the one from the CIMD and crashes because the EMI one is NULL. However I'm pretty sure the code is checking the smsc-id first so this comparison shouldnt happen anyway. Note on smsc-id: if you got multiple links to the same SMSC then you MUST name the smsc-id's all the same. I have for example 4 EMI links to the same SMSC and I might send an SMS on the first link and receive the delivery report on the 3rd link. If the smsc-id's are not the same, Kannel will consider the delivery report being non matching. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: DLR and SMPP..
Andreas Fink wrote: Note on smsc-id: if you got multiple links to the same SMSC then you MUST name the smsc-id's all the same. I have for example 4 EMI links to the same SMSC and I might send an SMS on the first link and receive the delivery report on the 3rd link. If the smsc-id's are not the same, Kannel will consider the delivery report being non matching. what about if you have several links to the same SMSC using _not_ the same protocol? Like having 1 EMI2 and 1 SMPP link to SMSC A. Does it then require to have both the same smsc-id?! -- this holds only for same protos, right? Uhh. Well if you have two paths to the same SMSC using two different type of protocols (SMPP and EMI for example) then you are in big trouble I would guess. The reason for it is that the timestamp information probably looks very different in SMPP and in EMI. So if you submit message to one link and you receive delivery report back on another protocol, I would be very much surprised if you can match the two informations together as timestamp information looks different in the two protocols (in EMI its a timestamp in SMPP its a message-id. Anyway, if you can make sure that delivery report message comes back on the same link as you send it, you simply can treat the two links as two different SMSC's. If you can not predict on which link the delivery report comes back, treat them as ONE smsc but then you have to ask your carrier how you can match SMPP information to EMI information. Personally I think this makes no sense in real life. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: DLR and SMPP..
The same thing happens when connecting through EMI2.., so something must be broken in the DLR implementation. On Wed, 2 Jan 2002, Stefan Cars wrote: The patched worked (it doesn't crash anymore) but the problem that it doesn't find the DLR id is still there: 2002-01-02 11:01:41 [7] ERROR: Got DELIV REPORT but couldnt find message or was not interested in it A similar problems occurs when using CIMD2 (when receiving the delivery report from the SMSC): 2002-01-02 11:00:12 [4] INFO: Starting delivery report stefan from 46708443600 2002-01-02 11:00:12 [4] PANIC: gwlib/octstr.c:260: octstr_copy_real: Assertion `len = 0' failed. On Tue, 1 Jan 2002, Stipe Tolj wrote: When using DLR with my SMSC that uses SMPP kannel crashes (cvs version): 2001-12-31 21:42:27 [9] DEBUG: ** SMPP handle_pdu Got DELIVER REPORT 2001-12-31 21:42:27 [9] PANIC: gwlib/octstr.c:2032: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gwlib/octstr.c:728:octstr_compare.) it seems that there is a octstr_compare() call within smsc_smpp.c at line 449-450 that cause this assertion. The following atteched patch should fix this NULL pointer assertion for octstr_compare?! Stefan, please try this patch and report and if there are no objections we will commit the patch to cvs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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: DLR and SMPP..
The patched worked (it doesn't crash anymore) but the problem that it doesn't find the DLR id is still there: 2002-01-02 11:01:41 [7] ERROR: Got DELIV REPORT but couldnt find message or was not interested in it A similar problems occurs when using CIMD2 (when receiving the delivery report from the SMSC): 2002-01-02 11:00:12 [4] INFO: Starting delivery report stefan from 46708443600 2002-01-02 11:00:12 [4] PANIC: gwlib/octstr.c:260: octstr_copy_real: Assertion `len = 0' failed. On Tue, 1 Jan 2002, Stipe Tolj wrote: When using DLR with my SMSC that uses SMPP kannel crashes (cvs version): 2001-12-31 21:42:27 [9] DEBUG: ** SMPP handle_pdu Got DELIVER REPORT 2001-12-31 21:42:27 [9] PANIC: gwlib/octstr.c:2032: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gwlib/octstr.c:728:octstr_compare.) it seems that there is a octstr_compare() call within smsc_smpp.c at line 449-450 that cause this assertion. The following atteched patch should fix this NULL pointer assertion for octstr_compare?! Stefan, please try this patch and report and if there are no objections we will commit the patch to cvs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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: DLR and SMPP..
Hi there! I am also having problems with dlrs under smpp. I am geting this error when i ask for dlr: 2002-01-02 13:14:18 [8] DEBUG: boxc_receiver: sms received 2002-01-02 13:14:18 [5] PANIC: gwlib/octstr.c:2031: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gw/smsc_smpp.c:566:handle_pdu.) I am using simulators for SMPP (openSMPP from logica and SMPPSim by Martin Woolley)... maybe these simulators don't handle very well DLR requests :( :( anyone have ideas about my problem??? thanks! Valter Santos - Original Message - From: Stipe Tolj [EMAIL PROTECTED] To: Stefan Cars [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, January 01, 2002 2:30 PM Subject: Re: DLR and SMPP.. When using DLR with my SMSC that uses SMPP kannel crashes (cvs version): 2001-12-31 21:42:27 [9] DEBUG: ** SMPP handle_pdu Got DELIVER REPORT 2001-12-31 21:42:27 [9] PANIC: gwlib/octstr.c:2032: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gwlib/octstr.c:728:octstr_compare.) it seems that there is a octstr_compare() call within smsc_smpp.c at line 449-450 that cause this assertion. The following atteched patch should fix this NULL pointer assertion for octstr_compare?! Stefan, please try this patch and report and if there are no objections we will commit the patch to cvs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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 --- gateway/gw/smsc_smpp.c.orig Tue Jan 1 14:26:20 2002 +++ gateway/gw/smsc_smpp.c Tue Jan 1 14:27:26 2002 @@ -446,8 +446,8 @@ /* we get the following status: DELIVRD, ACCEPTD, EXPIRED, DELETED, UNDELIV, UNKNOWN, REJECTD */ - if ((octstr_compare(stat,octstr_imm(DELIVRD))==0) - || (octstr_compare(stat,octstr_imm(ACCEPTD))==0)) + if ((stat != NULL) ((octstr_compare(stat,octstr_imm(DELIVRD))==0) + || (octstr_compare(stat,octstr_imm(ACCEPTD))==0))) dlrstat = DLR_SUCCESS; else dlrstat = DLR_FAIL;
Re: DLR and SMPP..
[EMAIL PROTECTED] wrote: As I see it this approach with octstr_compare is a part of the Kannel's protective coding style where the NULL pointers are not meant to be used as any other similar pointer. So the assert prevents the NULL pointer to go on loosely and stops it before it may cause a segmentation fault on some other part of the program that is not ready to handle NULL pointers. Therefore the line between a NULL pointer and an empty octstr; first one is an accident that shouldn't happen, the latter is a way to say that there is no content. I agree in the view of protective coding style, hence we may distringuish between a NULL pointer and an empty content, IMO. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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: DLR and SMPP..
[EMAIL PROTECTED] wrote: As I see it this approach with octstr_compare is a part of the Kannel's protective coding style where the NULL pointers are not meant to be used as any other similar pointer. So the assert prevents the NULL pointer to go on loosely and stops it before it may cause a segmentation fault on some other part of the program that is not ready to handle NULL pointers. Therefore the line between a NULL pointer and an empty octstr; first one is an accident that shouldn't happen, the latter is a way to say that there is no content. I agree in the view of protective coding style, hence we may distringuish between a NULL pointer and an empty content, IMO. Ok. how about dealing with NULL as a different string of but still being able to compare NULL to something and NULL to NULL? -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: DLR and SMPP..
When using DLR with my SMSC that uses SMPP kannel crashes (cvs version): 2001-12-31 21:42:27 [9] DEBUG: ** SMPP handle_pdu Got DELIVER REPORT 2001-12-31 21:42:27 [9] PANIC: gwlib/octstr.c:2032: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gwlib/octstr.c:728:octstr_compare.) Andreas, have you any idea here? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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: DLR and SMPP..
When using DLR with my SMSC that uses SMPP kannel crashes (cvs version): 2001-12-31 21:42:27 [9] DEBUG: ** SMPP handle_pdu Got DELIVER REPORT 2001-12-31 21:42:27 [9] PANIC: gwlib/octstr.c:2032: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gwlib/octstr.c:728:octstr_compare.) it seems that there is a octstr_compare() call within smsc_smpp.c at line 449-450 that cause this assertion. The following atteched patch should fix this NULL pointer assertion for octstr_compare?! Stefan, please try this patch and report and if there are no objections we will commit the patch to cvs. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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 --- gateway/gw/smsc_smpp.c.orig Tue Jan 1 14:26:20 2002 +++ gateway/gw/smsc_smpp.c Tue Jan 1 14:27:26 2002 @@ -446,8 +446,8 @@ /* we get the following status: DELIVRD, ACCEPTD, EXPIRED, DELETED, UNDELIV, UNKNOWN, REJECTD */ - if ((octstr_compare(stat,octstr_imm(DELIVRD))==0) - || (octstr_compare(stat,octstr_imm(ACCEPTD))==0)) + if ((stat != NULL) ((octstr_compare(stat,octstr_imm(DELIVRD))==0) + || (octstr_compare(stat,octstr_imm(ACCEPTD))==0))) dlrstat = DLR_SUCCESS; else dlrstat = DLR_FAIL;
Re: DLR and SMPP..
When using DLR with my SMSC that uses SMPP kannel crashes (cvs version): 2001-12-31 21:42:27 [9] DEBUG: ** SMPP handle_pdu Got DELIVER REPORT 2001-12-31 21:42:27 [9] PANIC: gwlib/octstr.c:2032: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gwlib/octstr.c:728:octstr_compare.) it seems that there is a octstr_compare() call within smsc_smpp.c at line 449-450 that cause this assertion. The following atteched patch should fix this NULL pointer assertion for octstr_compare?! Stefan, please try this patch and report and if there are no objections we will commit the patch to cvs. Why dont we modify octstr_compare that a NULL string can be compared too? NULL would then be equal to . Does that make sense? -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: DLR and SMPP..
Andreas Fink wrote: Why dont we modify octstr_compare that a NULL string can be compared too? NULL would then be equal to . Does that make sense? I'm not sure how deep the impact would be. Anyone from the core architects still reading the list and have their heads up, please?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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
DLR and SMPP..
When using DLR with my SMSC that uses SMPP kannel crashes (cvs version): 2001-12-31 21:42:27 [9] DEBUG: ** SMPP handle_pdu Got DELIVER REPORT 2001-12-31 21:42:27 [9] PANIC: gwlib/octstr.c:2032: seems_valid_real: Assertion `ostr != NULL' failed. (Called from gwlib/octstr.c:728:octstr_compare.)
