Closed jimmy232 closed 3 years ago
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 notifications@github.com 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: it turns out i had the wrong password after all. but according to the log it was attempting to reconnect every 30 seconds. Sorry I don't have a copy of the log files on hand at the moment
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.
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