-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
You broke my lights! AGAIN #2460
Comments
Okay. trying to be "smart" about how to be future-proof with some config is most likely going to be futile with any software as the config might be subject to change over versions, bug or no bug. As for your debugging methods; I'm not sure how much of your stack you upgrade before you test it, but if it works before you upgraded mosquitto and not after, probably there is some change in mosquitto causing the issue (bug or no bug)
So, my answer... Q: Are you gonna break my config in the next couple of releases?
Your warnings are in the change log. I'm not sure what you mean by "nuke the setting", but I'm 99% confident that forking mosquitto will cause you more work to keep it up to date than just giving the new, pre-compiled, version a spin and adapt to the changes. There is also the option to roll back if something breaks and you don't have the time / energy to fix it on the spot and maybe do another attempt later when you have a new idea on how to solve it. These are things you always have to consider doing upgrades in production environments, home use or not. Posting issues about how we broke your lights by you upgrading your software isn't going to get you very far with solving the problems you have. Speaking of the problems; Config documentation says Without additional information about your setup eg. your mosquitto configuration file and some logs would be nice, The fact that
gets ECONREFUSED. And mosquitto_pub "works" is very confusing. |
Would you mind pointing me to the exact line that caused this? Because i can't find it.
By that i meant forking it without any future changes.
Why would i want to do that?
I don't expect anyone to do that :) It was a sarcastic remark.
I'm running ArchLinux ARM. That is not as simple as you make it sound.
Ohh no! This one is fully on you! Specifically the dev that caused this. (might or might not be you)
Well, that's not how it works.
For the purpose of this test, i changed the config to have these properties and values
As for MQTT connections.
For the json code. You need "the program" and package.json. Below is the program. I removed most of it but kept the structure so you get a feeling of how it works:
and package.json:
Put them both in a folder and type
So as you can see. I truly do have mosquito_pub that works and nodejs that fails.
Then both work fine and local network devices can connect to it just fine too. Sorry for the very long message but this was probably much more helpful then either my or your post ;) |
I don't even think this is mosquitto related. You could also try add another listener to actually listen for ipv6 addresses too (i think). I wouldn't classify this as a config change; maybe a bugfix to not listen for anything else than you explicitly tell it to listen to. now; if you lead with configs and maybe some logs in the future instead of ranting about how other people break your stack after an upgrade with an issue covered 90% with just air, maybe things will go a bit smoother.
as for which line could be your warning;
This one talks about listener related fixes and about configuration. Not directly to the configuration line "listener" or ipv6, granted, but should be a red flag / warning about potential issues with your current setup, no?
That's my point. Having things automatically upgrade / using rolling release is bound to cause sudden issues with your setup. Pinning a version does not mean you have to stay there forever.
What a load of crap.
i'll have to look into why removin 0.0.0.0 allows for external connections. |
and you end the message with:
Say it however you want. There's a bug, that much is clear.
Hmm, you might be right about ipv6 there. That's probably default behavior in the nodejs mqtt package as i didn't change anything. The code i've shown you is exactly what i've executed without any changes on that side in between config changes. I've demonstrated it working and failing in the previous post. 127.0.0.1 might work but i'm just not going to change it from localhost as that should work too.
So here's my thought process when i was debugging it this time.
Nice theory but doesn't always work in practice. To be fair to you folks, the changelog does look nice and well written! You can't mention bugs you don't know about and i might have well discovered an unknown bug with this bug report. So i suppose the changelog for the version that fixes this (aka, requires 0.0.0.0 for the purposes that i use it) should give me a nice warning.
It depends. Also, on the testing subject. I'm just an individual with a home project. It can probably be expected that my testing is close to none in terms of automated testing etc... But mosquitto on the other hand, as an Eclipse project and being company backed, should have tests in place for this. Specifically as this could well relate to security. Now i'm not saying you don't have tests (you probably do), but it certainly didn't caught this one. So some evaluation on the testing side might need to be done to catch this in the future. |
Well... you may have stumbled upon another bug unrelated to your "bug". I'm under the impression that the mosquitto broker shouldn't allow external connections unless explicitly configured to do so. I do not know which one is correct and therefore maybe there is a bug there. Both behaviors are sound. However, explicitly listening to 0.0.0.0 (ipv4) as you did should not automatically create another listener for ::1 (ipv6) and therefore this mosquittos behavior is correct in this case, and your application buggy / faulty configuration.
It's not so clear.
oh, wow, ok. Whether you introduce a simple change in your own software such as changing a string to use ipv4 when you obviously configured it to listen to ipv4, or even better - make it configurable, is up to you. IF it turns out that leaving it blank after about your thought process; this is where i think you are doing it very easy for yourself to fall into these unexpected issues. Assuming the time is for maintenance.
if this line didn't spell it out for me, the combination of the fact that mosquitto_pub worked and not my controller software should at the very least point towards something wrong with the controller, not mosquitto.
well, okay. so you didn't fully understand the implications of binding to 0.0.0.0, and unlucky enough that your own application happened to use the ::1 address instead of 127.0.0.1?
Explicitly requiring 0.0.0.0 will definitively break any application attempting to connect on any ipv6 address.
It probably works better than whatever you are doing right now.
requiring the use of 0.0.0.0 for the purpose of connecting with ipv6, to me sounds a bit of a stretch.
I don't expect you to make any tests at all. You can test much as you want, or nothing. Running as a home user does not remove all the risks involved of something failing in a larger system with an upgrade compared with a company. |
I like this sarcastic close to rude conversation. We both seem to be quite good at that, my compliments :) My reasoning here is that it worked before and only the update of mosquitto made it fail. I say only because the packages the nodejs application uses were not updated at all in this path. Now sure, there could be system packages having an effect that i don't know about yet. I have seen that before with with NFS (filesystem). But those kind of updates where package x breaks something totally unrelated in package y is super uncommon! I'm using Arch for years now and only have seen it like once or twice. Therefore my gut instinct, which is proven by running the nodejs app in both config scenarios, is to blame mosquitto. Thus far it still looks like that is the right approach. As for ipv6 and why i don't want to change Think about it. mosquitto_pub with localhost works. Nodejs with localhost doesn't. There was no code update being done on the nodejs side (i did update it since though) so that does point to mosquitto. The question now becomes
While i didn't update nodejs packages in the begin (again, i did now), pulling in the updates did update nodejs itself so there's a remote (very unlikely) possibility that something changed there affecting it. As long as i don't know the cause, i'm not going to change a thing config wise as any change would be symptom fixing, not cause fixing. If you want to, i can have a look at the mqtt nodejs package to see if i can figure out why it even attempts ipv6 as i certainly didn't tell it to. |
Did adding 0.0.0.0 work for you with 2.0.11? If it does, maybe there wasn't a change introduced in the broker that broke your application, just the fact that you added 0.0.0.0 and your application happened to resolve localhost to ::1. This would explain why your application worked before and not after upgrade, and fit the description of not touching your mqtt library version. there is obviously a difference in how mosquitto resolves localhost to how your node resolves localhost. some might pick the first matching one, others maybe prefer ipv6 and others prefer ipv4. I would just take the easy route and make the hostname configurable and be done with it. This way the program can be made working even on the quirkiest systems + the user can select which one he / she wanna use. |
I literally said:
How much more explicit do you need it to be?
Re-read the first post. You're now making assumptions that i clearly answered. Now i did add 0.0.0.0 just in case - but READ CAREFULLY - that was when migrating from 1.x to 2.0.11. I found forum posts advising me to add that just to be sure on one side but also to be explicit. So in that time, for the migration, i did add it just in case and left it there as it was working as intended. But i did no such thing at all between 1.0.11 and 1.0.14. That means the config between 1.0.11 and 1.0.14 stayed the same. The rest of your message is based on this wrong assumption and on top of it you're going to assume how Thank you for thinking with me though :) |
fact: connecting to an ipv6 address with a service binding to 0.0.0.0 will never work. period. There are a few options i can think of:
Actually running your test on my arch system exhibit the very same problem on both 2.0.11 and 2.0.14. You can test this too, by reverting to mosquitto 2.0.11 (only mosquitto if i may) and see for yourself, does it work or not? Option number 2 is in this case much more likely if you ask me. Now, how you choose to deal with the issue is up to you.
The very fact that mosquitto_pub connected with ipv4 (because it worked) and your node connected with ipv6 (because it doesnt work) could be proof that some utilities resolve dns differently. My You can also test this by removing both localhost entries in your /etc/hosts file to see if any of the utilities still work. This is my explanation to why your controller does not work, and mosquitto_pub does. If you like, you can also see that mosquitto_pub is connecting with ipv4 if you look in your mosquitto logs for something like You can test this too by setting up a broker in the foreground with:
Notice that there is no 0.0.0.0. Run
and look for the log lines with New client. /etc/hosts is most likely not parsed differently because the information still has to be correct, just that the content is used differently. There is actually another option you could try, is to disable ipv6 all together. That is if you are not actually using ipv6.
but who knows what consequences this has... i guess. |
Hi,
Version 2.0.11 worked
Version 2.0.14 broke it
The change i had to make this time.
From:
listener 1883 0.0.0.0
to:
listener 1883
I explicitly added
0.0.0.0
in an attempt to be ahead of config security nightmares so that my node is accessible locally and throughout the local network. Normally in other applications you need to set that explicitly.So i thought i'd be "smart" and do that for mosquitto too. As i certainly didn't want it to kill my lights yet again.
I did find these hints to add
0.0.0.0
in the days of the 1.x to 2.x version migration on a forum to get it to behave like 1.x did in terms of network security.Now it turns out that i have to remove
0.0.0.0
to get it working locally. Nice brainfuck.With this is do have to specifically say that with 0.0.0.0 mosquitto does seem to be working locally when using
mosquitto_pub
on the same machine. But when running a nodejs script with the mqtt library you get a ECONREFUSED. That is all running on the very same machine with the mqtt connection being done like:If you're wondering and just to be sure. No, there is no docker involved in this setup at all! It's all running as local system services. So localhost in my nodejs application and localhost in mosquitto_pub are the same.
So, my question..
Are you gonna break my config in the next couple of releases? If so, please warn me in advance as i will then fork this project and nuke the setting because this is getting ludicrous.
I'm really and truly fed up with debugging broken lights just to figure out - yet again - that it's your fault, not mine.
It does make me super eager to change my lights to be mesh based and not need mosquitto at all anymore. But that's a quite an enormous coding challenge that i don't really want to do just yet. But hey, you might just push me to get working on that.
The text was updated successfully, but these errors were encountered: