Re: what to do with store.bak file after Kannel crash?

[DHC Admin]

I had a similar problem. I checked that there were no queued messages,
stopped kannel, removed all the store files, started it again and had no
problems since, nor any kind of error, files were just recreated on start
(but small size)



On Thu, Sep 8, 2016 at 5:24 PM, Jeff Thorn 
wrote:

> Hello Group,
>
> I just experienced a very rare crash of Kannel. We are using the following
> settings for store type:
>
> store-type = file
> store-location = /var/log/kannel/msg-store.db
>
> After restarting everything, I noticed a very large (3 GB)
> msg-store.db.bak file.
>
> Kannel took several minutes to start back up after this crash during this
> time the CPU was nearly maxed out. I assume during this time, Kannel was
> processing saved messages from the store file. Is this correct?
>
> What exactly is in the contents of the msg-store.db.bak file? Did these
> messages get handled by kannel or did the database simply get saved for
> backup purposes. Do I need to do anything specifically to handle all these
> messages in the .bak file? Or is it safe to delete now that kannel is back
> up?
>
> Thanks,
> Jeff
>
>

Re: Load balancing MT with preferred SMSC

[DHC Admin]

Of course you have removed the # form those lines, right? Other than that,
I cannot tell why it's not working for you.

On Sat, Sep 17, 2016 at 8:48 AM, Davor Spasoski 
wrote:

> Hi,
>
>
>
> I’m trying to  use opensmppbox and kannel to act as SMPP proxy. The SMSC
> operator doesn’t allow direct connections and it has two SMSCs, one of
> which is preferred and the other handles traffic if only the preferred
> fails. *But, both are always active*, i.e. bearerbox is normally bound to
> both.
>
> I have a dozen of ESMEs that should connect to opensmppbox with a single
> bind and then bearerbox should make two connections to smsc1 and smsc2 for
> each and every esme. To simplify, the flow with one  ESME would look like
> this:
>
>
>
> ___   _
>
> ESME1 --> | Opensmppbox   | --> | Bearerbox |---> |SMSC1|
>
> |   ||   |  -
>
> |___||   |---> |SMSC2|
>
> |___|  -
>
>
>
> For each new ESME there would be a new set of binds from bearerbox to
> SMSCs and the system-id of the esme should distinguish the rotue in
> bearerbox.
>
> Hence, use-systemid-as-smsboxid is set to true in opensmppbox.conf
>
>
>
> At the moment, I have two fake SMSCs with same SMSC-id and they share the
> load as expected. However, no matter what I try with directives like
> preferred-smsc-id and allowed-smsc-id, I can’t make a confgiration to make
> bearerbox route *all MT SMS to SMSC1 only and route to SMSC2 if only
> SMSC1* is down.
>
>
>
> This is part of my bearerbox configuration:
>
>
>
> group = smsc
>
> smsc = fake
>
> port = 12000
>
> smsc-id = vasgw
>
> #allowed-smsc-id = "vasgw"
>
> #preferred-smsc-id = "vasgw"
>
>
>
> group = smsc
>
> smsc = fake
>
> port = 12001
>
> smsc-id = vasgw
>
> #allowed-smsc-id = "vasgw"
>
>
>
> Also, bearebox should accept MO SMS from any of the SMSC1 and SMSC2
>
>
>
> Any ideas how to achieve this?
>
>
>
> BR,
>
> *Davor*
>
>
>
> --
>
> Disclaimer: one.Vip DOO Skopje
> This e-mail (including any attachments) is confidential and may be
> protected by legal privilege. If you are not the intended recipient, you
> should not copy it, re-transmit it, use it or disclose its contents, but
> should return it to the sender immediately and delete your copy from your
> system. Any unauthorized use or dissemination of this message in whole or
> in part is strictly prohibited. Please note that e-mails are susceptible to
> change. one.Vip DOO Skopje shall not be liable for the improper or
> incomplete transmission of the information contained in this communication
> nor for any delay in its receipt or damage to your system.
> Please, do not print this e-mail unless it is necessary! Think about
> saving the environment!
>
> Напомена: оне.Вип ДОО Скопје
> Оваа електронска порака (вклучувајќи ги и прилозите) е доверлива и може да
> биде заштитена со правни привилегии. Доколку не сте лицето на кое таа му е
> наменета пораката, не треба да ја копирате, дистрибуирате или да ја
> откривате нејзината содржина, туку веднаш да ја препратите до испраќачот и
> да ја избришете оригиналната порака и сите нејзини копии од Вашиот
> компјутерски систем. Секое неовластено користење на оваа порака во целост
> или делови од истата е строго забрането. Ве молиме да забележите дека
> електронските пораки се подложни на промени. оне.Вип ДОО Скопје не презема
> одговорност за несоодветно или нецелосно пренесување на информациите
> содржани во оваа комуникација, ниту пак за било какво задоцнување на
> приемот или оштетувања на вашиот систем.
> Ве молиме не ја печатете оваа порака освен ако не е неопходно! Зачувајте
> ја природата!
>

Re: Sending Prioritary SMSs

[DHC Admin]

queue does work as expected, FIFO

you may create a second connection to the same SMSC for priority messages
only, without load balancing between connections.

On Tue, Mar 10, 2015 at 2:34 PM, ha...@aeon.pk  wrote:

> I haven't used fakesmsc. However, try throttling the speed of the
> connection to 1 or 2 SMS/sec.
>
> On Tue, Mar 10, 2015 at 9:55 PM, Manuel García Cabrera <
> mcabr...@contentamobile.com> wrote:
>
>> I'm trying to test it with fakesmsc. Do you know how to simulate a delay
>> in the sending of the message? I'm having a hard time testing it this way
>> because the queue empties way too fast.
>>
>>
>> On 10/03/15 10:35, ha...@aeon.pk wrote:
>>
>> Perhaps I cannot point out the logic of why exactly this happens, since I
>> discovered it only by doing.
>>
>> Also, another way is that if your main bulk is going via SQLBOX, then if
>> you push a message via SMSBOX, it will get higher prio and gets on top of
>> the queue.
>>
>> Plz try it to confirm, since I did it quite long time ago.
>>
>> On Tue, Mar 10, 2015 at 6:28 PM, Manuel García Cabrera <
>> mcabr...@contentamobile.com> wrote:
>>
>>> Really? But wouldn't that mean that it's not actually a queue?
>>>
>>>
>>> On 10/03/15 10:19, ha...@aeon.pk wrote:
>>>
>>> If you insert a new message in the existing queue, it automatically gets
>>> delivered before the queued ones.
>>>
>>> On Tue, Mar 10, 2015 at 6:07 PM, Manuel García Cabrera <
>>> mcabr...@contentamobile.com> wrote:
>>>
 Hi, I'm trying to send prioritary messages when there already are many
 messages queued for sending. Suppose I have on SMSC with a 10.000 message
 queue, and I want the next message I queue to be sent before those 10.000
 messages. Is that possible?


>>>
>>>
>>
>>
>

Re: How can I see the TCP packages of an incoming SMS

[DHC Admin]

If you know a tcpdump would do, why don't you use it? On a linux machine
you would do: tcpdump -w FILENAME.pcap -s 0 host XXX.XXX.XXX.XXX (for
example) then use wireshark software to read the resulting file from the
capture.

Once on wireshark you can search for SMPP params, like phone number.

hope this helps.

On Tue, Sep 20, 2016 at 5:38 PM, Manuel García Cabrera <
mcabr...@contentamobile.com> wrote:

> I have a SIM inside a GSM modem (Portech mv-374), and I need to see how an
> incoming SMS packet is formed. A tcpdump would do, but I don't know how to
> obtain that. Can someone point me in the right direction?
>
>
>

How can I see the TCP packages of an incoming SMS

[Manuel García Cabrera]

I have a SIM inside a GSM modem (Portech mv-374), and I need to see how 
an incoming SMS packet is formed. A tcpdump would do, but I don't know 
how to obtain that. Can someone point me in the right direction?

Re: Response from get URL fails 50% of time

[Peter Janovsky]

Hi Tosin,

If I'm understanding your question, these are the steps I take when
debugging issues with MO messages possibly failing when executing the HTTP
GET/POST against the defined URL. If you've assigned values to the
*log-file* and *access-log* configuration settings for the *smsbox* and
*core* groups then you'll see log statements similar to the following to
help you trace

*core config group access-log setting*
Receive SMS [SMSC:] ...

*smsbox group log-file setting*
Starting to service...

*smsbox config group access-log setting*
SMS HTTP-request ...

These log statements will contain the HTTP response code. If you're heavily
exercising Kannel, it's possible the service responsible for handling the
HTTP requests is failing to keep up. Under the *smsbox* group you can
assign the *http-request-retry* configuration setting which takes care of
retrying the request n times if it fails.

Please note I am simply guessing here as I do not know the specifics
surrounding the failure. Hope this helps.