-
Notifications
You must be signed in to change notification settings - Fork 71
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
Carrier crashes if a relay has been created but was previously rejected #1034
Comments
I seem to be able to replicate the crash just by starting up a relay that Cog doesn't know about! |
It looks like the real issue is that Relays connecting to the bus from the same machine, such that their peer host is 127.0.0.1 end up being let through (see Line 19 in a537b6e
The intent of the 127.0.0.1 matching condition was to let the clients Cog itself starts up to connect to the bus unencumbered. Locally I've tweaked the criteria to allow only clients through whose IDs start with "emqttc" (just for testing; that's not a fix) and the proper behavior is demonstrated. Cog's connections go through (because they're initiated from the I'm going to think a bit on how to get a better demarcation between internal Cog message bus clients and everybody else. |
Previously, only connections coming from Relays had usernames and passwords associated with them; any connection from Cog itself had neither. We would distinguish between them by examining which host the connection was coming from; if it was 127.0.0.1, we treated it like it was a Cog connection, and like a Relay connection (which needed to be authenticated) otherwise. This would cause Cog to crash if a Relay process was running on the same host as Cog, and if it tried to connect prior to being registered with Cog. Now, _all_ connections have a username and password associated with them. All Cog-initiated connections have a username of `COG_INTERNAL`, and use a randomly-generated password that is generated at Cog startup, allowing us to properly distinguish between Cog connections and Relay connections. Fixes #1034
Previously, only connections coming from Relays had usernames and passwords associated with them; any connection from Cog itself had neither. We would distinguish between them by examining which host the connection was coming from; if it was 127.0.0.1, we treated it like it was a Cog connection, and like a Relay connection (which needed to be authenticated) otherwise. This would cause Cog to crash if a Relay process was running on the same host as Cog, and if it tried to connect prior to being registered with Cog. Now, _all_ connections have a username and password associated with them. All Cog-initiated connections have a username of `COG_INTERNAL`, and use a randomly-generated password that is generated at Cog startup, allowing us to properly distinguish between Cog connections and Relay connections. Fixes #1034
To repro this bug, start Cog without creating a Relay. Then start Relay and watch it try to connect to Cog; you should see a
Cannot SUBSCRIBE ... ACL Deny
in the logs. Now, without restarting Relay, create a relay for that Relay's id (cogctl relays create ...
) and you should see Carrier crash with the following output.The text was updated successfully, but these errors were encountered: