Wi-Fi does not connect automatically on boot after upgrade to 3.4.0.24 (and onwards)

Bug Reports
,
#1

REPRODUCIBILITY (% or how often): always
BUILD ID = OS VERSION (Settings > About product): 3.4.0.24
HARDWARE (Jolla1, Tablet, XA2,…): Xperia X
UI LANGUAGE: English
REGRESSION: (compared to previous public release: Yes, No, ?): Yes

DESCRIPTION:

The phone no longer connects to a saved Wi-Fi automatically on boot after upgrade to 3.4.0.24.

PRECONDITIONS:

None.

STEPS TO REPRODUCE:

  1. Boot the phone

EXPECTED RESULT:

A saved Wi-Fi AP is connected to.

ACTUAL RESULT:

The saved and available Wi-Fi AP is not connected to, the Wi-Fi icon has a star in it.

ADDITIONAL INFORMATION:

Possible workarounds.

  • Disable and re-enable Wi-Fi: the saved Wi-Fi AP is connected to automatically in a few seconds.
  • Connect to the saved Wi-Fi AP manually by opening Wi-Fi settings and selecting it from the list.
  • Restart connman from shell (systemctl restart connman.service).

I’ve tried a couple things suggested in other topics on upgrade-related issues.

  • Attempted upgrade from shell in case it did not complete successfully, even though there was no error displayed after upgrade (ssu re 3.4.0.24; version --dup) - did not help.
  • Try connman migration (systemctl status connman-nemo-migration) - did not help, it seems the migration had already happened (/home/.system/var/lib/connman.nemo.migrated exists). Also, I can see old saved Wi-Fi APs in the settings.

The phone has no SIM card inserted, I use it only as a mini tablet. Only a few applications installed, all from the Jolla Store.

Another related regression is that fingerprint scanner also does not work after boot and starts working after connecting to Wi-Fi. Not sure if it’s worth a separate report as the issues seem related.

1 Like
Community meeting on IRC 25th May 2023
#2

A more recent thread brought to my attention the fact that the fingerprint issue is likely a feature. I had reviewed the release notes before upgrade, but did not really pay attention to that point. I may have assumed it is related to encryption (which I don’t use) due to the formulation.

Security code (if in use) must be typed when the phone is booting up.

I would say fingerprint is not accepted for the first unlock after boot up. Anyway, so much for the fingerprint sidetrack.

The main problem of this thread is, sadly, still reproducible.

I’ve since verified settings for the AP are present in ~/.local/share/system/privileged/connman/wifi_${wlan0_mac}_${hex_ssid}_managed_psk/settings with Favorite=true, AutoConnect=true, Hidden=true (I suppose this indicates the AP does not broadcast SSID, which may be relevant).

Also, I’ve tried looking at the output of # journalctl -a | grep -F connman (included below), which was requested in related threads.

Nov 15 15:59:07 Sailfish dbus-daemon[677]: [system] Activating via systemd: service name='net.connman.vpn' unit='connman-vpn.service' requested by ':1.31' (uid=100000 pid=1609 comm="/usr/bin/lipstick -plugin evdevtouch:/dev/touchscr")
Nov 15 15:59:07 Sailfish dbus-daemon[677]: dbus-daemon[677]: [system] Activating via systemd: service name='net.connman.vpn' unit='connman-vpn.service' requested by ':1.31' (uid=100000 pid=1609 comm="/usr/bin/lipstick -plugin evdevtouch:/dev/touchscr")
Nov 15 15:59:07 Sailfish systemd[1]: [/usr/lib/systemd/system/connman-vpn.service:18] Unknown lvalue 'PrivateUsers' in section 'Service'
Nov 15 15:59:07 Sailfish systemd[1]: [/usr/lib/systemd/system/connman-vpn.service:19] Unknown lvalue 'ProtectControlGroups' in section 'Service'
Nov 15 15:59:09 Sailfish connmand[1756]: Connection Manager version 1.32+git136.2
Nov 15 15:59:10 Sailfish dbus-daemon[677]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.34' (uid=0 pid=1756 comm="/usr/sbin/connmand -n -W nl80211 --nobacktrace --s")
Nov 15 15:59:10 Sailfish dbus-daemon[677]: dbus-daemon[677]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.34' (uid=0 pid=1756 comm="/usr/sbin/connmand -n -W nl80211 --nobacktrace --s")
Nov 15 15:59:10 Sailfish dbus-daemon[677]: [system] Activating via systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service' requested by ':1.35' (uid=0 pid=1756 comm="/usr/sbin/connmand -n -W nl80211 --nobacktrace --s")
Nov 15 15:59:10 Sailfish dbus-daemon[677]: dbus-daemon[677]: [system] Activating via systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service' requested by ':1.35' (uid=0 pid=1756 comm="/usr/sbin/connmand -n -W nl80211 --nobacktrace --s")
Nov 15 15:59:10 Sailfish dbus-daemon[677]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.34" (uid=0 pid=1756 comm="/usr/sbin/connmand -n -W nl80211 --nobacktrace --s") interface="org.neard.Manager" member="RegisterHandoverAgent" error name="(unset)" requested_reply="0" destination="org.neard" (uid=1027 pid=763 comm="/usr/sbin/nfcd -o syslog")
Nov 15 15:59:10 Sailfish dbus-daemon[677]: dbus-daemon[677]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.34" (uid=0 pid=1756 comm="/usr/sbin/connmand -n -W nl80211 --nobacktrace --s") interface="org.neard.Manager" member="RegisterHandoverAgent" error name="(unset)" requested_reply="0" destination="org.neard" (uid=1027 pid=763 comm="/usr/sbin/nfcd -o syslog")
Nov 15 15:59:10 Sailfish dbus-daemon[677]: [system] Successfully activated service 'net.connman.vpn'
Nov 15 15:59:10 Sailfish dbus-daemon[677]: dbus-daemon[677]: [system] Successfully activated service 'net.connman.vpn'
Nov 15 15:59:10 Sailfish connman-vpnd[1790]: Connection Manager VPN daemon version 1.32+git136.2
Nov 15 15:59:10 Sailfish connmand[1756]: Method "ListAdapters" with signature "" on interface "org.bluez.Manager" doesn't exist
Nov 15 15:59:13 Sailfish lipstick[1609]: [W] unknown:0 - Unable to fetch Connman services: "The name net.connman was not provided by any .service files"
Nov 15 15:59:13 Sailfish lipstick[1609]: [W] unknown:0 - "The name net.connman was not provided by any .service files"
Nov 15 15:59:13 Sailfish lipstick[1609]: [W] unknown:0 - "The name net.connman was not provided by any .service files"
Nov 15 15:59:13 Sailfish lipstick[1609]: [W] unknown:0 - "The name net.connman was not provided by any .service files"
Nov 15 15:59:13 Sailfish lipstick[1609]: [W] unknown:0 - "Method \"GetProperties\" with signature \"\" on interface \"net.connman.Technology\" doesn't exist\n"
Nov 15 15:59:13 Sailfish lipstick[1609]: [W] unknown:0 - "Method \"GetProperties\" with signature \"\" on interface \"net.connman.Technology\" doesn't exist\n"
Nov 15 15:59:13 Sailfish connmand[1756]: tech 0x2e66a8 statechange notify fail
Nov 15 15:59:13 Sailfish connmand[1756]: user changed to 100000
Nov 15 15:59:14 Sailfish connmand[1756]: [gsupplicant] WARNING! Unexpected interface capability key GroupMgmt

“Rejected send message” from dbus-daemon and “Unable to fetch Connman services” from lipstick seem suspicious, but without a success scenario to compare against I’m not sure those are relevant.

I would appreciate any hints for further troubleshooting, ideas on how to fix this.

#3

The wireless access point had SSID broadcasting turned off, turns out this is what triggers the problem - enabling SSID broadcasting makes the problem go away.

To verify I’ve tried booting the phone 5 times with the AP configured to not broadcast SSID (as it had been configured all the time), left the phone idle for 5 minutes and checked the Wi-Fi connection status. In all tests there was no connection, a star displayed in Wi-Fi signal strength indicator as mentioned in OP. After enabling SSID broadcasting Wi-Fi connection is reliably acquired within 10 seconds after bootup.

I consider this is a regression as automatic connection to the saved AP not broadcasting SSID used to work reliably on boot ever since I started using Sailfish X (SFOS v3.0.0.8). Please let me know if there is anything else I could do to help get this fixed in a future release.

2 Likes
#4

Reproducible on both 4.0.1.48 (Koli) and 4.1.0.24 (Kvarken).

#5

Yes. Confirming this for another X (F5122).

#6

Reproducible in all releases since 4.1.0.24 (Kvarken), including the current latest 4.5.0.19 (Struven ketju).

Very rarely the automatic connection on boot to the hidden Wi-Fi AP succeeds. Haven’t really counted, but I’d say less than 1 in 50 boots is the success case.

#7

I tested on a spare X and couldn’t reproduce your bug. Maybe it’s related to a specific AP configuration?

#8

Yes, the AP has to be hidden.

I wanted to edit this into the OP, but it was already past the editing window, so it remains “hidden” in a subsequent post. Maybe that’s part of the reason why the issue hasn’t garnered much attention so far. However, I find it annoying because:

  • it is a regression as noted in the OP;
  • all the other devices I’ve tried work fine with the same AP (laptops running GNU/Linux, Windows, OS X, an iPad, phones running different versions of Android, other devices likely but not necessarily running different variations of Android). In other words, the SFOS device is the only one refusing to work with the AP without user intervention.

My annoyance with the issue is exacerbated by the fact I use the SFOS device as a mini tablet (without a SIM card on the off chance it matters), i.e. not a daily driver, so I turn it on and off multiple times a week reproducing the issue almost every time.

#9

I need to check more closely, but at first glance your bug sounds similar to this one:

#10

Thanks for the link! Yes, that’s definitely related as the other thread also mentions failure to connect automatically. I also experience the other symptoms like not showing the network name and asking for credentials for the saved hidden AP on manual connection attempt. But in my view the other symptoms would be of little importance if the automatic connection worked reliably.

1 Like
#11

I’ve been collecting data to get actual failure rate instead of just a guess. Failure rate running 4.5.0.19 is 89.86%, i.e. 9 times out of 10 the phone will not connect to a saved hidden Wi-Fi AP automatically after power on. The tally for 4.5.0.21 is still running, but there is no significant difference so far.