Hy everybody.
Find my new at driver equipped kannel at
http://tar.gzipped.org/gateway.tar.bz2
(please be a bit patient with my dsl line)
It consists of
* an autoconf patched kannel merged with latest kannel.org CVS
* Alexander Malyshs bb_store.c because of i've experienced problems
with the store files getting erased on restart
* the gwthread_cancel function i've sent to the list earlier
(Stipje, i need that to work arround the condition, that the system
tcdrain call blocks in some cases of deffectie modems... i prefere
leaking kannels over blocking ones not delivering sms'es, I agree
with you that this should be uset with caution.)
* octstr_tokenize to better parse the typical answers of modems
* Verbose kill reason in bb_smsccon.c, smsccon.c, smsccon_p.h to have a
plain text status to have a more transparent status for
administrating the modems, like "pin wrong" etc...
* subdirectory smsc/at/ and various files beyond. I've chosen to do it
that way, because of the original driver already contained 3k lines
of code and was rather hard to overview.
* 3 additional fields in the sms structure:
2 ints to remember previous sending error conditions
1 string with the encoded message, because of re-encoding makes
problems with charset conversions
Functional changes to the AT-Driver:
I've consumed some time reading various at documentation (i.e. from
wavecom and some other portions of the web) checking with minicom how
the modem responds to it... afterwards i've created an array with the
strings and callback functions checking the results, and defines
referencing them (at_commands)
Now the callback function is responsible for examinating the results,
doing error checks, start to decide what to do further if something goes
totaly wrong.
Many of them still just return 'not implemented' because of i didn't
finde any use for them so far.
Over the half of them are fax-commands, which most likely never will be
used, but if doubt, uncomment them and go ahead.
Based on that, i've created at_application, which uses the api on a
higher level, which made it much easier to introduce new features to it.
Interested? Read on:
* detect the modem type in a more advanced manner, because of there are
some better ways than ati... in doubt watch the output of your kannel.
* pin handling. fully examine the feedback the modem gives, to keep
kannel from hammering the pin on the modem till it is locked.
* Modem-boot detection. query the phonebook, to see if the modem is
fully booted and logged on to the network. this was done by just
waiting before, which could fail in many cases.
* call forwarding checking. Anoyed of 'ring's stealing your performance?
kannel now checks, if there is a call-forwarding registered with this
modem, and if not, and configured, registers it with the gsm-network
of your provider.
* Sim Hogging. Receiving messages goes to your sim card by default. if
your modem supports (and actualy knows) the flat memory model (mt) you
might be in luck to get all messages (DLR's are messages) but if not,
you must decide for one. Usually this ends up in missing messages.
Allso sim cards are not that well coping with many read/delete cycles
and you will get 'sim-errors' soon. My solution is to write garbage to
the sim-memory, so the modem won't be able to write them, because of
they are already full, and kannel will find them if read by accident,
and won't delete them.
* Message reading. on first, we read messages with at+cmgl, which just
shows us new messages with their indexes. because of we delete
messages, we just should cope with new ones. but if the number of read
messages is smaler than the number of the ones in memory, we continue
with cmgr slot by slot. (which is slow, but safe)
* Message sending. The handling of the results is much more advanced
now. we don't dumbly hammer the message to the same modem on and on.
some error conditions indicate, that the message might be faulty, some
that the network maybe faulty, some that the modem maybe faulty. The
last case could have caused loss of messages in large scale... A modem
with sim error just responds with 'ERROR' to message-sending, so, the
message just was rejected with the old driver. so the modem would
wasted many messages. Now we bounce the messages back to the kannel
queueing mechanism, which hopefully chooses another modem for the next
delivery attemt, which isn't in that condition, and succesfully sends
the message for us. In some cases, we know that this modem won't send
any more messages without manual interaction of an administrator, so
we make the smsc die, which causes the queue to be emtied and appended
to other queues. I know, that this behaviour is not expected to be
made by an smsc, but it was the most logical way i found. Maybe kannel
should be able to switch for a blocked mode here? but i'm shure that
the actual behaviour is much better than loosing messages, and smsc's
blocking, stopping kannel from beeing able to be shut down cleanly.
All messages are written in plain text to the logfile. This is realy
needed to determine, which message actually really got sent by kannel,
and which one failed.
* Blocking io workaround. The system call 'tcdrain' waits for all data
being actually send to the serial device by the kernel. In some cases
the modem blocks, and doesn't drop the DTR line, which makes the
tcdrain call never return, the kannel child blocks. the messages get
stuck in its queue, and more messages get queued, if the others have
less messages. My solution to this is to have another thread, which
just sleeps most of the time. if the kannel wants to tcdrain, it just
wakes up that thread, and threadsleeps itself. if it awakes by itself,
the tcdrain call is assumed to be blocked. if not, it will be awoken
by the other thread after tcdraining. In case of fail, any further
communication with the modem is ridiculus. so the sms just may go
dead.
* Health checking. Check battery/charge state, and SWR state. if SWR
goes to 99, the sim is faulty. the smsc will die in that case. Health
check is invoked every 10 keep-alives, or by some failed CMGS call.
* most error conditions are reported through the VerboseKillReason, to
ease administration.
Things which still need to be done / where already done by the old
driver:
* CDSI configuring/handling with the modem device. I need to check if
that is usefull, and how it works.
* multiple message sending with one at command (we didn't use that so
far. i have no experiences with that, how it performes under heavy
load. i think, this should be done with multi-messages)
I don't know, if i clean up octstr's in any case, i think that should be
checked. Allso i don't know, if i really take care of all kannel
specialisms, or if there are better solutions to that problem.
The actual version is under production in my company atm. Actually we're
experiencing trouble with the HTTP inbound connection not being closed.
I've tried to work arround that configuring CURL sending HTTP/1.0, and
doing timeouts. I've seen, that the message gets delivered though.
I've attached sample config files in the example directory.
I should update the config too, if it is included to kannel.org, please
tell me when and how to handle that.
Any comments / suggestions are welcome.
Sincerely,
Wilfried Goesgens
