SMS send tool does not serialize sends

RouterOS Scripting
1

It appears the SMS send tool does not serialize sends. Meaning if I send three SMS send commands simultaneously, it will not lock the LTE card and some of them are missed. The first one I find works almost every time, after that it is a hit or a miss whether they work or not.

I noticed that the failures seems to be more prevalent if I use the API to send the sms rather than the Mikrotik terminal.

For example, say I create a user account “sms” with password “sms”, and I have the miniLTE at 192.168.0.1 with LTE card at USB3 channel 3, with the recipient’s cell phone being 555-555-5555.
If I run this multiple times with three different phone numbers, the first one will always be received, but the other two are a hit or a miss whether they get the message or not.

/usr/bin/curl -k -u sms:sms -X POST “https://192.168.0.1/rest/tool/sms/send” -H “content-type: application/json” --data ‘{“port”:“usb2”,“channel”:“3”,“phone-number”:“+15555555555”,“message”:“This is a test”}’

I can resolve this by putting an flock around the command with a sleep 1 at the end, however, I have multiple servers that need to send SMS messages, so the flock won’t be effective in these situations, and I need the Mikrotik OS/API to handle the queuing and synchronization of the SMS sends.

Does anyone know a bit about this, and if there’s a way to control this?

2

Here is the debug information, it shows that the lock is released before the final response. This might be the issue.

 2025-03-01 20:39:03 ssh,debug channel #0 peer window consumed: 0x329 left: 0x1016114
 2025-03-01 20:39:07 gsm,debug usb2,3, acquiring port (#=31) started
 2025-03-01 20:39:07 gsm,debug usb2,3: Port acquired
 2025-03-01 20:39:07 gsm,debug usb2,3: Port opened
 2025-03-01 20:39:07 gsm,async usb2,3: sent AT E0 V1
 2025-03-01 20:39:07 gsm,async usb2,3: rcvd OK
 2025-03-01 20:39:07 gsm,async usb2,3: sent AT+CPIN?
 2025-03-01 20:39:07 gsm,async usb2,3: rcvd +CPIN: READY
 2025-03-01 20:39:07 gsm,async usb2,3: sent AT+CNMI=1,1,0,1,0
 2025-03-01 20:39:07 gsm,async usb2,3: rcvd OK
 2025-03-01 20:39:07 gsm,debug usb2,3, acquiring port (#=31) finished
 2025-03-01 20:39:07 gsm,debug usb2,3, sending SMS, AT preferred (#=30) started
 2025-03-01 20:39:07 gsm,async usb2,3: sent AT+CMGF=0
 2025-03-01 20:39:07 gsm,async usb2,3: rcvd OK
 2025-03-01 20:39:07 gsm,async usb2,3: sent AT+CMGS=22
 2025-03-01 20:39:07 gsm,async usb2,3: rcvd
 2025-03-01 20:39:07 gsm,async usb2,3: sent xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 2025-03-01 20:39:08 gsm,async usb2,3: rcvd OK
 2025-03-01 20:39:08 gsm,debug usb2,3, sending SMS, AT preferred (#=30) finished
 2025-03-01 20:39:08 gsm,debug usb2,3: cleanup, stopping portman
 2025-03-01 20:39:08 gsm,debug usb2,3: cleanup, release portman lock        <------------ LOCK RELESED BEFORE FINAL +CMGS MESSAGE
 2025-03-01 20:39:08 gsm,async,event : +CMGS: 73
 2025-03-01 20:39:08 gsm,debug rcvd unsolicited AT for usb2,3: +CMGS: 73      <------------ FINAL RESPONSE FROM SMS AFTER LOCK IS RELEASED
3

I have further troubleshot the issue and found that it is random, but can be coerced to happen almost every time by using certain characters.
However, I found that I could enable MBIM on my LTE card and going through that interface things are working flawlessly.
I found a forum post where the LTE interface used to have these same issues but have been fixed. So this is most likely a PPP-Client interface issue, where it needs the same fixes that were applied to the LTE interface.