Operating system name and version: Ubuntu 9.10
Version of smsd: 3.1.6
Smsd installed from: sources
Name and model of a modem / phone:
Interface:

So far I'm very impressed, the only problems I had turned out to be answered in this forum...

what I'd like to do next is test what happens if there is a modem error, or signal quality error etc.

I realise I can do this by putting the modem in a tin box, or pulling out the sim etc but when I 'grepped' the fail_text I'd like to test each one of these.

Is there an approved way of testing the problem situations?

I'd also like to see a more structured 'error' system whereby errors are given codes rather than 'english' reasons - similar to FTP/HTTP where the code can imply whether the failure is because of the message itself (eg no destination) or a 'temporary' or 'local' fault (eg modem). This would mean a valid message that is rejected because of a signal problem could be picked up by another modem or another smsd...

Thanks,

There is no 'error simulation' mode, if this is what you meant.

Have you checked what you can do with an alarmhandler script? It's called every time when something abnormal happens.

I have to think about those error codes. However, usually those kind of codes are not shown in the Unix logfiles. I also cannot change the messages, because it will break existing functionality which is done by the users. Perhaps there could be a setting which defines if codes are used, and this should default to no. Probably an alarmhandler could have one more argument, an error code with the name of a file.

Currently, all possible error messages are not documented in the single list. Probably I will create this kind of a documentation, in the same way as the list of AT-commands has been made. However, some messages come from the modem and cannot be documented comprehensively.

Thanks Keke,

Obviously error simulation is difficult but, like PDU simulation or modem_disabled simulation, it's very useful in seeing how things work together when it's not all ticking over.

I tried the alarmhandler and got some interesting responses:

modem switched off (ie unresponsive) called alarmhandler unlimited(?) times with sev 3, and my reaction to that would be after X times reboot PC in case it's a serial port problem.

modem switched on gave 'modem busy' sev 2 and this was more worrying because 'the modem handler' failed but smsd didn't recover itself, so I'd assume a sev 2 means restart smsd - but I wondered if the alarm handler can do that, or whether it could kill it's PPID (or whatever) and leave upstart/inittab to respawn.

As far as messages go, I did consider this further for my own use - where messages can have a Failure_code where 1xx signifies smsd is faulty and 2xx signifies the modem/network is faulty and 3xx signifies the message itself is faulty - primarily so that 3xx messages won't be retried (eg no destination) and 2xx can be retried on another queue/modem etc etc. I guess 4xx would be unknown problems (like the file has disappeared mid-sending) and 5xx would be succesful...

I wonder if the alarmhandler could cope with an extra argument if the current 3rd one is already optional, so perhaps leave that as-is and put a failure_code in the file.