Is your feature request related to a problem? Please describe.
The connect Paho C internal errors (Async client) can be translated to string for easy logging with MQTTAsync_strerror(int code)(MqttAsync.c). This allow to get a readable error on rc returned by the connect method. Those errors are negative int values.
But on connect completion (CONNACK reception), some CONNACK protocol errors (described with reason string in MQTT3.1.1 ) can be uploaded that come from the connack->rc. Those error code are protocol errors ) and they are positive integers (0-5). But such protocol errors (>0) are not handled by the MQTTAsync_strerror() or by another method (AFAIK, I may be wrong but I did not find such), and the existing method MQTTAsync_strerror() would output them as "Unknown error code".
Describe the solution you'd like
May it be possible to add the (MQTT v3.1.1) CONNACK errors in a connect() completion error translation method ?
There are also 3 SUBACK protocol errors. Note that the MQTT v5 reason codes are handled in their own method and they seem to contain the SUBACK protocol errors.
Is your feature request related to a problem? Please describe. The connect Paho C internal errors (Async client) can be translated to string for easy logging with MQTTAsync_strerror(int code)(MqttAsync.c). This allow to get a readable error on rc returned by the connect method. Those errors are negative int values.
But on connect completion (CONNACK reception), some CONNACK protocol errors (described with reason string in MQTT3.1.1 ) can be uploaded that come from the connack->rc. Those error code are protocol errors ) and they are positive integers (0-5). But such protocol errors (>0) are not handled by the MQTTAsync_strerror() or by another method (AFAIK, I may be wrong but I did not find such), and the existing method MQTTAsync_strerror() would output them as "Unknown error code".
Describe the solution you'd like May it be possible to add the (MQTT v3.1.1) CONNACK errors in a connect() completion error translation method ? There are also 3 SUBACK protocol errors. Note that the MQTT v5 reason codes are handled in their own method and they seem to contain the SUBACK protocol errors.