New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 884177 link

Starred by 7 users

Issue metadata

Status: Verified
Owner:
Closed: Sep 24
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Enterprise configured Wifi SSID overrides connected Ethernet

Reported by russell....@ict.ekservices.org, Sep 14

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36
Platform: 10895.56.0 (Official Build) beta-chanel kip

Steps to reproduce the problem:
1. Plug Chromebook into a Wired ethernet network - working as normal
2. Configure an GSuite Device policy to distribute a Secure Wifi network (that is contactable) SSID, WPA2-PSK, Applied to Devices, SSID Hidden: No, Auto connect Yes, Restricted to Chromebook.

3) When the chromebook receives this enterprise wifi config.  If SSID is available, it will connect and takes precedence over the already connected Wired Local network.  

What is the expected behavior?
"Connected" ethernet connection should remain primary connection and new enterprise distributed wifi connection should be saved and only connect when wired is disconnected
As detailed here:
https://support.google.com/chromebook/answer/1056578?hl=en

What went wrong?
This seems to only happen if the saved wifi configuration has been installed using enterprise management.  The user has to then manually disconnect from this network to wired network to reconnect.

This does not happen when a saved wifi network is manually created.  In that scenario , even if the user sets Auto Connect, the Wired connection retains top precedence.

Did this work before? Yes 68.0.3440.118 

Chrome version: 69.0.3497.95  Channel: beta
OS Version: 10.0
Flash Version: 31.0.0.108

This is now causing problems in our enviromnet where we've pushed out wifi settings that our staff can use for public access wifi.  If deskbound, that normally use wired connection which allows access to internal resources.  Some users have upgraded to the 69beta channel and have reported not being able to get to once working internal sites (DNS failures due to public wifi now being primary connection - not Wired).  Colleagues using 68 Stable (and past versions) do not experience this as Wired remains primary.  

Working in  68.0.3440.118
10718.88.2 (Official Build) stable-channel elm
 
Components: OS>Systems>Network
Status: Untriaged (was: Unconfirmed)
I was able to repro this. If Wi-Fi network is enterprise configured, it disconnects in 68 and stays connected in 69 when plug a wired Ethernet network (see attached screenshots).

Google Chrome	68.0.3440.134 (Official Build) (64-bit)
Platform	10718.104.0 (Official Build) stable-channel coral-unibuild

Google Chrome	69.0.3497.95 (Official Build) beta (64-bit)
Platform	10895.56.0 (Official Build) beta-channel coral-unibuild
FYI, there is no such problem in 70 Dev.
Cc: pmarko@chromium.org steve...@chromium.org
Owner: hendrich@chromium.org
Alex, please work with shill folks to make sure we maintain the old behavior.
Cc: atwilson@chromium.org jayhlee@chromium.org royans@chromium.org
This bug was introduced by http://crrev.com/c/1120255 (release-R69-10895) and fixed with http://crrev.com/c/1136437 (release-R70-11021).
I reached out to royans@ and jayhlee@ and asked whether we should push for a respin/merge.
Status: Fixed (was: Untriaged)
Haven't received a respin confirmation from royans/jayhlee, so I'll guess this won't be fixed for M69 anymore, sorry. Should be fixed in M70 again.

Possible workaround: You can configure an ethernet connection (authentication=none) and then the M69 devices should not prefer the managed wifi over ethernet anymore.
Also, you may be able to set 'prefer this network' to true for Ethernet but not for the problematici WiFi network as a workaround.

Cc: vkasatkin@google.com hendrich@chromium.org cindyb@chromium.org marchuk@chromium.org
 Issue 891418  has been merged into this issue.
Hello Team,

I'd appreciate if I could receive a confirmation that the issue will be fixed with M70.

A customer is currently using a workaround for this issue, but would like to be certain that the new release will solve this problem for him. 

Thanks!
Yes, this issue will be fixed in M70. Sorry for the inconvenience.
Status: Verified (was: Fixed)
I have verified it in M70 and M71 as well.

Chrome OS: 11141.0.0
Chrome: 71.0.3572.0

Chrome OS: 11021.44.0
Chrome: 70.0.3538.55
Thanks for the fix.
- Do we have tests in place to make sure this doesn't happen again ?
There is a unit test for the networking sorting order. But since I made an intentional change to the sorting order back then, I also changed the corresponding unit test without realizing that this will also cause this bug. I can add a further test to the service unittest to explicitely check that ethernet is sorted above managed wifi. If somebody makes changes to the sorting order in the future, they would at least have to update both tests, hopefully making it more obvious.
Project Member

Comment 14 by bugdroid1@chromium.org, Oct 24

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/cb0dc904494a93db1fbbc4b2fa4065bdd00075fd

commit cb0dc904494a93db1fbbc4b2fa4065bdd00075fd
Author: Alexander Hendrich <hendrich@chromium.org>
Date: Wed Oct 24 20:03:15 2018

shill: Add test to prefer ethernet over (managed) WiFi

This CL adds another test to check that ethernet is sorted above
(managed) WiFi connections.

BUG= chromium:884177 
TEST=shill unit test ServiceTest.CompareEthernetOverManagedWifi

Change-Id: I0bdc7298b5c50e805e2d5343d24d251e62a4c94c
Reviewed-on: https://chromium-review.googlesource.com/1283611
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Alexander Hendrich <hendrich@chromium.org>
Reviewed-by: Ben Chan <benchan@chromium.org>

[modify] https://crrev.com/cb0dc904494a93db1fbbc4b2fa4065bdd00075fd/shill/service_test.cc
[modify] https://crrev.com/cb0dc904494a93db1fbbc4b2fa4065bdd00075fd/shill/service.h

Sign in to add a comment