Re: SMPP getting stuck
> cvs is updated anyway. yep, did that. 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: SMPP getting stuck
On Donnerstag, Januar 2, 2003, at 03:41 Uhr, Stipe Tolj wrote: Andreas Fink wrote: before submitting ANY patch to CVS it should be checked if the code compiles at least... With current cvs I get: gcc -D_REENTRANT=1 -I. -Igw -g -O2 -DBROKEN_PTHREADS=1 -I/usr/include/libxml -I/usr/include -I/usr/include/mysql -o gw/smsc/smsc_smpp.o -c gw/smsc/smsc_smpp.c gw/smsc/smsc_smpp.c: In function `handle_pdu': gw/smsc/smsc_smpp.c:684: parse error before `int' gw/smsc/smsc_smpp.c:997: `cmd_stat' undeclared (first use in this function) gw/smsc/smsc_smpp.c:997: (Each undeclared identifier is reported only once gw/smsc/smsc_smpp.c:997: for each function it appears in.) make: *** [gw/smsc/smsc_smpp.o] Error 1 Andreas, thanks for the hint. I can tell you I do this, and it *did* compile for me on Cygwin. strange. Why does it compile this SMP_PDU *resp; resp = NULL; int a; This is invalid in C (its valid in C++ however) because there is a statement in between the declarations. well the second problem was the parameter which was undefined so it couldn't be started. cvs is updated anyway. Andreas Fink Fink Consulting GmbH --- Tel: +41-61-332 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com ---
Re: SMPP getting stuck
Andreas Fink wrote: > > before submitting ANY patch to CVS it should be checked if the code compiles at >least... > > With current cvs I get: > > gcc -D_REENTRANT=1 -I. -Igw -g -O2 -DBROKEN_PTHREADS=1 -I/usr/include/libxml >-I/usr/include -I/usr/include/mysql -o gw/smsc/smsc_smpp.o -c gw/smsc/smsc_smpp.c > gw/smsc/smsc_smpp.c: In function `handle_pdu': > gw/smsc/smsc_smpp.c:684: parse error before `int' > gw/smsc/smsc_smpp.c:997: `cmd_stat' undeclared (first use in this function) > gw/smsc/smsc_smpp.c:997: (Each undeclared identifier is reported only once > gw/smsc/smsc_smpp.c:997: for each function it appears in.) > make: *** [gw/smsc/smsc_smpp.o] Error 1 Andreas, thanks for the hint. I can tell you I do this, and it *did* compile for me on Cygwin. Don't know why it did, but otherwise I wouldn't have commited it. 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: SMPP getting stuck
before submitting ANY patch to CVS it should be checked if the code compiles at least... With current cvs I get: gcc -D_REENTRANT=1 -I. -Igw -g -O2 -DBROKEN_PTHREADS=1 -I/usr/include/libxml -I/usr/include -I/usr/include/mysql -o gw/smsc/smsc_smpp.o -c gw/smsc/smsc_smpp.c gw/smsc/smsc_smpp.c: In function `handle_pdu': gw/smsc/smsc_smpp.c:684: parse error before `int' gw/smsc/smsc_smpp.c:997: `cmd_stat' undeclared (first use in this function) gw/smsc/smsc_smpp.c:997: (Each undeclared identifier is reported only once gw/smsc/smsc_smpp.c:997: for each function it appears in.) make: *** [gw/smsc/smsc_smpp.o] Error 1 the fix is to remove the line resp = NULL; and to initialize the variable resp to NULL a few lines above. and then when running bearerbox I get: 2003-01-02 08:29:22 [0] PANIC: Trying to fetch variable `wait-ack-expire' in group `smsc', not allowed. I'm fixing it for you now in CVS... On Donnerstag, Januar 2, 2003, at 12:26 Uhr, Stipe Tolj wrote: Nisan Bloch wrote: Here is a different take the Andreas's SMPP generic_nack patch. This is a bit more complete, and fixes a potential NULL pointer exception in the code. On line 922 a check is made for msg==NULL, and an error message outputed, but then bb_smscconn_send_failed is called with the NULL msg. This patch is quite different so I have attached the changed case, rather than a diff. changed applied to cvs. Thanks Nisan. 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 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: SMPP getting stuck
Nisan Bloch wrote: > > Here is a different take the Andreas's SMPP generic_nack patch. This is a > bit more complete, and fixes a potential NULL pointer exception in the > code. On line 922 a check is made for msg==NULL, and an error message > outputed, but then bb_smscconn_send_failed is called with the NULL msg. > > This patch is quite different so I have attached the changed case, rather > than a diff. changed applied to cvs. Thanks Nisan. 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: SMPP getting stuck
Hi All
anytake on this yet?
Nisan
Here is a different take the Andreas's SMPP generic_nack patch. This is a
bit more complete, and fixes a potential NULL pointer exception in the
code. On line 922 a check is made for msg==NULL, and an error message
outputed, but then bb_smscconn_send_failed is called with the NULL msg.
This patch is quite different so I have attached the changed case, rather
than a diff.
Nisan
case generic_nack:
cmd_stat = pdu->u.generic_nack.command_status;
os = octstr_format("%ld", pdu->u.generic_nack.sequence_number);
msg = dict_remove(smpp->sent_msgs, os);
octstr_destroy(os);
if (msg == NULL) {
warning(0, "SMPP[%s]: SMSC sent generic_nack "
"with wrong sequence number 0x%08lx",
octstr_get_cstr(smpp->conn->id),
pdu->u.generic_nack.sequence_number);
} else {
if ((cmd_stat == SMPP_ESME_RTHROTTLED) ||
(cmd_stat == SMPP_ESME_RMSGQFUL)) {
info(0,"SMPP[%s]: SMSC sent generic_nack %s: status 0x%08lx ",
(cmd_stat==SMPP_ESME_RTHROTTLED?"ESME_RTHROTTLED":"ESME_RMSGQFUL"),
octstr_get_cstr(smpp->conn->id),pdu->u.generic_nack.command_status);
time(&(smpp->throttling_err_time));
reason = smpp_status_to_smscconn_failure_reason(
pdu->u.generic_nack.command_status);
bb_smscconn_send_failed(smpp->conn, msg, reason);
--(*pending_submits);
} if (cmd_stat == SMPP_ESME_RUNKNOWNERR) {
info(0,"SMPP[%s]: SMSC sent generic_nack SMPP_ESME_RUNKNOWNERR:
status 0x%08lx ",
octstr_get_cstr(smpp->conn->id),pdu->u.generic_nack.command_status);
reason = smpp_status_to_smscconn_failure_reason(-1);
bb_smscconn_send_failed(smpp->conn, msg, reason);
--(*pending_submits);
} else {
error(0, "SMPP[%s]: SMSC sent generic_nack type 0x%08lx, code
0x%08lx.",
octstr_get_cstr(smpp->conn->id), pdu->type,
pdu->u.generic_nack.command_status);
reason = smpp_status_to_smscconn_failure_reason(-1);
bb_smscconn_send_failed(smpp->conn, msg, reason);
--(*pending_submits);
}
}
break;
Re: SMPP getting stuck
Hi
Here is a different take the Andreas's SMPP generic_nack patch. This is a
bit more complete, and fixes a potential NULL pointer exception in the
code. On line 922 a check is made for msg==NULL, and an error message
outputed, but then bb_smscconn_send_failed is called with the NULL msg.
This patch is quite different so I have attached the changed case, rather
than a diff.
Nisancase generic_nack:
cmd_stat = pdu->u.generic_nack.command_status;
os = octstr_format("%ld", pdu->u.generic_nack.sequence_number);
msg = dict_remove(smpp->sent_msgs, os);
octstr_destroy(os);
if (msg == NULL) {
warning(0, "SMPP[%s]: SMSC sent generic_nack "
"with wrong sequence number 0x%08lx",
octstr_get_cstr(smpp->conn->id),
pdu->u.generic_nack.sequence_number);
} else {
if ((cmd_stat == SMPP_ESME_RTHROTTLED) ||
(cmd_stat == SMPP_ESME_RMSGQFUL)) {
info(0,"SMPP[%s]: SMSC sent generic_nack %s: status 0x%08lx ",
(cmd_stat==SMPP_ESME_RTHROTTLED?"ESME_RTHROTTLED":"ESME_RMSGQFUL"),
octstr_get_cstr(smpp->conn->id),pdu->u.generic_nack.command_status);
time(&(smpp->throttling_err_time));
reason = smpp_status_to_smscconn_failure_reason(
pdu->u.generic_nack.command_status);
bb_smscconn_send_failed(smpp->conn, msg, reason);
--(*pending_submits);
} if (cmd_stat == SMPP_ESME_RUNKNOWNERR) {
info(0,"SMPP[%s]: SMSC sent generic_nack SMPP_ESME_RUNKNOWNERR:
status 0x%08lx ",
octstr_get_cstr(smpp->conn->id),pdu->u.generic_nack.command_status);
reason = smpp_status_to_smscconn_failure_reason(-1);
bb_smscconn_send_failed(smpp->conn, msg, reason);
--(*pending_submits);
} else {
error(0, "SMPP[%s]: SMSC sent generic_nack type 0x%08lx, code
0x%08lx.",
octstr_get_cstr(smpp->conn->id), pdu->type,
pdu->u.generic_nack.command_status);
reason = smpp_status_to_smscconn_failure_reason(-1);
bb_smscconn_send_failed(smpp->conn, msg, reason);
--(*pending_submits);
}
}
break;
Re: SMPP getting stuck
Hi
At 11:10 AM 12/5/02 +0100, Andreas Fink wrote:
I've fixed the problem in CVS.
the implementation didnt expect to see an error as generic_err_resp but
only as sms_submit_resp
the error was a THROTTLING.
Our soln is basically the same but with some minor differences..
Primarily we remove the message for sequence_number from the dictionary
(first), also we check for SMPP_ESME_RMSGQFUL. I removed the msg first
before checking the command_status, because it may be an
unknown/unhandled status, and then the message would remain in the
dictionary. This would slowly eat away at mem.
case generic_nack_resp:
os =
octstr_format("%ld",
pdu->u.generic_nack_resp.sequence_number);
msg =
dict_remove(smpp->sent_msgs, os);
octstr_destroy(os);
if
(msg == NULL) {
warning(0, "SMPP[%s]: SMSC sent generic_nack_resp "
"with wrong sequence number 0x%08lx",
octstr_get_cstr(smpp->conn->id),
pdu->u.generic_nack_resp.sequence_number);
}
else if ((pdu->u.generic_nack_resp.command_status ==
SMPP_ESME_RTHROTTLED) ||
(pdu->u.generic_nack_resp.command_status == SMPP_ESME_RMSGQFUL))
{
info(0,"SMPP[%s]: ESME_RTHROTTLED/ESME_RMSGQFUL: status 0x%08lx
",
octstr_get_cstr(smpp->conn->id),pdu->u.generic_nack_resp.command_status);
time(&(smpp->throttling_err_time));
reason = smpp_status_to_smscconn_failure_reason(
pdu->u.generic_nack_resp.command_status);
bb_smscconn_send_failed(smpp->conn, msg, reason);
--(*pending_submits);
} else
{
error(0, "SMPP[%s]: NACK PDU type 0x%08lx, code
0x%08lx.",
octstr_get_cstr(smpp->conn->id), pdu->type,
pdu->u.generic_nack_resp.command_status);
reason = smpp_status_to_smscconn_failure_reason(-1);
bb_smscconn_send_failed(smpp->conn, msg, reason);
--(*pending_submits);
}
break;
Nisan
Re: SMPP getting stuck
Hi Yup we have. This is what happens when you send above the throughput allowed by the SMSC you are connecting to for your account. 0x58 is SMPP_ESME_RTHROTTLED We have also seen SMPP_ESME_RMSGQFUL comming in on a generic_nack_resp. Our smsc module is modified for this. Basically we have added generic_nack_response pdu handler, which reques the message. I can submit patches if you are interested. Nisan At 08:02 AM 12/5/02 +0100, Andreas Fink wrote: Anyone seen this: 2002-12-05 06:57:53 [10] DEBUG: SMPP[link5]: Got PDU: 2002-12-05 06:57:53 [10] DEBUG: SMPP PDU 0x814fdc8 dump: 2002-12-05 06:57:53 [10] DEBUG: type_name: generic_nack_resp 2002-12-05 06:57:53 [10] DEBUG: command_id: 2147483648 = 0x8000 2002-12-05 06:57:53 [10] DEBUG: command_status: 88 = 0x0058 2002-12-05 06:57:53 [10] DEBUG: sequence_number: 31 = 0x001f 2002-12-05 06:57:53 [10] DEBUG: SMPP PDU dump ends. 2002-12-05 06:57:53 [10] ERROR: SMPP[link5]: Unknown PDU type 0x8000, ignored. This happens under high load on a SMPP link to a SMSC. after that the link is more or less stuck. Only restarting helps dequeuing messages again. Andreas Fink Fink Consulting GmbH --- Tel: +41-61-332 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com ---
Re: SMPP getting stuck
On Donnerstag, Dezember 5, 2002, at 03:23 Uhr, Stipe Tolj wrote: I'm vetoing against (-1) for the block: if(msg->sms.coding == 1)/* dont screw up unicode messages */ charset_gsm_to_latin1(msg->sms.msgdata); because most SMPP SMSC seem to send with data_coding = 0 and use GSM alphabet as default SMSC alphabet. This patch would result that characters (like german umlauts) would not be transcoded correctly for inbound messages! Andreas, can you describe which problem you have with it. ok. then how about: if((msg->sms.coding == 1) || (msg->sms.coding == 0) ) the problem I have is incoming logos (binary SMS) or similar SMS and especially Arab characters which are UCS2. Also if you chain Kannel over HTTP, then incoming characters will be translated twice. Andreas Fink Fink Consulting GmbH --- Tel: +41-61-332 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com ---
Re: SMPP getting stuck
I'm vetoing against (-1) for the block: if(msg->sms.coding == 1)/* dont screw up unicode messages */ charset_gsm_to_latin1(msg->sms.msgdata); because most SMPP SMSC seem to send with data_coding = 0 and use GSM alphabet as default SMSC alphabet. This patch would result that characters (like german umlauts) would not be transcoded correctly for inbound messages! Andreas, can you describe which problem you have with it. 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: SMPP getting stuck
On Donnerstag, Dezember 5, 2002, at 12:13 Uhr, Stipe Tolj wrote: Andreas, I've fixed the problem in CVS. the implementation didnt expect to see an error as generic_err_resp but only as sms_submit_resp the error was a THROTTLING. what are the other changes you commited for?! http://www.kannel.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc/smsc_smpp.c.diff?r1=1.17&r2=1.18 see ChangeLog: 2002-12-05 Andreas Fink <[EMAIL PROTECTED]> * gw/smsc/smsc_smpp.c: fixed throttling problem in SMPP which was triggered by getting back a generic error instead of a submit_response error. For incoming messages the original ID is set (my-number problem) as a temporary fix and if coding is not 1, then conversion to latin1 is not done to allow incoming unicode and binary to work properly. my-number: even if you dont set my-number, an incoming message on SMPP will have the destination number replaced with the global default. This is not supposed to be so. The problem is that my-number is copied from global default somehow because otherwhise the code wouldn't be executed. coding: when an incoming unicode message comes in (or any binary message) it gets converted to latin1 which makes it unusable. so the convertion to latin1 should not take place at all. long term this should be done in smsbox as discussed here a while ago. This one line change makes it latin1 only if it is GSM default character set and leaves it "as-is" in all other cases (but coding is of course set accordingly). Andreas Fink Fink Consulting GmbH --- Tel: +41-61-332 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com ---
Re: SMPP getting stuck
Andreas, > I've fixed the problem in CVS. > the implementation didnt expect to see an error as generic_err_resp but only as >sms_submit_resp > the error was a THROTTLING. what are the other changes you commited for?! http://www.kannel.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc/smsc_smpp.c.diff?r1=1.17&r2=1.18 Please comment on this. 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: SMPP getting stuck
On Donnerstag, Dezember 5, 2002, at 10:56 Uhr, Stipe Tolj wrote: 2002-12-05 06:57:53 [10] DEBUG: SMPP[link5]: Got PDU: 2002-12-05 06:57:53 [10] DEBUG: SMPP PDU 0x814fdc8 dump: 2002-12-05 06:57:53 [10] DEBUG: type_name: generic_nack_resp 2002-12-05 06:57:53 [10] DEBUG: command_id: 2147483648 = 0x8000 2002-12-05 06:57:53 [10] DEBUG: command_status: 88 = 0x0058 2002-12-05 06:57:53 [10] DEBUG: sequence_number: 31 = 0x001f 2002-12-05 06:57:53 [10] DEBUG: SMPP PDU dump ends. 2002-12-05 06:57:53 [10] ERROR: SMPP[link5]: Unknown PDU type 0x8000, ignored. hmm, ok, it's at least an "official" PDU for generic_nack. from the 3.4 spec: 4.3 GENERIC_NACK PDU This is a generic negative acknowledgement to an SMPP PDU submitted with an invalid message header. A generic_nack response is returned in the following cases: Invalid command_length If the receiving SMPP entity, on decoding an SMPP PDU, detects an invalid command_length (either too short or too long), it should assume that the data is corrupt. In such cases a generic_nack PDU must be returned to the message originator. Unknown command_id If an unknown or invalid command_id is received, a generic_nack PDU must also be returned to the originator. I've fixed the problem in CVS. the implementation didnt expect to see an error as generic_err_resp but only as sms_submit_resp the error was a THROTTLING. 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: SMPP getting stuck
> 2002-12-05 06:57:53 [10] DEBUG: SMPP[link5]: Got PDU: > 2002-12-05 06:57:53 [10] DEBUG: SMPP PDU 0x814fdc8 dump: > 2002-12-05 06:57:53 [10] DEBUG: type_name: generic_nack_resp > 2002-12-05 06:57:53 [10] DEBUG: command_id: 2147483648 = 0x8000 > 2002-12-05 06:57:53 [10] DEBUG: command_status: 88 = 0x0058 > 2002-12-05 06:57:53 [10] DEBUG: sequence_number: 31 = 0x001f > 2002-12-05 06:57:53 [10] DEBUG: SMPP PDU dump ends. > 2002-12-05 06:57:53 [10] ERROR: SMPP[link5]: Unknown PDU type 0x8000, ignored. hmm, ok, it's at least an "official" PDU for generic_nack. from the 3.4 spec: 4.3 GENERIC_NACK PDU This is a generic negative acknowledgement to an SMPP PDU submitted with an invalid message header. A generic_nack response is returned in the following cases: Invalid command_length If the receiving SMPP entity, on decoding an SMPP PDU, detects an invalid command_length (either too short or too long), it should assume that the data is corrupt. In such cases a generic_nack PDU must be returned to the message originator. Unknown command_id If an unknown or invalid command_id is received, a generic_nack PDU must also be returned to the originator. 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: SMPP getting stuck
Andreas Fink wrote: > > Anyone seen this: > > 2002-12-05 06:57:53 [10] DEBUG: SMPP[link5]: Got PDU: > 2002-12-05 06:57:53 [10] DEBUG: SMPP PDU 0x814fdc8 dump: > 2002-12-05 06:57:53 [10] DEBUG: type_name: generic_nack_resp > 2002-12-05 06:57:53 [10] DEBUG: command_id: 2147483648 = 0x8000 > 2002-12-05 06:57:53 [10] DEBUG: command_status: 88 = 0x0058 > 2002-12-05 06:57:53 [10] DEBUG: sequence_number: 31 = 0x001f > 2002-12-05 06:57:53 [10] DEBUG: SMPP PDU dump ends. > 2002-12-05 06:57:53 [10] ERROR: SMPP[link5]: Unknown PDU type 0x8000, ignored. hmm, is that any "official" PDU type from the specs?! 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
