| Keywords: Mode: All keywords (AND) |
|
Fri Jun 28, 2024 21:05
|
keke: The modem header is an informative marking of which modem has processed or received the message.
The selection of the transmitting modem can be made via queues and providers. For example, in a two-modem system, the smsd.conf is like:
...
[queues]
ALL_MODEMS = /var/spool/sms/all_modems
GSM1 = /var/spool/sms/GSM1
GSM2 = /var/spool/sms/GSM2
[providers]
ALL_MODEMS = 0,1,2,3,4,5,6,7,8,9,s
GSM1 = 0
GSM2 = 0
[GSM1]
...
queues = ALL_MODEMS, GSM1
[GSM2]
...
queues = GSM2, ALL_MODEMS
The modem reads the given queues in the given order. This can affect the processing speed in systems with a lot of messages.
The message file is placed in the outgoing folder as usual and equipped with the header Queue: <name>, which causes the message to move to the desired queue.
Specifically, you asked "...try a specific device first?". Queue selection is final, so other modems no longer process the message. If the selected modem fails in transmission, the message is moved to the failed folder, from where the own external process must move it to another queue, for example available to all modems, if so desired.
|
|
Tue Mar 12, 2024 23:21
|
keke: The first thing to note is that not all devices and message centers support status reports.
Second, getting status reports to work, unless it happens on its own, is perhaps the hardest part of setting up an SMS service.
Additional information about the modem is needed, it is printed in the log with the setting report_device_details=yes.
Initializing the modem with the command CNMI is important. With appropriate values, the report may or may not work. The goal would primarily be for the report to be saved in the same memory as other messages. Some devices have dedicated memory (SR) for reports and can be read using the dual memory handler. If the modem does not support memories, it may still route the reports. This is all very device specific and varies a lot.
|
|
Tue Feb 06, 2024 17:39
|
keke: The function you need can be implemented using Providers and Queues. See documentation and examples here: Configuring Providers.
|
|
Sat Nov 25, 2023 03:09
|
keke: Thanks for the clear information.
Add the setting keep_open = no to the modem section. It might solve such a situation.
|
|
Mon Oct 23, 2023 01:23
|
keke:
... how to send a message via the right modem
You need to use queues. In the smsd.conf, define (for example):
devices = modem_1, modem_2
[queues]
ALL = /var/spool/sms/checked
modem_1 = /var/spool/sms/modem_1
modem_2 = /var/spool/sms/modem_2
[modem_1]
device = /dev/modems/modem_1
queues = modem_1, ALL
[modem_2]
device = /dev/modems/modem_2
queues = modem_2, ALL
With these kind of definitions you can select the queue in the message file, using Queue: modem_1 header, for example. If no Queue is defined, the modem which first picks up the message will send it.
The queue names do not have to be the same as the modem names, in the example they are just chosen for clarity.
|
|
Tue Oct 10, 2023 14:47
|
keke: In this case, the naming of the smsd settings may not be as clear as possible. When the device is a socket, the settings that affect it are called socket_connection_alarm_after, socket_connection_errorsleeptime and socket_connection_retries. I don't remember why these were given their own names back in the day. But using these you may make the daemon try endlessly.
However, some possible errors are such that smsd cannot handle them. It would be a good idea to use the alarmhandler feature and monitor what kind of notifications smsd gives in different situations. A situation where smsd does not resolve itself can be solved in a suitable way and, for example, get smsd to restart if necessary.
Parameters of alarmhandler are documented here.
|
|
Mon Oct 09, 2023 17:27
|
keke: Thanks vampomyak for the clear information.
The message center gives hexadecimal letters in lowercase, which is exceptional.
A small addition to the source code is needed to handle this.
Edit the file smsd.c in the src directory.
Search for foundsomething=1 and you will find the following code. It's on line about 3963.
Add the lines highlighted in yellow to the code:
if (found>=0)
{
foundsomething=1;
*quick=1;
// 10/2023: allow lowcase letters from modem:
for (i = 0; line2; i++)
line2 = toupper((int)line2);
//Create a temp file for received message
//3.1beta3: Moved to the received2file function, filename is now a re$
//sprintf(filename,"%s/%s.XXXXXX",d_incoming,DEVICE.name);
//close(mkstemp(filename));
statusreport = received2file(line1, line2, filename, &stored_concaten$
STATISTICS->received_counter++;
Then save, recompile and restart.
|
|
Fri Sep 29, 2023 22:12
|
keke: To be clear, disable the dual memory handler (primary, secondary) at least at this point, as there seems to be no need for it.
The SIM card is full, but it is unclear why the modem gives an error when reading memory locations 0 and 1. You could try how the modem handles other ways of reading messages, see check_memory_method in the user manual and try, for example, the value 4.
It would also be useful to use the setting report_device_details = yes and show what the modem tells after rebooting smsd.
|
|
Fri Sep 29, 2023 16:46
|
keke: The Huawei modem needs this setting for the report to work:
init = AT+CPMS="SM","SM","SM";+CNMI=2,0,0,2,1
If some unexpected input is shown in the log, use this setting too:
init2 = AT^CURC=0
|
|
Sat Aug 12, 2023 20:35
|
keke: It would be useful to see a log file of receiving a message using loglevel=7.
|
|
Fri Jul 28, 2023 21:54
|
keke: In the src/Makefile, change the line:
CFLAGS += -W -Wall
to
CFLAGS += -fcommon
|
|
Thu Apr 13, 2023 02:35
|
keke: Possibly the SIM is slightly damaged or about to break. At this point, I recommend disabling the PIN request. If it is activated on the SIM card, it must be disabled, for example, using the phone. The modem process must be set to not process the PIN code at all: pin = ignore.
The problem should go away this way, but it is very possible that the modem and/or SIM will cause similar "no answer" situations later and in other contexts. You should also browse the log backwards if there are "no answer" situations with other commands. Other problems may have been less visible when the PIN problem is so serious that the process has to be stopped.
|
|
Fri Apr 07, 2023 02:35
|
keke: The general timeout is 5 seconds by default. You can see the value used by a certain function by adding report_read_timeouts = yes to the modem settings, so after restarting you will see the current values in the log. You can change the values with the modem settings read_timeout and read_timeout_XXX.
|
|
Thu Mar 09, 2023 16:04
|
keke: mt and ds are both important. In addition, it is necessary to ensure that the SIM card memory is used in all cases:
init = AT+CPMS="SM","SM","SM";+CNMI=2,0,0,0,0
|
|
Mon Dec 26, 2022 17:24
|
keke: There is no built-in function for this, so the function has to be done with an eventhandler that you have to create yourself. There are no ready-made scripts for this, so I will only describe the main features of the operation:
Use smstools factory settings and add general settings:
failed = /var/spool/sms/failed
eventhandler = /path/to/eventhandler
When the message is processed, smsd calls the eventhandler. When the first parameter is "FAILED", read the header "RetryStart:" from the file (the second parameter). If the header is found, count the time and exit if necessary. If the header is not found, add it with the timestamp to the file. Move the file back to the outgoing directory and smsd will try sending again.
|
|
Sat Dec 24, 2022 14:12
|
keke: That is, when you reboot the system, smsd works for some time without any problems. Later a message is received and then the problems begin.
Your event handler says: "Restarting SMSd service". Whatever is going on there, take it out. There is no need to restart smsd from within the script, nor should you do so.
Smsd should regularly check if there are any extra processes running, and stop if necessary. I don't know why it doesn't work in your case. Anyway, forget about stopping processes with cron, just remove starting new processes.
|
|
Fri Dec 23, 2022 22:08
|
keke: Again, it looks like more than one process is using the modem at the same time. Since you have already fixed a similar situation before, I hope you can fix it now as well. If the smsd startup method is different from the sms3 script, that might be the reason. It would be a good idea to check the log to see how the processes are started.
Your previous log showed that the modem responds with an error message to the command AT+CMGR=20. When there are 20 memory locations, and the number 20 gives "invalid memory index", most obviously the first location is the number 0. This is why a setting memory_start = 0 is required. And if you use a Huawei modem, they also start with the number zero.
|
|
Tue Dec 20, 2022 03:50
|
keke: Use also a modem setting memory_start = 0.
|
|
Mon Dec 19, 2022 17:21
|
keke: Do NOT use vwdial style initialization because it sets the modem to data mode. Use AT+CPMS="SM","SM","SM". Make sure the modem is reset before trying to read the messages.
If you still have problems, show the report_device_details output too.
|
|
Tue Dec 13, 2022 22:47
|
keke: I don't have any new ideas for this.
The log you showed earlier shows some strange things. Smsd wants to make sure that the modem responds to the command AT, and receives a serial number in response. It is the answer to the AT+CGSN command that smsd sometimes asks, but not now. It seems that some other process is asking for the serial number at the same time, possibly another smsd that shouldn't be running at the same time. Then smsd does the initialization, the modem responds with the quality of the signal. The answer is clearly wrong. Then smsd asks about the quality of the signal and gets information about the memory locations of the modem. The same inconsistency is repeated many times in the logs you show.
It strongly seems that the modem is shared by too many processes, or Docker is somehow messing up the communication. All I can do is ask you to do a new test after you have made sure that the modem is not used by any other process (for example, another smsd).
You can also test the modem with the smsd communication feature. First kill all smsd processes and make sure they are killed. Then start smsd with smsd -C GSM0 and send an AT command to the modem. The answer should be OK and nothing else. Then wait with your hands in the air. If the modem reports various things even though they have not been asked in this terminal, it should be clear that there is some other process that is asking them somewhere.
|
|
Mon Dec 05, 2022 02:12
|
keke: At this point the only thing that comes to mind is the modem port. What created the link /dev/ttyUSBmodem and where does it point?
In many cases, Huawei devices create three different ports, only one of which is fully usable with smstools. Do you have more than one port for the modem in your system and if so have you tried others?
Presumably the device is currently not responding at all. If it answers anything, I need to see what kind of communication there has been with the modem. The setting report_device_details exists just for such investigations, so also show the information it reports if the modem reports something
|
|
Thu Nov 17, 2022 14:35
|
keke: Please stop wvdial and any other processes that may be using the modem. Smstools must be the one and only process which uses the modem.
|
|
Fri Oct 21, 2022 20:36
|
keke: The only thing that comes to mind now would be that for some reason the .lock file was not deleted when the message was created. But at least the sensms included in the package does not use the .lock file at all.
Since this problem has apparently happened more than once, I would like to see a listing (ls -l) of the outgoing directory at the moment when the problem is on and smsd has not yet been restarted.
Also the full configuration (smsd.conf) would be useful to see.
If you want to limit the view of the data, you can do it with the Private tag.
|
|
Tue Oct 18, 2022 14:47
|
keke: Maybe you could use this setting: regular_run
Unrelated, but in your configuration, the second init line overwrites the first init setting:
[E160]
init = AT^CURC=0
init = AT+CPMS="ME","ME","ME"
|
|
Tue Oct 18, 2022 14:38
|
keke: In some cases, it is not possible to give all the necessary commands to the modem at once, or it is clearer to give them separately. Because of this, two settings are available, one or both of which can be used.
In addition, there is a "wakeup_init" setting that may be needed with some modems, especially when using telnet. It is sent to the modem at the very beginning. There is a small wait after sending, but the return value is not checked. Most users won't need this.
If init or init2 fails (return value is not OK), the whole operation is aborted.
The maximum length of init strings is 98 characters, or 97 characters when using telnet.
|
