Re: Problem sending Picture Message and Operator Logo

2003-10-16 Thread Juan Enrique Gómez
El mié, 15-10-2003 a las 17:01, Yip Yin Yee escribió:

Hi!

Be careful with the kind of mobile you're using, the udh seems to be for
nokia only.

Best,

 Hi,
 
 I have installed Kannel 1.2.1 on Knoppix Linux and I can send text and ringtones with
 the following http commands:
 
 (Text)
 http://198.198.1.150:13013/cgi-bin/sendsms?username=testerpassword=foobarto=91234567text=Kannel+i
 
 s+working+!
 
 (Ringtone) - working on nokia 6610, NOT working in nokia 8250
 http://198.198.1.150:13013/cgi-bin/sendsms?username=testerpassword=foobarto=91234567udh=%06%05%04
 %15%81%15%81text=024A3A51D195CDD004001B2055059061056055855054854082084990coding=1
 
 
 But whenever I try to send any Picture Messages and Operator Logo the http page will 
 say sent but
 the message will arrive on my mobile phone as garbage.
 
 (Picture Message)
 http://198.198.1.150:13013/cgi-bin/sendsms?username=testerpassword=foobarto=91234567udh=%06%05%04
 %15%8A%15%8Atext=3004546573740201481C0166998000
 0140006000E2400E9003128031080CF3B8018040041104440140FFFE2F8B12024000
 00538CAA02806289C401804141400140014280024000200B0504158A000301030201
 428001F000A28001800FFE00A500015FFEA57FFA400AAA005500028201500440015D08A188102480
 0040FF0201404100010003ABE0024408200D55588280101440001C018036014001806B02
 40550281990B0504158A000301030366cod
 ing=1
 
 (Operator Logo)
 MCC=525
 MNC=05
 http://198.198.1.150:13013/cgi-bin/sendsms?username=testerpassword=foobarto=91234567udh=%06%05%04
 %15%82%00%00text=25F55000480E010007EFC9003F2000
 012049002021205DF02077BEFB8000E1C9103F242289E1C99007262289E1CDD007373EF98000E1CD
 D0073738E18000E1CDD03F373EF98000
 
 
 Can someone help me and give me some advice on how I can solve this problem ?
 
 THANKS !!
 YEN
 
 __
 Here is my kannel.conf file:
 
 #
 # THIS IS A SAMPLE CONFIGURATION FOR KANNEL
 #
 # For any modifications to this file, see Kannel User Guide
 # If that does not help, send email to [EMAIL PROTECTED]
 #
 group = core
 admin-port = 13000
 admin-password = bar
 smsbox-port = 13001
 #status-password = foo
 #admin-deny-ip = 
 #admin-allow-ip = 
 #log-file = /tmp/kannel.log
 #log-level = 0
 #access-log = access.log
 #http-proxy-host = 127.0.0.1
 #http-proxy-port = 8080
 #http-proxy-exceptions = 127.0.0.1
 #http-proxy-username = user
 #http-proxy-password = password
 #ssl-certkey-file = mycertandprivkeyfile.pem
 
 # Smsbox related
 #smsbox-port = 13001
 #box-deny-ip = *.*.*.*
 #box-allow-ip = 127.0.0.1
 #unified-prefix = 00358,0
 #white-list = http://127.0.0.1/white-list.txt;
 #black-list = http://127.0.0.1/black-list.txt;
 #store-file = kannel.store
 
 # Wapbox related
 #wapbox-port = 13002
 #udp-deny-ip = *.*.*.*
 #udp-allow-ip = 127.0.0.1
 #wdp-interface-name = *
 
 # SMSC CONNECTIONS - GLOBAL FIELDS
 #group = smsc
 #smsc =
 #smsc-id = ID
 #denied-smsc-id = X;Y
 #allowed-smsc-id = Z
 #preferred-smsc-id = W
 #allowed-prefix = 040;050
 #denied-prefix = 060;070
 #alt-charset =
 
 
 # SMSC Nokia CIMD2
 #group = smsc
 #smsc = cimd2
 #host =
 #port =
 #smsc-username =
 #smsc-password =
 #keepalive =
 #sender-prefix =
 
 
 # SMSC EMI
 #group = smsc
 #smsc = emi2
 #smsc = emi_ip to use the old implementation
 #host =
 #port =
 #smsc-username =
 #smsc-password =
 #device = /dev/
 #phone =
 #our-port =
 #receive-port =
 #connect-allow-ip =
 #keepalive =
 #flow-control =
 
 # SMSC SMPP
 #group = smsc
 #smsc = smpp
 #host =
 #port =
 #receive-port =
 #smsc-username =
 #smsc-password =
 #system-type =
 #address-range =
 
 
 # SMSC SEMA
 #group = smsc
 #smsc = sema
 #device = /dev/tty0
 #smsc_nua = (X121 smsc address)
 #home_nua = (x121 radio pad address)
 #wait_report = 0/1 (0 means false, 1 means true)
 
 
 # SMSC OIS
 #group = smsc
 #smsc = ois
 #host = 103.102.101.100
 #port = 1
 #receive-port = 1
 #ois-debug-level = 0
 
 # include = /etc/kannel/modems.conf
 
 # SMSC GSM
 group = smsc
 smsc = at
 # modemtype = wavecom | premicell | siemens | siemens-tc35 | falcom | nokiaphone | 
 ericsson
 modemtype = wavecom
 device = /dev/ttyS0
 #pin = 2345
 #validityperiod = 167
 
 # MODEM CONFIG
 group = modems
 id = wavecom
 name = Wavecom
 detect-string = WAVECOM
 speed = 9600
 
 
 # SMSC Fake
 #group = smsc
 #smsc = fake
 #host =
 #port =
 #connect-allow-ip =
 
 
 # SMSC HTTP
 #group = smsc
 #smsc = http
 #system-type = kannel
 #send-url =
 #port =
 #connect-allow-ip =
 #username =
 #password =
 
 
 # SMSBOX SETUP
 
 group = smsbox
 bearerbox-host = localhost
 sendsms-port = 13013
 #sendsms-chars = 0123456789 +-
 global-sender = 
 #log-file = /tmp/smsbox.log
 #log-level = 0
 

Re: smppbox - any updates?

2003-10-16 Thread Alexander Malysh
Hi Alex,

On Wednesday 15 October 2003 22:49, Alex Kinch wrote:
 Thanks Alexander.

 Next question then.. how close is the release of 1.3.2 and 1.4.0?

IMO, we are very very close to the release. We have (at the moment) all? bugs 
closed (I can only speek about sms part of kannel) and have 3 panding patches 
that will be commited soon. 1) log module race fix; 2) bearerbox signal 
handling fix; 3) boxc patch , still in development, but near complete, means 
testing phase (see Message-Id: [EMAIL PROTECTED] for 
description).

So I hope, we can make release end of next week happens ;) What is a opinion 
of other developers ???


 I would offer to help, but I'm not very good at C coding :-)

Great!!! Just try to grab latest CVS and apply above patches (w/o boxc 
patch) , do a stress tests and report any bugs...

Thanks in advance for testing!


 Alex

 - Original Message -
 From: Alexander Malysh [EMAIL PROTECTED]
 To: Alex Kinch [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Wednesday, October 15, 2003 9:13 PM
 Subject: Re: smppbox - any updates?

-- 
Best regards / Mit besten Grüßen aus Düsseldorf

Dipl.-Ing.
Alexander Malysh
___

Centrium GmbH
Vogelsanger Weg 80
40470 Düsseldorf

Fon: +49 (0211) 74 84 51 80
Fax: +49 (0211) 277 49 109

email: [EMAIL PROTECTED]
web: www.centrium.de
msn: [EMAIL PROTECTED]
icq: 98063111
___

Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html




Re: [FYI] billing identifier/information proxying

2003-10-16 Thread Stipe Tolj
 For MO, we have now a '%B' escape code for the sms-service to pass
 this binfo field into any HTTP requests and for MT we have a 'binfo'
 CGI variable in the sendsms interface.

BTW, both have been documented in the user's guide.

Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Vogelsanger Weg 80
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are



Re: [FYI] billing identifier/information proxying

2003-10-16 Thread Stipe Tolj
Hi Paul,

Paul Keogh wrote:
 
  In EMI2 we forward the XSer 0c field and in SMPP we forward the
  service_type from the deliver_sm.
 
 
 The EMI-UCP specification suggests that this field is reserved for
 future use.
 
 What syntax are you using for this field and is it operator specific ?

AFAIS, EMI 4.0 says that fields beyond 0c, which means 0d-ff are
reserved for future use.

0c is explicetly defined to be an billing identifier field.

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



cmti cdsi Patch

2003-10-16 Thread Steve Kennedy
Hi,

I'd still like to get this included in Kannel, it alters the behaviour
of the (old) at2 module to handle inbound SMS's better.

It probably needs rejigging to make it work with the new smsc_at stuff,
but I think it's very worthwhile and has been working here successfully
for about 6 months !!!

Maybe it could be turned into a configurable option.


Steve

-- 
NetTek Ltd Phone/Fax +44-(0)20 7483 2455
SMS steve-pager (at) gbnet.net [body] gpg 1024D/468952DB 2001-09-19
Index: gw/smsc/smsc_at2.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_at2.c,v
retrieving revision 1.12
diff -u -r1.12 smsc_at2.c
--- gw/smsc/smsc_at2.c  25 Nov 2002 16:29:27 -  1.12
+++ gw/smsc/smsc_at2.c  9 Dec 2002 17:00:18 -
@@ -458,14 +458,7 @@
 
 if (privdata-sms_memory_poll_interval  privdata-modem-message_storage) {
 /* set message storage location for SIM buffering using the CPMS command */
-Octstr *temp;
-temp = octstr_create(AT+CPMS=);
-octstr_append_char(temp, 34);
-octstr_append(temp, privdata-modem-message_storage);
-octstr_append_char(temp, 34);
-ret = at2_send_modem_command(privdata, octstr_get_cstr(temp), 0, 0);
-octstr_destroy(temp);
-if (ret != 0)
+if (at2_set_message_storage(privdata, privdata-modem-message_storage) != 0)
 return -1;
 }
 
@@ -535,6 +528,16 @@
 ret = 1;
 goto end;
 }
+   if (octstr_search(line, octstr_imm(+CMTI:), 0) != -1 || 
+   octstr_search(line, octstr_imm(+CDSI:), 0) != -1) {
+   /*
+  we received an incoming message indication
+  put it in the pending_incoming_messages queue for later retrieval
+   */
+   debug(bb.smsc.at2, 0, AT2[%s]: +CMTI incoming SMS indication: %s, 
octstr_get_cstr(privdata-name), octstr_get_cstr(line));
+   list_append(privdata-pending_incoming_messages, (void 
*)octstr_create(octstr_get_cstr(line)));
+continue;
+   }
 if (octstr_search(line, octstr_imm(+CMT:), 0) != -1 ||
octstr_search(line, octstr_imm(+CDS:), 0) != -1 ||
 ((octstr_search(line, octstr_imm(+CMGR:), 0) != -1)  (cmgr_flag = 
1)) ) {
@@ -609,11 +612,132 @@
 return ret;
 }
 
-
-void at2_read_sms_memory(PrivAT2data* privdata)
+int at2_read_delete_message(PrivAT2data* privdata, int message_number)
 {
 char cmd[20];
+int message_count = 0;
+
+sprintf(cmd, AT+CMGR=%d, message_number);
+/* read one message from memory */
+at2_write_line(privdata, cmd);
+if (at2_wait_modem_command(privdata, 0, 0, message_count) != 0) {
+   debug(bb.smsc.at2, 0, AT2[%s]: failed to get message %d., 
+   octstr_get_cstr(privdata-name), message_number);
+return 0; /* failed to read the message - skip to next message */
+}
+
+/* no need to delete if no message collected */
+if (!message_count) { 
+   debug(bb.smsc.at2, 0, AT2[%s]: not deleted., 
+   octstr_get_cstr(privdata-name));
+return 0;
+}
+
+sprintf(cmd, AT+CMGD=%d, message_number); /* delete the message we just read */
+/* 
+* 3 seconds (default timeout of send_modem_command()) is not enough with some
+* modems if the message is large, so we'll give it 7 seconds 
+*/
+if (at2_send_modem_command(privdata, cmd, 7, 0) != 0) {  
+   /* 
+   * failed to delete the message, we'll just ignore it for now, 
+   * this is bad, since if the message really didn't get deleted
+   * we'll see it next time around. 
+   */
+error(2, AT2[%s]: failed to delete message %d.,
+   octstr_get_cstr(privdata-name), message_number);
+}
 
+return 1;
+}
+
+/*
+ * This function loops through the pending_incoming_messages queue for CMTI
+ * notifications.
+ * Every notification is parsed and the messages are read (and deleted)
+ * accordingly.
+*/
+void at2_read_pending_incoming_messages(PrivAT2data* privdata)
+{
+Octstr *current_storage = NULL;
+
+if (privdata-modem-message_storage) {
+   current_storage = octstr_duplicate(privdata-modem-message_storage);
+}
+while (list_len(privdata-pending_incoming_messages)  0) {
+int pos;
+long location;
+Octstr *cmti_storage = NULL, *line = NULL;
+
+line = list_extract_first(privdata-pending_incoming_messages);
+   /* message memory starts after the first quote in the string */
+if ((pos = octstr_search_char(line, '', 0)) != -1) {
+/* grab memory storage name */
+int next_quote = octstr_search_char(line, '', ++pos);
+if (next_quote == -1) { /* no second qoute - this line must be broken 
somehow */
+O_DESTROY(line);
+continue;
+   }
+
+/* store notification storage 

[PATCH] Re: cmti cdsi Patch

2003-10-16 Thread Alexander Malysh
Hi,

I'm ++1 for this patch :)

attched you can find rediffed patch agains current cvs.

On Thursday 16 October 2003 19:58, Steve Kennedy wrote:
 Hi,

 I'd still like to get this included in Kannel, it alters the behaviour
 of the (old) at2 module to handle inbound SMS's better.

 It probably needs rejigging to make it work with the new smsc_at stuff,
 but I think it's very worthwhile and has been working here successfully
 for about 6 months !!!

 Maybe it could be turned into a configurable option.


 Steve

-- 
Best regards / Mit besten Grüßen aus Düsseldorf

Dipl.-Ing.
Alexander Malysh
___

Centrium GmbH
Vogelsanger Weg 80
40470 Düsseldorf

Fon: +49 (0211) 74 84 51 80
Fax: +49 (0211) 277 49 109

email: a.malysh at centrium.de
web: www.centrium.de
msn: olek2002 at hotmail.com
icq: 98063111
___

Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Index: gw/smsc/smsc_at.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_at.c,v
retrieving revision 1.7
diff -a -u -r1.7 smsc_at.c
--- gw/smsc/smsc_at.c	15 Oct 2003 21:28:27 -	1.7
+++ gw/smsc/smsc_at.c	16 Oct 2003 20:43:40 -
@@ -458,14 +458,7 @@
 
 if (privdata-sms_memory_poll_interval  privdata-modem-message_storage) {
 /* set message storage location for SIM buffering using the CPMS command */
-Octstr *temp;
-temp = octstr_create(AT+CPMS=);
-octstr_append_char(temp, 34);
-octstr_append(temp, privdata-modem-message_storage);
-octstr_append_char(temp, 34);
-ret = at2_send_modem_command(privdata, octstr_get_cstr(temp), 0, 0);
-octstr_destroy(temp);
-if (ret != 0)
+if (at2_set_message_storage(privdata, privdata-modem-message_storage) != 0)
 return -1;
 }
 
@@ -535,6 +528,17 @@
 ret = 1;
 goto end;
 }
+if (octstr_search(line, octstr_imm(+CMTI:), 0) != -1 || 
+octstr_search(line, octstr_imm(+CDSI:), 0) != -1) {
+		/*
+		   we received an incoming message indication
+		   put it in the pending_incoming_messages queue for later retrieval
+		*/
+debug(bb.smsc.at2, 0, AT2[%s]: +CMTI incoming SMS indication: %s, octstr_get_cstr(privdata-name), octstr_get_cstr(line));
+list_append(privdata-pending_incoming_messages, line);
+line = NULL;
+continue;
+}
 if (octstr_search(line, octstr_imm(+CMT:), 0) != -1 ||
 		octstr_search(line, octstr_imm(+CDS:), 0) != -1 ||
 ((octstr_search(line, octstr_imm(+CMGR:), 0) != -1)  (cmgr_flag = 1)) ) {
@@ -612,11 +616,132 @@
 return ret;
 }
 
-
-void at2_read_sms_memory(PrivAT2data* privdata)
+int at2_read_delete_message(PrivAT2data* privdata, int message_number)
 {
 char cmd[20];
+int message_count = 0;
+
+sprintf(cmd, AT+CMGR=%d, message_number);
+/* read one message from memory */
+at2_write_line(privdata, cmd);
+if (at2_wait_modem_command(privdata, 0, 0, message_count) != 0) {
+	debug(bb.smsc.at2, 0, AT2[%s]: failed to get message %d., 
+	octstr_get_cstr(privdata-name), message_number);
+return 0; /* failed to read the message - skip to next message */
+}
+
+/* no need to delete if no message collected */
+if (!message_count) { 
+	debug(bb.smsc.at2, 0, AT2[%s]: not deleted., 
+	octstr_get_cstr(privdata-name));
+return 0;
+}
+
+sprintf(cmd, AT+CMGD=%d, message_number); /* delete the message we just read */
+/* 
+* 3 seconds (default timeout of send_modem_command()) is not enough with some
+* modems if the message is large, so we'll give it 7 seconds 
+*/
+if (at2_send_modem_command(privdata, cmd, 7, 0) != 0) {  
+/* 
+ * failed to delete the message, we'll just ignore it for now, 
+ * this is bad, since if the message really didn't get deleted
+ * we'll see it next time around. 
+ */
+error(2, AT2[%s]: failed to delete message %d.,
+  octstr_get_cstr(privdata-name), message_number);
+}
+
+return 1;
+}
+
+/*
+ * This function loops through the pending_incoming_messages queue for CMTI
+ * notifications.
+ * Every notification is parsed and the messages are read (and deleted)
+ * accordingly.
+*/
+void at2_read_pending_incoming_messages(PrivAT2data* privdata)
+{
+Octstr *current_storage = NULL;
+
+if (privdata-modem-message_storage) {
+	current_storage = octstr_duplicate(privdata-modem-message_storage);
+}
+while (list_len(privdata-pending_incoming_messages)  0) {
+int pos;
+long location;
+Octstr *cmti_storage = NULL, *line = NULL;
+
+line = list_extract_first(privdata-pending_incoming_messages);
+	/* message memory starts after 

SMPP broken in cvs-20031016?

2003-10-16 Thread Alex Kinch




Just rebuilt our test box to use cvs-20031016 
(previously was running 1.3.1-devel). I'm now experiencing problems with 
incoming SMPP. The message comes in, and shows up the bearerbox debug log - but 
nothing happens. It doesn't go anywhere!

Basically the SMPP sender does a deliver_sm, which 
Kannel acknowledges with a deliver_sm_resp. Then nothing. Plus according to the 
status, no messages have been delivered on that particular SMPP 
connection.

Here's a dump of the log:

2003-10-16 22:22:05 [16] DEBUG: SMPP[]: Got 
PDU:2003-10-16 22:22:05 [16] DEBUG: SMPP PDU 0x81c2e40 dump:2003-10-16 
22:22:05 [16] DEBUG: type_name: deliver_sm2003-10-16 22:22:05 
[16] DEBUG: command_id: 5 = 0x00052003-10-16 22:22:05 [16] 
DEBUG: command_status: 0 = 0x2003-10-16 22:22:05 [16] 
DEBUG: sequence_number: 4 = 0x00042003-10-16 22:22:05 [16] 
DEBUG: service_type: "23410"2003-10-16 22:22:05 [16] 
DEBUG: source_addr_ton: 1 = 0x00012003-10-16 22:22:05 [16] 
DEBUG: source_addr_npi: 1 = 0x00012003-10-16 22:22:05 [16] 
DEBUG: source_addr: "+44XX"2003-10-16 22:22:05 [16] 
DEBUG: dest_addr_ton: 1 = 0x00012003-10-16 22:22:05 [16] 
DEBUG: dest_addr_npi: 1 = 0x00012003-10-16 22:22:05 [16] 
DEBUG: destination_addr: "8"2003-10-16 22:22:05 [16] 
DEBUG: esm_class: 0 = 0x2003-10-16 22:22:05 [16] 
DEBUG: protocol_id: 0 = 0x2003-10-16 22:22:05 [16] 
DEBUG: priority_flag: 1 = 0x00012003-10-16 22:22:05 [16] 
DEBUG: schedule_delivery_time: NULL2003-10-16 22:22:05 [16] 
DEBUG: validity_period: NULL2003-10-16 22:22:05 [16] 
DEBUG: registered_delivery: 0 = 0x2003-10-16 22:22:05 
[16] DEBUG: replace_if_present_flag: 0 = 0x2003-10-16 
22:22:05 [16] DEBUG: data_coding: 242 = 0x00f22003-10-16 
22:22:05 [16] DEBUG: sm_default_msg_id: 0 = 0x2003-10-16 
22:22:05 [16] DEBUG: sm_length: 4 = 0x00042003-10-16 
22:22:05 [16] DEBUG: short_message: "test"2003-10-16 22:22:05 
[16] DEBUG: SMPP PDU dump ends.2003-10-16 22:22:05 [16] DEBUG: SMPP[]: 
Sending PDU:2003-10-16 22:22:05 [16] DEBUG: SMPP PDU 0x81c3498 
dump:2003-10-16 22:22:05 [16] DEBUG: type_name: 
deliver_sm_resp2003-10-16 22:22:05 [16] DEBUG: command_id: 
2147483653 = 0x80052003-10-16 22:22:05 [16] DEBUG: 
command_status: 10 = 0x000a2003-10-16 22:22:05 [16] DEBUG: 
sequence_number: 4 = 0x00042003-10-16 22:22:05 [16] DEBUG: 
message_id: NULL2003-10-16 22:22:05 [16] DEBUG: SMPP PDU dump 
ends.

Any ideas?

Alex


Re: SMPP broken in cvs-20031016?

2003-10-16 Thread Alexander Malysh
Hi Alex,

first of all: SMPP in kannel is _not_ broken. It's a smsc, you connected to, 
is broken!

On Thursday 16 October 2003 23:36, Alex Kinch wrote:
 Just rebuilt our test box to use cvs-20031016 (previously was running
 1.3.1-devel). I'm now experiencing problems with incoming SMPP. The message
 comes in, and shows up the bearerbox debug log - but nothing happens. It
 doesn't go anywhere!

 Basically the SMPP sender does a deliver_sm, which Kannel acknowledges with
 a deliver_sm_resp. Then nothing. Plus according to the status, no messages
 have been delivered on that particular SMPP connection.

have you notice a command status in deliver_sm_resp? it's 0x0a == Invalid 
source address. And see source address in deliver_sm: '+' in front which is 
not allowed.

So you should try to contact telco and tell them that smsc is broken.
And second: please try attached patch that just implements a workaround for 
this mess ;)

Good luck and please tell if attached patch works for you...


 Here's a dump of the log:

 2003-10-16 22:22:05 [16] DEBUG: SMPP[]: Got PDU:
 2003-10-16 22:22:05 [16] DEBUG: SMPP PDU 0x81c2e40 dump:
 2003-10-16 22:22:05 [16] DEBUG:   type_name: deliver_sm
 2003-10-16 22:22:05 [16] DEBUG:   command_id: 5 = 0x0005
 2003-10-16 22:22:05 [16] DEBUG:   command_status: 0 = 0x
 2003-10-16 22:22:05 [16] DEBUG:   sequence_number: 4 = 0x0004
 2003-10-16 22:22:05 [16] DEBUG:   service_type: 23410
 2003-10-16 22:22:05 [16] DEBUG:   source_addr_ton: 1 = 0x0001
 2003-10-16 22:22:05 [16] DEBUG:   source_addr_npi: 1 = 0x0001
 2003-10-16 22:22:05 [16] DEBUG:   source_addr: +44XX
 2003-10-16 22:22:05 [16] DEBUG:   dest_addr_ton: 1 = 0x0001
 2003-10-16 22:22:05 [16] DEBUG:   dest_addr_npi: 1 = 0x0001
 2003-10-16 22:22:05 [16] DEBUG:   destination_addr: 8
 2003-10-16 22:22:05 [16] DEBUG:   esm_class: 0 = 0x
 2003-10-16 22:22:05 [16] DEBUG:   protocol_id: 0 = 0x
 2003-10-16 22:22:05 [16] DEBUG:   priority_flag: 1 = 0x0001
 2003-10-16 22:22:05 [16] DEBUG:   schedule_delivery_time: NULL
 2003-10-16 22:22:05 [16] DEBUG:   validity_period: NULL
 2003-10-16 22:22:05 [16] DEBUG:   registered_delivery: 0 = 0x
 2003-10-16 22:22:05 [16] DEBUG:   replace_if_present_flag: 0 = 0x
 2003-10-16 22:22:05 [16] DEBUG:   data_coding: 242 = 0x00f2
 2003-10-16 22:22:05 [16] DEBUG:   sm_default_msg_id: 0 = 0x
 2003-10-16 22:22:05 [16] DEBUG:   sm_length: 4 = 0x0004
 2003-10-16 22:22:05 [16] DEBUG:   short_message: test
 2003-10-16 22:22:05 [16] DEBUG: SMPP PDU dump ends.
 2003-10-16 22:22:05 [16] DEBUG: SMPP[]: Sending PDU:
 2003-10-16 22:22:05 [16] DEBUG: SMPP PDU 0x81c3498 dump:
 2003-10-16 22:22:05 [16] DEBUG:   type_name: deliver_sm_resp
 2003-10-16 22:22:05 [16] DEBUG:   command_id: 2147483653 = 0x8005
 2003-10-16 22:22:05 [16] DEBUG:   command_status: 10 = 0x000a
 2003-10-16 22:22:05 [16] DEBUG:   sequence_number: 4 = 0x0004
 2003-10-16 22:22:05 [16] DEBUG:   message_id: NULL
 2003-10-16 22:22:05 [16] DEBUG: SMPP PDU dump ends.


 Any ideas?

 Alex

-- 
Best regards / Mit besten Grüßen aus Düsseldorf

Dipl.-Ing.
Alexander Malysh
___

Centrium GmbH
Vogelsanger Weg 80
40470 Düsseldorf

Fon: +49 (0211) 74 84 51 80
Fax: +49 (0211) 277 49 109

email: a.malysh at centrium.de
web: www.centrium.de
msn: olek2002 at hotmail.com
icq: 98063111
___

Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Index: gw/smsc/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.52
diff -a -u -r1.52 smsc_smpp.c
--- gw/smsc/smsc_smpp.c	16 Oct 2003 16:00:44 -	1.52
+++ gw/smsc/smsc_smpp.c	16 Oct 2003 22:24:05 -
@@ -298,7 +298,9 @@
 /* check if intl. and digit only; assume number is larger then 7 chars */
 if (ton == GSM_ADDR_TON_INTERNATIONAL 
 octstr_len(pdu-u.deliver_sm.source_addr) = 7 
-octstr_check_range(pdu-u.deliver_sm.source_addr, 0, 256, gw_isdigit)) {
+((octstr_get_char(pdu-u.deliver_sm.source_addr, 0) == '+' 
+ octstr_check_range(pdu-u.deliver_sm.source_addr, 1, 256, gw_isdigit)) ||
+octstr_check_range(pdu-u.deliver_sm.source_addr, 0, 256, gw_isdigit))) {
 
 /* check if we received leading '00', then remove it*/
 if (octstr_search(pdu-u.deliver_sm.source_addr, octstr_imm(00), 0) == 0)


pgp0.pgp
Description: signature


Re: SMPP broken in cvs-20031016?

2003-10-16 Thread Stipe Tolj
Hi Alex,

Alex Kinch wrote:
 
 
 Just rebuilt our test box to use cvs-20031016 (previously was
 running 1.3.1-devel). I'm now experiencing problems with incoming
 SMPP. The message comes in, and shows up the bearerbox debug log -
 but nothing happens. It doesn't go anywhere!
 
 Basically the SMPP sender does a deliver_sm, which Kannel
 acknowledges with a deliver_sm_resp. Then nothing. Plus according to
 the status, no messages have been delivered on that particular SMPP
 connection.

the deliver_sm PDU looks ok. So there is no change in the admin status
HTTP interface?

The message is not passed to smsbox? and it is not logged in
access-log?

Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Vogelsanger Weg 80
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are



Re: SMPP broken in cvs-20031016?

2003-10-16 Thread Stipe Tolj
Alexander Malysh wrote:
 
 have you notice a command status in deliver_sm_resp? it's 0x0a == Invalid
 source address. And see source address in deliver_sm: '+' in front which is
 not allowed.
 
 So you should try to contact telco and tell them that smsc is broken.
 And second: please try attached patch that just implements a workaround for
 this mess ;)

yep, Alex is right here. Haven't checked the PDU that pedantically as
he did ;)

The source_addr_ton specifies 0x01 which means no prefixing at all.
And the + prefix is hance *not* protocoll conform.

Alex, to put this vendor on a black list, which one is it?

Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Vogelsanger Weg 80
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are