Selecting the option to "allow others to use this network" made the connection possible again.  For me this "fixed" the bug for now.

Also an issue with VPN connections for which this workaround doesn't help.

aashutoshk@ / jmuppala@ - though it seems that this might be a M69 issue given that 10870.0.0 is good build and 10872.0.0 bad build, please do check on M68 and M67 as well and update the bug.

Verified on R67(10575.54.0) and R68(10718.50.0), I do not see any issues on these builds.

I can not produce this on link @ 10872.0.0 with a PSK network.

I am still seeing this issue on 10895.0.0 on various devices all the time.
@stevenjb please try forget network and add it again.

Also please find the attached screenshot below.

Deleted: psk_network__connect_error.png 766 KB

	psk_network__connect_error.png 766 KB View Download

I tried that :)

I am unable to reproduce this on eve @ 69.0.3488.0.

Have you tried this with multiple networks?

Could you please file a feedback report and provide a link with the following repro:
1. Forget any test networks.
2. Reboot the device.
3. Log in.
4. Connect to one or more (preferably more if possible) networks with this symptom.
5. Toggle 'share' and connect to one of the problem networks.
6. File a feedback report and provide a link to it here.

Also, can you verify whether the bug can be reproduced from the Settings UI?

@stevenjb Hi, i tried step 1 and 2, and after the reboot did not see the issue anymore. 

Before these steps, however was always able to reproduce the issue , also from the Settings UI.

Feedback report @ https://listnr.corp.google.com/report/85566169071

Definitely busted for me. Version 69.0.3494.0 on Pixelbook. Unless I enable "Allow other users of this device to use this network" it is not joining any new WiFi networks. Any open wired connections via USB-C adaptors work fine.
Also I have "Enable ARC VPN integration" on and none of the Android VPN clients I use work for the main OS anymore.

Likely related to sandboxing shill, as CL:1132174 (https://chromium-review.googlesource.com/c/aosp/platform/system/connectivity/shill/+/1132174) landed in 10872.0.0. I'll look into reproducing the issue and do some syscall auditing to see if anything obvious is failing.

Is there any evidence of this breaking on a plain-old wifi network that is password protected (rather than a corp network that has more advanced certificate setup etc)? I just set up a password protected network and didn't have any trouble logging in with a 10872.0.0 dev image.

I haven't been able to reproduce this at all myself, Google-A works just fine on my Pixelbook @ 69.0.3494.0. I suspect it may be related to a specific update path?

These 2 lines are the best indication I have as to whats going on (came from repro-ing the issue on a device in the lab):

2018-07-25T11:08:38.438270-07:00 ERR shill[1216]: [ERROR:error.cc(138)] [profile.cc(112)]: Profile storage for chronos:shill does not already exist
2018-07-25T11:08:38.438321-07:00 ERR shill[1216]: [ERROR:profile.cc(112)] InitStorage(...): Domain=dbus, Code=org.chromium.flimflam.Error.NotFound, Message=Profile storage for chronos:shill does not already exist

paul@modaco.com: does this bug describe the issue you were seeing with connecting to VPN? https://bugs.chromium.org/p/chromium/issues/detail?id=867680

*specifically, were you in "policy fetched (Enterprise)" mode

Only unique errors that I can see in the logs here that are not already noted in issue 867171 or  issue 867685  are these 2:

2018-06-25T21:14:36.013141+00:00 ERR shill[1520]: [ERROR:rtnl_handler.cc(293)] sequence 103 received error 17 (File exists)

2018-06-25T21:15:01.025431+00:00 ERR shill[1520]: [ERROR:active_link_monitor.cc(222)] Link monitor has reached the failure threshold with 5 broadcast failures and 0 unicast failures.
2018-06-25T21:15:01.025635+00:00 INFO shill[1520]: [INFO:wifi.cc(1726)] In OnLinkMonitorFailure(): Skipping reassociate since gateway was never found.

The following revision refers to this bug:
  https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/1709b45b60b9ea26114ba9643b0a22a5876c3ff6

commit 1709b45b60b9ea26114ba9643b0a22a5876c3ff6
Author: Micah Morton <mortonm@chromium.org>
Date: Tue Jul 31 23:37:25 2018

shill_login_user: Ensure shill user profile dir is owned by shill:shill

We need to chown this dir to be owned by shill:shill even if it already
exists, so that when we update CrOS devices to running shill as
shill:shill (instead of root:root), the dir gets updated to the correct
permissions.

BUG=chromium:867171, chromium:867685 , chromium:865184 , chromium:867680 , chromium:864874 , chromium:865789 , chromium:866041 , chromium:866559 , chromium:866961 
TEST=flash 10820 image to lulu device. log in as user. configure VPN
stuff. flash new 10888 image to lulu and update shill_login_user script.
login and notice that these problems go away.

Change-Id: Ib487d3a36a7b351887e5c101f1e797a0ab21c3b9
Reviewed-on: https://chromium-review.googlesource.com/1153841
Commit-Ready: Micah Morton <mortonm@chromium.org>
Tested-by: Micah Morton <mortonm@chromium.org>
Reviewed-by: Abhishek Bhardwaj <abhishekbh@chromium.org>
Reviewed-by: Micah Morton <mortonm@chromium.org>

[modify] https://crrev.com/1709b45b60b9ea26114ba9643b0a22a5876c3ff6/bin/shill_login_user

Not able to reproduce this issue on 10928.0.0 (Babymega/Coral), hence closing the bug. Will re-open this bug if the issue pops up again.

Same story here, after updated, Only Guest access works normal, and off course Open Wifi, my user profile does not, unless I use the toggle button.  Samsung Chrome 69.0.3494.0

Same pics too. Nice UI but serious problem with this Wifi limitation.