That was the decision initially, but due to improvements including bug fixes, added features (e.g. IMSI switching which we are hoping will be added soon), and manufacturing providing units with version 4.6+; we would very much like resolve the issue to allow for updates.
As for the 2 bytes that were sent for disconnection, our MQTT server does receive them and processes the disconnection.
I don’t think that the NO CARRIER is due to the disconnection of server since we are disconnecting from the MQTT server but not from the network yet at that point [though I can’t guarantee anything here]. To my understanding the no carrier error is for when the network connection is dropped.
If I don’t disconnect then the socket times out after a while on the server side, whereas the device side right now current drivers would start getting confused as to the state of the sockets if I start skipping steps like closing the network connection without disconnecting the MQTT server. Is there something in particular that would be good to test here and if so what would be the best approach to it to get the results we’re looking for?