Re: Queued DLRs
On 3/8/07, XSG Telecom M.I. de Jong <[EMAIL PROTECTED]> wrote: Kannel keeps putting DLRs into it's store and refuses to send them out... It DOES sent DLRs, some do get sent, some don't OR DLRs get sent with u huge delay. Looking at processor info the machine itself isn't stressed at all and Kannel doesn't seem to be stressed either. So why are the DLRs getting queued? Why isn't it just sending them out? And is there a way to FORCE Kannel to process it's DLR queue? Try flushing the DLR queue. As always, details in User's Guide. http://www.kannel.org/download/1.4.1/userguide-1.4.1/userguide.html#AEN834 Totally off-topic though, after reading many books on Agile Software Development processes, including those from Ken Schwaber and Alistair Cockburn, I think I understand why conventional development processes tend to regard documentation as a required donkeywork. Now, agile processes value working software over complete documentation but in the case of Kannel we have both working software and excellent documentation yet people actually don't read it. Now it feels like there's something wrong here. Is this because documentation is so big and full of so much information, or is it so badly organized that people are having hard times reading it, or the product is so good people think they can figure out themselves without the need of reading the documentation, or people are being just lazy? Anyone? Hmm. -- Enver
Re: fakesmsc configuration
On 3/31/07, Tulga. G <[EMAIL PROTECTED]> wrote: Hi guys, Merhaba, 1. Why message start "123 345 text nop"? what mean 123 345? [source] [destination] [message-type] [content]. See http://www.kannel.org/download/1.4.1/userguide-1.4.1/userguide.html#AEN5023 for details. 2. What about CDRs? I'm trying connect SMSC - Kannel - SMSC through SMPP 3.4. I need generate CDRs. Kannel is a WAP and SMS gateway, it is built to connect your application to some SMSC so it's up to your application to generate CDRs and Kannel doesn't do this AFAIK. 3. I added test users to sendsms-user group. I must restart smsbox and bearerbox? Unfortunately, you have to restart smsbox but I don't think you need to restart bearerbox. -- Enver
dlr errors
hi, i'm seeing this error quite a bit: 2007-04-02 11:58:12 [26174] [4] INFO: Starting delivery report from <+NUMBER> 2007-04-02 11:58:12 [26174] [9] ERROR: Error reading from fd 28: 2007-04-02 11:58:12 [26174] [9] ERROR: System error 54: Connection reset by peer what can that mean? also if i do: lynx -dump "http://localhost:PORT/store-status.txt?password=PASS"; i get an empty queue, but if i do: lynx -dump "http://localhost:PORT/status.txt?password=PASS"; it says that there are 194 queued DLR's, shouldn't they be showing up in the store-status report? i'm using internal dlr storage. cheers iain
Re: Queued DLRs [Really Kannel Doc difficulties]
**>Message-ID: <[EMAIL PROTECTED]> **>Date: Mon, 2 Apr 2007 02:34:54 +0300 **>From: "Enver ALTIN" <[EMAIL PROTECTED]> **>To: "XSG Telecom M.I. de Jong" <[EMAIL PROTECTED]> **>Subject: Re: Queued DLRs **>In-Reply-To: <[EMAIL PROTECTED]> **>MIME-Version: 1.0 **>References: **> <[EMAIL PROTECTED]> **>Cc: users@kannel.org **> **> **>Try flushing the DLR queue. As always, details in User's Guide. **> **>http://www.kannel.org/download/1.4.1/userguide-1.4.1/userguide.html#AEN834 **> **>Totally off-topic though, after reading many books on Agile Software **>Development processes, including those from Ken Schwaber and Alistair **>Cockburn, I think I understand why conventional development processes **>tend to regard documentation as a required donkeywork. Now, agile **>processes value working software over complete documentation but in **>the case of Kannel we have both working software and excellent **>documentation yet people actually don't read it. Now it feels like **>there's something wrong here. Is this because documentation is so big **>and full of so much information, or is it so badly organized that **>people are having hard times reading it, or the product is so good **>people think they can figure out themselves without the need of **>reading the documentation, or people are being just lazy? Anyone? Hmm. I think the problem is: - complexity of Kannel's capabilities - lack of background in the WAP/SMS/MMS implementation of new Kannel users - overwhelming amount of technical information inside the Kannel documentation - not enough detailed/annotated examples - incomplete glossary/bibliography - lack of index I tried to re-write the manual when I was writing a UUID module for Kannel v1.3.1 (which my employer will not allow me to open-source), but ran out of time resources. The major problem is that the document is in DSSL (Docbook) format and there are limited editors (circa 2003) that natively support it in a WYSIWYG mode. Additionally, it did not use a version of DSSSL that can be XML validated. As a result, it's a pain to re-write. I ended up using VI, converting the whole document to dockbookx (to support XML validation of the document), added section numbering to keep myself from getting lost, hand edititing the resulting document, and passing it through openJade to render an HTML version for ever change. VERY time consuming. I've been trying to find time to continue this but real-life intrudes in my open-source ventures. For anyone interested, here's what my old version looked like: http://202.181.245.115/kannel-doc/1.3.1/userguide.html See ya... d.c.
SMS reciving problem
I use kannel: Kannel bearerbox version `1.4.1'. Build `Oct 16 2006 10:48:53', compiler `4.1.1 20060525 (Red Hat 4.1.1-1)'. System Linux, release 2.6.19-1.2288.2.4.fc5, version #1 SMP Sun Mar 4 15:57:52 EST 2007, machine x86_64. Hostname h8.dbweb.ee, IP 217.159.233.174. Libxml version 2.6.23. Using SQLite 2.8.17. Using native malloc. My kannel is connected to operator SMSC-es with two VPN IPSec tunnels. First tunnel: My kannel eth1: *.*.*.55 - VPN LAN: *.*.*.53 My VPN GW: 13.180.29.56 <- Tunnel -> Operator IPV GW: *.*.*.15 - Operator SMSC: *.*.*.119. I use it to send SMSes out. Second tunnel: My kannel eth1: *.*.*.55 - VPN LAN: *.*.*.53 My VPN GW: 13.180.29.56 <- Tunnel -> Operator IPV GW: *.*.*.15 - Operator SMSC: *.*.*.21 It's SMSC that sends mobile SMSes to my kannel. Operator uses CMG UCP/EMI type SMSC. Here is my kannel konf: group = core admin-port = 13000 admin-password = ** status-password = ** admin-deny-ip = "*.*.*.*" admin-allow-ip = "*.*.*.*" smsbox-port = 1301 box-allow-ip = "*.*.*.*" wdp-interface-name = "*" log-file = "/var/log/kannel/bearerbox.log" access-log = "/var/log/kannel/access.log" store-file = "/var/log/kannel/store.log" log-level = 0 group = smsbox bearerbox-host = localhost sendsms-port = 13013 global-sender = 12014 log-file = /var/log/kannel/smsbox.log log-level = 0 group = sms-service keyword = test get-url = "http://localhost/smsservice.php?sender=%p&text=%r"; group = smsc smsc-id = EMT_MT smsc = emi port = 1 host = *.*.*.119 smsc-username = smsc-password = group = sendsms-user username = password = My http status: SMS: received 0 (0 queued), sent 1 (0 queued), store size 0 SMS: inbound 0.00 msg/sec, outbound 0.00 msg/sec DLR: 0 queued, using internal storage Box connections: smsbox:(none), IP 127.0.0.1 (0 queued), (on-line 0d 5h 57m 13s) SMSC connections: EMT_MTEMI2:*.*.*.119:1:12014 (online 85s, rcvd 0, sent 1, failed 0, queued 0 msgs) And what is my problem? I can send sms out. But if I send SMS to my short number it's not coming to my kannel and I don't know what's wrong. If I change smsbox-port back to 13001 and run fakesmsc then all works fine. 1301 is because operator demands it. Ok if I send sms to my shortnumber http status shows: SMS: received 0 (0 queued), sent 1 (0 queued), store size 0 SMS: inbound 0.00 msg/sec, outbound 0.00 msg/sec DLR: 0 queued, using internal storage Box connections: smsbox:(none), IP 127.0.0.1 (0 queued), (on-line 0d 6h 9m 13s) smsbox:(none), IP *.*.*.21(Operator SMSC IP) (0 queued), (on-line 0d 0h 0m 22s) SMSC connections: EMT_MTEMI2:217.71.32.119:1:12014 (online 85s, rcvd 0, sent 1, failed 0, queued 0 msgs) in bearerbox.log: 2007-03-30 23:17:31 [18836] [5] INFO: Client connected from <*.*.*.21> 2007-03-30 23:17:31 [18836] [5] DEBUG: Started thread 24 (gw/bb_boxc.c:function) 2007-03-30 23:17:31 [18836] [24] DEBUG: Thread 24 (gw/bb_boxc.c:function) maps to pid 18836. 2007-123.618723 *.*.*.55 -> *.*.*.21 TCP ci3-software-1 > 12785 [SYN, ACK] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 WS=5 123.624779 *.*.*.55 -> *.*.*.21 TCP ci3-software-1 > 12785 [ACK] Seq=1 Ack=107 Win=183 Len=0-30 23:17:31 [18836] [24] DEBUG: Started thread 25 (gw/bb_boxc.c:boxc_sender) 2007-03-30 23:17:31 [18836] [25] DEBUG: Thread 25 (gw/bb_boxc.c:boxc_sender) maps to pid 18836. Same time thethereal shows: 123.618723 *.*.*.55 -> *.*.*.21 TCP ci3-software-1 > 12785 [SYN, ACK] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 WS=5 123.624779 213.180.29.55 -> 217.71.32.21 TCP ci3-software-1 > 12785 [ACK] Seq=1 Ack=107 Win=183 Len=0 And after about one minute in bearbox: 2007-03-30 23:19:02 [18836] [24] INFO: Connection closed by the box <*.*.*.21> 2007-03-30 23:19:02 [18836] [25] DEBUG: send_msg: sending msg to box: <*.*.*.21> 2007-03-30 23:19:02 [18836] [25] DEBUG: Thread 25 (gw/bb_boxc.c:boxc_sender) terminates. 2007-03-30 23:19:02 [18836] [24] DEBUG: Thread 24 (gw/bb_boxc.c:function) terminates. tcpflow is show nothing. And the same time tethereal shows: 215.071237 *.*.*.55 -> *.*.*.21 TCP ci3-software-1 > 12785 [PSH, ACK] Seq=1 Ack=108 Win=183 [TCP CHECKSUM INCORRECT] Len=16[Unreassembled Packet [incorrect TCP checksum]] 215.071360 *.*.*.55 -> *.*.*.21 TCP ci3-software-1 > 12785 [FIN, ACK] Seq=17 Ack=108 Win=183 Len=0 tcpflow shows: *.*.*.055.01301-*.*.*.021.16760: And it is always the same if sms tries to go into my kannel. I don't know where to search the error. Operator tells that all is ok in their side. Best regards, Margusja --- Margusja +37251780 skype: margusja msn: [EMAIL PROTECTED] homepage: http://margusja.pri.ee --- Margusja +37251780 skype: margusja msn: [EMAIL PROTECTED] homepage: http://margusja.pri.ee
