search

davesteele / comitup

Bootstrap Wifi support over Wifi
https://davesteele.github.io/comitup/
GNU General Public License v2.0
320 stars 54 forks source link

Comitup often prevents connection to already configured SSID, posibility to add timeout before spawning hotspot would be nice #74

Closed Baltix closed 4 years ago

Baltix commented 4 years ago

I'm using Comitup with Raspberry PI with DietPI image (based on Debian "Buster"), comitup configures connection to WiFi Access Point and succesfully connects, but when reboot Raspberry sometimes hotspot "comitup-nn" is created instead of connecting to configured Access Point. from system logs I've noticed, that network-manager connects to configured Access Point during opeating system startup, but after few seconds disconnects and then comitup creates hotspot :(

This issue happens often when several connections to different Access Points are configured. I need several configuration do different Access Points because the same Raspberry computer is used in different schools.

It would be nice if you add an option in /etc/comitup.conf "no-connection-timeout" for time without connection to configured access point before spawning hotspot - for example if "no-connection-timeout=30" then comitup will create a hotspot not immediately after connection to configured access point fails to connect, but only if there are Wifi no connection to configured access points for 30 seconds. This will be very useful in situations. where is weak WiFi signal and network-manager not always successfully connects to access point on the first attempt.

Thanks for creating useful open source software, Mantas

davesteele commented 4 years ago

Comitup starts in the HOTSPOT state, then cycles through candidates after 5 seconds. It used to only cycle through APs it could see, but that proved unreliable.

So the comitup hotspot is always being created on startup. You are noticing this after multiple connections are defined because the cycling starts taking more time.

What you want is for Comitup to detect an existing upstream connection at startup, and go directly to CONNECTED mode if there is one.

Baltix commented 4 years ago

@davesteele Thanks for answering, how could I help to solve this issue? Currently connection to Wi-Fi is not reliable if comitup is installed and teachers can't use my solution without knowing how to reconfigure network with comitup :( When comitup is installed Raspberry can't connect to the same access point and strong Wifi signal after I turn of Raspberry and turn on it again :(

I'm attaching a 'journalctl -xe' log output and quickly explain the situation: Comitup_doesnt_connect_to_Azuolas-Baltix_SSID-journalctl-xe.log

Latest comitup 1.8 version is installed on DietPi image (Debian Buster). 2 access points are configured: 'Lonas' and 'Azuolas-Baltix' (2 files in /etc/NetworkManager/system-connections/ folder - Lonas.nmconnection and Azuolas-Baltix.nmconnection )

Access point 'Lonas' is not available in that location, but Azuolas-Baltix is available and correctly configured.

I've modified etc/comitup.conf - set ap_name: zzBaltix-Linux- and changed comitup.service file - set RestartSec=25 , but the same issues appear when leaving default value RestartSec=5

Comitup starts the HOTSPOT and tries to connect to both access points every 3 minutes, but disconnects from 'Azuolas-Baltix' access point just after connection is established , see these lines in attached file Comitup_doesnt_connect_to_Azuolas-Baltix_SSID-journalctl-xe.log: NetworkManager[421]: [1574086992.3921] device (wlan0): state change: config -> deactivating (reason 'new-activation', sys-iface-state: 'managed') NetworkManager[421]: [1574086992.3936] audit: op="connection-activate" uuid="b9a756d4-3a87-4199-8e26-19187b6c1dc0" name="zzBaltix-Linux-22-0000" pid=481 uid=0 result="success" NetworkManager[421]: [1574086992.3938] device (wlan0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed')

When I remove comitup 1.8 package with 'apt-get remove comitup' and turn off HOTSPOT with command 'nmcli connection down' then Network-Manager connects automatically to Azuolas-Baltix accesspoint without any additional commands or configuration see this log file Successfully_connects_to_Azuolas-Baltix_after_removing_comitup_journalctl-xe.log:

root@BaltixPi:/# apt-get remove comitup [..] root@BaltixPi:/# nmcli d wifi list IN-USE SSID MODE CHAN RATE SIGNAL BARS SECURITY
zzBaltix-Linux-22 Infra 1 0 Mbit/s 0 ____ WPA1 WPA2 root@BaltixPi:/# nmcli connection down zzBaltix-Linux-22-0000 (at Nov 18 19:35 in this log file Successfully_connects_to_Azuolas-Baltix_after_removing_comitup_journalctl-xe.log ) Connection 'zzBaltix-Linux-22-0000' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/106) root@BaltixPi:/# nmcli d wifi list IN-USE SSID MODE CHAN RATE SIGNAL BARS SECURITY Azuolas-Baltix Infra 13 270 Mbit/s 100 ▂▄▆█ WPA2

When I installed comitup again with command "dpkg -i comitup_1.8-1_all.deb" then configured Wi-Fi connection was disconnected and HOTSPOT is activated and never disabled until I turn off Raspberry :(
root@BaltixPi:/home# dpkg -i comitup_1.8-1_all.deb [..] root@BaltixPi:/home# nmcli d wifi list IN-USE SSID MODE CHAN RATE SIGNAL BARS SECURITY zzBaltix-Linux-22 Infra 1 0 Mbit/s 0 ____ --

davesteele commented 4 years ago

You've installed to DietPi, and there are wpa_supplicant errors in the log. Do you have the wpa_supplicant problem (#12)?

If the connections are auto connecting, they weren't created by Comitup (Edit - not a true statement). Does it work correctly if they are created by Comitup?

It could help if Comitup created auto-connect connections (Edit - it already does), and transitioned directly to CONNECTED when the wifi is already up. By the same token, it could help to let NetworkManager autoconnect, instead of cycling through connections.

You can see more by setting the debug level to logging.DEBUG, and monitoring /var/log/comitup.log.

yohannaje commented 4 years ago

Hi! I'm having a similar issue, I'm using comitup for digital signage in my in-laws pharmacy (I load a webpage in kiosk mode on the autostart file), the thing is they cut the power every night, so the raspberry boots each morning. Sometimes it connects well, but lately it's been "forgeting" the configured ssid so it makes me go to reconnect everything every time.

At first I thought it was a problem with their networks, they have a 2.4 and a 5.8GHz so maybe one of them wasnt working properly but it has happened already with both of them (I also was wondering if I set up the credentials if it remembers both networks or just the latest one)

Anything I could do? Thanks!

davesteele commented 4 years ago

It could be a worn out SD card.

Can you stop the comitup service via ssh (sudo systemctl stop comitup) and make the connection manually ("nmcli con", then "nmcli con ")?

Baltix commented 4 years ago

@yohannaje @davesteele problem is not in Wireless networks or bad SD card, but in comitup software, I think because comitup creates HOTSPOT connection and then attempts to connect to all created connections, including just created HOTSPOT connection. I think problem can by solved by patchin /comitup/states.py file, now there is a function def hotspot_timeout(): with this code: dev = modemgr.get_state_device('CONNECTED') conn_list = candidate_connections(dev)

I think conn_list contains not only configured connection to existing access points, but also comitup created hotspot, right?

Btw, why in the last files of states.py file (after if name == 'main': ) firstly is the line set_state('HOTSPOT') instead of set_state('CONNECTING', candidate_connections()) ?

davesteele commented 4 years ago

Ok, but if performance is degrading over time, I'd suspect first either the SD card or an increasing connection list.

The "if" statement in hotspot_timeout is disabling the periodic connection attempts from HOTSPOT mode if we are operating in single Wifi interface mode, and someone is connected to the HOTSPOT. If the connection scan is attempted in that case, everyone is kicked off of the hotspot.

Note that any code in a "if name == "main":" block in any file other than comitup.py is for test and development only. HOTSPOT is indeed the first state, but that is defined in states.py init_states().

A better fix may be to replace the call initializing the state with:

   conn_list = candidate_connections(dev)
   if conn_list:
       set_state('CONNECTING', conn_list)
   else:
       <hotspot state>

See if that improves your reliability.

The challenge will probably be on startup. NetworkManager is not always ready for business at the precise time it says it is.

The hotspot should not be in the list. That's a bug if it is the case. There is code in nm.py get_candidate-connections() to filter hotspots out. I'd welcome a pull request if that is not the case.

davesteele commented 4 years ago

Even better would be to add another "if" clause to go straight to CONNECTED if the connection is connected (which would probably need a delay added to comitup.py startup to work well.

Baltix commented 4 years ago

@davesteele I patched states.py init_states function as you suggested, but this doesn't help - comitup doesn't connect to correctly configured "Azuolas-Baltix" ssid (access point) when another ssid - "Lonas" is configured :( I think problem is not in init_states function, currently I've set the debug level to logging.DEBUG and attaching 2 comitup.log files when using this patched init_states function:

def init_states(hosts, callbacks, hotspot_pw):
    global hotspot_name
    nmmon.init_nmmon()
    set_hosts(*hosts)
    for callback in callbacks:
        add_state_callback(callback)
    hotspot_name = dns_to_conn(hosts[0])
    assure_hotspot(hotspot_name, modemgr.get_ap_device(), hotspot_pw)
    dev = modemgr.get_state_device('CONNECTED')
    conn_list = candidate_connections(dev)
    if conn_list:
       set_state('CONNECTING', conn_list)
    else:
       # Set an early kick to set CONNECTING mode
       set_state('HOTSPOT')
       timeout_add(5*1000, hotspot_timeout, state_id)

comitup.log-doesnt-connect-when-two-ssid-configured.log comitup.log-successfully-connects-with-one-ssid-configured.log

As you see from attached log files - comitup doesn't connect to "Azuolas-Baltix" access point when there is a file /etc/NetworkManager/system-connections/Lonas.nmconnection on startup, but connects successfully to "Azuolas-Baltix" when I remove /etc/NetworkManager/system-connections/Lonas.nmconnection and restart Raspberry Pi 3

It seems comitup is waiting 8 seconds or more when trying to connect to first SSID, but doesn't wait when connecting to second or third SSID, I think may be the issue why comitup doesn't connect to "Azuolas-Baltix" when another SSID is configured and comitup tries to connect to another SSID at first.

Also It seems I've found 2 errors in nm.py - when debug level is logging.DEBUG then these exceptions appear in /var/log/comitup.log : 2019-11-24 14:55:07,414 - comitup - DEBUG - Not in cache 2019-11-24 14:55:07,422 - comitup - DEBUG - Got an exception, returning None, get_ssid_from_connection Traceback (most recent call last): File "/usr/share/comitup/comitup/nm.py", line 60, in wrapper return fp(*args, *kwargs) File "/usr/share/comitup/comitup/nm.py", line 155, in get_ssid_from_connection return settings['802-11-wireless']['ssid'] KeyError: '802-11-wireless' [..] 2019-11-24 23:17:21,455 - comitup - DEBUG - states: Calling nm.get_active_ip() 2019-11-24 23:17:22,393 - comitup - DEBUG - Got an exception, returning None, get_active_ip Traceback (most recent call last): File "/usr/share/comitup/comitup/nm.py", line 60, in wrapper return fp(args, **kwargs) File "/usr/share/comitup/comitup/nm.py", line 142, in get_active_ip return device.Ip4Config.Addresses[0][0] AttributeError: 'NoneType' object has no attribute 'Addresses'

Baltix commented 4 years ago

It seems nmmon is used when connecting to first SSID (comitup.log contains lines like "comitup - DEBUG - nmm - primary state 110" when connecting to first SSID - "Lonas"), but there are no such lines when connecting to second SSID - "Azuolas-Baltix", while "journalctl -xe" displays, that Network-Manager succesfully connects to "Azuolas-Baltix" and then immediately disconnects because of newly requested connection to comitup HOTSPOT (named "zzBaltix-Linux-22"):

NetworkManager[421]: [1574086992.2769] device (wlan0): Activation: (wifi) connection 'Azuolas-Baltix' has security, and secrets exist. No new secrets needed. NetworkManager[421]: [1574086992.2770] Config: added 'ssid' value 'Azuolas-Baltix' NetworkManager[421]: [1574086992.2772] Config: added 'scan_ssid' value '1' NetworkManager[421]: [1574086992.2773] Config: added 'bgscan' value 'simple:30:-80:86400' NetworkManager[421]: [1574086992.2774] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256' NetworkManager[421]: [1574086992.2774] Config: added 'auth_alg' value 'OPEN' NetworkManager[421]: [1574086992.2775] Config: added 'psk' value '' NetworkManager[421]: [1574086992.3313] device (wlan0): supplicant interface state: disconnected -> scanning NetworkManager[421]: [1574086992.3920] device (wlan0): disconnecting for new activation request. NetworkManager[421]: [1574086992.3921] device (wlan0): state change: config -> deactivating (reason 'new-activation', sys-iface-state: 'managed') NetworkManager[421]: [1574086992.3936] audit: op="connection-activate" uuid="b9a756d4-3a87-4199-8e26-19187b6c1dc0" name="zzBaltix-Linux-22-0000" pid=481 uid=0 result="success" NetworkManager[421]: [1574086992.3938] device (wlan0): state change: deactivating -> disconnected (reason 'new-activation', sys-iface-state: 'managed')

davesteele commented 4 years ago

Thanks for the analysis. I appreciate the work, and encourage you to continue to work it through. I probably won't be able to participate until Christmas break.

Baltix commented 4 years ago

@davesteele It's too complicated to me to find why comitup doesn't wait when connecting to second or third SSID, I'm newbie in Python :( Could you give me some tips how to find why comitup doesn't wait when connecting to second SSID and how to fix it?

davesteele commented 4 years ago

The end of the waiting period is supposed to be defined by the call of connecting_timeout(). The timeout is established in set_state(), which is used to set CONNECTING in hotspot_timeout() and connecting_fail(). Note that, for subsequent connections, the process is kicked off in connecting_fail(). Is the (global) conn_list preserved properly through that process?

Baltix commented 4 years ago

@davesteele Sorry, I'ts pretty hard for me to understand the logic of comitup application :( How to check if the (global) conn_list is preserved properly through that process?

davesteele commented 4 years ago

For debugging purposes, just add print statements at places of interest, stop the systemd comitup service, and run comitup as root from the command line.

Baltix commented 4 years ago

Thanks, it seems a problem is not because of timeout - I've copied /etc/NetworkManager/system-connections/Azuolas-Baltix.nmconnection file (this connection is created through comitup web interface) to another file with changing one letter in filename - /etc/NetworkManager/system-connections/Azuolus-Baltix.nmconnection and changed uuid and id inside, but left all other values (including ssid=Azuolas-Baltix) identifical. So now I have 3 configured connections in /etc/NetworkManager/system-connections/ folder but 2 are identifical - same ssid=Azuolas-Baltix , same password and other configuration just uuid and id differ). In my current location active is Azuolas-Baltix access point.

In /var/log/comitup.log I see these lines:

2019-11-29 18:19:58,276 - comitup - DEBUG - candidates: ['Lonas', 'Azuolas-Baltix', 'Azuolas-Baltix'] 2019-11-29 18:19:58,276 - comitup - DEBUG - states: Calling nm.get_connection_by_ssid() 2019-11-29 18:19:58,277 - comitup - DEBUG - Calling nm.ListConnections() [...] 2019-11-29 18:19:58,415 - comitup - INFO - Setting state to CONNECTING 2019-11-29 18:19:58,424 - comitup - DEBUG - states: Calling nm.disconnect() 2019-11-29 18:19:58,425 - comitup - DEBUG - Calling disconnect 2019-11-29 18:19:58,427 - comitup - DEBUG - Error received in disconnect 2019-11-29 18:19:58,427 - comitup - INFO - Attempting connection to Lonas 2019-11-29 18:19:58,427 - comitup - DEBUG - Connecting to Lonas 2019-11-29 18:19:58,427 - comitup - DEBUG - states: Calling nm.activate_connection_by_ssid() 2019-11-29 18:19:58,428 - comitup - DEBUG - Calling nm.ListConnections() 2019-11-29 18:19:58,488 - comitup - DEBUG - Calling GetSettings 2019-11-29 18:19:58,489 - comitup - DEBUG - Calling nm.NetworkManager.ActivateConnection() 2019-11-29 18:19:59,032 - comitup - DEBUG - stopping comitup-web.service web service 2019-11-29 18:19:59,057 - comitup - DEBUG - Running dnsmasq using 2019-11-29 18:19:59,066 - comitup - DEBUG - nmm - primary state 40 2019-11-29 18:19:59,066 - comitup - DEBUG - nmm - secondary state 40 2019-11-29 18:19:59,067 - comitup - DEBUG - nmm - primary state 50 2019-11-29 18:19:59,067 - comitup - DEBUG - nmm - secondary state 50 2019-11-29 18:19:59,067 - comitup - DEBUG - nmm - primary state 60 2019-11-29 18:19:59,068 - comitup - DEBUG - nmm - secondary state 60 2019-11-29 18:19:59,068 - comitup - DEBUG - nmm - primary state 40 2019-11-29 18:19:59,068 - comitup - DEBUG - nmm - secondary state 40 2019-11-29 18:19:59,068 - comitup - DEBUG - nmm - primary state 50 2019-11-29 18:19:59,069 - comitup - DEBUG - nmm - secondary state 50 2019-11-29 18:20:23,827 - comitup - DEBUG - nmm - primary fail 2019-11-29 18:20:23,828 - comitup - DEBUG - nmm - secondary fail 2019-11-29 18:20:23,829 - comitup - DEBUG - Connection failed

It's ok, because ssid Lonas isn't available here, but then comitup tries to connect to the second connection "Azuolas-Baltix", fails to connect to the second connection (as always), but SUCCESSFULLY CONNECTS to the third connection, which is identifical to second:

2019-11-29 18:20:23,831 - comitup - INFO - Setting state to CONNECTING 2019-11-29 18:20:24,375 - comitup - DEBUG - states: Calling nm.disconnect() 2019-11-29 18:20:24,375 - comitup - DEBUG - Calling disconnect 2019-11-29 18:20:24,377 - comitup - DEBUG - Error received in disconnect 2019-11-29 18:20:24,377 - comitup - INFO - Attempting connection to Azuolas-Baltix 2019-11-29 18:20:24,377 - comitup - DEBUG - Connecting to Azuolas-Baltix 2019-11-29 18:20:24,378 - comitup - DEBUG - states: Calling nm.activate_connection_by_ssid() 2019-11-29 18:20:24,378 - comitup - DEBUG - Calling nm.ListConnections() 2019-11-29 18:20:24,437 - comitup - DEBUG - Calling GetSettings 2019-11-29 18:20:24,438 - comitup - DEBUG - Calling GetSettings 2019-11-29 18:20:24,438 - comitup - DEBUG - Calling nm.NetworkManager.ActivateConnection() 2019-11-29 18:20:24,979 - comitup - DEBUG - stopping comitup-web.service web service 2019-11-29 18:20:25,014 - comitup - DEBUG - Running dnsmasq using 2019-11-29 18:20:25,021 - comitup - DEBUG - Connection failed 2019-11-29 18:20:25,021 - comitup - INFO - Setting state to CONNECTING 2019-11-29 18:20:25,032 - comitup - DEBUG - states: Calling nm.disconnect() 2019-11-29 18:20:25,033 - comitup - DEBUG - Calling disconnect 2019-11-29 18:20:25,040 - comitup - INFO - Attempting connection to Azuolas-Baltix 2019-11-29 18:20:25,040 - comitup - DEBUG - Connecting to Azuolas-Baltix 2019-11-29 18:20:25,040 - comitup - DEBUG - states: Calling nm.activate_connection_by_ssid() 2019-11-29 18:20:25,040 - comitup - DEBUG - Calling nm.ListConnections() 2019-11-29 18:20:25,669 - comitup - DEBUG - Calling GetSettings 2019-11-29 18:20:25,669 - comitup - DEBUG - Calling GetSettings 2019-11-29 18:20:25,670 - comitup - DEBUG - Calling nm.NetworkManager.ActivateConnection() 2019-11-29 18:20:26,219 - comitup - DEBUG - stopping comitup-web.service web service 2019-11-29 18:20:26,249 - comitup - DEBUG - Running dnsmasq using 2019-11-29 18:20:26,258 - comitup - DEBUG - nmm - primary state 30 2019-11-29 18:20:26,258 - comitup - DEBUG - nmm - secondary state 30 2019-11-29 18:20:26,258 - comitup - DEBUG - nmm - primary state 40 2019-11-29 18:20:26,259 - comitup - DEBUG - nmm - secondary state 40 2019-11-29 18:20:26,259 - comitup - DEBUG - nmm - primary state 50 2019-11-29 18:20:26,259 - comitup - DEBUG - nmm - secondary state 50 2019-11-29 18:20:26,260 - comitup - DEBUG - nmm - primary state 60 2019-11-29 18:20:26,260 - comitup - DEBUG - nmm - secondary state 60 2019-11-29 18:20:26,260 - comitup - DEBUG - nmm - primary state 40 2019-11-29 18:20:26,260 - comitup - DEBUG - nmm - secondary state 40 2019-11-29 18:20:26,261 - comitup - DEBUG - nmm - primary state 50 2019-11-29 18:20:26,261 - comitup - DEBUG - nmm - secondary state 50 2019-11-29 18:20:26,262 - comitup - DEBUG - nmm - primary state 110 2019-11-29 18:20:26,263 - comitup - DEBUG - nmm - secondary state 110 2019-11-29 18:20:26,263 - comitup - DEBUG - nmm - primary state 30 2019-11-29 18:20:26,263 - comitup - DEBUG - nmm - secondary state 30 2019-11-29 18:20:26,264 - comitup - DEBUG - nmm - primary state 40 2019-11-29 18:20:26,264 - comitup - DEBUG - nmm - secondary state 40 2019-11-29 18:20:26,264 - comitup - DEBUG - nmm - primary state 50 2019-11-29 18:20:26,264 - comitup - DEBUG - nmm - secondary state 50 2019-11-29 18:20:26,265 - comitup - DEBUG - nmm - primary state 60 2019-11-29 18:20:26,265 - comitup - DEBUG - nmm - secondary state 60 2019-11-29 18:20:26,265 - comitup - DEBUG - nmm - primary state 40 2019-11-29 18:20:26,265 - comitup - DEBUG - nmm - secondary state 40 2019-11-29 18:20:26,266 - comitup - DEBUG - nmm - primary state 50 2019-11-29 18:20:26,266 - comitup - DEBUG - nmm - secondary state 50 2019-11-29 18:20:31,534 - comitup - DEBUG - nmm - primary state 70 2019-11-29 18:20:31,535 - comitup - DEBUG - nmm - secondary state 70 2019-11-29 18:20:37,117 - comitup - DEBUG - nmm - primary pass 2019-11-29 18:20:37,118 - comitup - DEBUG - nmm - secondary pass 2019-11-29 18:20:37,120 - comitup - DEBUG - Connection successful

Maybe you have some ideas why comitup can't connect to second connection, but successfully connects to identical third connection?

davesteele commented 4 years ago

nmmon.py is responsible for calling the _pass() and _fail() functions in states.py. I'd suspect a race condition in that code - responding to an unrelated NetworkManager event.

davesteele commented 4 years ago

Expanding on the theory. Timeout callbacks in states.py use a decorator to verify that the callback is happening in the same state as when it is defined, using a monotonic state id. There is a timeout used for callbacks in nmmon.py which should be using the same logic.

davesteele commented 4 years ago

Are you in a position to be able to test 936d61e?

Baltix commented 4 years ago

@davesteele Thanks, your fixed the main issue and now comitup always successfully connects to configured connections!

I've found another issue - comitup sometimes starts earlier than avahi-daemon, this can by fixed by adding 

[Unit]
Requires=avahi-daemon.service

to /lib/systemd/system/comitup.service Also I've done some improvements to other functions - for example currently comitup added HOTSPOT connection is always left in /etc/NetworkManager/system-connections/ , even after successful connection to configured access point, so, I've added nm.del_connection_by_ssid(hotspot_name) in def connecting_pass() function:

def connecting_pass():
log.debug("Connection successful")
log.debug('Removing hotspot_name %s' % hotspot_name)
nm.del_connection_by_ssid(hotspot_name)
set_state('CONNECTED')

Also I modified init_states function - added Checking if Network-Manager isn't already connected to configured Access Point, I'm attaching a patch with all my improvements to states.py

skiping-hotspot-creation-if-connected_states.py.patch.txt

davesteele commented 4 years ago

Unfortunately, I released v1.9 before seeing this last post.

The eventual goal for the hotspot connection name is to include a hash of the Comitup-internal configuration for the connection, and only create the file if it isn't present. That way, user changes to that file are preserved. Under that scenario, new configuration files should be rare, and the user should have a say in deleting old ones.

The timeout argument in set_state() essentially defines the retry time on checking for connections. Did you have a need to increase that to 5 minutes?

Your startup changes could still disrupt an already-established connection, if there are multiple connections defined. I'd look into setting the state directly to CONNECTED in that case. There would need to be consideration for establishing the hotspot, for dual interface configurations.

davesteele commented 4 years ago

I'm going to close this thread, as an onerous part of the interruption is addressed. If you have more about the initial Comitup state, start in a new issue.