Hi, We are now in SMPP 5.0. This affects versions earlier than 3.4. Sure it has ocuppied some people in the past, but given that it affects an almost obsolete SMPP version, it wouldn't make much sense to change the code just for that. However, it sounds nice to update the manual. Are you up for it?
BR, Nikos ----- Original Message ----- From: shaded 4 To: [email protected] Sent: Monday, May 25, 2009 5:14 AM Subject: Re: Messages intermittently getting stuck in kannel's queue Thanks to everyone for their replies! Ok, so the consensus seems to be that this is a bug in kannel, and that it still exists in the latest version. We connect to a number of different SMSC's, so for each one I have now split them up as you have suggested - I have made a separate section for the transmitter port, and a separate section for the receiver port (see below). So this workaround now involves a lot of duplicated data, but if it works and doesn't have any other side effects, then all is good. So far at least, I haven't seen any problems with this configuration - I expected that kannel might barf if it has multiple definitions for "smsc-id = SMSC7" and multiple things writing to the same log file, but it seems ok thus far. One nagging thought in my mind - this seems to be a rather fundamental bug that I would expect a lot of people would have run across. Not sure why they haven't - is it because SMSC's don't go down very often? Should this bug be documented prominently in the kannel user's guide so that people are aware of it? I couldn't see it documented anywhere, though maybe I missed it somehow. Here for example is how I have split up the configuration for SMSC7 into separate port and receive-port sections. I hope I've done it correctly. group = smsc smsc = smpp smsc-id = SMSC7 host = x.x.x.x port = 1000 smsc-username = .... smsc-password = .... system-type = smpp address-range = "" keepalive = 0 log-file = "/log/kannel/smsc7.log" log-level = 0 msg-id-type = 0x01 throughput = 25 allowed-smsc-id = SMSC7 group = smsc smsc = smpp smsc-id = SMSC7 host = x.x.x.x receive-port = 1000 smsc-username = .... smsc-password = .... system-type = smpp address-range = "" keepalive = 0 log-file = "/log/kannel/smsc7.log" log-level = 0 msg-id-type = 0x01 throughput = 25 allowed-smsc-id = SMSC7 Thanks again to everyone! It's great to get a bit of certainty back. _______________ 2009/5/20 Nikos Balkanas <[email protected]> Hi, It is a bug even now, AFAIK. Unfortunately not easy to correct, and only for outdated SMScs. Tranceiver mode means that you can use a single connection for sending and receiving. Depends on your SMSC's SMPP version. It is not supported earlier than SMPP 3.4. The bug is due to the fact that one status is used internally to describe the SMSc. It can be either "inactive' or "active". Assume that the send link goes down and cannot send any SMS. SMSc is marked momentarily "inactive". Normally this should be it, and kannel would try to reconnect. However the receive link, receive an enquire-link packet, which resets the SMSc status as "active". Therefore kannel doesn't try to reconnect. BR, Nikos ----- Original Message ----- From: Donald Jackson To: shaded 4 Cc: [email protected] Sent: Friday, May 15, 2009 9:15 AM Subject: Re: Messages intermittently getting stuck in kannel's queue This is a bug in 1.4.1, I can't remember the exact details but its to do with the one of the 2 binds dropping. The solution to this problem is, if you have an smsc group with a tx/rx pair like: # TX/RX pair group=smsc smsc=smpp host=smpp.host.com port=2345 receive-port=2345 smsc-id=mysmsc ... You can split it into 2 SMSC's, like: # TX group=smsc smsc=smpp host=smpp.host.com port=2345 smsc-id=mysmsc ... # RX group=smsc smsc=smpp host=smpp.host.com receive-port=2345 smsc-id=mysmsc ... Hope this helps, Thanks, Donald http://www.ddj.co.za 2009/5/15 shaded 4 <[email protected]> Thanks very much for your reply, Abdulmnem! I don't think that's the problem in this case. From what I can tell from the logs, kannel successfully binds to both the transmitter and the receiver streams, and it shows apparently successful enquire_link/enquire_link_resp messages going in both directions, every 30 seconds for each stream. (E.g. enquire_links for the transmitter at 4:30:03, 4:30:33, 4:31:03, etc and for the receiver at 4:30:11, 4:30:41, 4:31:11, etc. ) Any other suggestions from anyone? Although I think the problem lies elsewhere, can anyone else verify Abdulmnem's suggestion that this might be some bug in v1.4.1 ? Has it been fixed in the more recent versions? From http://kannel.org/news.shtml, I can't tell if it lists this problem. I know in our environment it's a lot of work and bureaucracy to upgrade versions of software, so I don't want to do it unneccessarily. Pardon my ignorance, but does 'transceiver mode' mean that it would connect to both the transmitter/receiver streams via a single connection? We have always been using separate transmitter and receiver connections, as the SMSC support team has told us in the past to do it this way and to not use the transceiver mode (I'm not sure why - I have no experience with SMSC's directly). But we don't need the receiver on this particular SMSC, and I have now disabled it. I'm not really confident that this will fix the problem, but we'll see. In any case, it certainly won't hurt. Monim Benaiad wrote: -------------------------------------------------- > Hi, > > Is there any known problem in kannel such that it sometimes > refuses to send messages? (I'm talking about just transmitter > functionality here, not receiver.) > It seems to happen sometimes after connectivity to a SMSC is > disrupted and reconnected. > > The only way that kannel eventually sends the messages > is if I restart kannel, or after it again loses and regains > connectivity the next time. > ...etc. > AFAIK, The "transceiver-mode" variable in the smsc group will solve this problem. I think it's a bug in that version, because Kannel reconnect the receiver only. also remove the "receive-port". TIA Abdulmnem Benaiad Almontaha almontaha.com shaded4 wrote: -------------------------------------------------- Hi, Is there any known problem in kannel such that it sometimes refuses to send messages? (I'm talking about just transmitter functionality here, not receiver.) It seems to happen sometimes after connectivity to a SMSC is disrupted and reconnected. The only way that kannel eventually sends the messages is if I restart kannel, or after it again loses and regains connectivity the next time. We have been using kannel 1.4.1 for years. According to http://kannel.org/news.shtml, it's a stable version which has been out for some years before the very recent newer versions. I haven't seen this problem in production before (maybe because connectivity to the SMSC's is rarely disrupted there), but we have noticed it in our test environment where disruptions are more common. What seems to happen: - Kannel is working fine, sending messages to the correct SMSC's exactly as expected. So apparently we have it configured correctly. - Connectivity to the SMSC's is temporarily lost for whatever reason. E.g. network connectivity slowness or outage, etc. - When network connectivity is restored, kannel automatically reconnects (re-binds, if that's the correct terminology). No problem so far. That's all ok, but sometimes any future messages targeted to some particular SMSC (e.g. call it SMPP_SMSC1) now get stuck in kannel and refuse to budge. Messages to other SMSC's still go through ok. This is what I observe when I try to subsequently send 17 messages to kannel which in normal circumstances always correctly route to SMPP_SMSC1. I have all of kannel's logs enabled to maximum verbosity, i.e. log-level=0 . - I see the messages go into kannel's store-file and not budging. - The messages appear in smsbox's access-log and log-file, but they do NOT appear (yet) in the 'core' group's access-log . - Kannel and the SMSC are constantly sending enquire_link and enquire_link_resp messages every 30 seconds, which show that the connection is supposedly constantly active during this time. - Running kannel's status snapshot (i.e. http://127.0.0.1:13000/status) shows the general SMS section reporting that there are 17 messages in the queued store, but the SMPP_SMSC1 line shows 0 queued messages. (Shouldn't that say 17 as well??) -------------------------------------------------------------------- SMS: received 95 (0 queued), sent 12626 (17 queued), store size 17 SMSC connections: SMPP_SMSC1 SMPP:x.x.x.x:n/n:username1:smpp (online 74534s, rcvd 0, sent 2615, failed 0, queued 0 msgs) SMPP_SMSC2 SMPP:x.x.x.x:n/n:username2:smpp (online 83104s, rcvd 5, sent 21, failed 0, queued 0 msgs) ....etc. -------------------------------------------------------------------- - The 'core' group's log-file shows kannel going through all of the 17 messages every 30 seconds, but frustratingly I can't find anything in any log file telling me WHY it's not sending the messages. Can anybody tell me what is the significance of the rightmost numbers on each line. E.g. 0x9a59e28 appears on each line - what does that mean? What does "0x9a96ba0 vs 0x9a59e28" mean? Are the message having too much fun playing soccer games against each other? 2009-05-14 12:57:09 [29629] [23] DEBUG: sms_router: gwlist_len = 17 2009-05-14 12:57:09 [29629] [23] DEBUG: sms_router: handling message (0x9a59e28 vs 0x9a59e28) 2009-05-14 12:57:09 [29629] [23] DEBUG: sms_router: handling message (0x9a96ba0 vs 0x9a59e28) ....etc. 2009-05-14 12:57:09 [29629] [23] DEBUG: sms_router: handling message (0x9a5c370 vs 0x9a59e28) 2009-05-14 12:57:09 [29629] [23] DEBUG: sms_router: handling message (0x9a59e28 vs 0x9a59e28) 2009-05-14 12:57:09 [29629] [23] DEBUG: sms_router: time to sleep 30.00 secs. The only thing that causes these messages to be eventually sent is: - If I manually restart kannel. - Or if there is another temporary disruption to the SMSC connectivity, and then kannel automatically reconnects (re-binds). As soon as that happens, kannel immediately sends all of the stuck messages to the correct SMPP_SMSC1. It is also only at this time that these messages are logged in the 'core' group's access-log . So why were the messages stuck in the first place? If the enquire_link and enquire_link_resp messages show that link is supposedly constantly up during this time, why is kannel holding on to these messages? Two things I can think of: a) I found a bug in kannel, e.g. some component of kannel might think that the link is still down. b) *Something* might be telling kannel that the link is not really up or not healthy or something?? I don't know. Should I be looking for something special in the enquire_link messages, or in the initial bind messages perhaps? I can post logs if that helps. What also puzzles me is that we have a lot of SMSC's configured in our kannel, but the problem most often seems to occur with messages that we want to route to SMPP_SMSC1. I _think_ it may have also happened with some of the other SMSC's, but I'm not sure. What's slightly special about SMPP_SMSC1 is that it is our 'default' SMSC. All of our other SMSC's like SMPP_SMSC2, SMPP_SMSC3, etc. have a config like the following. The allowed-smsc-id line means that only messages specified with 'smsc=SMPP_SMSC2' will go through SMPP_SMSC2 for example. group = smsc smsc = smpp smsc-id = SMPP_SMSC2 host = .... port = .... receive-port = .... smsc-username = .... smsc-password = .... system-type = smpp address-range = "" keepalive = 0 log-file = .... log-level = 0 msg-id-type = 0x01 throughput = 25 allowed-smsc-id = SMPP_SMSC2 alt-charset = ASCII But SMPP_SMSC1 is our default SMSC. So it will accept messages which specify one of - smsc=SMPP_SMSC1 - smsc=jfdkljgltjhgtjljkgflkj (any rubbish value) - No smsc setting The denied-smsc-id line ensures that other messages can't pass through this SMSC. group = smsc smsc = smpp smsc-id = SMPP_SMSC1 host = .... port = .... receive-port = .... smsc-username = .... smsc-password = .... system-type = smpp address-range = "" keepalive = 0 log-file = .... log-level = 0 msg-id-type = 0x01 throughput = 25 denied-smsc-id = SMPP_SMSC2;SMPP_SMSC3;SMPP_SMSC4;SMPP_SMSC5;.... alt-charset = ASCII Yes, all this normally works exactly as I expect. So the messages aren't getting stuck due to some misconfiguration as far as I know, but they get stuck intermittently. -- Donald Jackson http://www.ddj.co.za/ donaldjster(a)gmail.com
