+CME ERROR: Operation not allowed

[alexmaron81]

Hi, I have a new error again. What could this be related to?

The first few messages were sent successfully, and the fifteenth were not. It always varies which message causes the problem.

Our device uses the 1nce service and goes to the backend via VPN.

[RobMeades]

Hi Alex: can you remind me again which module type you are using?

I assume that the previous fourteen messages, the ones that were successfully transmitted, were of a similar form, i.e. including commas and quotation marks in the same kind of pattern as the one that failed? I ask because otherwise it looks like just the kind of thing that would fail if the module in question needs a string in that position and is being confused by the presence of the comma.

Assuming the previous fourteen messages that were sent successfully were of a similar form, so the message format is not the issue, a CME ERROR: Operation not allowed is usually caused by an event that preceded the transmission attempt: would it be possible to include that preceding stuff in a log pasted here please?

[alexmaron81]

Hi Rob, we use SARA-R412M 02B-01

This used to work very well. The developers who develop the backend for us have carried out an update and I don't know if that has anything to do with it. RabbitMQ is running on the server with the extension for port 1883

[RobMeades]

Thanks.

This used to work very well.

If this used to work then there can't be an issue with the formatting of the AT command, the commas/quotes etc., the CME ERROR: Operation not allowed must be due to something that happened earlier in the log.

If we take the AT+UMQTTER response at face value then, from A.7.4.1 of the AT manual, 28 means "No MQTT connection when attempting UMQTTC". Is there any sign, earlier in the log, of the cellular or the MQTT connection dropping?

[alexmaron81]

[RobMeades]

The +UMQTTC: 1,3 will be your problem. From section 29.6.2 of the AT manual:

...and from section 29.6.4 of the AT manual:

[philwareublox]

In this case it might be best to disconnect from the broker with +UMQTTC=0 and then try to connect again. This will [hopefully] help the client get its internal state correct and fresh again instead of trying again and again with these stalls/timeouts.

[RobMeades]

Hmmm, actually, there is a flaw in the logic here. Assuming Alex has registered a uMqttClientSetDisconnectCallback() it wouldn't be triggered in this case: for a disconnect the ubxlib code is expecting a +UUMQTTC: 0, x, i.e. a "logout" URC, maybe where x = 101 for connection lost, but good 'ole SARA-R412M, bless its little cotton socks, is sending a "login with failure" URC, +UUMQTTC: 1,x where x is non-zero. A little bit odd, since it had plainly logged in successfully, but still we should handle it. I will make that change and get you to review it @philwareublox.

To be clear @alexmaron81, this won't fix your problem but it may make it easier for you to recover from it.

[RobMeades]

The fix that will detect the +UUMQTTC: 1,x, where x != 0, mode MQTT broker disconnect can be found in commit 2f39e1b03d8ecf1c0735599bed9aafecb0c98a13.

[alexmaron81]

Hi, I have solved the problem. It was due to our second server which was recently copied to the cloud. This created two OPEN VPN clients that both establish a connection. And at some point the message is sent to one of them which actually has no logged in client open.

nevertheless, thank you for the effort, and I hope that the change was not superfluous!?

[RobMeades]

Ah, that's excellent, and indeed the change was a very worthwhile catch, so all is good in the world. Well, this bit anyway :-).

[VincentLePhenix]

Bjr tout le monde, Monsieur alexmaron81, je peux avoir votre code pour tester. J'ai la même erreur depuis plus de 4 semaines. La seule différence je n'utilise pas MQTT, mais ce serait bon d'utiliser. Vraiment cela me fera plaisir. J'envoie des données vers un serveur en ligne en utilisant la commande AT.