-
Notifications
You must be signed in to change notification settings - Fork 54
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
Need to delete connections with bad authentication data #106
Comments
As the system is now, the comitup web site should be coming up between connection attempts (2 minutes? - not sure), giving an opportunity to redefine the connection. Comitup could detect that this is a password rejection, and delete the defined connection with the wrong credentials. That would eliminate the race to get through the config web pages, and would not be too hard to implement. |
Hi David,
I’m trying to setup a product that uses the rpi as it’s server.
Comitup is good but could do with a little customising to suit our needs for when our product is ready.
Would you be interested in developing a custom version of Comitup for us as our own?
…Sent from my iPhone
On 30 Mar 2020, at 6:12 am, David Steele ***@***.***> wrote:
As the system is now, the comitup web site should be coming up between connection attempts (2 minutes? - not sure), giving an opportunity to redefine the connection.
Comitup could detect that this is a password rejection, and delete the defined connection with the wrong credentials. That would eliminate the race to get through the config web pages, and would not be too hard to implement.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
We can talk about it. My email address is on the davesteele.github.io page. |
Is there any way to increase the time between connection attempts so that the user will have a chance to redefine the network? |
If someone is connected to the hotspot, the periodic connection attempts are suspended. |
i am having a problem where the hotspot appears for a millisecond and i cannot connect to it before it is gone again. |
Is there anything interesting in /var/log/comitup.log, /var/log/comitup-web.log, or NetworkManager entries in /var/log/daemon.log. |
I will have a chance to try it later today and I'll update here with what happens update: |
That's enough information. Thanks. Comitup needs to delete connections if there is an explicit authentication failure, or handle this case more gracefully. To those coming to this via Hacktoberfest, the best way to start may be by using the Comitup Image on a Raspberry Pi. |
Just tried this, other than the fact that it takes a while for the authentication failure to happen, it appears to be working fine. To those still seeing this, are you running current code, and are you using web_service? |
Current behavior fails the connection, then returns to the HOTSPOT mode for 3 minutes. |
Hi there! I'm reviving this issue because I'm experiencing what in my opinion is a not expected behaviour of comitup. It's happen many times that after a power line breakdown, the modem starts up with an incomplete configuration that returns to the client a bad configuration error, but it is only because an inicial mal functioning of the modem. I think that DELETING the network is fine only if it's the first time you try to connect to it. In the case you already have connected to that network we should delete it, at least trying a couple of times after deleting it. |
It just keeps getting more complicated:
If any change is to be made, I would lean towards reverting to the "try till oblivion" model. |
Commit #db528bd2 deletes connections with credential failures. This has caused problems when the upstream AP is booting or otherwise boogered. Instead, preserve the connection, but backoff the HOTSPOT timeout after a failed CONNCTING attempt. This is currently untested. Addresses #106
oh man! you are great David! thank you so much, I will be testing this today. I'll let you know. |
It works great! I would say you can merge it! Thank you so much! |
The change is in 1.32-1. |
Hey ya, amazing work you've done so far.
There seems to be an issue when the network password changes without reverting back to AP mode.
It works fine when there is a change in SSID name, as it will fire up AP mode immediately.
Syslog files shows attempts to connect but fails due to 'no-secrets' which I believe is because the network password has changed.
comitup-cli (d) works, but this is a inconvenience to setup again using SSH via ethernet
Any thoughts
The text was updated successfully, but these errors were encountered: