I upgraded from 6.0.2 to 6.1.2 and a non-ha mosquito broker (not client) no longer can create a connection to the mosquito broker in ha.
I do have a username/password configured, I have seen those notes.
Separate devices as clients (e.g. esphome) connect fine (with that same username/password).
The other mosquito server, which is on a different subnet (is that relevant?) is failing:
1652575861: Client TelescopeWeather disconnected.
1652575863: Connecting bridge (step 1) ha (192.168.132.254:1883)
1652575863: Connecting bridge (step 2) ha (192.168.132.254:1883)
1652575863: Connection Refused: not authorised
I rolled back to 6.0.2 with no other changes and it started working again, so this is definitely a change in 6.1.2.
I looked through the description of changes and did not notice anything that seems relevant, other than the comment about anonymous connections (which this is not), and a new authorization component (but I did not customize anything so would not expect that to matter).
The password in the mosquito server is configured as a password file, e.g. it shows:
allow_anonymous false
autosave_interval 10
password_file /etc/mosquitto/conf.d/pwd
connection ha
address 192.168.132.254:1883
topic homeassistant/# out
topic telescope/# out
and then I have a pwd file with an encoded password. Which is correct since it works with 6.0.2.
The mosquito installed is on a rPi and is 1.5.7 (latest in the distro).
Did something change in the authorization that it can’t properly interpret prior version authorization requests?
The authorization plugin changed. It was previously using this fork of this auth plugin which has been archived for some time and was never updated to work with mosquito 2.0. It now used mosquito go auth which does work with mosquito 2.0 and is recommended by eclipse in the mosquito doc.
That being said, as long as clients of your broker are using credentials that are either listed as local logins in the addon config or are credentials for users in HA they should still work. If you were using some other mechanism to authenticate with the addon via the customize option then it’s definitely possible something broke and you’ll have to compare the two auth plugins I suppose.
I am not sure I know enough to answer the question. The main difference I see is that I am using a bridge configuration from another mosquito broker and not a mosquito client. That bridge configuration is defined in the config file and uses an (encrypted) password file. From a brief read of various documents, I do not see a format that can use an in-the-clear password the same way it is done for clients. Whether this uses a different path through the authorization plugin I do not know.
But this is a vanilla broker/bridge setup, there is no code customization, not addons or plugins in use that are not part of the main distro (and it is from the distro not built from source).
Again – after the (ha) mosquito upgrade, all mqtt clients worked fine for me, it is only the bridge configuration that is failing.
Is there some specific info I can provide? Other than the password file itself, the complete bridge configuration is in the OP. It’s very vanilla, though I have no idea how many people might use a secondary broker in HA.
Sorry I’m not really sure. I’m not an expert in mosquito at all. The customize option is available in the addon but in truth it’s only partially supported. It’s supported in the sense that we ensure your customizations continue to apply but it’s impossible to guarantee everyone’s specific customizations continue to work every release. Mosquito has many many options and it’s totally separate software maintained by others so we can’t possibly test everything people could do in customization.
In general I’d actually recommend deploying your own broker as a separate docker container over heavy usage of customization with the addon. But it sounds like you already have another broker deployed. Out of curiosity what’s the advantage to using the addon in that case? Why not just have HA and everything else talk directly to that other broker?
EDIT: oh, one thing that could help, I added a debug option in 6.1.2. Add debug: true to your config and the addon will spit out debug level logs for both mosquito and the mosquitto-go-auth plugin.
I do not understand why you keep saying “customization”. To my knowledge I am customizing nothing. Or if I am, can you hint where and how, as I do not intend to customize anything.
As to rationale as background:
I have a telescope setup that includes a weather station. This whole setup is sometimes used in my back yard, and sometimes used at remote, non-networked dark sites. The weather station collects data and pushes it into a self-contained mosquito broker (i.e. all this is in a Raspberry Pi with a bunch of physical sensors hanging from it); the telescope system itself (a separate Windows PC) consumes that data for its own use as a mosquito client (controlling dew heaters, recording wind into data collected, detecting rain to do a safety-park on the mount). All this is self contained and not related to Ha.
When all this is used in the back yard, however, I want to get a copy of that sensor data so I can “see” it from inside at my computer, so the weather station mosquito broker just establishes a bridge (which is effectively a replicated copy) to the Ha instance and pushes all the same data to Ha.
The Ha version is unchanged – there is ZERO configuration on the Ha side for this, other than its normal auto-discovery of properly named sensors. To Ha this looks like any other sensor data when received.
But the connection for the weather broker to send it, despite including authentication information, is being rejected.
The whole setup is off and in the house right now, I need to get it outside and powered and will try to get debug info.
Oh I’m sorry I misunderstood. I thought that snippet of mosquitto config was being handed to the addon via customize, I didn’t realize that was for the other broker.
So in that case I would’ve expected it to keep working but I’m not really sure how bridging works. I know mosquitto-go-auth uses a different utility for encrypting passwords in it’s password file so maybe it’s related to that? But I’m not sure how each broker encrypting it’s internal password file could affect the other.
I would start with debug logging and see if that provides useful Intel.
OK, some progress. Reinstalled, turned on debug logging, fired up the weather station, and I see this in the debug log:
1652632678: New connection from 192.168.135.3:40784 on port 1883.
error: received null username or password for unpwd check
1652632678: Client <unknown> disconnected, not authorised.
I need to get a sniffer set up and see what it is actually sending. The 1883 connection is not encrypted so I hope I can see the detail if I do that.
I wonder if there are alternative formats, one for clear text user/password and one encrypted, and the new authentication is only honoring clear text? I’ll also try to see if I can force the broker-to-broker setup to use the same format as a client, but so far no luck finding that.
Hmmm… the MQTT connect command shows no authentication information (to be precise it has the flag “user name flag: not set” and “password flag: not set”.
But I had the prior setup requiring authentication. I wonder if I have an incorrect configuration for the user/password file info, and it was always connecting without authentication despite telling it to require. Checking further…
Apparently I was mistaken, and the password file in the remote broker is for client connections only. there is a separate, in the clear
remote_username xxx
remote_password xxx
that sets the remote connection credentials.
What still confuses me is I was not aware I allowed no-credential connections in the older mosquito. I do not quite know how to tell now what was mis-configured to allow that, but clearly it was, and then it stopped working with the new version.
My mistake was in the remote broker setup. Now fixed, now working.
My apologies for the confusion, and thank you for trying to help.
So this was actually a bug. This pr was supposed to do that. But it actually removed the allow_anonymous setting from the config file and in mosquitto 1.6 allow_anonymous defaulted to true so it really turned it on for everyone. Not ideal.
Updating mosquitto to 2.0 fixed this without me realizing it since in 2.0 mosquitto changed the default of allow_anonymous to false. Had a course issue reports that made me aware of this after the release of 6.1
Glad it’s resolved though, sorry about the inconvenience.