Re: [RFC] smsc logging patch commit?!
Hi Stipe, I have not tried your patch but at first glance it looks good... +1 from me Am Dienstag, 4. März 2003 14:26 schrieb Stipe Tolj: Hi list, I'd like to apply my patch this afternoon. It an 'feature-add' and hence does not break any common behaviour. If someone has considerable constrainst against a commit, please veto. 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 -- 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] icq: 98063111
Re: [PATCH] trivial dcs_to_fields fix
Hi Stipe, all, On Wednesday 26 February 2003 23:00, Stipe Tolj wrote: Alexander Malysh wrote: attached patch should fix dcs_to_fields and versus functions. The problem: assume you got dcs=0xf5 in your smpp/ucp triber. Simple call: dcs = 0xf5; dcs_to_fields(dcs,msg); filds_to_dcs(msg, msg-sms.alt_dcs); And look what happens ;) Please apply... that patch would change the alt_dcs behaviour from alt_dcs = 0 to alt_dcs = 1 for all MT messages. No. This patch has nothing to do with MT messages ... It corrects only alt_dcs settings for MO messages. For MT we use alt_dcs directive from config file or sendsms http api... I think , it's not good if MO message has had dcs=0xf5 and after simple dcs_to_fields(dcs,msg); fields_to_dcs(msg, msg-sms.alt_dcs); calls has dcs=0x05 because of missing alt_dcs setting in message. Or I am missing something? Specifically we would default the 'alt-dcs' config directive of the smsc group to 1 instread of 0. Any comments/votes from the others?! 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 -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de msn: [EMAIL PROTECTED] smime.p7s Description: signature
Re: bug in smsc_smpp.c login failure
Hi,
what about attached patch ?
Am Donnerstag, 27. Februar 2003 10:30 schrieb Stipe Tolj:
Alan McNatty wrote:
On Thu, 2003-02-27 at 18:54, Nisan Bloch wrote:
Hi
At 03:46 PM 2/27/03 +1300, Alan McNatty wrote:
Hello,
found that if I type in the smpp password incorrectly kannel loops
forever trying to reconnect. ie:
-1 from me
In the current form this path will not allow any retries for any sort
of bind error. eg what happens if there is a temporary connectivity
issue, or the SMPP server is down for a short while/
What I'm trying highlight is that there is a gap in logic ..
Currently regardless of the type of error we continually retry to bind.
If we specifically receive an error indicating the password is invalid
the SMSC is obviously up but we may as well kill the thread.
yep, that's true in some sense. Trying to reconnect forever while we
get the error information from the SMSC that we can't login with that
credentials *could* be considered as login abuse :)
At least I would consider this if our SMPP clients would hammer our
SMPP server with invalid credentials.
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
--
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]
icq: 98063111
Index: gw/smsc/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.25
diff -a -u -r1.25 smsc_smpp.c
--- gw/smsc/smsc_smpp.c 23 Feb 2003 11:35:34 - 1.25
+++ gw/smsc/smsc_smpp.c 27 Feb 2003 10:25:35 -
@@ -62,6 +62,8 @@
*/
enum {
+SMPP_ESME_RINVPASWD = 0x000E,
+SMPP_ESME_RINVSYSID = 0x000F,
SMPP_ESME_RMSGQFUL= 0x0014,
SMPP_ESME_RTHROTTLED = 0x0058,
SMPP_ESME_RX_T_APPN = 0x0064,
@@ -958,6 +960,9 @@
code 0x%08lx.,
octstr_get_cstr(smpp-conn-id),
pdu-u.bind_transmitter_resp.command_status);
+if (pdu-u.bind_transmitter_resp.command_status == SMPP_ESME_RINVSYSID ||
+pdu-u.bind_transmitter_resp.command_status == SMPP_ESME_RINVPASWD)
+smpp-quitting = 1;
} else {
*pending_submits = 0;
smpp-conn-status = SMSCCONN_ACTIVE;
@@ -972,6 +977,9 @@
code 0x%08lx.,
octstr_get_cstr(smpp-conn-id),
pdu-u.bind_transceiver_resp.command_status);
+if (pdu-u.bind_transceiver_resp.command_status == SMPP_ESME_RINVSYSID ||
+pdu-u.bind_transceiver_resp.command_status == SMPP_ESME_RINVPASWD)
+smpp-quitting = 1;
} else {
*pending_submits = 0;
smpp-conn-status = SMSCCONN_ACTIVE;
@@ -986,6 +994,9 @@
code 0x%08lx.,
octstr_get_cstr(smpp-conn-id),
pdu-u.bind_receiver_resp.command_status);
+if (pdu-u.bind_receiver_resp.command_status == SMPP_ESME_RINVSYSID ||
+pdu-u.bind_receiver_resp.command_status == SMPP_ESME_RINVPASWD)
+smpp-quitting = 1;
} else {
/* set only resceive status if no transmitt is bind */
if (smpp-conn-status != SMSCCONN_ACTIVE) {
Re: SMPP 3.4 C-Octet String Termination
Hi, this is not the kannel problem! Your smsc sned wrong pdu: please look smpp v.3.4 issue 1.2 site 61... short_message field is Octet-String and not C-Octet-String. Your smsc is just buggy ;) Am Mittwoch, 26. Februar 2003 16:00 schrieb Stipe Tolj: Alex Judd wrote: We're working with a SMPP 3.4 server that validly (according to the 3.4 specs) terminates the C-Octet Strings it sends us with a NULL character. This currently isn't handled directly by Kannel and ends up as an extra character on the message content. For example a message of AAA, length 3, now arrives at Kannel as AAA@, length 4 [which is obviously wrong] I've made a short term workaround to remove the character by using the octstr_strip_nonalphanums on the msg-sms.msgdata however I'm interested in whether everyone thinks Kannel should strip off this null character (like I do) or whether this should occur at application level? If it's Kannel I'll submit a proper patch hmm, so someone is not acting spec conform, either Kannel or they?! 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 -- 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] icq: 98063111
Re: SMPP 3.4 C-Octet String Termination
it can't be C-Octet-String at all ;) Just think that '@' in GSM 03.38 is 0x00 ;) Am Mittwoch, 26. Februar 2003 16:10 schrieb Stipe Tolj: Alexander Malysh wrote: this is not the kannel problem! Your smsc sned wrong pdu: please look smpp v.3.4 issue 1.2 site 61... short_message field is Octet-String and not C-Octet-String. Your smsc is just buggy ;) if that's the case, Alex, could you ask which explicit SMSC it is? So we can put the vendor and the model on a not spec conform black-list :) 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 -- 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] icq: 98063111
Re: SMPP 3.4 C-Octet String Termination
Hi Alex, Am Mittwoch, 26. Februar 2003 16:30 schrieb Alex Judd: Alexander Not sure if that's true. According to the SMPP3.4 specs C-Octet String A series of ASCII characters terminated with the NULL character. Notes: (i) Reference made to NULL settings of Octet-String fields implies that the field consists of a single ^^ Single is single;) That means only NULL without message body ! But you received 0x410x6c0x650x780x00 ??? This is totally wrong ... NULL character, i.e., an octet encoded with value 0x00 (zero). Which would mean it's valid to send a message content of message received 2003-02-26 12:24:42 [6] DEBUG: SMPP[Vittel]: Got PDU: .. 2003-02-26 12:24:42 [6] DEBUG: short_message: 2003-02-26 12:24:42 [6] DEBUG:Octet string at f4ef8: 2003-02-26 12:24:42 [6] DEBUG: len: 5 2003-02-26 12:24:42 [6] DEBUG: size: 6 2003-02-26 12:24:42 [6] DEBUG: immutable: 0 2003-02-26 12:24:42 [6] DEBUG: data: 41 6c 65 78 00Alex. ..^^^ which then is translated by Kannel as 2003-02-26 12:24:42 [6] INFO: Starting to service Alex@ from 447740305115 to 80118 which is defintiely wrong. Yes, no? Alex - Original Message - From: Alexander Malysh [EMAIL PROTECTED] To: Stipe Tolj [EMAIL PROTECTED] Cc: Alex Judd [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, February 26, 2003 3:16 PM Subject: Re: SMPP 3.4 C-Octet String Termination it can't be C-Octet-String at all ;) Just think that '@' in GSM 03.38 is 0x00 ;) Am Mittwoch, 26. Februar 2003 16:10 schrieb Stipe Tolj: Alexander Malysh wrote: this is not the kannel problem! Your smsc sned wrong pdu: please look smpp v.3.4 issue 1.2 site 61... short_message field is Octet-String and not C-Octet-String. Your smsc is just buggy ;) if that's the case, Alex, could you ask which explicit SMSC it is? So we can put the vendor and the model on a not spec conform black-list :) 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 -- 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] icq: 98063111 -- 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] icq: 98063111
[PATCH] trivial dcs_to_fields fix
Hi, attached patch should fix dcs_to_fields and versus functions. The problem: assume you got dcs=0xf5 in your smpp/ucp triber. Simple call: dcs = 0xf5; dcs_to_fields(dcs,msg); filds_to_dcs(msg, msg-sms.alt_dcs); And look what happens ;) Please apply... -- 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] icq: 98063111 Index: gw/sms.c === RCS file: /home/cvs/gateway/gw/sms.c,v retrieving revision 1.6 diff -a -u -r1.6 sms.c --- gw/sms.c 7 Dec 2002 14:30:54 - 1.6 +++ gw/sms.c 26 Feb 2003 16:09:20 - @@ -83,6 +83,7 @@ dcs = 0x07; (*msg)-sms.coding = (dcs 0x04) ? DC_8BIT : DC_7BIT; /* grab bit 2 */ (*msg)-sms.mclass = 1 + (dcs 0x03); /* grab bits 1,0 */ +(*msg)-sms.alt_dcs = 1; /* set 0xfX data coding */ } /* Non-MWI Mode 0 */
Re: [PATCH] generic support for our-host smsc directive
Hi, looks good , +1 from me ... On Wednesday 26 February 2003 22:09, Angel Fradejas wrote: Hi all, Find attached a patch to add generic support for the our-host smsc config directive. Until now it was only supported in emi2 and smpp, and not fully (for example emi2_open_listening_socket() created the server socket without explicit binding to a specific interface). This patch adds support to SMSCConn based drivers: smsc_emi2.cCMG UCP/EMI 4.0 smsc_smasi.c SM/ASI (for CriticalPath InVoke SMS Center 4.x) smsc_cgw.c Sonera ContentGateway software smsc_http.cHTTP-based relay and content gateways smsc_fake.cFake SMSC smsc_smpp.cSMPP 3.4 I may add generic support to the old SMSCenter based drivers (cimd2, ois, etc) if there's interest. Please, consider committing to cvs. Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de msn: [EMAIL PROTECTED] pgp0.pgp Description: signature
[PATCH] add restart to bearerbox
Hi list,
attached patch adds restart functionality to bearerbox and will fix small bug
in bb_boxc.c (not closing of listen socket while shutting down).
Please look in it and vote ;)
--
Best Regards / Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 240
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: http://www.centrium.de
msn: [EMAIL PROTECTED]
Index: gw/bb_boxc.c
===
RCS file: /home/cvs/gateway/gw/bb_boxc.c,v
retrieving revision 1.61
diff -a -u -r1.61 bb_boxc.c
--- gw/bb_boxc.c 5 Feb 2003 23:49:30 - 1.61
+++ gw/bb_boxc.c 22 Feb 2003 21:02:49 -
-738,6 +738,8
while(list_wait_until_nonempty(smsbox_list)!= -1)
sleep(1);
+/* close listen socket */
+close(fd);
list_destroy(smsbox_list, NULL);
smsbox_list = NULL;
-785,7 +787,9
/* wait for wdp_to_wapboxes to exit */
while(list_consume(wapbox_list)!=NULL)
;
-
+
+/* close listen socket */
+close(fd);
list_destroy(wapbox_list, NULL);
wapbox_list = NULL;
Index: gw/bb_http.c
===
RCS file: /home/cvs/gateway/gw/bb_http.c,v
retrieving revision 1.41
diff -a -u -r1.41 bb_http.c
--- gw/bb_http.c 20 Nov 2002 00:36:50 - 1.41
+++ gw/bb_http.c 22 Feb 2003 21:02:50 -
-142,6 +142,21
return octstr_create(Running resumed);
}
+static Octstr *httpd_restart(List *cgivars)
+{
+Octstr *reply;
+if ((reply = httpd_check_authorization(cgivars, 0))!= NULL) return reply;
+if ((reply = httpd_check_status())!= NULL) return reply;
+
+if (bb_status == BB_SHUTDOWN) {
+bb_status = BB_DEAD;
+gwthread_wakeup_all();
+return octstr_create(Trying harder to restart);
+}
+bb_restart();
+return octstr_create(Restarting.);
+}
+
static Octstr *httpd_flush_dlr(List *cgivars)
{
Octstr *reply;
-258,6 +273,9
} else if (octstr_str_compare(url, /cgi-bin/resume)==0
|| octstr_str_compare(url, /resume)==0) {
reply = httpd_resume(cgivars);
+} else if (octstr_str_compare(url, /cgi-bin/restart)==0
+ || octstr_str_compare(url, /restart)==0) {
+ reply = httpd_restart(cgivars);
} else if (octstr_str_compare(url, /cgi-bin/flush-dlr)==0
|| octstr_str_compare(url, /flush-dlr)==0) {
reply = httpd_flush_dlr(cgivars);
-268,7 +286,7
|| octstr_str_compare(url, /start-smsc)==0) {
reply = httpd_restart_smsc(cgivars);
/*
- * reconfig? restart?
+ * reconfig?
*/
} else {
reply = octstr_format(Unknown command %S, url);
Index: gw/bearerbox.c
===
RCS file: /home/cvs/gateway/gw/bearerbox.c,v
retrieving revision 1.132
diff -a -u -r1.132 bearerbox.c
--- gw/bearerbox.c 6 Sep 2002 12:01:27 - 1.132
+++ gw/bearerbox.c 22 Feb 2003 21:02:51 -
-65,7 +65,7
static Mutex *status_mutex;
Mutex *boxid_mutex;
static time_t start_time;
-
+int restart = 0;
/* to avoid copied code */
-524,6 +524,9
dlr_shutdown();
gwlib_shutdown();
+if (restart == 1)
+execvp(argv[0],argv);
+
return 0;
}
-636,7 +639,8
int bb_restart(void)
{
-return -1;
+restart = 1;
+return bb_shutdown();
}
pgp0.pgp
Description: signature
[PATCH] Re: RE : SMPP 3.3 trouble
Hi, please apply attached patch and try again... For all: SMPP v3.4 spec allow sequence number in the range from 0x0001 to 0x7FFF And we send 0x0 , that is wrong and SMSC do right job! I have sent similar patch for a while but . Am Freitag, 21. Februar 2003 13:29 schrieb Raphael Bellec: Thanks, I just applied it and I have the following log (see below). I have 2 questions: - Why is there 2 enquire link, is there one for the transmitter and one for the receiver? - The sequence number of the generic_nack seems to refer to the bind transmitter and bind_receiver. Is it the case? If it is, why does the SMSC wait for the enquire_link to send the generic_nack. If it is not the case, what could explain it? (SMSC trouble? ). Regards. 2003-02-21 11:28:18 [0] INFO: Kannel bearerbox II version 1.3.1 starting 2003-02-21 11:28:18 [0] INFO: MAIN: Start-up done, entering mainloop 2003-02-21 11:28:18 [7] DEBUG: sms_router: time to sleep 2003-02-21 11:28:18 [7] DEBUG: sms_router: list_len = 0 2003-02-21 11:28:18 [5] DEBUG: SMPP[opsmsc]: Sending PDU: 2003-02-21 11:28:18 [5] DEBUG: SMPP PDU 0x80f3b48 dump: 2003-02-21 11:28:18 [5] DEBUG: type_name: bind_transmitter 2003-02-21 11:28:18 [5] DEBUG: command_id: 2 = 0x0002 2003-02-21 11:28:18 [5] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: sequence_number: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: system_id: *** 2003-02-21 11:28:18 [5] DEBUG: password: *** 2003-02-21 11:28:18 [5] DEBUG: system_type: VMA 2003-02-21 11:28:18 [5] DEBUG: interface_version: 51 = 0x0033 2003-02-21 11:28:18 [5] DEBUG: addr_ton: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: addr_npi: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: address_range: 2003-02-21 11:28:18 [5] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:18 [6] DEBUG: SMPP[opsmsc]: Sending PDU: 2003-02-21 11:28:18 [6] DEBUG: SMPP PDU 0x80f3c78 dump: 2003-02-21 11:28:18 [6] DEBUG: type_name: bind_receiver 2003-02-21 11:28:18 [6] DEBUG: command_id: 1 = 0x0001 2003-02-21 11:28:18 [6] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:18 [6] DEBUG: sequence_number: 1 = 0x0001 2003-02-21 11:28:18 [6] DEBUG: system_id: *** 2003-02-21 11:28:18 [6] DEBUG: password: *** 2003-02-21 11:28:18 [6] DEBUG: system_type: VMA 2003-02-21 11:28:18 [6] DEBUG: interface_version: 51 = 0x0033 2003-02-21 11:28:18 [6] DEBUG: addr_ton: 0 = 0x 2003-02-21 11:28:18 [6] DEBUG: addr_npi: 0 = 0x 2003-02-21 11:28:18 [6] DEBUG: address_range: 2003-02-21 11:28:18 [6] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [5] DEBUG: SMPP[opsmsc]: Sending enquire link: 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU 0x80f3c78 dump: 2003-02-21 11:28:48 [5] DEBUG: type_name: enquire_link 2003-02-21 11:28:48 [5] DEBUG: command_id: 21 = 0x0015 2003-02-21 11:28:48 [5] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:48 [5] DEBUG: sequence_number: 2 = 0x0002 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [6] DEBUG: SMPP[opsmsc]: Sending enquire link: 2003-02-21 11:28:48 [6] DEBUG: SMPP PDU 0x80f3c78 dump: 2003-02-21 11:28:48 [6] DEBUG: type_name: enquire_link 2003-02-21 11:28:48 [6] DEBUG: command_id: 21 = 0x0015 2003-02-21 11:28:48 [6] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:48 [6] DEBUG: sequence_number: 3 = 0x0003 2003-02-21 11:28:48 [6] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [5] DEBUG: SMPP[opsmsc]: Got PDU: 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU 0x80f3cc0 dump: 2003-02-21 11:28:48 [5] DEBUG: type_name: generic_nack 2003-02-21 11:28:48 [5] DEBUG: command_id: 2147483648 = 0x8000 2003-02-21 11:28:48 [5] DEBUG: command_status: 4 = 0x0004 2003-02-21 11:28:48 [5] DEBUG: sequence_number: 0 = 0x 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [5] WARNING: SMPP[opsmsc]: SMSC sent generic_nack with wrong sequence number 0x 2003-02-21 11:28:48 [5] ERROR: SMPP[opsmsc]: I/O error or other error. Re-connecting. 2003-02-21 11:28:49 [6] DEBUG: SMPP[opsmsc]: Got PDU: 2003-02-21 11:28:49 [6] DEBUG: SMPP PDU 0x80f3c50 dump: 2003-02-21 11:28:49 [6] DEBUG: type_name: generic_nack 2003-02-21 11:28:49 [6] DEBUG: command_id: 2147483648 = 0x8000 2003-02-21 11:28:49 [6] DEBUG: command_status: 4 = 0x0004 2003-02-21 11:28:49 [6] DEBUG: sequence_number: 1 = 0x0001 2003-02-21 11:28:49 [6] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:49 [6] WARNING: SMPP[opsmsc]: SMSC sent generic_nack with wrong sequence number 0x0001 2003-02-21 11:28:49 [6] ERROR: SMPP[opsmsc]: I/O error or other error. Re-connecting. 2003-02-21 11:28:49 [5] DEBUG: SMPP[opsmsc]: Sending PDU: 2003-02-21 11:28:49 [5] DEBUG: SMPP PDU 0x80f3b48 dump: 2003-02-21 11:28:49 [5] DEBUG: type_name: bind_transmitter -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh
Re: multiple bearer box ?
Am Donnerstag, 20. Februar 2003 09:35 schrieb Kalle Marjola: The current Kannel is, however, made in that way that it gets trashed if it receives messages faster than it can handle, so beware :] I have sent patch to the list for avoiding this issue , but unfortunately it was not accepted ;( I will rework this patch and resend to the list. We use this patch in production and do not have any problems that kannel trashed. -- 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] icq: 98063111
Re: multiple bearer box ?
Am Donnerstag, 20. Februar 2003 11:44 schrieb Stipe Tolj: Alexander Malysh wrote: Am Donnerstag, 20. Februar 2003 09:35 schrieb Kalle Marjola: The current Kannel is, however, made in that way that it gets trashed if it receives messages faster than it can handle, so beware :] I have sent patch to the list for avoiding this issue , but unfortunately it was not accepted ;( I will rework this patch and resend to the list. We use this patch in production and do not have any problems that kannel trashed. please re-send and also quote which mail thread contained your orginal patch, so we can review why we didn't commit it yet. I need some time to make a new patch ;) Old version is at: http://www.mail-archive.com/devel@kannel.3glab.org/msg05721.html But some things have changed since first version ;) 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 -- 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] icq: 98063111
[PATCH] Re: SMPP 3.3 trouble
: Killing signal received, shutting down... 2003-02-20 11:23:48 [0] DEBUG: Shutting down Kannel... 2003-02-20 11:23:48 [0] DEBUG: shutting down smsc 2003-02-20 11:23:48 [0] DEBUG: Shutting down SMSCConn SMPP:192.168.1.210:3700/3700:login...:VMA (slow) 2003-02-20 11:23:48 [5] DEBUG: SMPP[opsmsc]: Sending unbind: 2003-02-20 11:23:48 [5] DEBUG: SMPP PDU 0x80f3d28 dump: 2003-02-20 11:23:48 [5] DEBUG: type_name: unbind 2003-02-20 11:23:48 [5] DEBUG: command_id: 6 = 0x0006 2003-02-20 11:23:48 [5] DEBUG: command_status: 0 = 0x 2003-02-20 11:23:48 [5] DEBUG: sequence_number: 6 = 0x0006 2003-02-20 11:23:48 [5] DEBUG: SMPP PDU dump ends. 2003-02-20 11:23:48 [5] DEBUG: SMPP[opsmsc]: io_thread: break and shutting down 2003-02-20 11:23:48 [5] DEBUG: Thread 5 (gw/smsc/smsc_smpp.c:io_thread) terminates. 2003-02-20 11:23:48 [6] DEBUG: SMPP[opsmsc]: Sending unbind: 2003-02-20 11:23:48 [6] DEBUG: SMPP PDU 0x80f3b18 dump: 2003-02-20 11:23:48 [6] DEBUG: type_name: unbind 2003-02-20 11:23:48 [6] DEBUG: command_id: 6 = 0x0006 2003-02-20 11:23:48 [6] DEBUG: command_status: 0 = 0x 2003-02-20 11:23:48 [6] DEBUG: sequence_number: 7 = 0x0007 2003-02-20 11:23:48 [6] DEBUG: SMPP PDU dump ends. 2003-02-20 11:23:48 [6] DEBUG: SMPP[opsmsc]: io_thread: break and shutting down 2003-02-20 11:23:48 [6] DEBUG: Thread 6 (gw/smsc/smsc_smpp.c:io_thread) terminates. 2003-02-20 11:23:48 [0] DEBUG: SMSCConn SMPP:192.168.1.210:3700/3700:login...:VMA shut down. 2003-02-20 11:23:48 [0] DEBUG: shutting down udp 2003-02-20 11:23:48 [4] DEBUG: Thread 4 (gw/bb_boxc.c:smsboxc_run) terminates. 2003-02-20 11:23:48 [0] INFO: All flow threads have died, killing core 2003-02-20 11:23:48 [0] DEBUG: Waiting for 2 (gwlib/http.c:server_thread) to terminate 2003-02-20 11:23:48 [3] DEBUG: HTTP: No clients with requests, quitting. 2003-02-20 11:23:48 [3] DEBUG: Thread 3 (gw/bb_http.c:httpadmin_run) terminates. 2003-02-20 11:23:48 [7] DEBUG: Thread 7 (gw/bb_smscconn.c:sms_router) terminates. 2003-02-20 11:23:48 [2] DEBUG: Thread 2 (gwlib/http.c:server_thread) terminates. 2003-02-20 11:23:48 [1] DEBUG: Thread 1 (gwlib/fdset.c:poller) terminates. 2003-02-20 11:23:48 [0] DEBUG: final clean-up for SMSCConn 2003-02-20 11:23:48 [0] INFO: Total WDP messages: received 0, sent 0 2003-02-20 11:23:48 [0] INFO: Total SMS messages: received 0, sent 0 2003-02-20 11:23:48 [0] DEBUG: Immutable octet strings: 230. Thanks for your help. Regards. Raphaël Bellec Directeur des opérations Manobi France Cap Alpha Avenue de lEurope, Clapiers 34940 Montpellier Cedex Tél : + 33 (0) 4 67 59 36 56 Fax : + 33 (0) 4 67 59 30 10 E-mail : [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] icq: 98063111
Re: SMPP 3.3 trouble
oops, fogot the patch ;) here is it... -- 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] icq: 98063111 Index: gw/smsc/smpp_pdu.def === RCS file: /home/cvs/gateway/gw/smsc/smpp_pdu.def,v retrieving revision 1.4 diff -a -u -r1.4 smpp_pdu.def --- gw/smsc/smpp_pdu.def 14 Nov 2002 00:38:51 - 1.4 +++ gw/smsc/smpp_pdu.def 20 Feb 2003 17:34:02 - @@ -149,7 +149,7 @@ ) PDU(generic_nack, -0x, +0x8000, HEADER )
[PATCH] SMPP trivial
Hi list, here is trivial SMPP generic_nack fix. generic_nack command id is 0x8000 instead of 0x Please apply ... -- 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] icq: 98063111 Index: gw/smsc/smpp_pdu.def === RCS file: /home/cvs/gateway/gw/smsc/smpp_pdu.def,v retrieving revision 1.4 diff -a -u -r1.4 smpp_pdu.def --- gw/smsc/smpp_pdu.def 14 Nov 2002 00:38:51 - 1.4 +++ gw/smsc/smpp_pdu.def 20 Feb 2003 17:34:02 - @@ -149,7 +149,7 @@ ) PDU(generic_nack, -0x, +0x8000, HEADER )
Re: multiple bearer box ?
Hi, On Wednesday 19 February 2003 11:03, Stipe Tolj wrote: Asif Ali wrote: hello all, i am new to this mailing list, i want to know if anybody's working on multi-bearer box architecture or there are any plans as it was identified as one of the key performance bottleneck issues, also the persistance of message streams as they pass through bearer box. hmm, I had that discussion with Alex from Centrium. They run an one bearerbox per smsc link architecture. It is definetly more Not 100% true ;) We run one logical link per bearerbox (e.g. 3 sessions for one offerer). For now I have not seen any performance bottleneck issues with bearerbox. Some of our bearerboxes running with ~60sms/sec. Now you will ask, why multiple bearerboxes ;) It's easy... It's more simple to maintain/route messages beetwen multiple bearerboxes. For example bearerbox do not support dynamic config reload and it's just more simple to read/write ~30 Lines of config file as 300 lines ;) performative if you get rid of all the required routing inside bearerbox if you use a bunch of smsc links inside one bearerbox, but it's more of theoretical interest. We run over 80 links in one bearerbox and fully stable. BTW, the performance bottle-neck will be of significanse when you get beyond 400 Msg/sec. (!) in MT/MO traffic, which I honestly don't expect you to have ;) 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 -- 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]
Re: [PATCH] allow setting service-type for SMPP SMSC
Hi, +1 from me too. We use similar patch for a while... Am Dienstag, 18. Februar 2003 15:08 schrieb Stipe Tolj: David Holland wrote: On Tue, Feb 18, 2003 at 02:58:12PM +0100, Stipe Tolj wrote: One thing only: what's the default of the value if *no* config directive is given?! NULL. (and I have tested that -- it appears correctly in the PDU dump) It looks you don't initialize the variable and hence you will pass garbage, or does cfg_get() return NULL in case the value is not given?! Yes, that's what happens. ok, then I'm off with ++1 :) 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 -- 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]
Re: [PATCH] allow setting service-type for SMPP SMSC
Am Dienstag, 18. Februar 2003 15:34 schrieb Stipe Tolj: +1 from me too. We use similar patch for a while... so why didn't you post it ;)) ahh I thought it is uninteresting for all ;) 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 -- 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]
Re: [RFC] urltrans'lations
Hi Stipe, List, Am Montag, 17. Februar 2003 16:48 schrieb Stipe Tolj: [snip] BTW, anyone tried to port Netikos's urltrans() routines (which are very good IMO) to the official source tree?! Can you please provide link to their changes/patches ? 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 -- 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]
Re: smsc_smpp.c -- some minor fixes
;) case 0x05: /* JIS - what do I do with that ? */ break; case 0x06: /* Cyrllic - iso-8859-5, I'll convert to unicode */ @@ -288,7 +298,7 @@ * you implement them if you feel like it */ default: -msg-sms.coding = DC_7BIT; + /* DAVE -- Don't do this, it was set OK by dcs_to_fields msg-sms.coding = DC_7BIT; */ } msg-sms.pid = pdu-u.deliver_sm.protocol_id; -- 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]
Fwd: Re: smsc_smpp.c -- some minor fixes
The old code overwrites correct values with wrong ones. Send a nokia
business card over sms to a kannel instance running smpp to see what I
mean.
will be tested ;)
There are no real efficiency implications to my patch. The int variable
udh_offset is initialized to 0, so if esm_class doesn't set UDHI, the line
after the conditional does The Right Thing.
You have misundestanding me. Why always copy octstr from pdu into msgdata ?
If udhi is not set we can just point msgdata to pdu message and set pdu
message to NULL, so pdu message will not be destroyed and we do not need to
alloc./copy octstr. (This is what smpp driver do already).
As for not using the #defines... Guilty as charged. I'll resubmit with the
comments cleaned up and using the #define. Thanks!
Dave WHITE
CONNECT AUSTRIA
-- original message --
Subject: Re: smsc_smpp.c -- some minor fixes
From: Alexander Malysh [EMAIL PROTECTED]
Date: Tue, 11 Feb 2003 18:57:22 +0100
Hi all,
-1 from me... see comments...
Am Dienstag, 11. Februar 2003 15:55 schrieb Dave White:
Here's a patch that fixes two deficiencies with Kannel's SMPP
implementation.
*) UDH for MO messages is not supported in the unpatched driver.
This patch will correctly deal with the most common (SMPP 3.3-style)
technique for sending MO's with UDH, namely esm_class |= 64 with the UDH
placed in the short_message field.
*) Coding for some message types is broken.
I changed smsc_smpp.c to rely on the (dcs|fields)to(fields|dcs)
functions in sms.c, and to only mess with the values if it does a
transformation to UCS2 or iso-8859-1.
I have some minor qualms about the patch.
There was
pdu-u.deliver_sm.short_message = NULL;
in pdu_to_msg in smsc_smpp.c which I honestly don't understand.
Also, I'm not entirely clear on how memory is freed in Kannel from the
Msg structure. Is there something like a destructor for the generated
datastructures Kannel uses? Could someone give me a pointer (groan)
where I should look to understand this?
So there is a small chance that it may leak a little memory. I suspect
the usual segfault on a free the dangling pointer would have bit me by
now if there were something wrong, but I don't want to rule that out
until a few more eyes have a look at it.
Testing on my system(s) works -- i.e. no observed crashes or memory
leak warnings, and correct handling of every kind of SMS data I could
throw at it.
Have fun,
David WHITE
CONNECT AUSTRIA
-- PATCH --
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.22
diff -u -r1.22 smsc_smpp.c
--- gw/smsc/smsc_smpp.c 2 Jan 2003 14:43:00 - 1.22
+++ gw/smsc/smsc_smpp.c 11 Feb 2003 14:48:37 -
@@ -233,7 +233,8 @@
static Msg *pdu_to_msg(SMPP *smpp, SMPP_PDU *pdu)
{
-Msg *msg;
+Msg *msg;
+int udh_offset = 0;
gw_assert(pdu-type == deliver_sm);
@@ -242,10 +243,19 @@
pdu-u.deliver_sm.source_addr = NULL;
msg-sms.receiver = pdu-u.deliver_sm.destination_addr;
pdu-u.deliver_sm.destination_addr = NULL;
-msg-sms.msgdata = pdu-u.deliver_sm.short_message;
-pdu-u.deliver_sm.short_message = NULL;
Set pdu-u.deliver_sm.short_message to NULL is OK, so we does't need to
copy/alloc. octstr (this is more efficiently).
+/* msg-sms.msgdata = pdu-u.deliver_sm.short_message; - done
later -- DAVE
+ pdu-u.deliver_sm.short_message = NULL; */
dcs_to_fields(msg, pdu-u.deliver_sm.data_coding);
+/* DAVE -- actually handle UDH */
+if (pdu-u.deliver_sm.esm_class 0x40) {
Why you do not use defines ? (e.g. pdu-u.deliver_sm.esm_class
ESM_CLASS_SUBMIT_UDH_INDICATOR) All (I believe) values are defined in
smpp_pdu.h
+ udh_offset = octstr_get_char(pdu-u.deliver_sm.short_message,0)+1;
+ msg-sms.udhdata =
octstr_copy(pdu-u.deliver_sm.short_message,0,udh_offset);
if we set pdu-u.deliver_sm.short_message=NULL above , this will not work
;( It should be:
udh_offset = octstr_get_char(msg-sms.msgdata,0)+1;
if (udh_offset octstr_len(msg-sms.msgdata)) /* just sanity check */
goto error;
msg-sms.udhdata = octstr_copy(msg-sms.msgdata,0,udh_offset);
octstr_delete(msg-sms.msgdata, 0, udh_offset);
This is (imho) more efficiently , because not every sms will have udh set
...
+}
+info(0, SMPP: pdu-u.deliver_sm.short_message = %x, udh_offset =
%d,pdu-u.deliver_sm.short_message,udh_offset);
+msg-sms.msgdata =
octstr_copy(pdu-u.deliver_sm.short_message,udh_offset,octstr_len(pdu-u.
de liver_sm.short_message)-udh_offset); +
+
/* handle default data coding */
switch (pdu-u.deliver_sm.data_coding) {
case 0x00: /* default SMSC alphabet */
@@ -257,11 +267,11 @@
if (charset_convert(msg-sms.msgdata,
octstr_get_cstr(smpp-alt_charset
Fwd: Re: EMI Driver Bug
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=testuserpassword=password;
t o=12345676from=987654321text=Test Message (A) is being
sent!smsc=testdlrmask=24dlrurl=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 * 0x, const char * 0x10066ffc, long 289,
const char * 0x10066ff4)
octstr_duplicate_real(Octstr * 0x)
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/2086/3//54657374204D65737361676
5202841292030206973206265696E672073656E7421//020111///0F
2003-02-03 15:11:28 [8] DEBUG: Adding DLR smsc=emi_smsc,
ts=emi_smsc-0:45676, src=2086, 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=%dsmsc_reply=%Areceiver=%psender=%Pmessage-
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
Re: EMI Driver Bug
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-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 -- 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]
[PATCH] Re: EMI Driver Bug
Hi All, attached patch should solve the bug , make small cleanup and add additional sanity check... please look in it and vote ... Am Montag, 3. Februar 2003 19:08 schrieb Michael Mulcahy: Michael you are right... should we replace: dlrmsg-sms.msgdata = octstr_duplicate(emimsg-fields[E50_AMSG]); with: dlrmsg-sms.msgdata = octstr_create(); ? I think so, unless other people working with EMI have a better idea! 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alexander Malysh (by way of Alexander Malysh [EMAIL PROTECTED]) Sent: 03 February 2003 15:57 To: [EMAIL PROTECTED] Subject: Re: EMI Driver Bug 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=testuserpassw ord=password t o=12345676from=987654321text=Test Message (A) is being sent!smsc=testdlrmask=24dlrurl=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 * 0x, const char * 0x10066ffc, long 289, const char * 0x10066ff4) octstr_duplicate_real(Octstr * 0x) 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/2086/3//5465737420 4D65737361676 5202841292030206973206265696E672073656E7421//020111///0F 2003-02-03 15:11:28 [8] DEBUG: Adding DLR smsc=emi_smsc, ts=emi_smsc-0:45676, src=2086, 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=%dsmsc_reply=%Areceiver=%psende r=%Pmessage- 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
Re: mysql and kannel
Hi Ivone, please stop asking config and compile options! This is developer mailing list for reporting bugs and discussing of devel things... For you questions exists user mailing list: [EMAIL PROTECTED] Thanks in advance ... On Friday 31 January 2003 21:36, Ivone Uribe wrote: Hi all!! I have a doubt. I have the mysql in these directories: /var/lib/mysql /var/lib/mysql/mysql /usr/bin/mysql /usr/lib/mysql /usr/share/mysql for this option --with-mysql[=DIR] where to look for MySQL libs and header files DIR points to the installation /usr/local/mysql] which dir should I choose? Thanks! Ivone _ -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de msn: [EMAIL PROTECTED] msg06401/pgp0.pgp Description: signature
[PATCH] SMPP trivial
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Stipe,list
Stipe I believe you have not seen corrected patch for smpp pdu parsing ;( It
was my fault not to resend my patch ;)
Please apply , this trivial patch will fix parsing of opt. parameters with
length = 0...
- --
Best Regards / Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: http://www.centrium.de
msn: [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+NwflnX3e5W+uJ0ERAt9ZAJ4twVEf2iuNNDgV6SOIGiPaf1AovwCgkmzM
RgKdsBmWGaTXmT5G0Cy2Tgg=
=i40c
-END PGP SIGNATURE-
Index: gw/smsc/smpp_pdu.c
===
RCS file: /home/cvs/gateway/gw/smsc/smpp_pdu.c,v
retrieving revision 1.8
diff -a -u -r1.8 smpp_pdu.c
--- gw/smsc/smpp_pdu.c 28 Jan 2003 00:11:54 - 1.8
+++ gw/smsc/smpp_pdu.c 28 Jan 2003 22:46:47 -
@@ -218,7 +218,7 @@
switch (type) {
#define OPTIONAL_BEGIN(num_expected)\
{ /* Read optional parameters */ \
-while (pos+4 len) { \
+while (pos+4 = len) { \
unsigned long opt_tag, opt_len; \
Octstr *opt_val = NULL; \
Octstr *tag_str = NULL; \
Re: [PATCH] http smsc crash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, +1 from me ... On Monday 27 January 2003 10:52, Angel Fradejas wrote: Hi all, Just a quick patch to fix a crash on the http smsc driver, when receiving incoming messages. (Maybe not on the first received, but on the 3rd or 4th). Simple enough to go in before new release. Cheers. Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 - -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de msn: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+NQ/EnX3e5W+uJ0ERAkZPAKD22vx3wMHgDACrgr04m2EAmeXi6ACgo+ib efCohIoWGZ4S69iU19zuEVI= =Dexk -END PGP SIGNATURE-
Re: [PATCH] make SMPP's PDU parsing more robust
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Stipe,
On Sunday 26 January 2003 14:13, Stipe Tolj wrote:
Hi Alexander,
Alexander Malysh schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
attached patch make parsing of SMPP optional parameters more robust
(IMHO). Patch include some cleanups , increasing MAX_SMPP_PDU_LEN
(because message_payload can be up to 64K octets) and add ability to dump
optional parameters.
I have rewritten parsing of optional parameters. Please look in it and
say what is more robust (my implementation , based on original, or the
original). My implementation was tested with 3 different SMSC
implementations.
comments and votes please ...
looks good to me, while untested yet. I'll try to hit some SMPP SMSCs
we use and see if standard operations work well.
BTW, which 3 SMSC vendors did you test against?!
Two of it were own implementations of our offerers and one were Telepath (I
beleave , but not sure).
BTW, after sending this patch I found a small BUG ;)
+{ /* Read optional parameters */ \
+while (pos+4 len) { \
Here must be:
+{ /* Read optional parameters */ \
+while (pos+4 = len) { \
Because it is OK if length of value is 0. Old version will work for most
optional parameters , but not for opt. parameters with length of value = 0.
Corrected patch attached. Sorry for 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
- --
Best Regards / Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: http://www.centrium.de
msn: [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+M+tLnX3e5W+uJ0ERAqUIAKCFVY2KcV/epd1ndbRu0OVkc3T05QCfa7In
BQntI4Lwvnq23ftUU7JI7wc=
=yY46
-END PGP SIGNATURE-
Index: gw/smsc/smpp_pdu.c
===
RCS file: /home/cvs/gateway/gw/smsc/smpp_pdu.c,v
retrieving revision 1.7
diff -a -u -r1.7 smpp_pdu.c
--- gw/smsc/smpp_pdu.c 21 Jan 2003 14:39:58 - 1.7
+++ gw/smsc/smpp_pdu.c 26 Jan 2003 14:10:38 -
@@ -9,7 +9,8 @@
#include smpp_pdu.h
#define MIN_SMPP_PDU_LEN(4*4)
-#define MAX_SMPP_PDU_LEN(1024)
+/* old value was (1024). We need more because message_payload can be up to 64K octets*/
+#define MAX_SMPP_PDU_LEN(7424)
static unsigned long decode_integer(Octstr *os, long pos, int octets)
@@ -64,7 +65,8 @@
pdu-type = type;
switch (type) {
-#define OPTIONAL_BEGIN(num_expected) p-optional_parameters = dict_create(num_expected, (void (*)(void *))octstr_destroy);
+#define OPTIONAL_BEGIN(num_expected) \
+ p-optional_parameters = dict_create(num_expected, (void (*)(void *))octstr_destroy);
#define TLV(tag_id, min_len, max_len)
#define OPTIONAL_END
#define INTEGER(name, octets) \
@@ -89,7 +91,6 @@
return pdu;
}
-
void smpp_pdu_destroy(SMPP_PDU *pdu)
{
if (pdu == NULL)
@@ -144,7 +145,7 @@
#define TLV(tag_id, min_len, max_len) \
{ /* Add optional parameter - if existing */ \
short tag_id_buffer = tag_id; \
-Octstr *opt_tag = octstr_create_from_data_real((char*) tag_id_buffer, 2); \
+Octstr *opt_tag = octstr_create_from_data((char*) tag_id_buffer, 2); \
Octstr *opt_val = dict_get(p-optional_parameters, opt_tag);\
if (opt_val != NULL) { \
long opt_len = octstr_len(opt_val); \
@@ -216,40 +217,37 @@
switch (type) {
#define OPTIONAL_BEGIN(num_expected)\
-{ /* Rread optional parameters */ \
-while (pos len) { \
-Octstr *opt_tag = NULL; \
+{ /* Read optional parameters */ \
+while (pos+4 = len) { \
+unsigned long opt_tag, opt_len
Re: [RFC] new development version?!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stipe,List, On Sunday 26 January 2003 13:44, Stipe Tolj wrote: Hi list, we had a couple of bug fixes now since 1.3.0 and I'd like to release a new development version. Any vetos?! it's a good idea ;) Which versioning should be used for it? 1.3.1? I will vote for 1.3.1 (you know my opinion about versioning ;)) BTW, anyone working on the long outstanding WTLS issue?! I think it would be pretty cool to have that fully implemented. 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 - -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de msn: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+NACenX3e5W+uJ0ERAu01AKDJdt+ye8dyIW0dmUZQr7KRN5NBzgCgtwMh dS/JVT2q9V0oTytQYCNA7nY= =LhWY -END PGP SIGNATURE-
[PATCH] make SMPP's PDU parsing more robust
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
attached patch make parsing of SMPP optional parameters more robust (IMHO).
Patch include some cleanups , increasing MAX_SMPP_PDU_LEN (because
message_payload can be up to 64K octets) and add ability to dump optional
parameters.
I have rewritten parsing of optional parameters. Please look in it and say
what is more robust (my implementation , based on original, or the original).
My implementation was tested with 3 different SMSC implementations.
comments and votes please ...
- --
Best Regards / Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: http://www.centrium.de
msn: [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+MuLVnX3e5W+uJ0ERAvsAAKCX94DOMQB/cypfjLOktlFKYxXOBACghXVA
2EikLgVhNL88McrsZpHyYKw=
=Y4q9
-END PGP SIGNATURE-
Index: gw/smsc/smpp_pdu.c
===
RCS file: /home/cvs/gateway/gw/smsc/smpp_pdu.c,v
retrieving revision 1.7
diff -a -u -r1.7 smpp_pdu.c
--- gw/smsc/smpp_pdu.c 21 Jan 2003 14:39:58 - 1.7
+++ gw/smsc/smpp_pdu.c 25 Jan 2003 19:19:50 -
@@ -9,7 +9,8 @@
#include smpp_pdu.h
#define MIN_SMPP_PDU_LEN(4*4)
-#define MAX_SMPP_PDU_LEN(1024)
+/* old value was (1024). We need more because message_payload can be up to 64K octets*/
+#define MAX_SMPP_PDU_LEN(7424)
static unsigned long decode_integer(Octstr *os, long pos, int octets)
@@ -64,7 +65,8 @@
pdu-type = type;
switch (type) {
-#define OPTIONAL_BEGIN(num_expected) p-optional_parameters = dict_create(num_expected, (void (*)(void *))octstr_destroy);
+#define OPTIONAL_BEGIN(num_expected) \
+ p-optional_parameters = dict_create(num_expected, (void (*)(void *))octstr_destroy);
#define TLV(tag_id, min_len, max_len)
#define OPTIONAL_END
#define INTEGER(name, octets) \
@@ -89,7 +91,6 @@
return pdu;
}
-
void smpp_pdu_destroy(SMPP_PDU *pdu)
{
if (pdu == NULL)
@@ -144,7 +145,7 @@
#define TLV(tag_id, min_len, max_len) \
{ /* Add optional parameter - if existing */ \
short tag_id_buffer = tag_id; \
-Octstr *opt_tag = octstr_create_from_data_real((char*) tag_id_buffer, 2); \
+Octstr *opt_tag = octstr_create_from_data((char*) tag_id_buffer, 2); \
Octstr *opt_val = dict_get(p-optional_parameters, opt_tag);\
if (opt_val != NULL) { \
long opt_len = octstr_len(opt_val); \
@@ -216,39 +217,36 @@
switch (type) {
#define OPTIONAL_BEGIN(num_expected)\
-{ /* Rread optional parameters */ \
-while (pos len) { \
-Octstr *opt_tag = NULL; \
+{ /* Read optional parameters */ \
+while (pos+4 len) { \
+unsigned long opt_tag, opt_len; \
Octstr *opt_val = NULL; \
Octstr *tag_str = NULL; \
-int opt_len = 0;\
-int tag_id_buffer = 0; \
-opt_tag = octstr_copy(data_without_len, pos, 2); pos += 2; \
-opt_len = octstr_get_char(data_without_len, pos); pos++;\
-debug(smpp_pdu, 0, Optional parameter length read as %d, opt_len); \
-if (opt_len 0) { \
-opt_val = octstr_copy(data_without_len, pos, opt_len); \
-pos += opt_len; \
+opt_tag = decode_integer(data_without_len, pos, 2); pos += 2; \
+debug(sms.smpp, 0, Optional parameter tag (0x%04lx), opt_tag); \
+opt_len = decode_integer(data_without_len, pos, 2); pos += 2; \
+debug(smpp_pdu, 0, Optional parameter length read as %ld, opt_len);
+#define TLV(tag_id, min_len, max_len) \
+if (tag_id
Re: [PATCH] unneeded counter increase?!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stipe, list, +1 from me. Counter will be increased in bb_smscconn_receive(...)... On Tuesday 21 January 2003 12:04, Stipe Tolj wrote: Hi list, is this patch making sense: RCS file: /home/cvs/gateway/gw/smsc/smsc_emi2.c,v retrieving revision 1.7 diff -r1.7 smsc_emi2.c 713d712 counter_increase(conn-received); Can someone who runs emi2 in production state a comment and/or vote please?! 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 - -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+LTKsnX3e5W+uJ0ERAt6RAJsFzOY9qoH3KxsI0UI0/bVVPtYnXwCfcdv4 /bCxdWEUv1gV21+HPHtroL4= =yPfE -END PGP SIGNATURE-
Re: Notice of issue in SMPP Driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stipe, all, On Monday 13 January 2003 22:54, Stipe Tolj wrote: should we introduce transmitter and receiver dependent status flags, like smpp-conn-status-receiver = SMSCCON_RECONNECTING; smpp-conn-status-transmitter = SMSCCON_ACTIVE. ?? it looks ugly (IMHO). What about , just to allow either receiver or transmitter or transceiver ? Like so: group = smsc smsc = smpp port = xxx host = xxx group = smsc smsc = smpp receive-port = xxx receive-host = xxx ?? Any patch for the suspected rade condition yet? 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 - -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+I0V9nX3e5W+uJ0ERAgFeAJoCSwIZr94FhPjF6KgapRzSymasAQCglkh9 DuMmB9lMAEpnrZfNMspHa2k= =6Yil -END PGP SIGNATURE-
Need some input about DLR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I need some explanation about DLR in SMPP. SMPP spec. is unfortunally not clear about sms states. Really question is: what mean UNDELIVERABLE ? Mean this 1) undeliverable at this point in time or 2) undeliverable at all ? If second , what state should be send for buffered ? It would be greate if people can tell their experiences with different SMSC's... Thanks in advance... - -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+G0njnX3e5W+uJ0ERAh3FAJ9DHLZGCgMRVl6wmhF9MfOzzfza1ACgh3B3 zLpIB2AWp/NxbVjZ5eYuGeA= =mMjD -END PGP SIGNATURE-
Re: [RFC] version number for development release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I agree with Bruno. +1 from me (if I may to vote?)... On Saturday 04 January 2003 16:34, Bruno David Simões Rodrigues wrote: Citando Stipe Tolj [EMAIL PROTECTED]: Hi guys, I asked what the versioning should look like for the upcoming development release?! Should I name it 1.3.0 or then 1.3.1 for the stabilized version or 1.3.0rc1? Just tag it as 1.3.0. If it's a development branch, it doesn't need to be stable. Then tag 1.3.1, 1.3.2 as soon as someone implements something big and we need to know 1.3.2 was before implementing xpto and everything was working. PS: Stipe: I was in Düsseldorf some weeks ago and I've tried to call you and a nice operator girl said that your number was not assigned (something like that for what I understood from german :) - -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Fw2FnX3e5W+uJ0ERAr/CAJ4v6CY/mAehxjzDL+ajc2d1IRogaQCgo1tk pHZJBel5k/xSVA1tbgQ6CA8= =ZZuj -END PGP SIGNATURE-
Re: [RFC] version number for development release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 04 January 2003 18:08, Stipe Tolj wrote: Alexander Malysh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I agree with Bruno. +1 from me (if I may to vote?)... as this is an open source project everyone is invited to vote. At least if the vote references an previously explained opinion or contains explanetory why one is voting the way he does ;) It's _simple_ , I do not like rc for development release ;) 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 - -- Best Regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+FxoBnX3e5W+uJ0ERAkCCAKDpuYErk8csIEBpazM/AxqNXyp/VACgjyaY Vm2/Y5G978UTi3vzAj4Hnhs= =uGmQ -END PGP SIGNATURE-
Re: [PATCH] Re: Kannel 1.2.1 PANIC when invoking store-status url
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stipe, all, On Friday 27 December 2002 00:56, Stipe Tolj wrote: Alexander Malysh wrote: this patch shall fix this ... thanks a lot for the patch! I slightly modified it and commited it to cvs. BTW, checking if the Octstr *filename id not NULLed or the FILE *file descriptor is basically the same in this case?! Unfortunally no... If store_cleanup thread call store_dump you set file = NULL and if in the same moment store_save called , then you check file != NULL and return with 0. But in this case we have store file and we want block on the list (sms_store or ack_store) and you have race condition wich follows with warning get ACK of message not found... FILE *file is not the indicator that we doesn't use store file ! Indicator for us is filename , wich will not be set to NULL... 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 - -- Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+DEu9nX3e5W+uJ0ERAkbnAJ9I3twAf2Wits36pNjETZ2c9YHpJACg53hp mzpuDWpHoP6w68T3ejbUu6Y= =4+Wm -END PGP SIGNATURE-
Re: [PATCH] heartbeat bug fix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again,
On Friday 27 December 2002 01:03, Stipe Tolj wrote:
Hi Alex,
Alexander Malysh schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
here is small patch to get heartbeat work again ...
thanks for the patch. We appritiate your commitment.
Ah sorry , I thought that it is self-describing ;)
Index: gw/heartbeat.c
===
RCS file: /home/cvs/gateway/gw/heartbeat.c,v
retrieving revision 1.3
diff -a -u -r1.3 heartbeat.c
- --- gw/heartbeat.c29 May 2002 12:27:21 - 1.3
+++ gw/heartbeat.c 26 Dec 2002 22:02:43 -
@@ -56,11 +56,12 @@
* This is not bad unless we send them way too fast. Make sure
* our frequency is not more than twice the configured one.
*/
- -if (difftime(last_hb, time(NULL)) info-freq / 2)
Here is wrong difftime calculation and heartbeat messages will never be sent
to bearerbox.
+if (difftime(time(NULL), last_hb) info-freq / 2)
continue;
msg = msg_create(heartbeat);
- -msg-heartbeat.load = info-load_func();
This is just sanity check for the case , that you have no load function and
want tell bearerbox , that you alive ...
+if (NULL != info-load_func)
+msg-heartbeat.load = info-load_func();
info-send_func(msg);
last_hb = time(NULL);
}
@@ -70,6 +71,10 @@
hb_load_func_t *load_func)
{
struct hb_info *info;
Sanity check for case that someone want use heartbeat and doesn't define send
function.
+
+/* can't start with send_funct NULL */
+if (send_func == NULL)
+return -1;
info = gw_malloc(sizeof(*info));
info-send_func = send_func;
[snip]
- --
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: http://www.centrium.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+DFGznX3e5W+uJ0ERAqBSAKCi12LyQvyndPgFAlGupOxST2ymZACfUexp
QDxkPkUP+Za7T20wr2S2YeI=
=WUTL
-END PGP SIGNATURE-
[PATCH] Re: Kannel 1.2.1 PANIC when invoking store-status url
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
this patch shall fix this ...
On Thursday 26 December 2002 16:38, Stipe Tolj wrote:
Hi Mauricio,
I'm back again after few months and starting new tests and assessments.
great, welcome back :)
I'm using Kannel 1.2.1 with external dlr (MySQL) and experiencing this
error when invoking the store-status url.
2002-12-26 11:57:04 [3] PANIC: gwlib/list.c:287: list_lock: Assertion
`list != NULL' failed.
Any help?
not directly. Please take some time to crack the problem down on your
own. It seems a list seems to be tried to be locked while it is
NULLed.
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
- --
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: http://www.centrium.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+C0AGnX3e5W+uJ0ERAvv+AJ9QkouM7wlvtS5/v+She1cskcmgywCeI3h2
4YCsbNoH8Ggx9DYEpcHW9vc=
=6I2C
-END PGP SIGNATURE-
Index: gw/bb_store.c
===
RCS file: /home/cvs/gateway/gw/bb_store.c,v
retrieving revision 1.16
diff -a -u -r1.16 bb_store.c
--- gw/bb_store.c 26 Aug 2002 14:10:10 - 1.16
+++ gw/bb_store.c 26 Dec 2002 17:55:24 -
@@ -207,6 +207,10 @@
ret = octstr_create();
+/* check if we initialized before */
+if (filename == NULL)
+ return ret;
+
/* set the type based header */
if (status_type == BBSTATUS_HTML) {
octstr_append_cstr(ret, table border=1\n
@@ -280,7 +284,8 @@
{
Msg *copy;
-if (file == NULL)
+/* check if we initialized before */
+if (filename == NULL)
return 0;
if (msg_type(msg) == sms) {
[PATCH] heartbeat bug fix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
here is small patch to get heartbeat work again ...
- --
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: http://www.centrium.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+C3pHnX3e5W+uJ0ERAuktAKDWyw9zxpiYyJ8LS9AVTvXkesVJTwCcC5Wg
5T3VoZr/KpaEph9CeprNw4M=
=gmcd
-END PGP SIGNATURE-
Index: gw/heartbeat.c
===
RCS file: /home/cvs/gateway/gw/heartbeat.c,v
retrieving revision 1.3
diff -a -u -r1.3 heartbeat.c
--- gw/heartbeat.c 29 May 2002 12:27:21 - 1.3
+++ gw/heartbeat.c 26 Dec 2002 22:02:43 -
@@ -56,11 +56,12 @@
* This is not bad unless we send them way too fast. Make sure
* our frequency is not more than twice the configured one.
*/
-if (difftime(last_hb, time(NULL)) info-freq / 2)
+if (difftime(time(NULL), last_hb) info-freq / 2)
continue;
msg = msg_create(heartbeat);
-msg-heartbeat.load = info-load_func();
+if (NULL != info-load_func)
+msg-heartbeat.load = info-load_func();
info-send_func(msg);
last_hb = time(NULL);
}
@@ -70,6 +71,10 @@
hb_load_func_t *load_func)
{
struct hb_info *info;
+
+/* can't start with send_funct NULL */
+if (send_func == NULL)
+return -1;
info = gw_malloc(sizeof(*info));
info-send_func = send_func;
[PATCH] smpp suspend fix
Hi all,
attached patch will fix non working suspend/isolate for smpp.
--
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstraße 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: www.centrium.de
? test/wapproxy
Index: gw/smsc/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.19
diff -a -u -r1.19 smsc_smpp.c
--- gw/smsc/smsc_smpp.c 7 Dec 2002 14:53:40 - 1.19
+++ gw/smsc/smsc_smpp.c 11 Dec 2002 11:03:40 -
@@ -63,7 +63,8 @@
enum {
SMPP_ESME_RMSGQFUL = 0x0014,
-SMPP_ESME_RTHROTTLED = 0x0058
+SMPP_ESME_RTHROTTLED = 0x0058,
+SMPP_ESME_RX_T_APPN = 0x0064
} SMPP_ERROR_MESSAGES;
@@ -683,6 +684,19 @@
switch (pdu-type) {
case deliver_sm:
/* XXX UDH */
+ /*
+ * If SMSCConn stopped then send temp. error code
+ */
+ mutex_lock(smpp-conn-flow_mutex);
+ if (smpp-conn-is_stopped) {
+ mutex_unlock(smpp-conn-flow_mutex);
+ resp = smpp_pdu_create(deliver_sm_resp,
+ pdu-u.deliver_sm.sequence_number);
+ resp-u.deliver_sm.command_status = SMPP_ESME_RX_T_APPN;
+ break;
+ }
+ mutex_unlock(smpp-conn-flow_mutex);
+
/*
* bb_smscconn_receive can fail, but we ignore that since we
* have no way to usefull tell the SMS center about this
Re: [PATCH] smpp suspend fix
Hi again, Am Mittwoch, 11. Dezember 2002 12:44 schrieb Stipe Tolj: Hi Alexander, attached patch will fix non working suspend/isolate for smpp. please do write more commentary to your patches. The others should gain the ability to see what has been fixed, this includes the description of the scenario when something does not work as intended and in which way you solve the problem. Sorry ... Here is sum up of the problem. If bearerbox will be suspended/isolated then smscconn_stop set is_stopped flag in SMSCConn to 1. But unfortunally SMPP never check this flag and do not implement stop callback function (defined in SMSCConn). Also SMPP will allways receive messages and suspend does't work... Suspend require that SMSCConn do not receive any messages , but can send. My patch check if is_stopped flag is set and then set command_status in deliver_sm_resp to ESME Receiver Temporary App Error Code so SMSC will try again. Thanks in advance. 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 -- Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de
[PATCH] internal dlr race fix
Hi,
here is 3 liner patch to fix race condition in internal dlr.
--
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstraße 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: www.centrium.de
Index: gw/dlr.c
===
RCS file: /home/cvs/gateway/gw/dlr.c,v
retrieving revision 1.31
diff -a -u -r1.31 dlr.c
--- gw/dlr.c 14 Nov 2002 02:29:25 - 1.31
+++ gw/dlr.c 2 Dec 2002 16:34:09 -
@@ -511,6 +511,7 @@
int dlr_mask;
debug(dlr.dlr, 0, Looking for DLR smsc=%s, ts=%s, dst=%s, type=%d, smsc, ts, dst, typ);
+list_lock(dlr_waiting_list);
len = list_len(dlr_waiting_list);
for (i=0; i len; i++) {
dlr = list_get(dlr_waiting_list, i);
@@ -563,9 +564,11 @@
dlr_destroy(dlr);
}
+list_unlock(dlr_waiting_list);
return msg;
}
}
+list_unlock(dlr_waiting_list);
debug(dlr.dlr, 0, DLR not found!);
/* we couldnt find a matching entry */
return NULL;
[PATCH] store not critical fix
Hi all,
and again small fix ;) Here is small fix for bb_store.
--
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstraße 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: www.centrium.de
Index: gw/bb_store.c
===
RCS file: /home/cvs/gateway/gw/bb_store.c,v
retrieving revision 1.16
diff -a -u -r1.16 bb_store.c
--- gw/bb_store.c 26 Aug 2002 14:10:10 - 1.16
+++ gw/bb_store.c 2 Dec 2002 18:40:34 -
@@ -393,10 +393,6 @@
msgs++;
}
else if (msg_type(msg) == ack) {
- if (msg-sms.sms_type == report) {
- octstr_destroy(pack);
- continue;
- }
key = octstr_format(%d-%d, msg-ack.time, msg-ack.id);
dmsg = dict_remove(msg_hash, key);
if (dmsg != NULL)
Re: [PATCH] avoid bearerbox oom-kill (fix)
Hi Stipe,
On Sunday 17 November 2002 15:05, you wrote:
Hi Alexander,
ok, I tried to understand the patch. Here is what I sum up:
Within gw/bb_boxc.c:boxc_receiver() you create a msg of type ack and
fill it with values depending on the result of the smsc2_rout() call.
ok so far ok.
you are right here..
Then you inject the ack msg to conn-incoming. But I don't see any
usage of that queue within smsbox? So the question is: where is the
ack msg used after this?
Please see boxc_sender :
if ((msg = list_consume(conn-incoming)) == NULL) {
...
}
boxc_sender is consumer of this list ...
We don't use smsbox and generated ack will not be used within smsbox. This should be
implemented ;)
If you want I can do this ?
Regards Alex
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
--
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstrasse 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: http://www.centrium.de
[PATCH] Avoid bearerbox oom-kill!
Hi List,
here is a small patch to avoid bearerbox oom-kill and give smsbox really
status of sms.
OOM-Kill simple scenario:
your bearerbox is connected to SMSC but connection is broken (temporarely).
So smsbox send sms to bearerbox (bbbox) and bbbox store it in queue (list) and
sometimes is bbbox too large im mem (in worst case will be killed from
kernel). Now you can define in config maximum-queue-length (applies for both
queues) and bbbox send ack/nack to smsbox.
For MO traffic I have added saying return codes , so each ptocol layer can use
this (I beleave it's better as just -1 and protocol layer don't know why?)
Comments?
--
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstraße 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: www.centrium.de
Index: gw/bb_boxc.c
===
RCS file: /home/cvs/gateway/gw/bb_boxc.c,v
retrieving revision 1.59
diff -a -u -r1.59 bb_boxc.c
--- gw/bb_boxc.c 14 Nov 2002 02:29:25 - 1.59
+++ gw/bb_boxc.c 15 Nov 2002 12:57:37 -
@@ -42,7 +42,7 @@
static List *smsbox_list = NULL;
/* dictionaries for holding the smsbox routing information */
-static Dict *smsbox_by_id = NULL;
+static Dict *smsbox_by_id = NULL;
static Dict *smsbox_by_smsc = NULL;
static Dict *smsbox_by_receiver = NULL;
@@ -56,7 +56,7 @@
static long boxid = 0;
-extern Mutex *boxid_mutex;
+extern Mutex *boxid_mutex;
typedef struct _boxc {
@@ -108,7 +108,7 @@
return NULL;
}
}
-
+
if (pack == NULL)
return NULL;
@@ -124,7 +124,8 @@
static void boxc_receiver(void *arg)
{
Boxc *conn = arg;
-Msg *msg;
+Msg *msg, *mack;
+int rc;
/* remove messages from socket until it is closed */
while (bb_status != BB_DEAD conn-alive) {
@@ -133,35 +134,49 @@
msg = read_from_box(conn);
-if (msg == NULL) { /* garbage/connection lost */
-conn-alive = 0;
-break;
-}
-
-if (msg_type(msg) == sms conn-is_wap == 0) {
-debug(bb.boxc, 0, boxc_receiver: sms received);
+ if (msg == NULL) { /* garbage/connection lost */
+ conn-alive = 0;
+ break;
+ }
-/*
- * XXX save modifies ID, so if the smsbox uses it, save
- * it FIRST for the reply message!!!
- */
-store_save(msg);
-if (smsc2_rout(msg)== -1) {
-warning(0, Message rejected by bearerbox, no router!);
-/* send NACK */
-bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED);
-}
-if (msg-sms.sms_type == mt_push) {
-/*
- * XXX generate ack-message and send it - in fact, this
- * should include information did it succeed, wa sit queued
- * or rejected...
- */
-}
+ if (msg_type(msg) == sms conn-is_wap == 0) {
+ debug(bb.boxc, 0, boxc_receiver: sms received);
+ /* save modifies ID, so if the smsbox uses it, save
+ * it FIRST for the reply message!!!
+ * generate ack-message and send it - in fact, this
+ * should include information did it succeed, wa sit queued
+ * or rejected...
+ */
+ mack = msg_create(ack);
+ mack-ack.id = msg-sms.id;
+ mack-ack.time = msg-sms.time;
+ store_save(msg);
+ rc = smsc2_rout(msg);
+ switch (rc) {
+ case -1:
+ warning(0, Message rejected by bearerbox, no router !);
+ /* send NACK */
+ bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED);
+ mack-ack.nack = ack_failed;
+ break;
+ case -2:
+ warning(0, Message rejected by bearerbox, queue full !);
+ /* send NACK */
+ bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED);
+ mack-ack.nack = ack_failed_tmp;
+ break;
+ case 0:
+ mack-ack.nack = ack_buffered;
+ break;
+ case 1:
+ mack-ack.nack = ack_success;
+ break;
+ }
+ list_produce(conn-incoming, mack);
} else if (msg_type(msg) == wdp_datagram conn-is_wap) {
debug(bb.boxc, 0, boxc_receiver: got wdp from wapbox);
-
+
list_produce(conn-outgoing, msg);
} else if (msg_type(msg) == sms conn-is_wap) {
@@ -189,10 +204,10 @@
else if (msg_type(msg) == admin msg-admin.command == cmd_identify) {
List *newlist;
-/* and add the boxc_ud into conn for boxc_status() output */
+/* and add the boxc_id into conn for boxc_status() output */
if (conn-boxc_id == NULL)
conn-boxc_id = octstr_duplicate(msg-admin.boxc_id
[PATCH] avoid bearerbox oom-kill (fix)
Hi,
this is the same oom-kill patch with memleak bugfix.
--
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstraße 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: www.centrium.de
Index: gw/bb_boxc.c
===
RCS file: /home/cvs/gateway/gw/bb_boxc.c,v
retrieving revision 1.59
diff -a -u -r1.59 bb_boxc.c
--- gw/bb_boxc.c 14 Nov 2002 02:29:25 - 1.59
+++ gw/bb_boxc.c 15 Nov 2002 17:41:17 -
@@ -42,7 +42,7 @@
static List *smsbox_list = NULL;
/* dictionaries for holding the smsbox routing information */
-static Dict *smsbox_by_id = NULL;
+static Dict *smsbox_by_id = NULL;
static Dict *smsbox_by_smsc = NULL;
static Dict *smsbox_by_receiver = NULL;
@@ -56,7 +56,7 @@
static long boxid = 0;
-extern Mutex *boxid_mutex;
+extern Mutex *boxid_mutex;
typedef struct _boxc {
@@ -108,7 +108,7 @@
return NULL;
}
}
-
+
if (pack == NULL)
return NULL;
@@ -124,7 +124,8 @@
static void boxc_receiver(void *arg)
{
Boxc *conn = arg;
-Msg *msg;
+Msg *msg, *mack;
+int rc;
/* remove messages from socket until it is closed */
while (bb_status != BB_DEAD conn-alive) {
@@ -133,42 +134,56 @@
msg = read_from_box(conn);
-if (msg == NULL) { /* garbage/connection lost */
-conn-alive = 0;
-break;
-}
-
-if (msg_type(msg) == sms conn-is_wap == 0) {
-debug(bb.boxc, 0, boxc_receiver: sms received);
+ if (msg == NULL) { /* garbage/connection lost */
+ conn-alive = 0;
+ break;
+ }
-/*
- * XXX save modifies ID, so if the smsbox uses it, save
- * it FIRST for the reply message!!!
- */
-store_save(msg);
-if (smsc2_rout(msg)== -1) {
-warning(0, Message rejected by bearerbox, no router!);
-/* send NACK */
-bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED);
-}
-if (msg-sms.sms_type == mt_push) {
-/*
- * XXX generate ack-message and send it - in fact, this
- * should include information did it succeed, wa sit queued
- * or rejected...
- */
-}
+ if (msg_type(msg) == sms conn-is_wap == 0) {
+ debug(bb.boxc, 0, boxc_receiver: sms received);
+ /* save modifies ID, so if the smsbox uses it, save
+ * it FIRST for the reply message!!!
+ * generate ack-message and send it - in fact, this
+ * should include information did it succeed, wa sit queued
+ * or rejected...
+ */
+ mack = msg_create(ack);
+ mack-ack.id = msg-sms.id;
+ mack-ack.time = msg-sms.time;
+ store_save(msg);
+ rc = smsc2_rout(msg);
+ switch (rc) {
+ case -1:
+ warning(0, Message rejected by bearerbox, no router !);
+ /* send NACK */
+ bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED);
+ mack-ack.nack = ack_failed;
+ break;
+ case -2:
+ warning(0, Message rejected by bearerbox, queue full !);
+ /* send NACK */
+ bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED);
+ mack-ack.nack = ack_failed_tmp;
+ break;
+ case 0:
+ mack-ack.nack = ack_buffered;
+ break;
+ case 1:
+ mack-ack.nack = ack_success;
+ break;
+ }
+ list_produce(conn-incoming, mack);
} else if (msg_type(msg) == wdp_datagram conn-is_wap) {
debug(bb.boxc, 0, boxc_receiver: got wdp from wapbox);
-
+
list_produce(conn-outgoing, msg);
} else if (msg_type(msg) == sms conn-is_wap) {
debug(bb.boxc, 0, boxc_receiver: got sms from wapbox);
store_save(msg);
-if (smsc2_rout(msg)== -1) {
+if (smsc2_rout(msg) 0) {
warning(0, Message rejected by bearerbox, no router!);
msg_destroy(msg);
}
@@ -189,10 +204,10 @@
else if (msg_type(msg) == admin msg-admin.command == cmd_identify) {
List *newlist;
-/* and add the boxc_ud into conn for boxc_status() output */
+/* and add the boxc_id into conn for boxc_status() output */
if (conn-boxc_id == NULL)
conn-boxc_id = octstr_duplicate(msg-admin.boxc_id);
-/*
+/*
* re-link the incoming queue for this connection to an independent
*/
newlist = list_create();
@@ -200,7 +215,7 @@
conn-incoming = newlist;
conn-retry = newlist
Re: [PATCH] avoid bearerbox oom-kill (resend)
Hi,
Am Freitag, 15. November 2002 19:00 schrieb Nisan Bloch:
Hi
please re submit this patch as a unified diff, and ignoring changes to
white space. This is horrid to read as there are many lines in the diff
that are not necessary.
sorry for this ;)
here is it ...
nisan
At 06:49 PM 11/15/02 +0100, Alexander Malysh wrote:
Content-Type: text/plain;
charset=iso-8859-15
X-MIME-Autoconverted: from 8bit to quoted-printable by mail-in-01.piro.net
id SAA23798
Hi,
this is the same oom-kill patch with memleak bugfix.
--
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstraße 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: www.centrium.de
--
Mit besten Grüßen aus Köln
Dipl.-Ing.
Alexander Malysh
___
Centrium GmbH
Ehrenstraße 2
50672 Köln
Fon: +49 (0221) 277 49 150
Fax: +49 (0221) 277 49 109
email: [EMAIL PROTECTED]
web: www.centrium.de
Index: gw/bb_boxc.c
===
RCS file: /home/cvs/gateway/gw/bb_boxc.c,v
retrieving revision 1.59
diff -a -u -b -r1.59 bb_boxc.c
--- gw/bb_boxc.c 14 Nov 2002 02:29:25 - 1.59
+++ gw/bb_boxc.c 15 Nov 2002 18:37:00 -
@@ -124,7 +124,8 @@
static void boxc_receiver(void *arg)
{
Boxc *conn = arg;
-Msg *msg;
+Msg *msg, *mack;
+int rc;
/* remove messages from socket until it is closed */
while (bb_status != BB_DEAD conn-alive) {
@@ -141,24 +142,38 @@
if (msg_type(msg) == sms conn-is_wap == 0) {
debug(bb.boxc, 0, boxc_receiver: sms received);
-/*
- * XXX save modifies ID, so if the smsbox uses it, save
+ /* save modifies ID, so if the smsbox uses it, save
* it FIRST for the reply message!!!
+ * generate ack-message and send it - in fact, this
+ * should include information did it succeed, wa sit queued
+ * or rejected...
*/
+ mack = msg_create(ack);
+ mack-ack.id = msg-sms.id;
+ mack-ack.time = msg-sms.time;
store_save(msg);
-if (smsc2_rout(msg)== -1) {
-warning(0, Message rejected by bearerbox, no router!);
+ rc = smsc2_rout(msg);
+ switch (rc) {
+ case -1:
+ warning(0, Message rejected by bearerbox, no router !);
/* send NACK */
bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED);
+ mack-ack.nack = ack_failed;
+ break;
+ case -2:
+ warning(0, Message rejected by bearerbox, queue full !);
+ /* send NACK */
+ bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED);
+ mack-ack.nack = ack_failed_tmp;
+ break;
+ case 0:
+ mack-ack.nack = ack_buffered;
+ break;
+ case 1:
+ mack-ack.nack = ack_success;
+ break;
}
-if (msg-sms.sms_type == mt_push) {
-/*
- * XXX generate ack-message and send it - in fact, this
- * should include information did it succeed, wa sit queued
- * or rejected...
- */
-}
-
+ list_produce(conn-incoming, mack);
} else if (msg_type(msg) == wdp_datagram conn-is_wap) {
debug(bb.boxc, 0, boxc_receiver: got wdp from wapbox);
@@ -168,7 +183,7 @@
debug(bb.boxc, 0, boxc_receiver: got sms from wapbox);
store_save(msg);
-if (smsc2_rout(msg)== -1) {
+if (smsc2_rout(msg) 0) {
warning(0, Message rejected by bearerbox, no router!);
msg_destroy(msg);
}
@@ -189,7 +204,7 @@
else if (msg_type(msg) == admin msg-admin.command == cmd_identify) {
List *newlist;
-/* and add the boxc_ud into conn for boxc_status() output */
+/* and add the boxc_id into conn for boxc_status() output */
if (conn-boxc_id == NULL)
conn-boxc_id = octstr_duplicate(msg-admin.boxc_id);
/*
Index: gw/bb_smscconn.c
===
RCS file: /home/cvs/gateway/gw/bb_smscconn.c,v
retrieving revision 1.54
diff -a -u -b -r1.54 bb_smscconn.c
--- gw/bb_smscconn.c 14 Nov 2002 02:29:25 - 1.54
+++ gw/bb_smscconn.c 15 Nov 2002 18:37:01 -
@@ -175,7 +175,7 @@
}
}
-int bb_smscconn_receive(SMSCConn *conn, Msg *sms)
+long bb_smscconn_receive(SMSCConn *conn, Msg *sms)
{
char *uf;
@@ -193,13 +193,9 @@
warning(0, incoming messages queue too long, dropping a message);
log_sms(conn, sms, DROPPED Received SMS);
gwthread_sleep(0.1); /* letting the queue go down */
- return -1
Re: WTL_patch_lxml error!
Hi, this should be -lxml2 Am Montag, 28. Oktober 2002 23:53 schrieb Ivone Uribe: Hi all again! Now, I'm trying to install the wtls_patch for the kannel gateway. But when I execute make for this patch (wtls_patch) I get an error! [root@WAP_GATEWAY wtls]# make gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o algorithm.o -c algorithm.c gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o certificate.o -c certificate.c gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o cipher_suite.o -c cipher_suite.c .. . gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o fake_wtls.o -c fake_wtls.c fake_wtls.c: In function `connect_to_wtls': fake_wtls.c:257: warning: passing arg 2 of `connect' from incompatible pointer type fake_wtls.c: In function `fake_wtls': fake_wtls.c:298: warning: passing arg 5 of `recvfrom' from incompatible pointer type gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o identifier.o -c identifier.c gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o key_exchange.o -c key_exchange.c gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o opaque_vector.o -c opaque_vector.c . ... I/usr/local/ssl/include -I. -o random.o -c random.c gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o server_hello.o -c server_hello.c gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o udp.o -c udp.c udp.c: In function `grab_datagram': udp.c:109: warning: passing arg 5 of `recvfrom' from incompatible pointer type udp.c: In function `grab_kannel_datagram': udp.c:159: warning: passing arg 5 of `recvfrom' from incompatible pointer type udp.c: In function `send_datagram': udp.c:203: warning: passing arg 5 of `sendto' from incompatible pointer type udp.c: In function `send_to_kannel_gw': udp.c:254: warning: passing arg 5 of `sendto' from incompatible pointer type gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o utils.o -c utils.c gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o wdp.o -c wdp.c wdp.c: In function `WDPDatagram_connect_kannel': wdp.c:164: warning: passing arg 2 of `connect' from incompatible pointer type wdp.c: In function `WDPDatagram_recv': wdp.c:204: warning: passing arg 5 of `recvfrom' from incompatible pointer type gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o wtls_alert.o -c wtls_alert.c gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o wtls_box.o -c wtls_box.c gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o wtls_encrypt.o -c wtls_encrypt.c .. I/usr/local/ssl/include -I. -o wtls_server.o -c wtls_server.c gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o wtls_states.o -c wtls_states.c ar rc libwtls.a algorithm.o certificate.o cipher_suite.o client_hello.o compression.o conn_state.o dh_parameters.o ec_parameters.o fake_wtls.o identifier.o key_exchange.o opaque_vector.o param_specifier.o prf.o public_key.o random.o server_hello.o udp.o utils.o wdp.o wtls_alert.o wtls_box.o wtls_encrypt.o wtls_event.o wtls_handshake.o wtls_machine.o wtls_record.o wtls_server.o wtls_states.o ranlib libwtls.a gcc -D_REENTRANT=1 -g -O2 -I/usr/include/libxml -I/usr/local/ssl/include -I. -o wtls_box wtls_box.o libwtls.a -lz -lpthread -lnsl -lm -L/usr/lib -lxml -lz -L/usr/local/ssl/lib -lcrypto /usr/bin/ld: cannot find -lxml collect2: ld returned 1 exit status make: *** [wtls_box] Error 1 I don't understand the cause for this error: /usr/bin/ld: cannot find -lxml. I have the libxml2-devel-2.4.2-1...rpm and the libxml2-2.4.2-1...rpm installed. I set this variables LD_LIBRARY_PATH=/usr/lib, LD_RUN_PATH=/usr/lib, but the error stay. Do I need another library like libxml1 or maybe I need set any variable? Please, anyone can help me? Any idea? Thanks in advance, Ivone _ MSN Fotos: la forma más fácil de compartir e imprimir fotos. http://photos.msn.es/support/worldwide.aspx -- Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstrasse 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: http://www.centrium.de
[PATCH] smpp (sequence_id start with 1)
Hi All, here is small bugfix. -- Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de ? doc/alligata/alligata.tmp Index: gw/smsc/smsc_smpp.c === RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v retrieving revision 1.14 diff -a -u -r1.14 smsc_smpp.c --- gw/smsc/smsc_smpp.c 17 Oct 2002 08:28:10 - 1.14 +++ gw/smsc/smsc_smpp.c 24 Oct 2002 10:59:00 - @@ -127,6 +127,8 @@ list_add_producer(smpp-msgs_to_send); smpp-received_msgs = list_create(); smpp-message_id_counter = counter_create(); +/* increase counter, because sequence_id start with 1 !!! */ +counter_increase(smpp-message_id_counter); smpp-host = octstr_duplicate(host); smpp-system_type = octstr_duplicate(system_type); smpp-username = octstr_duplicate(username);
Re: [PATCH] smpp (sequence_id start with 1)
and what is with bind_XXX ? you call bind first and here sequence_id is zero !!! Am Donnerstag, 24. Oktober 2002 15:00 schrieb Oded Arbel: -1 for that patch : in msg_to_pdu(), counter_increase is called before calling pdu_create(), so the counter can never be 0 when pdu_create() is entered. -- Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de
Re: [PATCH] smpp (sequence_id start with 1)
Hi, but it still not here in the last cvs version ;( Am Donnerstag, 24. Oktober 2002 15:35 schrieb Angel Fradejas: Hi all, Oded, counter_increase() is a post-increment function: it returns the value before incrementing. Anyway, this fix was already posted by myself on Sep 06, and commited in CVS. See http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc/smsc_smpp.c . diff?r1=1.9r2=1.10 Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: [EMAIL PROTECTED] [mailto:devel-admin;kannel.3glab.org]En nombre de Oded Arbel Enviado el: jueves 24 de octubre de 2002 15:00 Para: Alexander Malysh; [EMAIL PROTECTED] Asunto: RE: [PATCH] smpp (sequence_id start with 1) -1 for that patch : in msg_to_pdu(), counter_increase is called before calling pdu_create(), so the counter can never be 0 when pdu_create() is entered. -- Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de
Small typo fix (smsc_smpp)
Hi All, here is small typo bugfix. Otherwise if you get error from SMSC you can't find DLR for this sms. -- Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de Index: gw/smsc/smsc_smpp.c === RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v retrieving revision 1.13 diff -a -u -r1.13 smsc_smpp.c --- gw/smsc/smsc_smpp.c 16 Oct 2002 11:35:41 - 1.13 +++ gw/smsc/smsc_smpp.c 16 Oct 2002 17:35:55 - @@ -794,7 +794,7 @@ dlrmsg-sms.msgdata = reply; -time(msg-sms.time); +time(dlrmsg-sms.time); info(0,SMPP[%s]: DLR = %s, octstr_get_cstr(smpp-conn-id), octstr_get_cstr(dlrmsg-sms.dlr_url));
