Re: Kannel _ WTLS
Nick Clarey did wtls, maybe he can help you ? Aarno On Monday, February 24, 2003, at 10:21 AM, Obakeng wrote: I would like to develop a WTLS setup using kannel. Do you know if anyone has tried it?
Re: multiple bearer box - Netikos?
Nisan Bloch wrote: At 11:37 AM 2/25/03 +0100, Stipe Tolj wrote: Kalle Marjola wrote: That's why I published them, altought I knew that some things are a bit too radical. As we have no resources to do any development on it right now, I hope that you can scavenge useful things out from it and this way improve the Kannel project. yep, +1 :) that's what we all do. ditto +1 i dont have much spare time, but I could over the next week or so make a list of those pieces that we can move over basically transparently (eg http libs) and those that would be relatively easy (eg adding the sms-service rules from NMGW) and those that cannot be done without some major changes to Kannel. ok, go for it. Listen anyway to the list, because we may start already with sync'ing some parts from Netikos version to the official tree. 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: SMSC Modules (Was: Kannel Swisscom)
Hi list, this thread leads us to a discussion I had yesterday with Alexander from Centrium (and also Harrie Hazewinkel, who is hopefully still subscribed to the list :) We need to design a clean module API interface (which is already there in some extended sense) and allows to plug them in via dynamical loading of shared objects. In that way you would only load the SMSC module types you need and we may offer template, bare-bone source for new ones to follow. Has anyone checked the approach Harrie did for it? It's available on the web site at http://www.kannel.org/module_api/ Please do have a look and let's get started with this. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: Storing data into mysql server
Hi Srinivasa, Srinivasa Rao Munagala wrote: Hi, I am trying to configure the kannel gateway. I was able to configure the kannel gateway with dlr-db as mysql. There are no panics when the gateway is started using ./bearerbox confile. Problem when i am sending fake smsc i am getting reply from the kannel gateway. But the data related to fake sms is not stored in Mysql database. Please can one help me to configure the kannel to store the sms data into mysql server database. I guess you didn't get the point. The dlr-db group defines where to store (in your case the mysql db) the temporary DLR (delivery report) data, *not* the sms data itself! So when you fire out an SMS to an *real* SMSC and you want them to reply with a receive report you have to store that temporary data somewhere, either in memory or in the mysql db. So you mistaked by two ways: 1. Assuming that the fakesmsc would deliver DLRs, which it does not, AFAIK. 2. Assuming that the dlr-db group stores the messages into the db. If you want to store messages into your mysql db, then this should be out of scope of Kannel. Hence for MO messages smsbox is sending them to an HTTP server. Let the HTTP server do the storing of the SMS to your mysql db. Another suggested approach would be: (list, please thread this as proposal ;) Implement an 'msg-db' group that defines the fields of an SMS entry and a 'store-db' action in the 'sms-servce' group to tell smsbox to which db id to store an MO'ed message. So you'd get something like this: group = msg-id id = msg_store table = messages field-source = source_address field-destination = destination_address ... group = sms-service keyword = default store-db = msg_store max-messages = 0 This would allow you to store all incoming messages to the mysql table without replying to them directy. You could even extend the beast by implementing a read thread that queues in an outgoing messsages table and sends those to bearerbox for MT transport. 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: Kannel _ WTLS
I would like to develop a WTLS setup using kannel. Do you know if anyone has tried it? you both guys should first of all dig into the mailing list archive. Nick has send some mails about where he stopped with development of the WTLS layer in Kannel. I guess he's getting pi**ed when we ask him to explain it once more ;) Beware that you should have extended experience with SSL and TLS related stuff. The word 'openssl' should make your eyes glue, in order to get your hands on this. As a base you can use the kwtls patch that is still available at http://www.kannel.org/download/wtls/kwtls-1.0.3.tar.gz and try to implement the still missing things into Kannel's own WTLS stack. 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: Kannel snapshot and Vodaphone Spain
Try regular text: coding=2 flash : coding=2mclass=1 and don't forget to use alt-dcs = yes on your smsc-group. If you leave coding unset, you'll have 7bit, and you won't get a dcs that is accepted by Vodaphone Spain. Good luck. Angel Fradejas Mediafusion Espana, 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:[EMAIL PROTECTED] nombre de Arne K. Haaje Enviado el: miercoles 26 de febrero de 2003 14:42 Para: [EMAIL PROTECTED] Asunto: Kannel snapshot and Vodaphone Spain Hello, Does anybody know how to get Kannel to talk to Vodaphone Spain? I need to send regular text messages and flash messages, but whatever I try setting for coding and mclass the messages never reach the recipient. In kannel 1.1.5 I could set pdu-u.submit_sm.data_coding = 0xf5; in smsc_smpp.c to send regular text but I can not send flash messages with that verion. Is there some way of using the latest snapshot with Vodaphone Spain? -- Med vennlig hilsen, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.com/
RE: SMSC Modules (Was: Kannel Swisscom)
Nicholas Rahn wrote: iServer is a proprietary Swisscom SMSC. It abstracts multiple EMI/UCP connections with a proprietary HTTP/socket interface in order to provide billing, throughput, etc. There is currently no way to use kannel to connect to it. You could, however, write a new kannel smsc module to do it. :-) Nick Is there anyone willing to share his Swisscom iServer smsc module? If not, I'll have to write one soon. 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
Re: Kannel snapshot and Vodaphone Spain
onsdag 26. februar 2003, 15:19, skrev Angel Fradejas: Try regular text: coding=2 flash : coding=2mclass=1 and don't forget to use alt-dcs = yes on your smsc-group. If you leave coding unset, you'll have 7bit, and you won't get a dcs that is accepted by Vodaphone Spain. Thanks, but I still can not receive the messages. Do I need to set anything else in the smsc-group - ton, npi etc. ? I am using the same config as the patched 1.1.5, but I receive no messages - nether text or binary. -- Med vennlig hilsen, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.com/
SMPP 3.4 C-Octet String Termination
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 Alex Skywire http://www.skywire.co.uk/
RE: Kannel snapshot and Vodaphone Spain
I have these values in my smsc-group: #GSM_ADDR_TON_UNKNOWN source-addr-ton = 0 #GSM_ADDR_NPI_E164 source-addr-npi = 1 # for 0xFX dcs values alt-dcs = yes and successfully work with Vodaphone Spain. 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: Arne K. Haaje [mailto:[EMAIL PROTECTED] Enviado el: miércoles 26 de febrero de 2003 15:43 Para: Angel Fradejas; [EMAIL PROTECTED] Asunto: Re: Kannel snapshot and Vodaphone Spain onsdag 26. februar 2003, 15:19, skrev Angel Fradejas: Try regular text: coding=2 flash : coding=2mclass=1 and don't forget to use alt-dcs = yes on your smsc-group. If you leave coding unset, you'll have 7bit, and you won't get a dcs that is accepted by Vodaphone Spain. Thanks, but I still can not receive the messages. Do I need to set anything else in the smsc-group - ton, npi etc. ? I am using the same config as the patched 1.1.5, but I receive no messages - nether text or binary. -- Med vennlig hilsen, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.com/
Re: SMPP 3.4 C-Octet String Termination
On Mittwoch, Februar 26, 2003, at 03:52 Uhr, 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? I think kannel should respect the length. So a single octstr_trim(packet,len) should do the trick I guess. Andreas Fink Global Networks Switzerland AG -- Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association
Re: SMPP 3.4 C-Octet String Termination
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
Re: SMPP 3.4 C-Octet String Termination
I think kannel should respect the length. So a single octstr_trim(packet,len) should do the trick I guess. if you guys consider it a bug in Kannel, then pass the information you have to the bug tracking system. 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: Kannel snapshot and Vodaphone Spain
Forgot to say, I always supply the destination number in +346 format. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Angel Fradejas Enviado el: miércoles 26 de febrero de 2003 15:57 Para: Arne K. Haaje; [EMAIL PROTECTED] Asunto: RE: Kannel snapshot and Vodaphone Spain I have these values in my smsc-group: #GSM_ADDR_TON_UNKNOWN source-addr-ton = 0 #GSM_ADDR_NPI_E164 source-addr-npi = 1 # for 0xFX dcs values alt-dcs = yes and successfully work with Vodaphone Spain. 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: Arne K. Haaje [mailto:[EMAIL PROTECTED] Enviado el: miércoles 26 de febrero de 2003 15:43 Para: Angel Fradejas; [EMAIL PROTECTED] Asunto: Re: Kannel snapshot and Vodaphone Spain onsdag 26. februar 2003, 15:19, skrev Angel Fradejas: Try regular text: coding=2 flash : coding=2mclass=1 and don't forget to use alt-dcs = yes on your smsc-group. If you leave coding unset, you'll have 7bit, and you won't get a dcs that is accepted by Vodaphone Spain. Thanks, but I still can not receive the messages. Do I need to set anything else in the smsc-group - ton, npi etc. ? I am using the same config as the patched 1.1.5, but I receive no messages - nether text or binary. -- Med vennlig hilsen, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.com/
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
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
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
Alexander Malysh wrote: it can't be C-Octet-String at all ;) Just think that '@' in GSM 03.38 is 0x00 ;) so it's a pat situation?! 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: Kannel snapshot and Vodaphone Spain
onsdag 26. februar 2003, 16:06, skrev Angel Fradejas: Forgot to say, I always supply the destination number in +346 format. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Angel Fradejas Enviado el: miércoles 26 de febrero de 2003 15:57 Para: Arne K. Haaje; [EMAIL PROTECTED] Asunto: RE: Kannel snapshot and Vodaphone Spain I have these values in my smsc-group: #GSM_ADDR_TON_UNKNOWN source-addr-ton = 0 #GSM_ADDR_NPI_E164 source-addr-npi = 1 # for 0xFX dcs values alt-dcs = yes and successfully work with Vodaphone Spain. 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: Arne K. Haaje [mailto:[EMAIL PROTECTED] Enviado el: miércoles 26 de febrero de 2003 15:43 Para: Angel Fradejas; [EMAIL PROTECTED] Asunto: Re: Kannel snapshot and Vodaphone Spain onsdag 26. februar 2003, 15:19, skrev Angel Fradejas: Try regular text: coding=2 flash : coding=2mclass=1 and don't forget to use alt-dcs = yes on your smsc-group. If you leave coding unset, you'll have 7bit, and you won't get a dcs that is accepted by Vodaphone Spain. Thanks, but I still can not receive the messages. Do I need to set anything else in the smsc-group - ton, npi etc. ? I am using the same config as the patched 1.1.5, but I receive no messages - nether text or binary. This is my setup; # SMSC CONNECTIONS group = smsc smsc = smpp smsc-id = ES_AIRTEL host = 212.73.32.54 port = 2567 preferred-smsc-id = ES_AIRTEL receive-port = 2567 smsc-username = smsc-password = system-type = MESS address-range = preferred-prefix = 34 alt-dcs = yes source-addr-ton = 0 #GSM_ADDR_NPI_E164 source-addr-npi = 1 # SMSBOX SETUP I send with coding=2 and the +346 format, but I receive no messages. Is there something I need to change in the smsc group? -- Med vennlig hilsen, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.com/
Re: SMPP 3.4 C-Octet String Termination
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 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
Re: SMPP 3.4 C-Octet String Termination
Ahh.. I think Alexander is right DELIVER_SM specifies that short_message is a Var 0 - 254 size octets Then specified earleir in the spec. is that Var 0 - 254 is an Octet String, not a C-Octet String Octet Strings are not Null terminated. Looks like Mobay's gateway is buggy. I'll try and get them to fix it. Alex
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
Re: Kannel snapshot and Vodaphone Spain
onsdag 26. februar 2003, 16:32, skrev Angel Fradejas: Maybe you can provide with PDU dumps to see what's happening. Here it is, 2003-02-26 16:52:22 [9] DEBUG: boxc_receiver: sms received 2003-02-26 16:52:22 [3] DEBUG: HTTP: Resetting HTTPClient for `213.203.56.194'. 2003-02-26 16:52:22 [6] DEBUG: SMPP[ES_AIRTEL]: Manually forced source addr ton = 0, source add npi = 1 2003-02-26 16:52:22 [6] DEBUG: SMPP[ES_AIRTEL]: Sending PDU: 2003-02-26 16:52:22 [6] DEBUG: SMPP PDU 0x403009d0 dump: 2003-02-26 16:52:22 [6] DEBUG: type_name: submit_sm 2003-02-26 16:52:22 [6] DEBUG: command_id: 4 = 0x0004 2003-02-26 16:52:22 [6] DEBUG: command_status: 0 = 0x 2003-02-26 16:52:22 [6] DEBUG: sequence_number: 23 = 0x0017 2003-02-26 16:52:22 [6] DEBUG: service_type: NULL 2003-02-26 16:52:22 [6] DEBUG: source_addr_ton: 0 = 0x 2003-02-26 16:52:22 [6] DEBUG: source_addr_npi: 1 = 0x0001 2003-02-26 16:52:22 [6] DEBUG: source_addr: 7602 2003-02-26 16:52:22 [6] DEBUG: dest_addr_ton: 2 = 0x0002 2003-02-26 16:52:22 [6] DEBUG: dest_addr_npi: 1 = 0x0001 2003-02-26 16:52:22 [6] DEBUG: destination_addr: 34610846596 2003-02-26 16:52:22 [6] DEBUG: esm_class: 3 = 0x0003 2003-02-26 16:52:22 [6] DEBUG: protocol_id: 0 = 0x 2003-02-26 16:52:22 [6] DEBUG: priority_flag: 0 = 0x 2003-02-26 16:52:22 [6] DEBUG: schedule_delivery_time: NULL 2003-02-26 16:52:22 [6] DEBUG: validity_period: NULL 2003-02-26 16:52:22 [6] DEBUG: registered_delivery: 0 = 0x 2003-02-26 16:52:22 [6] DEBUG: replace_if_present_flag: 0 = 0x 2003-02-26 16:52:22 [6] DEBUG: data_coding: 245 = 0x00f5 2003-02-26 16:52:22 [6] DEBUG: sm_default_msg_id: 0 = 0x 2003-02-26 16:52:22 [6] DEBUG: sm_length: 4 = 0x0004 2003-02-26 16:52:22 [6] DEBUG: short_message: huff 2003-02-26 16:52:22 [6] DEBUG: SMPP PDU dump ends. 2003-02-26 16:52:22 [1] DEBUG: HTTP: Destroying HTTPClient area 0x80a1490. 2003-02-26 16:52:22 [1] DEBUG: HTTP: Destroying HTTPClient for `213.203.56.194'. 2003-02-26 16:52:22 [6] DEBUG: SMPP[ES_AIRTEL]: Got PDU: 2003-02-26 16:52:22 [6] DEBUG: SMPP PDU 0x40300ae8 dump: 2003-02-26 16:52:22 [6] DEBUG: type_name: submit_sm_resp 2003-02-26 16:52:22 [6] DEBUG: command_id: 2147483652 = 0x8004 2003-02-26 16:52:22 [6] DEBUG: command_status: 0 = 0x 2003-02-26 16:52:22 [6] DEBUG: sequence_number: 23 = 0x0017 2003-02-26 16:52:22 [6] DEBUG: message_id: 00024992 2003-02-26 16:52:22 [6] DEBUG: SMPP PDU dump ends. 2003-02-26 16:52:22 [1] DEBUG: Dumping 0 messages and 0 acks to store -- Med vennlig hilsen, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.com/
[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 */
[BUG FILED] 'make tests' broken recently
I filed a bug [Kannel 003]: 'make tests' doesn't work anymore See http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/Makefile.in.diff?r1=1.63r2=1.64 Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08
Re: SMPP 3.4 C-Octet String Termination
Alex, Have experienced SMSC that did this. In our case it was configurable on SMSC - eventually it was turned off. It may be worth seeing if you can do the same (given the SMSC's adding it). Cheers, Alan On Thu, 2003-02-27 at 03:52, 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 Alex Skywire http://www.skywire.co.uk/ -- Alan McNatty [EMAIL PROTECTED]
[PATCH] generic support for our-host smsc directive
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.c CMG UCP/EMI 4.0 smsc_smasi.c SM/ASI (for CriticalPath InVoke SMS Center 4.x) smsc_cgw.c Sonera ContentGateway software smsc_http.c HTTP-based relay and content gateways smsc_fake.c Fake SMSC smsc_smpp.c SMPP 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 FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 patch_generic_our_host.diff Description: Binary data
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
Re: Does Kannel log support logrotation (configure.in patch)
Sorry - missed an check to see if --enable/disable-docs had been set. As is configure.in On Sun, 2003-02-16 at 15:47, Stipe Tolj wrote: Alan McNatty wrote: Ok thanks - I see now how it works .. I've attached patch below in unified format. I've changed the order so that you first check for --enable-docs, etc then check to see if jade, jadetex, etc are all installed before confirming that indeed the docs should be made. It's a bit more all or nothing, that is you either have all the 'right things' installed to build all the docs or you don't so can't proceed. I'm not sure if everyone will like this - just something to test and consider. +1, commited to cvs. 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 -- Alan McNatty [EMAIL PROTECTED] Index: configure.in === RCS file: /home/cvs/gateway/configure.in,v retrieving revision 1.110 diff -u -r1.110 configure.in --- configure.in 16 Feb 2003 14:38:22 - 1.110 +++ configure.in 26 Feb 2003 22:51:02 - @@ -274,9 +274,10 @@ || test $JADE = no \ || test $JADETEX= no \ || test $PDFJADETEX = no \ -|| test $DVIPS = no \ -|| test $FIG2DEV= no \ -|| test $CONVERT= no +|| test $DVIPS = no \ +|| test $FIG2DEV= no \ +|| test $CONVERT= no \ +|| test $DOCSTARGET = no-docs then DOCSTARGET=no-docs else
bug in smsc_smpp.c login failure
Hello,
found that if I type in the smpp password incorrectly kannel loops
forever trying to reconnect. ie:
[6] DEBUG: SMPP PDU 0x80f3a18 dump:
[6] DEBUG: type_name: bind_receiver_resp
[6] DEBUG: command_id: 2147483649 = 0x8001
[6] DEBUG: command_status: 14 = 0x000e
[6] DEBUG: sequence_number: 732 = 0x02dc
[6] DEBUG: system_id: NULL
[6] DEBUG: SMPP PDU dump ends.
[6] ERROR: SMPP[xxx]: SMSC rejected login to receive, code 0x000e.
[6] ERROR: SMPP[xxx]: I/O error or other error. Re-connecting.
And so on ..
The smsc_smpp.c handle_pdu notices the error (and indeed reports on it)
but it's not noticed at the io_thread level so keeps trying.
I worked around it by setting smpp-quitting = 1 after the error message
in handle_pdu (see patch) which has the effect of shutting down the
failing threads (so they don't keep trying). Crude - provided as example
only - will look at improving this.
Also, in the instance you only have 1 smpp connection which when fails
in this way, the bearerbox sits without actually shutting down (ie:
doesn't realise there are no active threads and clean up, etc). Should
the bearerbox shutdown in this instance?
Cheers,
Alan
--
Alan McNatty [EMAIL PROTECTED]
Index: gw/smsc/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.25
diff -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 02:29:38 -
@@ -958,6 +958,11 @@
code 0x%08lx.,
octstr_get_cstr(smpp-conn-id),
pdu-u.bind_transmitter_resp.command_status);
+
+ /* Need to die here, well just don't keep trying this connection
+ * if the password doesn't work it never will */
+ smpp-quitting = 1;
+
} else {
*pending_submits = 0;
smpp-conn-status = SMSCCONN_ACTIVE;
What's the SAR status ??
hi all ! We've seen some of SAR patches moving around. I think newer kannel version(1.2.1) supports it. Has anybody tested this functionality with newer gateways ? Or are they still developing SAR ? Does anyone have a new patch ? urs, denzel.
Re: bug in smsc_smpp.c login failure
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/ Nisan [6] DEBUG: SMPP PDU 0x80f3a18 dump: [6] DEBUG: type_name: bind_receiver_resp [6] DEBUG: command_id: 2147483649 = 0x8001 [6] DEBUG: command_status: 14 = 0x000e [6] DEBUG: sequence_number: 732 = 0x02dc [6] DEBUG: system_id: NULL [6] DEBUG: SMPP PDU dump ends. [6] ERROR: SMPP[xxx]: SMSC rejected login to receive, code 0x000e. [6] ERROR: SMPP[xxx]: I/O error or other error. Re-connecting. And so on .. The smsc_smpp.c handle_pdu notices the error (and indeed reports on it) but it's not noticed at the io_thread level so keeps trying. I worked around it by setting smpp-quitting = 1 after the error message in handle_pdu (see patch) which has the effect of shutting down the failing threads (so they don't keep trying). Crude - provided as example only - will look at improving this. Also, in the instance you only have 1 smpp connection which when fails in this way, the bearerbox sits without actually shutting down (ie: doesn't realise there are no active threads and clean up, etc). Should the bearerbox shutdown in this instance? Cheers, Alan -- Alan McNatty [EMAIL PROTECTED]
Re: bug in smsc_smpp.c login failure
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. ie: 'I/O error or other error. Re-connecting' is not the right approach for some errors. I haven't supplied a fix yet (no +/- required yet), the diff I supplied was to highlight the location of the bug.
