Mosquitto 6.1.x with mosquitto-go-auth spams "error: received null username, ..."

[igogold]

Describe the issue you are experiencing

After upgrade Mosquitto add-on to 6.1.1 I've got a spam in add-on's log with a line:

error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check

I enabled debug output for mosquitto and found after a message from one of external devices I always got this error. Second devices with the same bridge configuration works well. There are two lines in the debug mode:

1651663393: Received PUBLISH from wirenboard-A4JBKLBD.wb2hass (d0, q1, r1, m26535, 'wb1/devices/power_status/controls/Vin', ... (5 bytes))
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
1651663393: Sending PUBACK to wirenboard-A4JBKLBD.wb2hass (m26535, rc0)
1651663393: Received PUBLISH from wirenboard-AHL3GFZO.wb2hass (d0, q1, r1, m54105, 'wb2/devices/wb-msw-v3_115/controls/Current Motion', ... (2 bytes))
1651663393: Sending PUBACK to wirenboard-AHL3GFZO.wb2hass (m54105, rc0)

It's interesting I anyway got the data to 'wb1/#' topic, but also have a huge spam as I have continuous flow of data especially from wirenboard-A4JBKLBD.wb2hass ('wb1/#').

I found this error text in the mosquitto-go-auth plugin sources but see no reason to get this message as have no difference between device with 'wb1/#' and one with 'wb2/#' messages.

I've tried to add usernames for mqtt clients in the add-on config, before I used HA accounts. mosquitto spams the error anyway.

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Which add-on are you reporting an issue with?

Mosquitto broker

What is the version of the add-on?

6.1.1

Steps to reproduce the issue

1. Upgrade add-on to 6.1.1
2. Wait client connected.
3. Read spam in the log.

Anything in the Supervisor logs that might be useful for us?

No response

Anything in the add-on logs that might be useful for us?

No response

Additional information

No response

[mdegat01]

Do you use the tasmota integration by any chance?

[igogold]

No, i don't have tasmota integration

[mdegat01]

Hm ok. Was chatting with another user seeing something similar from tasmota so I figured I'd ask. Do you know which device/integration/application is trying to publish those messages which causes those errors? If so can you link so I can look at how it is connecting?

[igogold]

I have two smart controllers Wiren Board with debian9 based system and some custom services. MQTT is the main message bus on the controller. It's also mosquitto used as MQTT broker, version 1.4.15 (with some modification, sources on GitHub). The settings on both controllers are the same (just topic names are differ), but messages from one of controllers have no issues, while from another produce errors.

Settings of mosquitto from "buggy" controller:

mosquitto.conf

# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid

persistence true
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

include_dir /etc/mosquitto/conf.d

conf.d/bridge.conf

#see bridge.conf.example for the example

queue_qos0_messages true
max_queued_messages 10000

connection wb2hass
address my.public.name
keepalive_interval 120

topic /devices/#  both 2 "" wb1
topic homeassistant/#  out 2
topic zigbee2mqtt_wb1/#  both 2

username user
password pass

On Mosquitto HA add-on side settings are default. Just added HA user for authorization.

[mdegat01]

So you shouldn't have to do this but if you uninstall and reinstall the addon what happens? Does that fix the error? In chatting with another user about this I'm getting the impression there is something cached about auth that's creating issues with the acl check. I'm working on adding some debug logging to help but after reinstalling they were able to eliminate the error.

[cogneato]

I was also experiencing this issue and found that it was due to retained or cached but unavailable mqtt entities which were being pulled in to the mqtt integration. I removed both the add-on and the mqtt integration, rebooted, and then installed the add-on and mqtt integration and the errors stopped appearing.

[tayanov]

im use espurino https://github.com/espruino/EspruinoHub project. it can't connect with mosquitto too? after upgrade

[igogold]

if you uninstall and reinstall the addon what happens? Does that fix the error?

Well, I uninstalled addon, restart HA core, installed addon back and reconfigured MQTT integration (wrote new password for 'homeassistant' user). Connection to addon's mosquitto server works well but there is nothing about new connections in the addon's log. Is it cached somewhere in the docker container? All I see in the log for now is:

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] mosquitto.sh: executing... 
[12:16:26] INFO: Certificates found: SSL is available
[cont-init.d] mosquitto.sh: exited 0.
[cont-init.d] nginx.sh: executing... 
[cont-init.d] nginx.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[12:16:26] INFO: Starting NGINX for authentication handling...
[12:16:27] INFO: Starting mosquitto MQTT broker...
1651734987: Loading config file /share/mosquitto/tuning.conf
1651734987: Warning: Mosquitto should not be run as root/administrator.
[12:16:28] INFO: Successfully send discovery information to Home Assistant.
[12:16:29] INFO: Successfully send service information to the Supervisor.

It's about 1 hour from addon start, 3 external clients connected since (and also internal from HA integration).

It the addon /etc/mosquitto/mosquitto.conf has such lines:

...
log_dest stdout
log_type error
log_type warning
log_type notice
log_type information
...

But now there is no spam from mosquitto-go-auth, it's good! :)

[mdegat01]

@tayanov From the installation notes for espurino:

On non-Raspberry Pi devices, Mosquitto (the MQTT server) may default to not allowing anonymous (un-authenticated) connections to MQTT. To fix this edit /etc/mosquitto/conf.d/local.conf and set allow_anonymous to true.

Seems like this software requires anonymous connections be allowed on the broker to function. I don't know why they would make it this way but this won't work anymore. Anonymous connections were supposed to be disabled a while ago with #2007 but apparently there was a bug that still allowed them. Now they are actually disabled in the latest version because Mosquitto came to the same conclusion we did: allowing anonymous connections is a bad security practice.

You can enable this for yours by using the customize option to set allow_anonymous true on your broker. But really you should ask that software to support providing login credentials for the broker with the MQTT connection details.

[mdegat01]

So to summarize for anyone coming here facing this issue. I'm gathering that its somehow caused by old retained messages on the broker sent by software you don't use anymore but used to. Particular software that supported Home Assistant discovery as those messages are always posted with retain: true. Retained messages don't expire FYI so if you've installed and uninstalled things that use MQTT in the past you probably have some hanging around.

I don't really know why this is as I'm not familiar enough with the internal workings of Mosquitto. I would guess some part of the credentials used to post the message are cached in these somehow but I'm really not sure.

The simple fix appears to be this: 1) Uninstall and reinstall the MQTT addon 2) Update the connection details and credentials for the MQTT integration in HA

You might be able to fix this without an uninstall if you connect to the broker with something like MQTT Explorer and specifically delete the stale retained messages. But you'd have to know which ones were stale and I'm not certain this will work as so far all users have gone the uninstall and reinstall route.

Sorry about this. Wish I knew more about why exactly this happens but at least the solution is fairly simple.

[JohanBraeken]

@tayanov From the installation notes for espurino:

On non-Raspberry Pi devices, Mosquitto (the MQTT server) may default to not allowing anonymous (un-authenticated) connections to MQTT. To fix this edit /etc/mosquitto/conf.d/local.conf and set allow_anonymous to true.

Seems like this software requires anonymous connections be allowed on the broker to function. I don't know why they would make it this way but this won't work anymore. Anonymous connections were supposed to be disabled a while ago with #2007 but apparently there was a bug that still allowed them. Now they are actually disabled in the latest version because Mosquitto came to the same conclusion we did: allowing anonymous connections is a bad security practice.

You can enable this for yours by using the customize option to set allow_anonymous true on your broker. But really you should ask that software to support providing login credentials for the broker with the MQTT connection details.

Is it still possible to explicitely allow anonymous access to the MQTT broker? I use a mix of authenticated and unauthenticated clients and have setup specific ACLs for anonymous access.

However, after updating to 6.1.1 I no longer can get anonymous access working. #2007 says: "Support for anonymous logins has been removed", not that it is now disabled by default.

[alastaid]

Hi, I am experiencing the same issue, have multiple devices, connecting from: room-assistant, tasmota and pisomfy these all work, however I have some dotnet containers I coded using mqttnet library and these are all failing on authentication now. I have removed, re-installed the add-on and the integration, but it is still failing. The containers fail with " (Connecting with MQTT server failed (NotAuthorized).)" and there is an error in the mosquito add-on log of "error: received null username or password for unpwd check". Just realised I can roll back with a Hassio backup, I have gone back to 6.0.1 and it all works

[alastaid]

Just to update, and hopefully this may help, I forgot to uncheck the auto update so after rolling back it updated overnight and it broke again. After spending a bit of time going through code, I had been using the .WithUserProperty("username","password") as part of the MqttClientOptionsBuilder from the mqttnet library, instead I used the .WithCredentials("username","password") and it now works.

[mdegat01]

@JohanBraeken Yes the intent of that PR was actually to remove anonymous logins but as I noted it didn't actually remove that support until this release. This was a mistake that turned this one into a breaking change but the intent all along was to remove a security issue.

That being said if you really want to use anonymous logins you should be able to using the customize option. This option lets you customize your mosquitto configuration file with additional options not in the addon config. Using this you should be able to add allow_anonymous true. If you're using ACLs then you're already using this option, just add an extra line to the config customizations.

[glennswest]

So a device needs to know the ip address of the ha, the user name, and the password, then the device can be "autodiscovered", if you have a fleet, then they need to do this via dhcp.

[monxas]

I'm still getting this error on 6.1.2, is there a fix planned for this? I'm not sure i understand the workarounds in the chat, and I can't go back to an old backup since it's a fresh home assistant

[sanderlv]

I ended up here also:

s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] mosquitto.sh: executing... 
[14:21:46] INFO: Setting up user mqtt
[14:21:46] INFO: SSL is not enabled
[cont-init.d] mosquitto.sh: exited 0.
[cont-init.d] nginx.sh: executing... 
[cont-init.d] nginx.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[14:21:46] INFO: Starting NGINX for authentication handling...
[14:21:47] INFO: Starting mosquitto MQTT broker...
1656937307: Warning: Mosquitto should not be run as root/administrator.
[14:21:47] INFO: Successfully send discovery information to Home Assistant.
[14:21:47] INFO: Successfully send service information to the Supervisor.
1656937307: mosquitto version 2.0.11 starting
1656937307: Config loaded from /etc/mosquitto/mosquitto.conf.
1656937307: Loading plugin: /usr/share/mosquitto/go-auth.so
1656937307:  ├── Username/password checking enabled.
1656937307:  ├── TLS-PSK checking enabled.
1656937307:  └── Extended authentication not enabled.
1656937307: Opening ipv4 listen socket on port 1883.
1656937307: Opening ipv6 listen socket on port 1883.
1656937307: Opening websockets listen socket on port 1884.
1656937307: mosquitto version 2.0.11 running
1656937307: New connection from 127.0.0.1:45376 on port 1883.
1656937307: Client <unknown> closed its connection.
1656937307: New connection from 192.168.1.142:55399 on port 1883.
1656937307: New connection from 192.168.1.112:32903 on port 1883.
1656937307: New client connected from 192.168.1.142:55399 as 7bf6VdygeJfs6nz31T2gZ5 (p2, c1, k60, u'mqtt').
1656937308: New client connected from 192.168.1.112:32903 as frigate112 (p2, c1, k60, u'mqtt').
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
1656937315: New connection from 192.168.1.166:57350 on port 1883.
1656937315: New client connected from 192.168.1.166:57350 as double-take-a49fff2e (p2, c1, k60, u'sander').
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
1656937315: New connection from 192.168.6.9:53904 on port 1883.
1656937315: New client connected from 192.168.6.9:53904 as VENTILATION_GATEWAY_0 (p2, c0, k10, u'mqtt').
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
1656937319: New connection from 192.168.1.142:56690 on port 1883.
1656937319: New client connected from 192.168.1.142:56690 as nodered_7da49238b659b9c4 (p2, c1, k60, u'mqtt').
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rlust]

Also having this issue!

[rlust]

I added allow_anonymous: true and still getting same errors.

error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check
error: received null username, clientid or topic, or access is equal or less than 0 for acl check

[jbrepogmailcom]

I have this issue on HAOS but cannot find config file. It is nowhere..

[kaciker]

Hm ok. Was chatting with another user seeing something similar from tasmota so I figured I'd ask. Do you know which device/integration/application is trying to publish those messages which causes those errors? If so can you link so I can look at how it is connecting?

HI, can you tell me please what about this realtion between this problem and Tasmota ?? I have arround 40 devices in Tasmota, and I havce this problen in my mosquitto server as well. Thanks

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[carlos1oliveir]

I upgrade my HA to last version today and actually i have this issue. 1 of my 6 mqqt equipaments stops working. It's possible to listen all in mosquitto broker but 1 of 6 equipment doesn't show on equipments list

[Wupsman]

I removed both the add-on and the mqtt integration, rebooted, and then installed the add-on and mqtt integration and the errors stopped appearing.

mdegat01, thank you for the tip, it solved the problem for me and I only de- and reinstalled the add-on mqtt.