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

Issue 740996 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment

ChromeOS client feature: Option to force DHCP release/renewal and WiFi rescan/reassotiation

Project Member Reported by vkhabarov@chromium.org, Jul 11 2017

Issue description

Case number: 12636771
Customer Domain: warbyparker.com

What steps will reproduce the problem?
1. Connect to WiFi network 
2. Move to another location (another floor) which uses another subnet, but same SSID
3. Use internet

What is the expected output?
- Device receivers new address from DHCP (or could be forced to do so) and experiences fast network speed

What do you see instead?
- Device stays with the same address, turning WiFi on/off doesn't help, network is really slow

How often does it reproduce? (Always, sometimes, hard to reproduce?)
Always

[ Detailed FR request. Explain why this FR is important with metrics if possible ]
Situations, when network renewal is needed, arise from time to time. 
This particular customer has network configuration, where different floors have different subnets, but same SSID, which affects other systems as well, but could be solved by switching WiFi off and on. As far as I understand, it won't help in ChromeOS by design, so he needs some way to force DHCP release/renewal and/or WiFi rescan/reassotiation
 
Cc: kirtika@chromium.org snanda@chromium.org
Owner: ----
+kirtika/snanda 


Comment 2 by snanda@chromium.org, Jul 18 2017

Cc: yoshi@chromium.org cernekee@chromium.org
If turning wifi on/off didn't help, it's unlikely to be related to DHCP renewal.

What speeds did you get?  How did you measure the speed?  What were you comparing the speed to?
> This particular customer has network configuration, where different floors have different subnets, but same SSID

Searching around on the internet, it seems like the fix for this is to either enable Layer 3 roaming or enable the Force DHCP option on the APs.

I see a Mobility Domain IE in the beacon format; that seems related to 802.11r.  If there was an IE that told the client it would be transitioning to a different subnet, that might be the indication we need.  Unfortunately I'm not aware of one (please correct me if I'm wrong).

Comment 4 by yoshi@chromium.org, Jan 3 2018

Cc: -yoshi@chromium.org
Labels: Enterprise-Triaged

Sign in to add a comment