New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bridge connection to public broker fails because of invalid UTF-8 topic names #1144

krismattheus opened this Issue Feb 4, 2019 · 3 comments


None yet
2 participants
Copy link

krismattheus commented Feb 4, 2019

When testing our mosquitto broker to make a bridge connection to the mosquitto broker, the bridge connection is established but within the same second it's disconnected again.
This only happens when the configuration of our bridge contains:

topic # both 0

When a specific topic is used, the bridge connection remains established.

After some debugging I found that the mosquitto broker contains topics with invalid UTF-8 names (for example 'ÿ' with only one byte = 0xFF). Apparently, a disconnect is forced in handle_publish.c when a PUBLISH message contains an invalid UTF-8 topic.

if(mosquitto_validate_utf8(topic, slen) != MOSQ_ERR_SUCCESS){
return 1;

I think it would be better to just ignore such a topic and continue with the next PUBLISH messages.

Maybe the code in handle_publish.c should be changed to:

if(mosquitto_validate_utf8(topic, slen) != MOSQ_ERR_SUCCESS){
    log__printf(NULL, MOSQ_LOG_INFO, "Dropped PUBLISH from %s because non UTF-8 topic (d%d, q%d, r%d, m%d, '%s')", context->id, dup, qos, retain, mid, topic);
    goto process_bad_message;

We use mosquitto version 1.5.5.
The test was done on Windows 10.


This comment has been minimized.

Copy link

ralight commented Feb 5, 2019

The MQTT spec is pretty clear on the required behaviour here.

If a Server or Client receives a Control Packet containing ill-formed UTF-8 it MUST close the Network Connection [MQTT-1.4.0-1].

The issue at hand is that isn't kept up to date, and so isn't validating UTF-8 strings. It is worth noting that the test server at is going to disappear soon:

@ralight ralight closed this Feb 5, 2019

@ralight ralight reopened this Feb 5, 2019


This comment has been minimized.

Copy link

krismattheus commented Feb 6, 2019

OK. I understand.
However, It would we good to log a message why the connection is closed.
Or at least return MOSQ_ERR_MALFORMED_UTF8 instead of 1 when the topic is invalid UTF-8.
This would greatly simplify diagnosing such a problem.


This comment has been minimized.

Copy link

ralight commented Feb 6, 2019

@krismattheus Agreed, I've just added in a new log message to cover this case.

@ralight ralight added this to the 1.5.6 milestone Feb 6, 2019

@ralight ralight closed this Feb 6, 2019

ralight added a commit that referenced this issue Feb 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment