Does SMSBox Really Sent Out Messages?
Hi, I found some weird situation. I cross checked bearerbox-access log and smsbox-access log. In the bearerbox-access I found 874 messages. But when check smsbox-access it's only 871 sent to back end application using http get protocol. Where does the 3 messages gone?I see no errors in the smsbox-access log (all http requests got http 200). So does SMSBox really sent out all messages to back end application? Thanks. sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/
Re: Does SMSBox Really Sent Out Messages?
Hi, Did you check your store queue before starting? There were propably some leftover messages in there... BR, Nikos - Original Message - From: sangprabv sangpr...@gmail.com To: Kannel list users@kannel.org Sent: Monday, August 09, 2010 10:29 AM Subject: Does SMSBox Really Sent Out Messages? Hi, I found some weird situation. I cross checked bearerbox-access log and smsbox-access log. In the bearerbox-access I found 874 messages. But when check smsbox-access it's only 871 sent to back end application using http get protocol. Where does the 3 messages gone?I see no errors in the smsbox-access log (all http requests got http 200). So does SMSBox really sent out all messages to back end application? Thanks. sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/
Re: Large and growing number of queued DLR
You're complicating things... even while bearerbox _process_ the DLR's as they arrive, they're awaited for on someplace else than the store, either a memory queue or a DB table, that's my point. Your example of a disconnected box doesn't apply to a real-case scenario at all and it's just a distraction from the original topic. I was explaining that you can't use a validity period approach to expire unfinished dlrs because they're on the DB (or the non-persisted internal storage, but we were focusing on the DB-persisted case) and you don't really have a list of all of them at hand. I don't see the point of bringing all the bearerbox complexities into the problem, I think I know pretty well how the whole thing work, I just didn't want to complicate things for no reason. Now, back to the problem, another approach would be to keep an in-memory list of all pending DLR's in memory and use the DB backend only for persistance (just like the message store does). You'd need to load it at boot and keep it synchronized at all times (add new DLR's as they arrive and delete them as they are finished). With that approach, a validity period system could be easily developed on top of it. Regards, Alex 2010/8/8 Nikos Balkanas nbalka...@gmail.com Sorry Alex, are you talking about DLRs or dlr_entries? What are lost between restarts are dlr_entries, not DLRs. DLRs are still received, but cannot find a matching dlr_entry and are discarded. Otherwise, if they are matched, they are send to smsbox. If smsbox is not available, or doesn't send an ACK, then they are kept in store, like any other MO, waiting for smsbox. How else can you find DLRs in store? Try sending a few SMS with dlr-mask, db storage for dlr_entries, and disconnect smsbox. Examine the store from HTTP admin after a while, when access.log logs in an incoming DLR. You will find that DLR in store. When you connect smsbox (or sqlbox, or smppbox) again, this DLR will be processed and deleted for storage. BR, Nikos - Original Message - From: Alejandro Guerrieri To: Nikos Balkanas Cc: Konstantin Vayner ; Users Sent: Sunday, August 08, 2010 10:50 PM Subject: Re: Large and growing number of queued DLR Why would we need the DB storage if that's the case? The DLR _matching_ is performed against the DB, not the store. If you use in-memory storage, DLR's are lost when restarting the service. That wouldn't happen if the store would hold them isn't it? Regards, Alex 2010/8/8 Nikos Balkanas nbalka...@gmail.com Alex, Are you sure about that? AFAIK DLRs are saved to store, like any other MO, until bb receives an ACK from upstream (smsbox, sqlbox, smppbox). BR, Nikos - Original Message - From: Alejandro Guerrieri To: Konstantin Vayner Cc: Users Sent: Sunday, August 08, 2010 12:56 PM Subject: Re: Large and growing number of queued DLR Well, that poses some problems. DLR's are a different animal than regular messages, they're not hold on the message store. DLR's are by default held in memory or, if you wish to persist them across restarts, you use DB storage. When you use a DB storage DLR's are no longer held in memory. Now, in order to reuse validity period, you'd need to have all DLR's in memory at all times and that's only true for in-memory DLR's. For DB-stored DLR's, since they're no longer in memory, all the operations are done over SQL queries so you don't longer have the ability of traversing them in memory. The approach with DB-based DLR's is to run a query like this: DELETE FROM dlr WHERE stamp (NOW()-INTERVAL 5 DAY) Now, if you use MySQL's MyISAM storage, that query locks the whole table, so you need to be very careful when running it (we do it at low traffic hours and we run it repeatedly with a LIMIT clause to make it return faster and allow for the rest of the queries to unlock. In other words, I wouldn't put that kind of query on a thread to execute repeatedly unattended. A possible approach would be to load all DLR's in memory when the service starts, the same way it's done with the regular messages and the file store. Once that's done, we'd be able to traverse the old DLR's without locking the system. Now, from a higher level perspective, this poses the question of the reason why DLR's are treated different than the rest of the messages that pass thru Kannel, but that's for another thread I guess ;) Regards, Alex On Sun, Aug 8, 2010 at 7:56 AM, Konstantin Vayner pon...@appcell.net wrote: Alejandro, Actually, kannel can reuse validity period and automatically issue (perhapse configurable?) expiration dlr + wipe a message when a message is past that period by some good value (lets say + 1 day - this should be more than enough). In fact we could issue another kind of dlr even - maybe unknown or smth... this would both solve a problem with bb building up queue of dlrs that will never be matched and aid external application logic imho
Re: Does SMSBox Really Sent Out Messages?
Have you checked the application's access log as well? I bet they won't be there... Nothing else on the logs? Maybe the requests failed and are being retried (or Kannel gave up retrying and discarded them). Regards, Alex On Mon, Aug 9, 2010 at 9:29 AM, sangprabv sangpr...@gmail.com wrote: Hi, I found some weird situation. I cross checked bearerbox-access log and smsbox-access log. In the bearerbox-access I found 874 messages. But when check smsbox-access it's only 871 sent to back end application using http get protocol. Where does the 3 messages gone?I see no errors in the smsbox-access log (all http requests got http 200). So does SMSBox really sent out all messages to back end application? Thanks. sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/
Re: Kannel performance benchmarking
Hi Nikos, Do you experience memory problem? In my case Kannel is eating the memory on high load traffics. I always need to restart the box to get more memory. I even give 3 on /proc/sys/vm/drop_caches but still Kannel eat the memory :( sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/ On Aug 9, 2010, at 9:42 PM, brett skinner wrote: Hi Nikos Out of curiosity can you go into more detail regarding what hardware you were running and your setup for MySql? Were you using Innodb or MyIsam. If you were using Innodb did you make any other configuration changes to MySql to accommodate Innodb. From the user guide it is implied that the bottle neck for Kannel is the number of messages that the SMSC can accommodate per second. Is this still the case? Regards, 2010/8/8 Nikos Balkanas nbalka...@gmail.com Hi, I have run some benchmarking for a client using fakesmpp. Using the default service for MO's I got: MO's: 1400 SMS/s MT + DLRs (internal): 747 SMS/s MT + DLRs (MySql): 434 SMS/s BR, Nikos - Original Message - From: ha...@aeon.pk To: kannel users Sent: Sunday, August 08, 2010 4:22 PM Subject: Kannel performance benchmarking Hi, I am interested to know about the kannel performance benchmarking, especially in terms of speed (msgs/sec), MO or MT. I assume that multiple smsboxes does not have any effect over kannel performance, since the front-end talking to SMSC is the main bearerbox. What is the max speed that could be attained by kannel and/or bearerbox? Regards, Hamza
RE: Life without smsbox
Hi Nikos, Thanks again for the feedback. You hit the nail on the head - I am seeing WARNING: smsbox_list empty! throughout the bearerbox log. Looks like running sqlbox alone is not enough to truly emulate a smsbox. So, I delved into the source for sqlbox, and from what I can see, it has no ACK response logic at all. It receives the DLR (or MO) from bearerbox, writes it to the DB and then passes it to a connected smsbox. It appears to rely on smsbox to generate the ACK - there's logic in there to pass smsbox messages back to bearerbox (which I assume would include the ACKs), but nothing to handle the situation where there is no smsbox connected. In this case, the message gets written to the DB then simply dropped, hence the queuing in bearerbox that I'm seeing. So, I'm looking at two options and would very much appreciate advice on which one would be most appropriate: 1. Configure a dummy smsbox to receive/ACK the messages from sqlbox but do nothing else them. Not sure if I can configure smsbox to do this (I'll hit the doc), whether I'll need to patch it to provide a ACK and drop mode, or whether I should have it call a dummy destination to avoid the patching. 2. Enhance sqlbox to generate its own ACK if it doesn't have a connected smsbox to pass the MO/DLR onto. Any suggestions? If not, I'll probably start on #2 as it seems much cleaner to me and avoids the unnecessary overhead of a dummy smsbox process and associated IPC. Who is the appropriate sqlbox owner that I should run these changes by? I'm sure I'm not the only one that has no need for smsbox. Thanks, Toby. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Monday, 9 August 2010 2:17 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Hi, The only way for bearerbox to remove the DLR from store is to receive an upstream ACK (smsbox or sqlbox). That is the architectural spec. If this is not happenning, sqlbox has a bug. You could check for that in maximum detail bb (and sqlbox) logs. If there is a problem with routing or boxc ids in bb, you should get a lot of warnings like Warning: smsbox-list empty!, which will also build up DLR store queue. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Sunday, August 08, 2010 3:26 PM Subject: RE: Life without smsbox Just a follow-up - I also tried setting smsbox-id = sqlbox in the sqlbox section, and sqlbox starts but I get the same results, which is that the bearerbox store size increments by one for each DLR received, as viewed in the status output. For example: SMS: received 0 (0 queued), sent 13 (0 queued), store size 85 Right now, my sqlbox.conf looks like this: group = sqlbox id = sqlbox smsbox-id = sqlbox bearerbox-port = 13100 bearerbox-host = localhost # smsbox-port = 13200 sql-log-table = smsgw_kannel_sms_result sql-insert-table = smsgw_kannel_sms_queue log-file = /usr/local/kannel/log/sqlbox.log log-level = 0 group = mysql-connection id = sqlbox host = localhost username = removed password = removed database = removed max-connections = 3 As you can see, the smsbox-port is commented out, meaning that I don't want sqlbox to try to talk to smsbox. I've tried with this line commented out, or uncommented (but pointed to a non-listening port). Both result in the same behaviour, Any more ideas anyone? I'm about to start delving into the source... Thanks, Toby.
Re: Need help in BearerBox and Smsbox Syncrinozation help
Hi You have a 3rd option: Do nothing on either boxes but do it on your own application that feed sms to opensmppbox. I do something like that by parsing the bearerbox status page and getting each smsc queue. If you do mess with either box, you will be brancing off kannel/opensmppbox and will not be able -or it will be more difficult- to continue getting improvements to those boxes. Hope helps Alvaro |-| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com On Sat, Aug 7, 2010 at 12:44 AM, adil nazir adil_nazi...@yahoo.com wrote: Dear Friends, I need your help i want to modify BearerBox and SMSBox to make SMSBox synchronize with BearerBox. I want this because i want to control my BearerBox queue, so that when BearerBox start filling its queue, then SMSBox must stop sending messages and give time to the BearerBox to handle its queued messages first. please guide me how can i do this i am new on Kannel. I have another solution to do this i should modify BearerBox queue in such a way that it strictly follow the behavior of priority queue and messages stored in the queue should have greater priority then the incoming messages. but i also do not know how to do this? These are the 2 solutions to achieve one goal which is to give more priority to the messages then the incoming messages. Please guide me how can i do this where i need modifications in code? and which method is good for that and also you can give me some easy and new suggestions to do this?
Re: Life without smsbox
Hi, You are missing an smsbox-route group. Once you configure that, your DLR problem will disappear. You need to set an smsbox-id in your smsbox group (I remeber you already have a dummy one), that corresponds to the id in your sqlbox. Then configure that to your smsbox-route group. Right now your bb is getting the DLRs, but doesn't know where to send them. Granted it is pretty lame to have only 1 smsbox connected to it, and not know what to do with it. It could be fixed sometime. Do not proceed with (2). BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 6:17 PM Subject: RE: Life without smsbox Hi Nikos, Thanks again for the feedback. You hit the nail on the head - I am seeing WARNING: smsbox_list empty! throughout the bearerbox log. Looks like running sqlbox alone is not enough to truly emulate a smsbox. So, I delved into the source for sqlbox, and from what I can see, it has no ACK response logic at all. It receives the DLR (or MO) from bearerbox, writes it to the DB and then passes it to a connected smsbox. It appears to rely on smsbox to generate the ACK - there's logic in there to pass smsbox messages back to bearerbox (which I assume would include the ACKs), but nothing to handle the situation where there is no smsbox connected. In this case, the message gets written to the DB then simply dropped, hence the queuing in bearerbox that I'm seeing. So, I'm looking at two options and would very much appreciate advice on which one would be most appropriate: 1. Configure a dummy smsbox to receive/ACK the messages from sqlbox but do nothing else them. Not sure if I can configure smsbox to do this (I'll hit the doc), whether I'll need to patch it to provide a ACK and drop mode, or whether I should have it call a dummy destination to avoid the patching. 2. Enhance sqlbox to generate its own ACK if it doesn't have a connected smsbox to pass the MO/DLR onto. Any suggestions? If not, I'll probably start on #2 as it seems much cleaner to me and avoids the unnecessary overhead of a dummy smsbox process and associated IPC. Who is the appropriate sqlbox owner that I should run these changes by? I'm sure I'm not the only one that has no need for smsbox. Thanks, Toby. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Monday, 9 August 2010 2:17 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Hi, The only way for bearerbox to remove the DLR from store is to receive an upstream ACK (smsbox or sqlbox). That is the architectural spec. If this is not happenning, sqlbox has a bug. You could check for that in maximum detail bb (and sqlbox) logs. If there is a problem with routing or boxc ids in bb, you should get a lot of warnings like Warning: smsbox-list empty!, which will also build up DLR store queue. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Sunday, August 08, 2010 3:26 PM Subject: RE: Life without smsbox Just a follow-up - I also tried setting smsbox-id = sqlbox in the sqlbox section, and sqlbox starts but I get the same results, which is that the bearerbox store size increments by one for each DLR received, as viewed in the status output. For example: SMS: received 0 (0 queued), sent 13 (0 queued), store size 85 Right now, my sqlbox.conf looks like this: group = sqlbox id = sqlbox smsbox-id = sqlbox bearerbox-port = 13100 bearerbox-host = localhost # smsbox-port = 13200 sql-log-table = smsgw_kannel_sms_result sql-insert-table = smsgw_kannel_sms_queue log-file = /usr/local/kannel/log/sqlbox.log log-level = 0 group = mysql-connection id = sqlbox host = localhost username = removed password = removed database = removed max-connections = 3 As you can see, the smsbox-port is commented out, meaning that I don't want sqlbox to try to talk to smsbox. I've tried with this line commented out, or uncommented (but pointed to a non-listening port). Both result in the same behaviour, Any more ideas anyone? I'm about to start delving into the source... Thanks, Toby.
Re: Kannel performance benchmarking
Hi, Server was 64bit Ubuntu system, kernel 2.6.31-22. Dual core Xeon @3.4GHz. 4 GB RAM. MyIsam Mysql, with index on ts,smsc. You may have to adjust this if using latest svn with EMI or CIMD2 connections. Interestingly, SQLbox, performed the same as smsbox in MT with DB for DLRs. BR, Nikos - Original Message - From: brett skinner To: Nikos Balkanas Cc: ha...@aeon.pk ; kannel users Sent: Monday, August 09, 2010 5:42 PM Subject: Re: Kannel performance benchmarking Hi Nikos Out of curiosity can you go into more detail regarding what hardware you were running and your setup for MySql? Were you using Innodb or MyIsam. If you were using Innodb did you make any other configuration changes to MySql to accommodate Innodb. From the user guide it is implied that the bottle neck for Kannel is the number of messages that the SMSC can accommodate per second. Is this still the case? Regards, 2010/8/8 Nikos Balkanas nbalka...@gmail.com Hi, I have run some benchmarking for a client using fakesmpp. Using the default service for MO's I got: MO's: 1400 SMS/s MT + DLRs (internal): 747 SMS/s MT + DLRs (MySql): 434 SMS/s BR, Nikos - Original Message - From: ha...@aeon.pk To: kannel users Sent: Sunday, August 08, 2010 4:22 PM Subject: Kannel performance benchmarking Hi, I am interested to know about the kannel performance benchmarking, especially in terms of speed (msgs/sec), MO or MT. I assume that multiple smsboxes does not have any effect over kannel performance, since the front-end talking to SMSC is the main bearerbox. What is the max speed that could be attained by kannel and/or bearerbox? Regards, Hamza
Re: Kannel performance benchmarking
No memory problems. It is reasonable that kannel will use more memory in higher traffic, since all queues are in memory, as long as it drops to nominal levels once the traffic is gone. BR, Nikos - Original Message - From: sangprabv To: brett skinner Cc: Nikos Balkanas ; kannel users Sent: Monday, August 09, 2010 5:59 PM Subject: Re: Kannel performance benchmarking Hi Nikos, Do you experience memory problem? In my case Kannel is eating the memory on high load traffics. I always need to restart the box to get more memory. I even give 3 on /proc/sys/vm/drop_caches but still Kannel eat the memory :( sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/ On Aug 9, 2010, at 9:42 PM, brett skinner wrote: Hi Nikos Out of curiosity can you go into more detail regarding what hardware you were running and your setup for MySql? Were you using Innodb or MyIsam. If you were using Innodb did you make any other configuration changes to MySql to accommodate Innodb. From the user guide it is implied that the bottle neck for Kannel is the number of messages that the SMSC can accommodate per second. Is this still the case? Regards, 2010/8/8 Nikos Balkanas nbalka...@gmail.com Hi, I have run some benchmarking for a client using fakesmpp. Using the default service for MO's I got: MO's: 1400 SMS/s MT + DLRs (internal): 747 SMS/s MT + DLRs (MySql): 434 SMS/s BR, Nikos - Original Message - From: ha...@aeon.pk To: kannel users Sent: Sunday, August 08, 2010 4:22 PM Subject: Kannel performance benchmarking Hi, I am interested to know about the kannel performance benchmarking, especially in terms of speed (msgs/sec), MO or MT. I assume that multiple smsboxes does not have any effect over kannel performance, since the front-end talking to SMSC is the main bearerbox. What is the max speed that could be attained by kannel and/or bearerbox? Regards, Hamza
RE: Life without smsbox
Hi Nikos, I'll certainly try what you suggest, but I'm not quite sure that's the issue. Although bearerbox may think it doesn't have any smsboxes connected, it's still happily routing messages to sqlbox - here's a brief extract from the bearerbox log: 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) terminates. 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: sqlbox sqlbox is also getting each message as intended, and I can see it arriving in its log, and I can also see bearerbox queuing them in the status output. smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) The piece that's missing really seems to be the ACK from sqlbox to bearerbox for each DLR message it receives. bearerbox is successfully sending each DLR to sqlbox, and sqlbox is successfully logging it to the DB. However, as sqlbox is sending no ACK back, bearerbox has no way of knowing that sqlbox received the DLR and is therefore queuing it locally, and periodically re-sending to sqlbox. Now I've read the sqlbox code, it seems that it's a thin shell and doesn't implement ANY of the ACK processing that smsbox does. It simply logs to the DB, passes messages to smsbox and hopes that smsbox will pass it back an ACK that it can then pass to bearerbox so that the loop can be closed. However, without an smsbox connection, sqlbox is simply processing and dumping each message from bearerbox, leading to the unnecessary queuing in bearerbox. Anyway, that's what I've worked out from a few hours of looking through the code. This is nothing compared to the years that everyone else has with it, and I'm happy to be proved wrong! Just as an aside, between the time I sent my earlier email and I saw your response, I implemented a very rudimentary #2 (ACK in sqlbox) and it seems to have resolved the issue. All I'm doing is checking on each message receipt inside sqlbox to see if a smsbox is connected. If so then nothing changes - if not, then sqlbox returns the successful ACK. Thanks, Toby -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Tuesday, 10 August 2010 12:08 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Hi, You are missing an smsbox-route group. Once you configure that, your DLR problem will disappear. You need to set an smsbox-id in your smsbox group (I remeber you already have a dummy one), that corresponds to the id in your sqlbox. Then configure that to your smsbox-route group. Right now your bb is getting the DLRs, but doesn't know where to send them. Granted it is pretty lame to have only 1 smsbox connected to it, and not know what to do with it. It could be fixed sometime. Do not proceed with (2). BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 6:17 PM Subject: RE: Life without smsbox Hi Nikos, Thanks again for the feedback. You hit the nail on the head - I am seeing WARNING: smsbox_list empty! throughout the bearerbox log. Looks like running sqlbox alone is not enough to truly emulate a smsbox. So, I delved into the source for sqlbox, and from what I can see, it has no ACK response logic at all. It receives the DLR (or MO) from bearerbox, writes it to the DB and then passes it to a connected smsbox. It appears to rely on smsbox to generate the ACK - there's logic in there to pass smsbox messages back to bearerbox (which I assume would include the ACKs), but nothing to handle the situation where there is no smsbox connected. In this case, the message gets written to the DB then simply dropped, hence the queuing in bearerbox that I'm seeing. So, I'm looking at two options and would very much appreciate advice on which one would be most appropriate: 1. Configure a dummy smsbox to receive/ACK the messages from sqlbox but do nothing else them. Not sure if I can configure smsbox to do this (I'll hit the doc), whether I'll need to patch it to provide a ACK and drop mode, or whether I should have it call a dummy destination to avoid the patching. 2. Enhance sqlbox to generate its own ACK if it doesn't have a connected smsbox to pass the MO/DLR onto. Any suggestions? If not, I'll probably start on #2 as it seems much cleaner to me and avoids the unnecessary overhead of a dummy smsbox process and associated IPC. Who is the appropriate sqlbox owner that I should run these changes by? I'm sure I'm not the only one that has no need for smsbox. Thanks, Toby. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Monday, 9 August 2010 2:17 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Hi, The only way for bearerbox to remove the DLR from store is to
Re: Modem Nokia N73 problem
Hi, That's fine, but I asked you to post relevant bb logs from modem initailaization, which I don't see. Have you read User's guide about it? BR, Nikos - Original Message - From: Dlamini Langa Phillip la...@sptc.co.sz To: Nikos Balkanas nbalka...@gmail.com Cc: users@kannel.org Sent: Monday, August 09, 2010 12:58 PM Subject: RE: Modem Nokia N73 problem Hi I think did everything mentioned wvdial.conf, the modem gets initialised but doesnot give me IP to connect to internet. System: RED HAT LINUX Desktop with modem Nokia N73 through USB cable. Here is my wdial.conf:, created with wvdialconf create FIRST STEP: I run this command on the terminal # sudo /sbin/modprobe usbserial vendor=0x0421 product=0x0486 SECOND STEP: I run the command :wvdialconf create , on the terminal , it showed the output as following, [r...@localhost ~]# wvdialconf create Scanning your serial ports for a modem. Port Scan*1: S0 S1 S2 S3 WvModem*1: Cannot get information for serial port. TtyUSB0*1: ATQ0 V1 E1 -- OK ttyUSB0*1: ATQ0 V1 E1 Z -- OK ttyUSB0*1: ATQ0 V1 E1 S0=0 -- OK ttyUSB0*1: ATQ0 V1 E1 S0=0 C1 -- OK ttyUSB0*1: ATQ0 V1 E1 S0=0 C1 D2 -- OK ttyUSB0*1: ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 -- OK ttyUSB0*1: Modem Identifier: ATI -- Nokia ttyUSB0*1: Speed 4800: AT -- OK ttyUSB0*1: Speed 9600: AT -- OK ttyUSB0*1: Speed 19200: AT -- OK ttyUSB0*1: Speed 38400: AT -- OK ttyUSB0*1: Speed 57600: AT -- OK ttyUSB0*1: Speed 115200: AT -- OK ttyUSB0*1: Speed 230400: AT -- OK ttyUSB0*1: Speed 460800: AT -- OK ttyUSB0*1: Max speed is 460800; that should be safe. ttyUSB0*1: ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 -- OK Found an USB modem on /dev/ttyUSB0. Modem configuration written to create. ttyUSB0Info: Speed 460800; init ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 THIRD STEP: I THEN PASTE THE BELOW SCRIPT IN THE FILE etc/wvdial.conf [Dialer Defaults] Modem = /dev/ ttyUSB0 Baud = 460800 Init1 = ATZ Init2 = ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 ISDN = 0 Modem Type = Analog Modem Phone = *99***1# Username = gp Password = gp Stupid Mode = 1 FOURTH STEP I then open terminal with root permissions and run the command : wvdial. the output was as follows : [r...@localhost ~]# wvdial -- WvDial: Internet dialer version 1.53.0 -- Warning: section [Dialer Default] does not exist in wvdial.conf.. -- Initializing modem. -- Sending: ATZ ATZ OK -- Sending: ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 OK -- Modem initialized. -- Sending: ATDT*99# -- Waiting for carrier. ATDT*99# CONNECT ~[7f...@!}!} } }2}...@#}!}$}%\}}} }*} } g}%~ -- Carrier detected. Starting PPP immediately. -- Starting pppd at Mon Aug 9 11:36:29 2010 -- pid of pppd: 4855 The problems it stop here and I DON'T KNOW WHY? OR THE PHONE IS NOT COMPACTIBLE TO BE USED AS A M -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Sunday, August 08, 2010 8:22 PM To: Dlamini Langa Phillip; users@kannel.org Subject: Re: Modem Nokia N73 problem Hi, Please never truncate threads. All past information is lost. What is your problem? Post detailed relevant bb logs of your modem initialization. BR, Nikos - Original Message - From: Dlamini Langa Phillip To: users@kannel.org Sent: Sunday, August 08, 2010 12:24 PM Subject: Modem Nokia N73 problem Hi I to use my Nokia N73 as modem for the kannel sms gateway. I want to send an sms through the modem and anyone with the idea of what is happening. Please help and this are the when using wvdial steps. Dialer Defaults] Init1 = ATZ Init2 = ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 Modem Type = Analog Modem ISDN = 0 Phone = *99# Modem = /dev/ttyUSBO Username = gp Password = gp Baud = 460800 Stupid Mode=1 wvdial result -- WvDial: Internet dialer version 1.53 -- Warning : section [Dialer Default] does not exist in wvdial.conf -- Initializing modem. -- Sending: ATZ ATZ OK -- Sending: ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 ATQ0 V1 E1 S0=0 C1 D2 +FCLASS=0 OK -- Modem initialized. -- Sending: ATDT*99# -- Waiting for carrier. ATDT*99# CONNECT ~[7f...@!}!} } }2}...@#}!}$}%\}}} }*} } g}%~ -- Carrier detected. Starting PPP immediately. -- Starting pppd at Sun Aug 8 09:56: 14 2010 -- pid of pppd: 4864 DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the administra...@sptc.co.sz, then delete the email and destroy any copies of it. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Swaziland Posts Telecommunication Corporation (SPTC) or any of its subsidiaries or associated companies. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. Swaziland Posts Telecommunication Corporation (SPTC) accepts no liability for any damage caused by any virus transmitted by this email. E-mail
Problem with spool store - missing sms_type
Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
Re: Life without smsbox
Nope. What you see is entirely different. send_msg is not sending the DLR to sqlbox, but rather responding an ACK to the received MT. I don't know if there is a problem with sqlbox, but I bet I would have heard about it if it were, but revert to the svn version and try smsbox-route. The warning you get is very crucial, you are missing incoming DLRs. You need to fix that, before anything else. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 7:24 PM Subject: RE: Life without smsbox Hi Nikos, I'll certainly try what you suggest, but I'm not quite sure that's the issue. Although bearerbox may think it doesn't have any smsboxes connected, it's still happily routing messages to sqlbox - here's a brief extract from the bearerbox log: 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) terminates. 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: sqlbox sqlbox is also getting each message as intended, and I can see it arriving in its log, and I can also see bearerbox queuing them in the status output. smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) The piece that's missing really seems to be the ACK from sqlbox to bearerbox for each DLR message it receives. bearerbox is successfully sending each DLR to sqlbox, and sqlbox is successfully logging it to the DB. However, as sqlbox is sending no ACK back, bearerbox has no way of knowing that sqlbox received the DLR and is therefore queuing it locally, and periodically re-sending to sqlbox. Now I've read the sqlbox code, it seems that it's a thin shell and doesn't implement ANY of the ACK processing that smsbox does. It simply logs to the DB, passes messages to smsbox and hopes that smsbox will pass it back an ACK that it can then pass to bearerbox so that the loop can be closed. However, without an smsbox connection, sqlbox is simply processing and dumping each message from bearerbox, leading to the unnecessary queuing in bearerbox. Anyway, that's what I've worked out from a few hours of looking through the code. This is nothing compared to the years that everyone else has with it, and I'm happy to be proved wrong! Just as an aside, between the time I sent my earlier email and I saw your response, I implemented a very rudimentary #2 (ACK in sqlbox) and it seems to have resolved the issue. All I'm doing is checking on each message receipt inside sqlbox to see if a smsbox is connected. If so then nothing changes - if not, then sqlbox returns the successful ACK. Thanks, Toby -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Tuesday, 10 August 2010 12:08 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Hi, You are missing an smsbox-route group. Once you configure that, your DLR problem will disappear. You need to set an smsbox-id in your smsbox group (I remeber you already have a dummy one), that corresponds to the id in your sqlbox. Then configure that to your smsbox-route group. Right now your bb is getting the DLRs, but doesn't know where to send them. Granted it is pretty lame to have only 1 smsbox connected to it, and not know what to do with it. It could be fixed sometime. Do not proceed with (2). BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 6:17 PM Subject: RE: Life without smsbox Hi Nikos, Thanks again for the feedback. You hit the nail on the head - I am seeing WARNING: smsbox_list empty! throughout the bearerbox log. Looks like running sqlbox alone is not enough to truly emulate a smsbox. So, I delved into the source for sqlbox, and from what I can see, it has no ACK response logic at all. It receives the DLR (or MO) from bearerbox, writes it to the DB and then passes it to a connected smsbox. It appears to rely on smsbox to generate the ACK - there's logic in there to pass smsbox messages back to bearerbox (which I assume would include the ACKs), but nothing to handle the situation where there is no smsbox connected. In this case, the message gets written to the DB then simply dropped, hence the queuing in bearerbox that I'm seeing. So, I'm looking at two options and would very much appreciate advice on which one would be most appropriate: 1. Configure a dummy smsbox to receive/ACK the messages from sqlbox but do nothing else them. Not sure if I can configure smsbox to do this (I'll hit the doc), whether I'll need to patch it to provide a ACK and drop mode, or whether I should have it call a dummy destination to avoid the patching. 2. Enhance sqlbox to generate its own ACK if it
Re: Problem with spool store - missing sms_type
Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
RE: Life without smsbox
I think you are both right. The smsbox_list empty problem is a bearerbox routing problem. However, AFAIR, sqlbox doesn't send back an ACK to saved messages if it receives them. It sure would be nice if it did. == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Monday, 09 August, 2010 18:31 To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Nope. What you see is entirely different. send_msg is not sending the DLR to sqlbox, but rather responding an ACK to the received MT. I don't know if there is a problem with sqlbox, but I bet I would have heard about it if it were, but revert to the svn version and try smsbox-route. The warning you get is very crucial, you are missing incoming DLRs. You need to fix that, before anything else. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 7:24 PM Subject: RE: Life without smsbox Hi Nikos, I'll certainly try what you suggest, but I'm not quite sure that's the issue. Although bearerbox may think it doesn't have any smsboxes connected, it's still happily routing messages to sqlbox - here's a brief extract from the bearerbox log: 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) terminates. 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: sqlbox sqlbox is also getting each message as intended, and I can see it arriving in its log, and I can also see bearerbox queuing them in the status output. smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) The piece that's missing really seems to be the ACK from sqlbox to bearerbox for each DLR message it receives. bearerbox is successfully sending each DLR to sqlbox, and sqlbox is successfully logging it to the DB. However, as sqlbox is sending no ACK back, bearerbox has no way of knowing that sqlbox received the DLR and is therefore queuing it locally, and periodically re-sending to sqlbox. Now I've read the sqlbox code, it seems that it's a thin shell and doesn't implement ANY of the ACK processing that smsbox does. It simply logs to the DB, passes messages to smsbox and hopes that smsbox will pass it back an ACK that it can then pass to bearerbox so that the loop can be closed. However, without an smsbox connection, sqlbox is simply processing and dumping each message from bearerbox, leading to the unnecessary queuing in bearerbox. Anyway, that's what I've worked out from a few hours of looking through the code. This is nothing compared to the years that everyone else has with it, and I'm happy to be proved wrong! Just as an aside, between the time I sent my earlier email and I saw your response, I implemented a very rudimentary #2 (ACK in sqlbox) and it seems to have resolved the issue. All I'm doing is checking on each message receipt inside sqlbox to see if a smsbox is connected. If so then nothing changes - if not, then sqlbox returns the successful ACK. Thanks, Toby -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Tuesday, 10 August 2010 12:08 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Hi, You are missing an smsbox-route group. Once you configure that, your DLR problem will disappear. You need to set an smsbox-id in your smsbox group (I remeber you already have a dummy one), that corresponds to the id in your sqlbox. Then configure that to your smsbox-route group. Right now your bb is getting the DLRs, but doesn't know where to send them. Granted it is pretty lame to have only 1 smsbox connected to it, and not know what to do with it. It could be fixed sometime. Do not proceed with (2). BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 6:17 PM Subject: RE: Life without smsbox Hi Nikos, Thanks again for the feedback. You hit the nail on the head - I am seeing WARNING: smsbox_list empty! throughout the bearerbox log. Looks like running sqlbox alone is not enough to truly emulate a smsbox. So, I delved into the source for sqlbox, and from what I can see, it has no ACK response logic at all. It receives the DLR (or MO) from bearerbox, writes it to the DB and then passes it to a connected smsbox. It appears to rely on smsbox to generate the ACK - there's logic in there to pass smsbox messages back to bearerbox (which I assume would include the ACKs), but nothing to handle the situation where there is no smsbox connected. In this case, the message gets written to the DB then simply dropped, hence the queuing
RE: Life without smsbox
Please share the patch ;) == Rene -Original Message- From: Toby Phipps [mailto:toby.phi...@nexmedia.com.sg] Sent: Monday, 09 August, 2010 18:24 To: 'Nikos Balkanas'; 'Rene Kluwen'; users@kannel.org Subject: RE: Life without smsbox Hi Nikos, I'll certainly try what you suggest, but I'm not quite sure that's the issue. Although bearerbox may think it doesn't have any smsboxes connected, it's still happily routing messages to sqlbox - here's a brief extract from the bearerbox log: 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) terminates. 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: sqlbox sqlbox is also getting each message as intended, and I can see it arriving in its log, and I can also see bearerbox queuing them in the status output. smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) The piece that's missing really seems to be the ACK from sqlbox to bearerbox for each DLR message it receives. bearerbox is successfully sending each DLR to sqlbox, and sqlbox is successfully logging it to the DB. However, as sqlbox is sending no ACK back, bearerbox has no way of knowing that sqlbox received the DLR and is therefore queuing it locally, and periodically re-sending to sqlbox. Now I've read the sqlbox code, it seems that it's a thin shell and doesn't implement ANY of the ACK processing that smsbox does. It simply logs to the DB, passes messages to smsbox and hopes that smsbox will pass it back an ACK that it can then pass to bearerbox so that the loop can be closed. However, without an smsbox connection, sqlbox is simply processing and dumping each message from bearerbox, leading to the unnecessary queuing in bearerbox. Anyway, that's what I've worked out from a few hours of looking through the code. This is nothing compared to the years that everyone else has with it, and I'm happy to be proved wrong! Just as an aside, between the time I sent my earlier email and I saw your response, I implemented a very rudimentary #2 (ACK in sqlbox) and it seems to have resolved the issue. All I'm doing is checking on each message receipt inside sqlbox to see if a smsbox is connected. If so then nothing changes - if not, then sqlbox returns the successful ACK. Thanks, Toby -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Tuesday, 10 August 2010 12:08 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Hi, You are missing an smsbox-route group. Once you configure that, your DLR problem will disappear. You need to set an smsbox-id in your smsbox group (I remeber you already have a dummy one), that corresponds to the id in your sqlbox. Then configure that to your smsbox-route group. Right now your bb is getting the DLRs, but doesn't know where to send them. Granted it is pretty lame to have only 1 smsbox connected to it, and not know what to do with it. It could be fixed sometime. Do not proceed with (2). BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 6:17 PM Subject: RE: Life without smsbox Hi Nikos, Thanks again for the feedback. You hit the nail on the head - I am seeing WARNING: smsbox_list empty! throughout the bearerbox log. Looks like running sqlbox alone is not enough to truly emulate a smsbox. So, I delved into the source for sqlbox, and from what I can see, it has no ACK response logic at all. It receives the DLR (or MO) from bearerbox, writes it to the DB and then passes it to a connected smsbox. It appears to rely on smsbox to generate the ACK - there's logic in there to pass smsbox messages back to bearerbox (which I assume would include the ACKs), but nothing to handle the situation where there is no smsbox connected. In this case, the message gets written to the DB then simply dropped, hence the queuing in bearerbox that I'm seeing. So, I'm looking at two options and would very much appreciate advice on which one would be most appropriate: 1. Configure a dummy smsbox to receive/ACK the messages from sqlbox but do nothing else them. Not sure if I can configure smsbox to do this (I'll hit the doc), whether I'll need to patch it to provide a ACK and drop mode, or whether I should have it call a dummy destination to avoid the patching. 2. Enhance sqlbox to generate its own ACK if it doesn't have a connected smsbox to pass the MO/DLR onto. Any suggestions? If not, I'll probably start on #2 as it seems much cleaner to me and avoids the unnecessary overhead of a dummy smsbox process and associated IPC. Who is the appropriate sqlbox owner that I should run these changes by? I'm sure I'm not the only one that has no need for smsbox. Thanks, Toby. -Original Message-
RE: Life without smsbox
Btw, you can post it on the de...@kannel.org list with a copy to Alejandro Guerrieri alejandro.guerri...@gmail.com. He is the one maintaining sqlbox at the moment. == Rene -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Rene Kluwen Sent: Monday, 09 August, 2010 18:54 To: 'Toby Phipps'; 'Nikos Balkanas'; users@kannel.org Subject: RE: Life without smsbox Please share the patch ;) == Rene -Original Message- From: Toby Phipps [mailto:toby.phi...@nexmedia.com.sg] Sent: Monday, 09 August, 2010 18:24 To: 'Nikos Balkanas'; 'Rene Kluwen'; users@kannel.org Subject: RE: Life without smsbox Hi Nikos, I'll certainly try what you suggest, but I'm not quite sure that's the issue. Although bearerbox may think it doesn't have any smsboxes connected, it's still happily routing messages to sqlbox - here's a brief extract from the bearerbox log: 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) terminates. 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: sqlbox sqlbox is also getting each message as intended, and I can see it arriving in its log, and I can also see bearerbox queuing them in the status output. smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) The piece that's missing really seems to be the ACK from sqlbox to bearerbox for each DLR message it receives. bearerbox is successfully sending each DLR to sqlbox, and sqlbox is successfully logging it to the DB. However, as sqlbox is sending no ACK back, bearerbox has no way of knowing that sqlbox received the DLR and is therefore queuing it locally, and periodically re-sending to sqlbox. Now I've read the sqlbox code, it seems that it's a thin shell and doesn't implement ANY of the ACK processing that smsbox does. It simply logs to the DB, passes messages to smsbox and hopes that smsbox will pass it back an ACK that it can then pass to bearerbox so that the loop can be closed. However, without an smsbox connection, sqlbox is simply processing and dumping each message from bearerbox, leading to the unnecessary queuing in bearerbox. Anyway, that's what I've worked out from a few hours of looking through the code. This is nothing compared to the years that everyone else has with it, and I'm happy to be proved wrong! Just as an aside, between the time I sent my earlier email and I saw your response, I implemented a very rudimentary #2 (ACK in sqlbox) and it seems to have resolved the issue. All I'm doing is checking on each message receipt inside sqlbox to see if a smsbox is connected. If so then nothing changes - if not, then sqlbox returns the successful ACK. Thanks, Toby -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Tuesday, 10 August 2010 12:08 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Hi, You are missing an smsbox-route group. Once you configure that, your DLR problem will disappear. You need to set an smsbox-id in your smsbox group (I remeber you already have a dummy one), that corresponds to the id in your sqlbox. Then configure that to your smsbox-route group. Right now your bb is getting the DLRs, but doesn't know where to send them. Granted it is pretty lame to have only 1 smsbox connected to it, and not know what to do with it. It could be fixed sometime. Do not proceed with (2). BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 6:17 PM Subject: RE: Life without smsbox Hi Nikos, Thanks again for the feedback. You hit the nail on the head - I am seeing WARNING: smsbox_list empty! throughout the bearerbox log. Looks like running sqlbox alone is not enough to truly emulate a smsbox. So, I delved into the source for sqlbox, and from what I can see, it has no ACK response logic at all. It receives the DLR (or MO) from bearerbox, writes it to the DB and then passes it to a connected smsbox. It appears to rely on smsbox to generate the ACK - there's logic in there to pass smsbox messages back to bearerbox (which I assume would include the ACKs), but nothing to handle the situation where there is no smsbox connected. In this case, the message gets written to the DB then simply dropped, hence the queuing in bearerbox that I'm seeing. So, I'm looking at two options and would very much appreciate advice on which one would be most appropriate: 1. Configure a dummy smsbox to receive/ACK the messages from sqlbox but do nothing else them. Not sure if I can configure smsbox to do this (I'll hit the doc), whether I'll need to patch it to provide a ACK and drop mode, or whether I should have it call a dummy destination to avoid the patching. 2. Enhance sqlbox to generate its own ACK
RE: Life without smsbox
Hmm, OK. Interesting. I've reverted to the SVN head of sqlbox and configured the following: group = smsbox bearerbox-host = localhost smsbox-id = sqlbox group = smsbox-route smsbox-id = sqlbox group = sqlbox id = sqlbox smsbox-id = sqlbox bearerbox-port = 13100 bearerbox-host = localhost # smsbox-port = 13200 sql-log-table = smsgw_kannel_sms_result sql-insert-table = smsgw_kannel_sms_queue log-file = /usr/local/kannel/log/sqlbox.log log-level = 0 Now, I see the following in bearerbox.log: 2010-08-10 00:53:11 [1691] [13] DEBUG: boxc_receiver: sms received 2010-08-10 00:53:11 [1691] [13] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 2010-08-10 00:53:17 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:17 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 The lines at 00:53:11 are written when the MT is sent out. The lines at 00:53:17 are written when the DLR arrives. And... unfortunately the queuing is back - here's the relevant status output: SMS: received 0 (0 queued), sent 2 (0 queued), store size 4 SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.01,0.01,0.01) msg/sec DLR: received 4, sent 0 DLR: inbound (0.02,0.01,0.01) msg/sec, outbound (0.00,0.00,0.00) msg/sec DLR: 262 queued, using mysql storage Box connections: smsbox:sqlbox, IP 127.0.0.1 (4 queued), (on-line 0d 0h 4m 39s) I still chalk the queuing up to a missing ACK from sqlbox - the following line is missing from the logs: DEBUG: boxc_receiver: got ack When I had smsbox running and calling a dummy URL to get rid of DLRs, that ack would appear each time a message (MT or DLR) was sent to sqlbox. So, I'm still convinced that the DLR routing to sqlbox is happening, and that bearerbox is just getting upset as it gets no ACK from sqlbox. My hypothesis regarding the WARNING: smsbox_list empty! message is that bearerbox isn't getting a smsbox registration message (as sqlbox doesn't generate one, and relies on the non-existent smsbox to do so), but is still routing both MT notifications and DLRs to sqlbox as it's been instructed to do. I'd be happy to be proved wrong though! Thanks, Toby. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Tuesday, 10 August 2010 12:31 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Nope. What you see is entirely different. send_msg is not sending the DLR to sqlbox, but rather responding an ACK to the received MT. I don't know if there is a problem with sqlbox, but I bet I would have heard about it if it were, but revert to the svn version and try smsbox-route. The warning you get is very crucial, you are missing incoming DLRs. You need to fix that, before anything else. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 7:24 PM Subject: RE: Life without smsbox Hi Nikos, I'll certainly try what you suggest, but I'm not quite sure that's the issue. Although bearerbox may think it doesn't have any smsboxes connected, it's still happily routing messages to sqlbox - here's a brief extract from the bearerbox log: 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) terminates. 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: sqlbox sqlbox is also getting each message as intended, and I can see it arriving in its log, and I can also see bearerbox queuing them in the status output. smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) The piece that's missing really seems to be the ACK from sqlbox to bearerbox for each DLR message it receives. bearerbox is successfully sending each DLR to sqlbox, and sqlbox is successfully logging it to the DB. However, as sqlbox is sending no ACK back, bearerbox has no way of knowing that sqlbox received the DLR and is therefore queuing it locally, and periodically re-sending to sqlbox. Now I've read the sqlbox code, it seems that it's a thin shell and doesn't implement ANY of the ACK processing that smsbox does. It simply logs to the DB, passes messages to smsbox and hopes that smsbox will pass it back an ACK that it can then pass to bearerbox so that the loop can be closed. However, without an smsbox connection, sqlbox is simply processing and dumping each message from bearerbox, leading to the unnecessary queuing in bearerbox. Anyway, that's what I've worked out from a few hours of looking through the code. This is nothing compared to the years that everyone else has with it, and I'm happy to be proved wrong! Just as an aside, between the time I sent my earlier email and I saw
Re: Problem with spool store - missing sms_type
Please address list. I didn't know that opensmppbox has now a queue. Clearly you shouldn't have overlapping spools between bb and openssmppbox. Configure different spool areas for each one. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: Nikos Balkanas nbalka...@gmail.com Sent: Monday, August 09, 2010 7:55 PM Subject: Re: Problem with spool store - missing sms_type Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted :) I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim li�cie datowanym 9 sierpnia 2010 (18:34:44) moΏna przeczytaζ: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
Re: Problem with spool store - missing sms_type
Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted :) I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim liście datowanym 9 sierpnia 2010 (18:34:44) można przeczytać: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
Re: Life without smsbox
I reiterate. SQLbox shouldn't have such an error. Your smsbox-route is not correct, you need to specify smsc-id. Read User's guide about it. You should still be getting that WARNING. Solve that, and you should be set. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 7:59 PM Subject: RE: Life without smsbox Hmm, OK. Interesting. I've reverted to the SVN head of sqlbox and configured the following: group = smsbox bearerbox-host = localhost smsbox-id = sqlbox group = smsbox-route smsbox-id = sqlbox group = sqlbox id = sqlbox smsbox-id = sqlbox bearerbox-port = 13100 bearerbox-host = localhost # smsbox-port = 13200 sql-log-table = smsgw_kannel_sms_result sql-insert-table = smsgw_kannel_sms_queue log-file = /usr/local/kannel/log/sqlbox.log log-level = 0 Now, I see the following in bearerbox.log: 2010-08-10 00:53:11 [1691] [13] DEBUG: boxc_receiver: sms received 2010-08-10 00:53:11 [1691] [13] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 2010-08-10 00:53:17 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:17 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 The lines at 00:53:11 are written when the MT is sent out. The lines at 00:53:17 are written when the DLR arrives. And... unfortunately the queuing is back - here's the relevant status output: SMS: received 0 (0 queued), sent 2 (0 queued), store size 4 SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.01,0.01,0.01) msg/sec DLR: received 4, sent 0 DLR: inbound (0.02,0.01,0.01) msg/sec, outbound (0.00,0.00,0.00) msg/sec DLR: 262 queued, using mysql storage Box connections: smsbox:sqlbox, IP 127.0.0.1 (4 queued), (on-line 0d 0h 4m 39s) I still chalk the queuing up to a missing ACK from sqlbox - the following line is missing from the logs: DEBUG: boxc_receiver: got ack When I had smsbox running and calling a dummy URL to get rid of DLRs, that ack would appear each time a message (MT or DLR) was sent to sqlbox. So, I'm still convinced that the DLR routing to sqlbox is happening, and that bearerbox is just getting upset as it gets no ACK from sqlbox. My hypothesis regarding the WARNING: smsbox_list empty! message is that bearerbox isn't getting a smsbox registration message (as sqlbox doesn't generate one, and relies on the non-existent smsbox to do so), but is still routing both MT notifications and DLRs to sqlbox as it's been instructed to do. I'd be happy to be proved wrong though! Thanks, Toby. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Tuesday, 10 August 2010 12:31 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Nope. What you see is entirely different. send_msg is not sending the DLR to sqlbox, but rather responding an ACK to the received MT. I don't know if there is a problem with sqlbox, but I bet I would have heard about it if it were, but revert to the svn version and try smsbox-route. The warning you get is very crucial, you are missing incoming DLRs. You need to fix that, before anything else. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 7:24 PM Subject: RE: Life without smsbox Hi Nikos, I'll certainly try what you suggest, but I'm not quite sure that's the issue. Although bearerbox may think it doesn't have any smsboxes connected, it's still happily routing messages to sqlbox - here's a brief extract from the bearerbox log: 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) terminates. 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: sqlbox sqlbox is also getting each message as intended, and I can see it arriving in its log, and I can also see bearerbox queuing them in the status output. smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) The piece that's missing really seems to be the ACK from sqlbox to bearerbox for each DLR message it receives. bearerbox is successfully sending each DLR to sqlbox, and sqlbox is successfully logging it to the DB. However, as sqlbox is sending no ACK back, bearerbox has no way of knowing that sqlbox received the DLR and is therefore queuing it locally, and periodically re-sending to sqlbox. Now I've read the sqlbox code, it seems that it's a thin shell and doesn't implement ANY of the ACK processing that smsbox does. It simply logs to the DB, passes messages to smsbox and hopes that smsbox will pass it back an ACK that it can then pass to bearerbox so
Re: Problem with spool store - missing sms_type
Hi, Open SMPPBOX haven't its own queue - I submit messages to Bearerbox via open SMPPBOX from other system. But sometimes these messages are being queued by Bearerbox in spool. But when Bearerbox is restarted while at spool there are some messages, it PANICs and won't run. The problem is because messages at spool haven't Type field. They have SMS ID, Time, Sender, Receiver, SMSC ID, BOX ID, UDH, Message fields but Type field is empty. Bearerbox during start informs about it: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! I didn't tried submitting messages to BEARERBOX from a standard SMSBOX yet, only by open SMPPBOX so I don't know at the moment if this problem happens only when using open SMPPBOX. @Nikos Sorry for adressing you private, it was my mistake. Tomasz Please address list. I didn't know that opensmppbox has now a queue. Clearly you shouldn't have overlapping spools between bb and openssmppbox. Configure different spool areas for each one. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: Nikos Balkanas nbalka...@gmail.com Sent: Monday, August 09, 2010 7:55 PM Subject: Re: Problem with spool store - missing sms_type Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted :) I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim licie datowanym 9 sierpnia 2010 (18:34:44) moΏna przeczytaζ: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
Re: Problem with spool store - missing sms_type
A similar problem happens with sqlbox if you don't set the sms_type to 2 when submitting mt's: everything works fine until you restart the service, and then when bearerbox tries to restore the queue from the store it fails with those errors. I don't know if opensmppbox is leaving the sms type empty, if is this a bug or misconfiguration (I've no experience with opensmppbox so far myself) but perhaps the sqlbox issue points you on the right direction? Regards, Alex On Mon, Aug 9, 2010 at 7:14 PM, Tomasz ad...@impexrur.pl wrote: Hi, Open SMPPBOX haven't its own queue - I submit messages to Bearerbox via open SMPPBOX from other system. But sometimes these messages are being queued by Bearerbox in spool. But when Bearerbox is restarted while at spool there are some messages, it PANICs and won't run. The problem is because messages at spool haven't Type field. They have SMS ID, Time, Sender, Receiver, SMSC ID, BOX ID, UDH, Message fields but Type field is empty. Bearerbox during start informs about it: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! I didn't tried submitting messages to BEARERBOX from a standard SMSBOX yet, only by open SMPPBOX so I don't know at the moment if this problem happens only when using open SMPPBOX. @Nikos Sorry for adressing you private, it was my mistake. Tomasz Please address list. I didn't know that opensmppbox has now a queue. Clearly you shouldn't have overlapping spools between bb and openssmppbox. Configure different spool areas for each one. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: Nikos Balkanas nbalka...@gmail.com Sent: Monday, August 09, 2010 7:55 PM Subject: Re: Problem with spool store - missing sms_type Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted :) I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim liœcie datowanym 9 sierpnia 2010 (18:34:44) moΏna przeczytaζ: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
store sms MO
hi evrybody, I've somme probleme with kannel. My smsc is connected with kannel and it's onlines. But when i loock to store-status, i see many sms are queued. And these sms are destinated to this smsc witch is online. My smsbox is also online. Does somebody can help me? From: toby.phi...@nexmedia.com.sg To: nbalka...@gmail.com; rene.klu...@chimit.nl; users@kannel.org Subject: RE: Life without smsbox Date: Tue, 10 Aug 2010 00:59:13 +0800 Hmm, OK. Interesting. I've reverted to the SVN head of sqlbox and configured the following: group = smsbox bearerbox-host = localhost smsbox-id = sqlbox group = smsbox-route smsbox-id = sqlbox group = sqlbox id = sqlbox smsbox-id = sqlbox bearerbox-port = 13100 bearerbox-host = localhost # smsbox-port = 13200 sql-log-table = smsgw_kannel_sms_result sql-insert-table = smsgw_kannel_sms_queue log-file = /usr/local/kannel/log/sqlbox.log log-level = 0 Now, I see the following in bearerbox.log: 2010-08-10 00:53:11 [1691] [13] DEBUG: boxc_receiver: sms received 2010-08-10 00:53:11 [1691] [13] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 2010-08-10 00:53:17 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:17 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 The lines at 00:53:11 are written when the MT is sent out. The lines at 00:53:17 are written when the DLR arrives. And... unfortunately the queuing is back - here's the relevant status output: SMS: received 0 (0 queued), sent 2 (0 queued), store size 4 SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.01,0.01,0.01) msg/sec DLR: received 4, sent 0 DLR: inbound (0.02,0.01,0.01) msg/sec, outbound (0.00,0.00,0.00) msg/sec DLR: 262 queued, using mysql storage Box connections: smsbox:sqlbox, IP 127.0.0.1 (4 queued), (on-line 0d 0h 4m 39s) I still chalk the queuing up to a missing ACK from sqlbox - the following line is missing from the logs: DEBUG: boxc_receiver: got ack When I had smsbox running and calling a dummy URL to get rid of DLRs, that ack would appear each time a message (MT or DLR) was sent to sqlbox. So, I'm still convinced that the DLR routing to sqlbox is happening, and that bearerbox is just getting upset as it gets no ACK from sqlbox. My hypothesis regarding the WARNING: smsbox_list empty! message is that bearerbox isn't getting a smsbox registration message (as sqlbox doesn't generate one, and relies on the non-existent smsbox to do so), but is still routing both MT notifications and DLRs to sqlbox as it's been instructed to do. I'd be happy to be proved wrong though! Thanks, Toby. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Tuesday, 10 August 2010 12:31 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Nope. What you see is entirely different. send_msg is not sending the DLR to sqlbox, but rather responding an ACK to the received MT. I don't know if there is a problem with sqlbox, but I bet I would have heard about it if it were, but revert to the svn version and try smsbox-route. The warning you get is very crucial, you are missing incoming DLRs. You need to fix that, before anything else. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 7:24 PM Subject: RE: Life without smsbox Hi Nikos, I'll certainly try what you suggest, but I'm not quite sure that's the issue. Although bearerbox may think it doesn't have any smsboxes connected, it's still happily routing messages to sqlbox - here's a brief extract from the bearerbox log: 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) terminates. 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: sqlbox sqlbox is also getting each message as intended, and I can see it arriving in its log, and I can also see bearerbox queuing them in the status output. smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) The piece that's missing really seems to be the ACK from sqlbox to bearerbox for each DLR message it receives. bearerbox is successfully sending each DLR to sqlbox, and sqlbox is successfully logging it to the DB. However, as sqlbox is sending no ACK back, bearerbox has no way of knowing that sqlbox received the DLR and is therefore queuing it locally, and periodically re-sending to sqlbox. Now I've read the sqlbox code, it seems that it's a thin shell and doesn't implement ANY of the ACK processing that smsbox does. It simply logs to
Re: Problem with spool store - missing sms_type
Hi, I've tried to send message via standard SMSBOX (CGI push) and when it is being queued sms_type field is present (value 2). But if message is pushed via open SMPPBOX, sms_type field is missing and Bearerbox crashes during restart. So it must be issue with open SMPPBOX. As Alex wrote, probably sms_type field is empty so it makes problems with store. Tomasz A similar problem happens with sqlbox if you don't set the sms_type to 2 when submitting mt's: everything works fine until you restart the service, and then when bearerbox tries to restore the queue from the store it fails with those errors. I don't know if opensmppbox is leaving the sms type empty, if is this a bug or misconfiguration (I've no experience with opensmppbox so far myself) but perhaps the sqlbox issue points you on the right direction? Regards, Alex On Mon, Aug 9, 2010 at 7:14 PM, Tomasz ad...@impexrur.pl wrote: Hi, Open SMPPBOX haven't its own queue - I submit messages to Bearerbox via open SMPPBOX from other system. But sometimes these messages are being queued by Bearerbox in spool. But when Bearerbox is restarted while at spool there are some messages, it PANICs and won't run. The problem is because messages at spool haven't Type field. They have SMS ID, Time, Sender, Receiver, SMSC ID, BOX ID, UDH, Message fields but Type field is empty. Bearerbox during start informs about it: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! I didn't tried submitting messages to BEARERBOX from a standard SMSBOX yet, only by open SMPPBOX so I don't know at the moment if this problem happens only when using open SMPPBOX. @Nikos Sorry for adressing you private, it was my mistake. Tomasz Please address list. I didn't know that opensmppbox has now a queue. Clearly you shouldn't have overlapping spools between bb and openssmppbox. Configure different spool areas for each one. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: Nikos Balkanas nbalka...@gmail.com Sent: Monday, August 09, 2010 7:55 PM Subject: Re: Problem with spool store - missing sms_type Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim liœcie datowanym 9 sierpnia 2010 (18:34:44) moΏna przeczytaζ: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
Re: Problem with spool store - missing sms_type
Yep, smsbox doesn't. Sqlbox, if you're not careful, does. The problem is with the way messages are checked. When messages are received from a box, they go to memory first _and_ the store later. In that case, bearerbox doesn't perform any sanity checks on the sms type field. Now, when messages are retrieved from the store during boot, a sanity check is performed and the whole system panics if it encounter a single invalid message. I think two things would be needed here: 1. Perform the same sanity checks when getting messages from boxes and reject anything that would cause a problem when retrieved from the store. 2. Add an option to boot kannel discarding those corrupted messages. A few hundred corrupted messages in the store could mean a nightmare when trying to restart a crashed server. Regards, Alex 2010/8/9 Nikos Balkanas nbalka...@gmail.com Hi, I can verify to the thousands of kannel users all over the wold, that smsbox doesn't have any such issue. However this seems an issue with bearerbox as well. SMPPbox should really generate correct Msg *, and bearerbox shouldn't pnick about them. I mean if it is happy processing them live, why should it panic at start? BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 8:14 PM Subject: Re: Problem with spool store - missing sms_type Hi, Open SMPPBOX haven't its own queue - I submit messages to Bearerbox via open SMPPBOX from other system. But sometimes these messages are being queued by Bearerbox in spool. But when Bearerbox is restarted while at spool there are some messages, it PANICs and won't run. The problem is because messages at spool haven't Type field. They have SMS ID, Time, Sender, Receiver, SMSC ID, BOX ID, UDH, Message fields but Type field is empty. Bearerbox during start informs about it: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! I didn't tried submitting messages to BEARERBOX from a standard SMSBOX yet, only by open SMPPBOX so I don't know at the moment if this problem happens only when using open SMPPBOX. @Nikos Sorry for adressing you private, it was my mistake. Tomasz Please address list. I didn't know that opensmppbox has now a queue. Clearly you shouldn't have overlapping spools between bb and openssmppbox. Configure different spool areas for each one. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: Nikos Balkanas nbalka...@gmail.com Sent: Monday, August 09, 2010 7:55 PM Subject: Re: Problem with spool store - missing sms_type Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted :) I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim li cie datowanym 9 sierpnia 2010 (18:34:44) moΠna przeczytaζ: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(main+0x80f) [0x40f22f] 2010-08-09 17:49:55 [29887] [0] PANIC: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f5cdfd3b1a6] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x40db09] When I checked store-status (via http admin) I could see that Type field of all messages was empty. All messages were submitted to Bearerbox via open SMPPBOX. My Kannel version is from latest SVN (Rev. 4837). Tomasz
RE: Life without smsbox
True. You have the same smsbox-id for both smsbox and sqlbox. It should be different. But... probably sqlbox isn't going to send an ACK. At least I didn't put it in the code. Maybe someone else. == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Monday, 09 August, 2010 19:07 To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox I reiterate. SQLbox shouldn't have such an error. Your smsbox-route is not correct, you need to specify smsc-id. Read User's guide about it. You should still be getting that WARNING. Solve that, and you should be set. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 7:59 PM Subject: RE: Life without smsbox Hmm, OK. Interesting. I've reverted to the SVN head of sqlbox and configured the following: group = smsbox bearerbox-host = localhost smsbox-id = sqlbox group = smsbox-route smsbox-id = sqlbox group = sqlbox id = sqlbox smsbox-id = sqlbox bearerbox-port = 13100 bearerbox-host = localhost # smsbox-port = 13200 sql-log-table = smsgw_kannel_sms_result sql-insert-table = smsgw_kannel_sms_queue log-file = /usr/local/kannel/log/sqlbox.log log-level = 0 Now, I see the following in bearerbox.log: 2010-08-10 00:53:11 [1691] [13] DEBUG: boxc_receiver: sms received 2010-08-10 00:53:11 [1691] [13] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 2010-08-10 00:53:17 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:17 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 The lines at 00:53:11 are written when the MT is sent out. The lines at 00:53:17 are written when the DLR arrives. And... unfortunately the queuing is back - here's the relevant status output: SMS: received 0 (0 queued), sent 2 (0 queued), store size 4 SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.01,0.01,0.01) msg/sec DLR: received 4, sent 0 DLR: inbound (0.02,0.01,0.01) msg/sec, outbound (0.00,0.00,0.00) msg/sec DLR: 262 queued, using mysql storage Box connections: smsbox:sqlbox, IP 127.0.0.1 (4 queued), (on-line 0d 0h 4m 39s) I still chalk the queuing up to a missing ACK from sqlbox - the following line is missing from the logs: DEBUG: boxc_receiver: got ack When I had smsbox running and calling a dummy URL to get rid of DLRs, that ack would appear each time a message (MT or DLR) was sent to sqlbox. So, I'm still convinced that the DLR routing to sqlbox is happening, and that bearerbox is just getting upset as it gets no ACK from sqlbox. My hypothesis regarding the WARNING: smsbox_list empty! message is that bearerbox isn't getting a smsbox registration message (as sqlbox doesn't generate one, and relies on the non-existent smsbox to do so), but is still routing both MT notifications and DLRs to sqlbox as it's been instructed to do. I'd be happy to be proved wrong though! Thanks, Toby. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Tuesday, 10 August 2010 12:31 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Nope. What you see is entirely different. send_msg is not sending the DLR to sqlbox, but rather responding an ACK to the received MT. I don't know if there is a problem with sqlbox, but I bet I would have heard about it if it were, but revert to the svn version and try smsbox-route. The warning you get is very crucial, you are missing incoming DLRs. You need to fix that, before anything else. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 7:24 PM Subject: RE: Life without smsbox Hi Nikos, I'll certainly try what you suggest, but I'm not quite sure that's the issue. Although bearerbox may think it doesn't have any smsboxes connected, it's still happily routing messages to sqlbox - here's a brief extract from the bearerbox log: 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) terminates. 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: sqlbox sqlbox is also getting each message as intended, and I can see it arriving in its log, and I can also see bearerbox queuing them in the status output. smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) The piece that's missing really seems to be the ACK from sqlbox to bearerbox for each DLR message it receives. bearerbox is successfully sending each DLR to sqlbox, and
Re: Problem with spool store - missing sms_type
Hi, The behaviour in store is the only correct one. sms_type could be an MO (0), MT (2) or DLR (3). Different logic and routing is applied in each case. During startup it doesn't know which one is and correctly panics. During operation, maybe bb can tell more, but I am not sure it is always safe to do so. It has to discriminate between an MT, a reroute_dlr (report_mt) and an mt_reply (from an MO). Or between an MO and a report_mo. Anyway, it should at least be consistent, and it should check for sms_type and if missing and absolutely sure it knows what it is, fill it in, else discard with an error. This is an opensmppbox issue. It should set the correct sms_type according to gw/msg.h. BR, Nikos - Original Message - From: Alejandro Guerrieri To: Nikos Balkanas Cc: Tomasz ; users@kannel.org Sent: Monday, August 09, 2010 9:12 PM Subject: Re: Problem with spool store - missing sms_type Yep, smsbox doesn't. Sqlbox, if you're not careful, does. The problem is with the way messages are checked. When messages are received from a box, they go to memory first _and_ the store later. In that case, bearerbox doesn't perform any sanity checks on the sms type field. Now, when messages are retrieved from the store during boot, a sanity check is performed and the whole system panics if it encounter a single invalid message. I think two things would be needed here: 1. Perform the same sanity checks when getting messages from boxes and reject anything that would cause a problem when retrieved from the store. 2. Add an option to boot kannel discarding those corrupted messages. A few hundred corrupted messages in the store could mean a nightmare when trying to restart a crashed server. Regards, Alex 2010/8/9 Nikos Balkanas nbalka...@gmail.com Hi, I can verify to the thousands of kannel users all over the wold, that smsbox doesn't have any such issue. However this seems an issue with bearerbox as well. SMPPbox should really generate correct Msg *, and bearerbox shouldn't pnick about them. I mean if it is happy processing them live, why should it panic at start? BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 8:14 PM Subject: Re: Problem with spool store - missing sms_type Hi, Open SMPPBOX haven't its own queue - I submit messages to Bearerbox via open SMPPBOX from other system. But sometimes these messages are being queued by Bearerbox in spool. But when Bearerbox is restarted while at spool there are some messages, it PANICs and won't run. The problem is because messages at spool haven't Type field. They have SMS ID, Time, Sender, Receiver, SMSC ID, BOX ID,  UDH, Message fields but Type field is empty. Bearerbox during start informs about it: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! I didn't tried submitting messages to BEARERBOX from a standard SMSBOX yet, only by open SMPPBOX so I don't know at the moment if this problem happens only when using open SMPPBOX. @Nikos Sorry for adressing you private, it was my mistake. Tomasz Please address list. I didn't know that opensmppbox has now a queue. Clearly you shouldn't have overlapping spools between bb and openssmppbox. Configure different spool areas for each one. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: Nikos Balkanas nbalka...@gmail.com Sent: Monday, August 09, 2010 7:55 PM Subject: Re: Problem with spool store - missing sms_type Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted :) I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim liΒ cie datowanym 9 sierpnia 2010 (18:34:44) mo� na przeczyta�¶: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox(gw_panic+0x14b) [0x487f5b] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419721] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419144] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419166] 2010-08-09 17:49:55 [29887] [0] PANIC: /usr/local/sbin/bearerbox [0x419689] 2010-08-09 17:49:55 [29887] [0] PANIC:
Re: store sms MO
Hi, If your problem is with MOs, please read User's guide about smsbox-route. That should do it. BR, Nikos - Original Message - From: Omar THIAM To: users@kannel.org Sent: Monday, August 09, 2010 8:44 PM Subject: store sms MO hi evrybody, I've somme probleme with kannel. My smsc is connected with kannel and it's onlines. But when i loock to store-status, i see many sms are queued. And these sms are destinated to this smsc witch is online. My smsbox is also online. Does somebody can help me? From: toby.phi...@nexmedia.com.sg To: nbalka...@gmail.com; rene.klu...@chimit.nl; users@kannel.org Subject: RE: Life without smsbox Date: Tue, 10 Aug 2010 00:59:13 +0800 Hmm, OK. Interesting. I've reverted to the SVN head of sqlbox and configured the following: group = smsbox bearerbox-host = localhost smsbox-id = sqlbox group = smsbox-route smsbox-id = sqlbox group = sqlbox id = sqlbox smsbox-id = sqlbox bearerbox-port = 13100 bearerbox-host = localhost # smsbox-port = 13200 sql-log-table = smsgw_kannel_sms_result sql-insert-table = smsgw_kannel_sms_queue log-file = /usr/local/kannel/log/sqlbox.log log-level = 0 Now, I see the following in bearerbox.log: 2010-08-10 00:53:11 [1691] [13] DEBUG: boxc_receiver: sms received 2010-08-10 00:53:11 [1691] [13] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 2010-08-10 00:53:17 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:17 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 The lines at 00:53:11 are written when the MT is sent out. The lines at 00:53:17 are written when the DLR arrives. And... unfortunately the queuing is back - here's the relevant status output: SMS: received 0 (0 queued), sent 2 (0 queued), store size 4 SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.01,0.01,0.01) msg/sec DLR: received 4, sent 0 DLR: inbound (0.02,0.01,0.01) msg/sec, outbound (0.00,0.00,0.00) msg/sec DLR: 262 queued, using mysql storage Box connections: smsbox:sqlbox, IP 127.0.0.1 (4 queued), (on-line 0d 0h 4m 39s) I still chalk the queuing up to a missing ACK from sqlbox - the following line is missing from the logs: DEBUG: boxc_receiver: got ack When I had smsbox running and calling a dummy URL to get rid of DLRs, that ack would appear each time a message (MT or DLR) was sent to sqlbox. So, I'm still convinced that the DLR routing to sqlbox is happening, and that bearerbox is just getting upset as it gets no ACK from sqlbox. My hypothesis regarding the WARNING: smsbox_list empty! message is that bearerbox isn't getting a smsbox registration message (as sqlbox doesn't generate one, and relies on the non-existent smsbox to do so), but is still routing both MT notifications and DLRs to sqlbox as it's been instructed to do. I'd be happy to be proved wrong though! Thanks, Toby. -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Tuesday, 10 August 2010 12:31 AM To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox Nope. What you see is entirely different. send_msg is not sending the DLR to sqlbox, but rather responding an ACK to the received MT. I don't know if there is a problem with sqlbox, but I bet I would have heard about it if it were, but revert to the svn version and try smsbox-route. The warning you get is very crucial, you are missing incoming DLRs. You need to fix that, before anything else. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 7:24 PM Subject: RE: Life without smsbox Hi Nikos, I'll certainly try what you suggest, but I'm not quite sure that's the issue. Although bearerbox may think it doesn't have any smsboxes connected, it's still happily routing messages to sqlbox - here's a brief extract from the bearerbox log: 2010-08-09 23:46:52 [24133] [4] WARNING: smsbox_list empty! 2010-08-09 23:46:52 [24133] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) terminates. 2010-08-09 23:46:52 [24133] [14] DEBUG: send_msg: sending msg to boxc: sqlbox sqlbox is also getting each message as intended, and I can see it arriving in its log, and I can also see bearerbox queuing them in the status output. smsbox:sqlbox, IP 127.0.0.1 (110 queued), (on-line 0d 0h 0m 50s) The piece that's missing really seems to be the ACK from sqlbox to bearerbox for each DLR message it receives. bearerbox is successfully sending each DLR to sqlbox, and sqlbox is successfully logging it to the DB. However, as sqlbox is sending no ACK back, bearerbox has no way of knowing that sqlbox received the DLR and is therefore queuing it locally, and periodically re-sending to sqlbox. Now I've read the sqlbox code, it seems
Re: Problem with spool store - missing sms_type
Exactly. The point is: during normal operation, kannel of course it doesn't panic and will accept messages without a valid sms type. However, they're kept on the store with an invalid format, so if you shutdown the service with messages pending on the store, and just one of them happens to have an invalid sms type, the service panics at startup. This is less than desirable of course, specially when you have a ton of completely valid messages and just a bunch of invalid. IMHO, kannel should reject messages with invalid sms type during regular operation (with a WARN logged). It _shouldn't_ try to fix them. That would take care of the problem in a proper way. Apart from that, a way to discard invalid messages at bootup without panicking would also be desirable :) Regards, Alex On Mon, Aug 9, 2010 at 11:11 PM, Rene Kluwen rene.klu...@chimit.nl wrote: Yes, open smppbox should correctly fill in the correct type. If it doesn't it is an error. But at the same time: If one particular message has an incorrent sms_type. Why panic? It can just discard the message and go on with normal operation. == Rene -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Nikos Balkanas Sent: Monday, 09 August, 2010 22:34 To: Alejandro Guerrieri Cc: users@kannel.org Subject: Re: Problem with spool store - missing sms_type Hi, The behaviour in store is the only correct one. sms_type could be an MO (0), MT (2) or DLR (3). Different logic and routing is applied in each case. During startup it doesn't know which one is and correctly panics. During operation, maybe bb can tell more, but I am not sure it is always safe to do so. It has to discriminate between an MT, a reroute_dlr (report_mt) and an mt_reply (from an MO). Or between an MO and a report_mo. Anyway, it should at least be consistent, and it should check for sms_type and if missing and absolutely sure it knows what it is, fill it in, else discard with an error. This is an opensmppbox issue. It should set the correct sms_type according to gw/msg.h. BR, Nikos - Original Message - From: Alejandro Guerrieri To: Nikos Balkanas Cc: Tomasz ; users@kannel.org Sent: Monday, August 09, 2010 9:12 PM Subject: Re: Problem with spool store - missing sms_type Yep, smsbox doesn't. Sqlbox, if you're not careful, does. The problem is with the way messages are checked. When messages are received from a box, they go to memory first _and_ the store later. In that case, bearerbox doesn't perform any sanity checks on the sms type field. Now, when messages are retrieved from the store during boot, a sanity check is performed and the whole system panics if it encounter a single invalid message. I think two things would be needed here: 1. Perform the same sanity checks when getting messages from boxes and reject anything that would cause a problem when retrieved from the store. 2. Add an option to boot kannel discarding those corrupted messages. A few hundred corrupted messages in the store could mean a nightmare when trying to restart a crashed server. Regards, Alex 2010/8/9 Nikos Balkanas nbalka...@gmail.com Hi, I can verify to the thousands of kannel users all over the wold, that smsbox doesn't have any such issue. However this seems an issue with bearerbox as well. SMPPbox should really generate correct Msg *, and bearerbox shouldn't pnick about them. I mean if it is happy processing them live, why should it panic at start? BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 8:14 PM Subject: Re: Problem with spool store - missing sms_type Hi, Open SMPPBOX haven't its own queue - I submit messages to Bearerbox via open SMPPBOX from other system. But sometimes these messages are being queued by Bearerbox in spool. But when Bearerbox is restarted while at spool there are some messages, it PANICs and won't run. The problem is because messages at spool haven't Type field. They have SMS ID, Time, Sender, Receiver, SMSC ID, BOX ID, Β UDH, Message fields but Type field is empty. Bearerbox during start informs about it: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! I didn't tried submitting messages to BEARERBOX from a standard SMSBOX yet, only by open SMPPBOX so I don't know at the moment if this problem happens only when using open SMPPBOX. @Nikos Sorry for adressing you private, it was my mistake. Tomasz Please address list. I didn't know that opensmppbox has now a queue. Clearly you shouldn't have overlapping spools between bb and openssmppbox. Configure different spool areas for each one. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: Nikos Balkanas nbalka...@gmail.com Sent: Monday, August 09, 2010 7:55 PM Subject: Re: Problem with spool store - missing sms_type Hi, Yes,
RE: Problem with spool store - missing sms_type
Yes, open smppbox should correctly fill in the correct type. If it doesn't it is an error. But at the same time: If one particular message has an incorrent sms_type. Why panic? It can just discard the message and go on with normal operation. == Rene -Original Message- From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Nikos Balkanas Sent: Monday, 09 August, 2010 22:34 To: Alejandro Guerrieri Cc: users@kannel.org Subject: Re: Problem with spool store - missing sms_type Hi, The behaviour in store is the only correct one. sms_type could be an MO (0), MT (2) or DLR (3). Different logic and routing is applied in each case. During startup it doesn't know which one is and correctly panics. During operation, maybe bb can tell more, but I am not sure it is always safe to do so. It has to discriminate between an MT, a reroute_dlr (report_mt) and an mt_reply (from an MO). Or between an MO and a report_mo. Anyway, it should at least be consistent, and it should check for sms_type and if missing and absolutely sure it knows what it is, fill it in, else discard with an error. This is an opensmppbox issue. It should set the correct sms_type according to gw/msg.h. BR, Nikos - Original Message - From: Alejandro Guerrieri To: Nikos Balkanas Cc: Tomasz ; users@kannel.org Sent: Monday, August 09, 2010 9:12 PM Subject: Re: Problem with spool store - missing sms_type Yep, smsbox doesn't. Sqlbox, if you're not careful, does. The problem is with the way messages are checked. When messages are received from a box, they go to memory first _and_ the store later. In that case, bearerbox doesn't perform any sanity checks on the sms type field. Now, when messages are retrieved from the store during boot, a sanity check is performed and the whole system panics if it encounter a single invalid message. I think two things would be needed here: 1. Perform the same sanity checks when getting messages from boxes and reject anything that would cause a problem when retrieved from the store. 2. Add an option to boot kannel discarding those corrupted messages. A few hundred corrupted messages in the store could mean a nightmare when trying to restart a crashed server. Regards, Alex 2010/8/9 Nikos Balkanas nbalka...@gmail.com Hi, I can verify to the thousands of kannel users all over the wold, that smsbox doesn't have any such issue. However this seems an issue with bearerbox as well. SMPPbox should really generate correct Msg *, and bearerbox shouldn't pnick about them. I mean if it is happy processing them live, why should it panic at start? BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 8:14 PM Subject: Re: Problem with spool store - missing sms_type Hi, Open SMPPBOX haven't its own queue - I submit messages to Bearerbox via open SMPPBOX from other system. But sometimes these messages are being queued by Bearerbox in spool. But when Bearerbox is restarted while at spool there are some messages, it PANICs and won't run. The problem is because messages at spool haven't Type field. They have SMS ID, Time, Sender, Receiver, SMSC ID, BOX ID, Β UDH, Message fields but Type field is empty. Bearerbox during start informs about it: 2010-08-09 17:49:55 [29887] [0] PANIC: Not handled sms_type within store! I didn't tried submitting messages to BEARERBOX from a standard SMSBOX yet, only by open SMPPBOX so I don't know at the moment if this problem happens only when using open SMPPBOX. @Nikos Sorry for adressing you private, it was my mistake. Tomasz Please address list. I didn't know that opensmppbox has now a queue. Clearly you shouldn't have overlapping spools between bb and openssmppbox. Configure different spool areas for each one. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: Nikos Balkanas nbalka...@gmail.com Sent: Monday, August 09, 2010 7:55 PM Subject: Re: Problem with spool store - missing sms_type Hi, Yes, I know that they are corrupted, but all msgs in spool are always corrupted :) I removed them, but all new messages queued at spool are corrupted. They are probably incorrectly saved by Bearerbox/openSMPPBOX. The problem starts when I want to restart Bearerbox - it displays PANICs and won't start until I remove spool manually. It causes that I can't restart Bearerbox if there is some queue in spool... Tomasz W Twoim liΞ’ cie datowanym 9 sierpnia 2010 (18:34:44) moΞ na przeczytaΞΒ¶: Hi, You have a corrupted SMS in your spool. Remove it and you will be fine. BR, Nikos - Original Message - From: Tomasz ad...@impexrur.pl To: users@kannel.org Sent: Monday, August 09, 2010 7:30 PM Subject: Problem with spool store - missing sms_type Hi, Today I've found some critical error with kannel spool store-type. When I have messages in a queue (spool) and restart Bearerbox I get Panic: 2010-08-09
Re: Problem with gw_gethostbyname in Stable version 1.4.3
Hi, Always use users list for such questions. Add your server to /etc/hosts. I don't know to which variable name you are referring to. Try: telnet 9201 from a shell to see if you have connectivity to HTTP smsc. That address 2.2.2.2 in your send-url looks mighty suspicious. BR, Nikos - Original Message - From: Brian Rathman br...@telrite.com To: de...@kannel.org Sent: Tuesday, August 10, 2010 12:49 AM Subject: Problem with gw_gethostbyname in Stable version 1.4.3 Hi, I am attempting to connect two Kannel servers at two different locations via the smsc group using smsc = http. I have tried this on three different server and I am getting the same bevahior on all three (system 1: debian 5.0.5, system 2: Ubuntu 9.04, system 3: Ubuntu 10.04). In all three cases, when I send a message via the sendsms-user group, I get the following error: 2010-08-09 10:13:47 [9636] [17] ERROR: Error while gw_gethostbyname occurs. 2010-08-09 10:13:47 [9636] [17] ERROR: System error 3: No such process 2010-08-09 10:13:47 [9636] [17] ERROR: gethostbyname failed 2010-08-09 10:13:47 [9636] [17] ERROR: error connecting to server `2.2.2.2:9001' at port `9001' I googled several things before bothering you guys, and even tried adding some code to the protected.c file in the gw_gethostbyname function to try and figure out what was going on. What I found, was that the name variable is showing up as 2.2.2.2:9001 instead of just 2.2.2.2. I'm not sure if this correct or not. Anyways, here is my config and my logs: # HTTP administration is disabled by default. Make sure you set the # password if you enable it. group = core admin-port = 13000 admin-password = bar admin-deny-ip = *.*.*.* admin-allow-ip = smsbox-port = 13001 #wapbox-port = 13002 wdp-interface-name = * log-file = /var/log/kannel/bearerbox.log log-level = 0 # Testing #log-level = 1 # Production box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 #group = wapbox #bearerbox-host = localhost #log-file = /var/log/kannel/wapbox.log group = smsc smsc = http system-type = kannel smsc-id = LBSMS1 smsc-username = XXX smsc-password = XXX port = 9001 send-url = http://2.2.2.2:9001; #connect-allow-ip = 127.0.0.1 group = smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 log-file = /var/log/kannel/smsbox.log log-level = 0 group = sendsms-user username = kustc password = XX #default-smsc = ATTSTC concatenation= true max-messages = 10 group = sms-service #keyword = keyword-regex = .* catch-all = yes max-messages = 0 get-url = http://10.20.10.10/test/sms?phone=%ptext=%a; Logs: /var/logs/kannel/bearerbox: 2010-08-09 17:42:23 [17821] [0] INFO: Added logfile `/var/log/kannel/bearerbox.log' with level `0'. 2010-08-09 17:42:23 [17821] [0] INFO: HTTP: Opening server at port 13000. 2010-08-09 17:42:23 [17821] [1] DEBUG: Thread 1 (gwlib/fdset.c:poller) maps to pid 17821. 2010-08-09 17:42:23 [17821] [0] DEBUG: Started thread 1 (gwlib/fdset.c:poller) 2010-08-09 17:42:23 [17821] [2] DEBUG: Thread 2 (gwlib/http.c:server_thread) maps to pid 17821. 2010-08-09 17:42:23 [17821] [0] DEBUG: Started thread 2 (gwlib/http.c:server_thread) 2010-08-09 17:42:23 [17821] [3] DEBUG: Thread 3 (gw/bb_http.c:httpadmin_run) maps to pid 17821. 2010-08-09 17:42:23 [17821] [0] DEBUG: Started thread 3 (gw/bb_http.c:httpadmin_run) 2010-08-09 17:42:23 [17821] [0] DEBUG: starting smsbox connection module 2010-08-09 17:42:23 [17821] [0] INFO: BOXC: 'smsbox-max-pending' not set, using default (100). 2010-08-09 17:42:23 [17821] [4] DEBUG: Thread 4 (gw/bb_boxc.c:sms_to_smsboxes) maps to pid 17821. 2010-08-09 17:42:23 [17821] [0] DEBUG: Started thread 4 (gw/bb_boxc.c:sms_to_smsboxes) 2010-08-09 17:42:23 [17821] [5] DEBUG: Thread 5 (gw/bb_boxc.c:smsboxc_run) maps to pid 17821. 2010-08-09 17:42:23 [17821] [0] DEBUG: Started thread 5 (gw/bb_boxc.c:smsboxc_run) 2010-08-09 17:42:23 [17821] [0] INFO: Set SMS resend frequency to 60 seconds. 2010-08-09 17:42:23 [17821] [0] INFO: SMS resend retry set to unlimited. 2010-08-09 17:42:23 [17821] [0] DEBUG: smsbox MO concatenated message handling enabled 2010-08-09 17:42:23 [17821] [0] INFO: DLR rerouting for smsc id LBSMS1 disabled. 2010-08-09 17:42:23 [17821] [0] INFO: HTTP: Opening server at port 9001. 2010-08-09 17:42:23 [17821] [6] DEBUG: Thread 6 (gw/smsc/smsc_http.c:httpsmsc_receiver) maps to pid 17821. 2010-08-09 17:42:23 [17821] [0] DEBUG: Started thread 6 (gw/smsc/smsc_http.c:httpsmsc_receiver) 2010-08-09 17:42:23 [17821] [7] DEBUG: Thread 7 (gw/smsc/smsc_http.c:httpsmsc_send_cb) maps to pid 17821. 2010-08-09 17:42:23 [17821] [0] DEBUG: Started thread 7 (gw/smsc/smsc_http.c:httpsmsc_send_cb) 2010-08-09 17:42:23 [17821] [0] INFO: HTTP[LBSMS1]: Initiated and ready 2010-08-09 17:42:23 [17821] [8] DEBUG: Thread 8 (gw/bb_smscconn.c:sms_router) maps to pid 17821. 2010-08-09 17:42:23 [17821] [0] DEBUG: Started thread 8 (gw/bb_smscconn.c:sms_router) 2010-08-09 17:42:23 [17821] [0] DEBUG: starting UDP
Re: Kannel performance benchmarking
Try valgrind in linux. BR, Nikos - Original Message - From: sangprabv sangpr...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: brett skinner tatty.dishcl...@gmail.com; kannel users users@kannel.org Sent: Tuesday, August 10, 2010 3:35 AM Subject: Re: Kannel performance benchmarking Yeah I understand that. But when the there is no traffic. Kannel doesn't release the cached or buffered memory it used. Do you have any solution? What command to list down or trace the memory usage by Kannel? So maybe we can investigate which function or module in Kannel is eating the memory. Thanks sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/ On Aug 9, 2010, at 11:19 PM, Nikos Balkanas wrote: No memory problems. It is reasonable that kannel will use more memory in higher traffic, since all queues are in memory, as long as it drops to nominal levels once the traffic is gone. BR, Nikos - Original Message - From: sangprabv To: brett skinner Cc: Nikos Balkanas ; kannel users Sent: Monday, August 09, 2010 5:59 PM Subject: Re: Kannel performance benchmarking Hi Nikos, Do you experience memory problem? In my case Kannel is eating the memory on high load traffics. I always need to restart the box to get more memory. I even give 3 on /proc/sys/vm/drop_caches but still Kannel eat the memory :( sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/ On Aug 9, 2010, at 9:42 PM, brett skinner wrote: Hi Nikos Out of curiosity can you go into more detail regarding what hardware you were running and your setup for MySql? Were you using Innodb or MyIsam. If you were using Innodb did you make any other configuration changes to MySql to accommodate Innodb. From the user guide it is implied that the bottle neck for Kannel is the number of messages that the SMSC can accommodate per second. Is this still the case? Regards, 2010/8/8 Nikos Balkanas nbalka...@gmail.com Hi, I have run some benchmarking for a client using fakesmpp. Using the default service for MO's I got: MO's: 1400 SMS/s MT + DLRs (internal): 747 SMS/s MT + DLRs (MySql): 434 SMS/s BR, Nikos - Original Message - From: ha...@aeon.pk To: kannel users Sent: Sunday, August 08, 2010 4:22 PM Subject: Kannel performance benchmarking Hi, I am interested to know about the kannel performance benchmarking, especially in terms of speed (msgs/sec), MO or MT. I assume that multiple smsboxes does not have any effect over kannel performance, since the front-end talking to SMSC is the main bearerbox. What is the max speed that could be attained by kannel and/or bearerbox? Regards, Hamza
Re: Kannel performance benchmarking
Yeah I understand that. But when the there is no traffic. Kannel doesn't release the cached or buffered memory it used. Do you have any solution? What command to list down or trace the memory usage by Kannel? So maybe we can investigate which function or module in Kannel is eating the memory. Thanks sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/ On Aug 9, 2010, at 11:19 PM, Nikos Balkanas wrote: No memory problems. It is reasonable that kannel will use more memory in higher traffic, since all queues are in memory, as long as it drops to nominal levels once the traffic is gone. BR, Nikos - Original Message - From: sangprabv To: brett skinner Cc: Nikos Balkanas ; kannel users Sent: Monday, August 09, 2010 5:59 PM Subject: Re: Kannel performance benchmarking Hi Nikos, Do you experience memory problem? In my case Kannel is eating the memory on high load traffics. I always need to restart the box to get more memory. I even give 3 on /proc/sys/vm/drop_caches but still Kannel eat the memory :( sangprabv sangpr...@gmail.com http://www.petitiononline.com/froyo/ On Aug 9, 2010, at 9:42 PM, brett skinner wrote: Hi Nikos Out of curiosity can you go into more detail regarding what hardware you were running and your setup for MySql? Were you using Innodb or MyIsam. If you were using Innodb did you make any other configuration changes to MySql to accommodate Innodb. From the user guide it is implied that the bottle neck for Kannel is the number of messages that the SMSC can accommodate per second. Is this still the case? Regards, 2010/8/8 Nikos Balkanas nbalka...@gmail.com Hi, I have run some benchmarking for a client using fakesmpp. Using the default service for MO's I got: MO's: 1400 SMS/s MT + DLRs (internal): 747 SMS/s MT + DLRs (MySql): 434 SMS/s BR, Nikos - Original Message - From: ha...@aeon.pk To: kannel users Sent: Sunday, August 08, 2010 4:22 PM Subject: Kannel performance benchmarking Hi, I am interested to know about the kannel performance benchmarking, especially in terms of speed (msgs/sec), MO or MT. I assume that multiple smsboxes does not have any effect over kannel performance, since the front-end talking to SMSC is the main bearerbox. What is the max speed that could be attained by kannel and/or bearerbox? Regards, Hamza
RE: Life without smsbox
Rene, As the subject line suggests, I'm not actually running a smsbox, and the smsbox-id in both sqlbox and smsbox groups is set to the same value as recommended by Nikos (below) in order to force the routing. Maybe I misunderstood his directions? In any case, the smsbox_list empty warning turned out to be a red herring. It turns out that it appeared in the logs only a couple of times when I was tweaking the configuration and sqlbox wasn't running. With the current configuration (with the smsbox-route group removed), DLRs are routing correctly to sqlbox, and I've confirmed this with traces in the sqlbox code, the lack of the smsbox_list empty warning, and 100% MT-to-DLR matching in the sqlbox tables. I'm guessing this routing is happening either because I'm forcing the routing (setting boxc_id in every MT submitted), or because there's only one box connected, and bearerbox routes it there. So, with the new ACK code I've added to sqlbox, things appear to be running very smoothly. I'm seeing both MT submission notification and true DLRs coming through to sqlbox, and the bearerbox logs and status output show that they're being properly ACKed and purged from the local store. I'm quite happy with this config. With regards to the sqlbox ACK generation patch, I've been thinking about what should trigger the sqlbox-originated ACK. I originally coded it to generate the ACK if there was no smsbox connected to it, but on second thought this doesn't seem like a great idea as there could be situations where smsbox should be running but isn't, so the ACKs SHOULD be delegated and messages queued. My next thought was to use the presence of the smsbox-port config parameter (sqlbox group) to trigger the ACK (sqlbox generates the ACK if sqlbox-port is not present in the config and it delegates the ACK if it is present). However, looking at the code, the smsbox-port parameter is defaulted to 13005 if not present, so this would break backwards compatibility. So, I'm thinking of adding a new config parameter instead - something like run-without-smsbox or sqlbox-generates-ack. Any suggestions or thoughts? Thanks, Toby. -Original Message- From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Tuesday, 10 August 2010 3:56 AM To: 'Nikos Balkanas'; 'Toby Phipps'; users@kannel.org Subject: RE: Life without smsbox True. You have the same smsbox-id for both smsbox and sqlbox. It should be different. But... probably sqlbox isn't going to send an ACK. At least I didn't put it in the code. Maybe someone else. == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Monday, 09 August, 2010 19:07 To: Toby Phipps; 'Rene Kluwen'; users@kannel.org Subject: Re: Life without smsbox I reiterate. SQLbox shouldn't have such an error. Your smsbox-route is not correct, you need to specify smsc-id. Read User's guide about it. You should still be getting that WARNING. Solve that, and you should be set. BR, Nikos - Original Message - From: Toby Phipps toby.phi...@nexmedia.com.sg To: 'Nikos Balkanas' nbalka...@gmail.com; 'Rene Kluwen' rene.klu...@chimit.nl; users@kannel.org Sent: Monday, August 09, 2010 7:59 PM Subject: RE: Life without smsbox Hmm, OK. Interesting. I've reverted to the SVN head of sqlbox and configured the following: group = smsbox bearerbox-host = localhost smsbox-id = sqlbox group = smsbox-route smsbox-id = sqlbox group = sqlbox id = sqlbox smsbox-id = sqlbox bearerbox-port = 13100 bearerbox-host = localhost # smsbox-port = 13200 sql-log-table = smsgw_kannel_sms_result sql-insert-table = smsgw_kannel_sms_queue log-file = /usr/local/kannel/log/sqlbox.log log-level = 0 Now, I see the following in bearerbox.log: 2010-08-10 00:53:11 [1691] [13] DEBUG: boxc_receiver: sms received 2010-08-10 00:53:11 [1691] [13] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:11 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 2010-08-10 00:53:17 [1691] [14] DEBUG: send_msg: sending msg to boxc: sqlbox 2010-08-10 00:53:17 [1691] [14] DEBUG: boxc_sender: sent message to 127.0.0.1 The lines at 00:53:11 are written when the MT is sent out. The lines at 00:53:17 are written when the DLR arrives. And... unfortunately the queuing is back - here's the relevant status output: SMS: received 0 (0 queued), sent 2 (0 queued), store size 4 SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.01,0.01,0.01) msg/sec DLR: received 4, sent 0 DLR: inbound (0.02,0.01,0.01) msg/sec, outbound (0.00,0.00,0.00) msg/sec DLR: 262 queued, using mysql storage Box connections: smsbox:sqlbox, IP 127.0.0.1 (4 queued), (on-line 0d 0h 4m 39s) I still chalk the queuing up to a missing ACK from sqlbox - the following line is missing from the logs: DEBUG: boxc_receiver: got ack When I had smsbox running and calling a dummy URL to get rid of DLRs, that ack would
