Other customer has reported a very similar issue as well.
The issue has started since M60.
The auto-connection function with EAP-TLS is working again after re-imaged to M59.

Here is the device log.
logs+20170912_XXXXXXXXX.tgz file 
https://drive.google.com/open?id=0B01YYztUbOCuRFRpQ0NrZGtNUGs
After OS recovery(M60) >re-enrolled>Connected to Wi-Fi OK>restarted and not auto connect to Wi-Fi>gather the log.(logs+20170912_XXXX.tgz file )

 crbug.com/766954 

The customer provided additional information.
 
-Fresh Device log files: after re-imaged to M61 by the image disk.
https://drive.google.com/open?id=0B01YYztUbOCuRmNtQkJyRmZidUU
(the issue is still pressit after updated to M61 by the recovery image. )

-Network setting info.
https://drive.google.com/open?id=0B01YYztUbOCuaUx6SnhkNk1KTHM
Verified “Automatically connection to this network” is enabled and chrome://network, but it does not connect to Wi-Fi by auto after reboot and re-login.
 (Manually connecting to Wi-Fi with EAP-TLS is OK)

Hi @bhthompson!
Could you please help triage this?
Thanks!

Kevin, is this in your jurisdiction?

 cernekee@
is there any update that can be shared with the customer?

I can reproduce this locally on canary (M64 10066.0.0).  The logs say:

2017-10-25T23:46:07.100527+00:00 INFO shill[6318]: [INFO:manager.cc(526)] PushProfileInternal finished; 1 profile(s) now present.
[...]
2017-10-25T23:46:07.103357+00:00 DEBUG shill[6318]: [VERBOSE1:dbus_object.cc(210)] Registering D-Bus object '/service/0'.
[...]
2017-10-25T23:46:07.104886+00:00 INFO shill[6318]: [INFO:service.cc(292)] wifi service 0 constructed.
2017-10-25T23:46:07.105028+00:00 DEBUG shill[6318]: [VERBOSE2:eap_credentials.cc(233)] (eap_credentials) Not connectable: Identity is empty.
2017-10-25T23:46:07.105256+00:00 INFO shill[6318]: [INFO:wifi_service.cc(181)] Constructed WiFi service 0 name: [SSID=Android Statue]
2017-10-25T23:46:07.105595+00:00 DEBUG shill[6318]: [VERBOSE2:manager.cc(1394)] manager Registering service 0
2017-10-25T23:46:07.105982+00:00 DEBUG shill[6318]: [VERBOSE2:eap_credentials.cc(272)] (eap_credentials) Not connectable: No suitable EAP configuration was found.
2017-10-25T23:46:07.106089+00:00 DEBUG shill[6318]: [VERBOSE2:service.cc(1179)] /service/0 SetProfile from (none) to chronos/shill.
2017-10-25T23:46:07.107074+00:00 INFO shill[6318]: [INFO:manager.cc(526)] PushProfileInternal finished; 2 profile(s) now present.


EAP.Identity is set correctly when I run /usr/local/lib/flimflam/test/list-services.  AutoConnect is true.  Need to keep digging to see why it is not being recognized.

`restart shill` yields the same result.

cernekee@
Thank you for sharing the update.

> 2017-10-25T23:46:07.105028+00:00 DEBUG shill[6318]: [VERBOSE2:eap_credentials.cc(233)] (eap_credentials) Not connectable: Identity is empty.

This message is a red herring.  It is only printed because wifi_service.cc updates the EAP connectivity status right after calling SetEapCredentials(new EapCredentials()).  So |identity_| really is empty initially, but it gets populated later during the Load() call.

> 2017-10-25T23:46:07.105982+00:00 DEBUG shill[6318]: [VERBOSE2:eap_credentials.cc(272)] (eap_credentials) Not connectable: No suitable EAP configuration was found.

I think this error is the real deal.  EAP.ClientCert, EAP.CertID, and a few others are empty in the shill profile and are not getting populated on login.  Maybe shill is losing them sometime after the successful connection, or maybe Chrome is zapping them.  Either way, the service truly is unconnectable in this state.  Will sniff dbus tomorrow to get to the bottom of it.

Hi pmarko, I think there might be a regression related to this change:

commit 2f149a05d31ad319ef6b620911b74e390dbee354
Author: pmarko <pmarko@chromium.org>
Date:   Fri May 12 05:21:45 2017 -0700

    Enable device-wide EAP-TLS networks


index 332e38d0ac01..cb9a4828cc8e 100644
--- a/chromeos/network/network_cert_migrator.cc
+++ b/chromeos/network/network_cert_migrator.cc
@@ -179,7 +180,7 @@ void NetworkCertMigrator::Init(NetworkStateHandler* network_state_handler) {
 }
 
 void NetworkCertMigrator::NetworkListChanged() {
-  if (!CertLoader::Get()->certificates_loaded()) {
+  if (!CertLoader::Get()->initial_load_finished()) {
     VLOG(2) << "Certs not loaded yet.";
     return;
   }


It looks like NetworkCertMigrator::MigrateClientCertProperties() is being run before FindCertificateWithPkcs11Id() is ready to look up cert IDs.  This causes Chrome to invoke SetEmptyShillProperties() and abort autoconnect of a manually-added (non policy) EAP-TLS network:

[5688:5688:1026/151004.712511:VERBOSE1:managed_network_configuration_handler_impl.cc(465)] Setting policies from user policy of 8342bbf22134ed2d49a4fea108c01a2ddec8b3fa.
[5688:5688:1026/151004.712625:VERBOSE1:managed_network_configuration_handler_impl.cc(541)] The relevant Shill profile isn't initialized yet, postponing policy application.
[5688:5688:1026/151004.739277:ERROR:input_method_manager_impl.cc(1031)] IMEEngine for "fgoepimhcoialccpbmpnnblemnepkkao" is not registered
[5688:5688:1026/151004.772097:VERBOSE1:user_session_manager.cc(1113)] Seed SigninManagerBase with the authenticated account info, success=1
[5688:5688:1026/151004.817100:VERBOSE1:user_image_manager_impl.cc(915)] Profile image initialized from disk.
[5688:5688:1026/151004.817246:VERBOSE1:input_events_blocker.cc(28)] InputEventsBlocker 0x13ea3100 destroyed.
[5688:5688:1026/151004.822220:INFO:chrome_cryptauth_service.cc(230)] Refresh token not yet available; waiting before starting CryptAuth managers.
[5688:5688:1026/151004.846238:VERBOSE1:oauth2_login_manager.cc(100)] Loading OAuth2 refresh token from database.
[5688:5688:1026/151004.887035:VERBOSE1:oauth2_login_manager.cc(131)] OnRefreshTokenAvailable
[5688:5688:1026/151004.890437:INFO:sync_scheduler_impl.cc(133)] Scheduling next sync for CryptAuth DeviceSync:
    Strategy: Aggressive Recovery
    Time Delta: 0 seconds
    Previous Failures: 1
[5688:5688:1026/151004.893841:INFO:sync_scheduler_impl.cc(133)] Scheduling next sync for CryptAuth Enrollment:
    Strategy: Periodic Refresh
    Time Delta: 25 days
[5688:5688:1026/151004.896260:VERBOSE2:network_cert_migrator.cc(188)] Start certificate migration of network configurations.
[5688:5688:1026/151004.896732:VERBOSE2:client_cert_resolver.cc(393)] NetworkListChanged.
[5688:5688:1026/151004.900148:ERROR:device_event_log_impl.cc(156)] [15:10:04.900] Network: managed_network_configuration_handler_impl.cc:728 Profile path unknown:/profile/chronos/shill: 0ca8f875-6fce-46b8-b2c5-7cd4824f8ae7
[5688:5688:1026/151004.900202:VERBOSE1:client_cert_resolver.cc(491)] The policy for network /service/2 with GUID 0ca8f875-6fce-46b8-b2c5-7cd4824f8ae7 is not available yet.
[5688:5688:1026/151004.900222:VERBOSE1:client_cert_resolver.cc(511)] No networks to resolve.
[5688:5688:1026/151004.900240:VERBOSE2:client_cert_resolver.cc(592)] Notify observers: no networks changed.
[5688:5688:1026/151004.900263:VERBOSE2:auto_connect_handler.cc(188)] device policy applied: 1
user policy applied: 0
policy application running: 0
client cert patterns resolved: 1
client cert resolve task running: 0
[5688:5688:1026/151004.900445:VERBOSE1:managed_network_configuration_handler_impl.cc(575)] Adding profile NetworkProfile(USER, /profile/chronos/shill, 8342bbf22134ed2d49a4fea108c01a2ddec8b3fa)'.
[5688:5688:1026/151004.918738:INFO:sync_scheduler_impl.cc(108)] Timer fired for aggressive recovery, making request...
[5688:5688:1026/151004.931391:WARNING:network_cert_migrator.cc(100)] No matching cert found, removing the certificate configuration from network /service/2
[5688:5688:1026/151005.174403:VERBOSE1:oauth2_login_verifier.cc(67)] MergeSession successful.
[5688:5688:1026/151005.174544:VERBOSE1:oauth2_login_manager.cc(252)] OAuth2 refresh and/or GAIA token verification succeeded.
[5688:5688:1026/151005.181296:VERBOSE1:oauth2_login_verifier.cc(82)] ListAccounts successful.

[...]

[5688:5688:1026/151007.471981:VERBOSE2:client_cert_resolver.cc(435)] OnCertificatesLoaded.
[5688:5688:1026/151007.472111:VERBOSE1:client_cert_resolver.cc(491)] The policy for network /service/1 with GUID 0b034276-6894-44e8-ba14-47a88f40c857 is not available yet.
[5688:5688:1026/151007.472149:VERBOSE1:client_cert_resolver.cc(491)] The policy for network /service/2 with GUID 0ca8f875-6fce-46b8-b2c5-7cd4824f8ae7 is not available yet.
[5688:5688:1026/151007.472175:VERBOSE1:client_cert_resolver.cc(511)] No networks to resolve.
[5688:5688:1026/151007.472201:VERBOSE2:client_cert_resolver.cc(592)] Notify observers: no networks changed.
[5688:5688:1026/151007.472233:VERBOSE2:auto_connect_handler.cc(188)] device policy applied: 1



My test setup is nothing special (regular gmail test account, not enterprise enrolled, EAP-TLS with FreeRadius, client cert owned by the user, cert+identity auth).  The repro procedure is:

1) Add CA + cert in chrome://certificate-manager
2) Connect to EAP-TLS wifi AP using cert
3) Run `/usr/local/lib/flimflam/test/list-services` and see that EAP.CertID and EAP.KeyID are populated
4) Log out
5) Log back in
6) Run `/usr/local/lib/flimflam/test/list-services` and see that EAP.CertID and EAP.KeyID are now empty
7) Check ~chronos/log/chrome and see the above error logged

My /etc/chrome_dev.conf uses:

vmodule=client_cert_resolver=4
vmodule=network_cert_migrator=4
vmodule=auto_connect_handler=4
vmodule=managed_network_configuration_handler_impl=4
vmodule=client_cert_util=4


Would you mind taking a look?

Thanks for the excellent analysis Kevin, I'll prepare a fix today!

It makes sense, as now initial_load_finished() is true on the sign-in screen already.

For policy-set networks, the following will happen:
- user signs in
- If certs are not available yet: NetworkCertMigrator clears cert/key info in shill
- Certs become available: ClientCertResolver finds the correct cert and applies it

For manually confiured networks, the third step doesn't exist, as shill was the source of truth for the configured certificate and we have no backup.

So, in some way, NetworkCertMigrator is "overtriggering" on user sign-in but it's been masked in my testing by the fact that ClientCertResolver saves the situation for policy-configured networks.

The obvious solution we could try to go with is to have CertLoader know _which_ cert databases has been loaded (system-wide certs only or system+user) and make NetworkCertMigrator only do its job when:
- the network is in a device-wide profile && system db has been loaded
- the network is in a user profile && user cert db has been loaded

This should restore the previous behavior.

CL up: https://chromium-review.googlesource.com/c/chromium/src/+/741239
Verifying that it solves the problem on a test machine now and if it does, will send it out for review.

Verified that the CL fixes the issue on my test machine, sent out for review.

 Issue 766954  has been merged into this issue.

pmarko@
is there any update that can be shared with the customer?

Re Comment #17:
Sorry for the delay! The fix was in review and should land in the next few hours.
I will then request to merge the fix to M-63.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/da53cf1ba363bc68bcddcfd6beb041288448d0d6

commit da53cf1ba363bc68bcddcfd6beb041288448d0d6
Author: Pavol Marko <pmarko@chromium.org>
Date: Fri Nov 03 08:56:26 2017

Defer user profile network cert migration until user cert db load

Only run network certificate migration logic on networks
configured in the user profile when the user NSS database is
loaded.
Network certificate migration is still performed for shared
profile networks when the first NSS database (usually the
device-wide "system" token database) is loaded.

Side note: NetworkCertMigrator was the only consumer of the
|initial_load| argument of the OnCertificatesLoaded observer calls,
and as it doesn't rely on it anymore, I'm simplifying the code by
removing the argument.

Background:
NetworkCertMigrator goes through all saved networks and matches
the configured certificate against available certificates.
The goal is to update the PKCS11 slot id the certificate is on
or clear it if the certificate is not available anymore.
CL https://codereview.chromium.org/2858113003 caused a regression
where network certificate migration logic was running on user
profile load but before the user's certificates were available,
so all configured network certificates were cleared.
The visible effect of this was that that AutoConnect does not
work for manually configured EAP-TLS networks in user profiles.

BUG= 774745 
TEST=chromeos_unittests --gtest_filter=*Cert*
     (this will include ClientCertResolver, CertLoader,
      NetworkCertMigrator tests)

Change-Id: I76ed96df283c5d4219a7731f1150c481c520ce67
Reviewed-on: https://chromium-review.googlesource.com/741239
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Pavol Marko <pmarko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#513726}
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chrome/browser/chromeos/options/cert_library.cc
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chrome/browser/chromeos/options/cert_library.h
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chrome/browser/chromeos/options/vpn_config_view.cc
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chrome/browser/chromeos/options/vpn_config_view.h
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chrome/browser/chromeos/options/wifi_config_view.cc
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chrome/browser/chromeos/options/wifi_config_view.h
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/cert_loader.cc
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/cert_loader.h
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/cert_loader_unittest.cc
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/network/client_cert_resolver.cc
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/network/client_cert_resolver.h
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/network/network_cert_migrator.cc
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/network/network_cert_migrator.h
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/network/network_cert_migrator_unittest.cc
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/network/network_certificate_handler.cc
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/network/network_certificate_handler.h
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/network/network_connection_handler_impl.cc
[modify] https://crrev.com/da53cf1ba363bc68bcddcfd6beb041288448d0d6/chromeos/network/network_connection_handler_impl.h

Requesting merge to M-63 (3239).

Thanks!

Will wait for this to be verified on tot first before merging.

Thanks! I'll post to this bug when the change lands in a dev build.

+Katherine, Jing
@Katherine/Jing, I'd appreciate it if you could verify the fix on dev channel (when it reaches dev channel :-) ).

We can check on Monday when (hopefully) we have a new Chrome.

This bug requires manual review: M63 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

BTW, there still seems to be no build yet with this revision yet.
I will set the status to "Fixed" when the first build appears.

CL from #19 made it into 10106.0.0 (64.0.3261.0), so we'll verify today.

Thank you Katherine. Please let us know what you find!

pmarko@
Just a quick question about this,
We could not merge to M63 and the issue has resolved via M64 (10106.0.0), correct?

Re Comment #28:
The current status is:
- I think the issue is resolved in M64, but Katherine/Jing will also verify and let us know.
- After that, we might be able to merge to M63, depending on whether we get merge approval or not.

As verified in M64.0.3261.0 10109.0.0 dev paine, device connected to EAP-TLS network automatically after sign-out and sign-in.

Moving this back to Fixed until the merge lands

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6880a64c1f1e880e75460c94e05a9154dd5df2f2

commit 6880a64c1f1e880e75460c94e05a9154dd5df2f2
Author: Pavol Marko <pmarko@chromium.org>
Date: Tue Nov 14 12:31:04 2017

[Merge to M63] Defer user profile network cert migration until user cert db load

Only run network certificate migration logic on networks
configured in the user profile when the user NSS database is
loaded.
Network certificate migration is still performed for shared
profile networks when the first NSS database (usually the
device-wide "system" token database) is loaded.

Side note: NetworkCertMigrator was the only consumer of the
|initial_load| argument of the OnCertificatesLoaded observer calls,
and as it doesn't rely on it anymore, I'm simplifying the code by
removing the argument.

Background:
NetworkCertMigrator goes through all saved networks and matches
the configured certificate against available certificates.
The goal is to update the PKCS11 slot id the certificate is on
or clear it if the certificate is not available anymore.
CL https://codereview.chromium.org/2858113003 caused a regression
where network certificate migration logic was running on user
profile load but before the user's certificates were available,
so all configured network certificates were cleared.
The visible effect of this was that that AutoConnect does not
work for manually configured EAP-TLS networks in user profiles.

BUG= 774745 
TEST=chromeos_unittests --gtest_filter=*Cert*
     (this will include ClientCertResolver, CertLoader,
      NetworkCertMigrator tests)

TBR=pmarko@chromium.org

(cherry picked from commit da53cf1ba363bc68bcddcfd6beb041288448d0d6)

Change-Id: I76ed96df283c5d4219a7731f1150c481c520ce67
Reviewed-on: https://chromium-review.googlesource.com/741239
Reviewed-by: Steven Bennetts <stevenjb@chromium.org>
Reviewed-by: Kevin Cernekee <cernekee@chromium.org>
Commit-Queue: Pavol Marko <pmarko@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#513726}
Reviewed-on: https://chromium-review.googlesource.com/768383
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#479}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chrome/browser/chromeos/options/cert_library.cc
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chrome/browser/chromeos/options/cert_library.h
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chrome/browser/chromeos/options/vpn_config_view.cc
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chrome/browser/chromeos/options/vpn_config_view.h
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chrome/browser/chromeos/options/wifi_config_view.cc
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chrome/browser/chromeos/options/wifi_config_view.h
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/cert_loader.cc
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/cert_loader.h
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/cert_loader_unittest.cc
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/network/client_cert_resolver.cc
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/network/client_cert_resolver.h
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/network/network_cert_migrator.cc
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/network/network_cert_migrator.h
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/network/network_cert_migrator_unittest.cc
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/network/network_certificate_handler.cc
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/network/network_certificate_handler.h
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/network/network_connection_handler_impl.cc
[modify] https://crrev.com/6880a64c1f1e880e75460c94e05a9154dd5df2f2/chromeos/network/network_connection_handler_impl.h

This has been merged to M-63. I will write a comment when it reaches the Beta build.

Hello Team,

I have a customer that is having the same behavior.
My I ask for an update for this issue?

Thanks in advance!

This should be in 63.0.3239.51, while the Beta channel seems to be currently still serving 63.0.3239.50, so it's not in Beta yet, sorry.

pmarko@
The customer who reported  (#1 ) the auto connection issue persists after upgrading to Chrome OS63 Beta (63.0.3239.70)
Please recheck the log file that they provided. 

Device log files.(timestamp 10:36 5th Dec AEDT)
https://drive.google.com/open?id=18dt1AF-oy3lmrJF6zR_wB7wfOxQCPwwJ

version info.
https://drive.google.com/open?id=1pmhjXlIMOeOLKkIPSAbqvh2I5jImTWkd

Please let us know if you need any extra info from the customer side.

I can see this in the logs:
net.log:2017-12-05T10:39:08.043768+11:00 INFO shill[1267]: [INFO:service.cc(314)] Suppressed autoconnect to service 1 (not connectable)
But I don't see any EAP connectability evaluation logs which I'd expect.

As far as I can tell from the logs, there was no successful manual connection attempt on Dec 05th.

Please not that the effect of the bug was that the association between the network configuration and the certificate has been lost, which marks the network as not connectable.
It is necessary to re-establish it by manually connect at least once under the patched version, selecting the correct client certificate in the Wifi configuration dialog.
From there on, autoconnect should work, as the association between the network and the certificate will be present again and will not get lost anymore.
I should have mentioned this earlier, apologies for that.

Could you please check if the customer connected to the network manually once under the new version, and if the problem still persisted afterwards?

Ping - any news about Comment #38 ? Would like to act soon if my advice from Comment #39 doesn't help :-)

Verified on Santa R71- 11137.0.0, 71.0.3567.0