Just to add more information we've been on the non beta version and we get the same results.

Also please reference this forum.  The info for this model is toward the bottom.

https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/chromebook-central/A_WvfFdEYjE/kTqjjB54CAAJ

We are seeing the same issues here: HP Chromebook 14 G3 connecting to 5 GHz radios. Access point models HP 425 and MSM 422. At the same time our Chromebooks have no issue connecting to our Aruba 204 5 GHz access points.

This happens for all URLs?  HTTP, HTTPS, Google-owned and non-Google owned domains?

Sounds like a ChromeOS systems issue, rather than the user mode network stack.  That having been said, if one of you can attach a net-internals log, I'll see if there's anything obviously weird going on the user mode side of things.  instructions:  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

I would say the connection is slow no matter what you try to do.  The sites mentioned are just to give us a speed value.

Here is the output of the net-internals. Let me know if you need more.

Deleted: net-internals-log.json 1.5 MB

net-internals-log.json 1.5 MB View Download

Prior to the capture my HP Chromebook 14 G3 was connected to an Aruba 204 access point 5GHz AC radio. I then connected to an MSM430 HP access point 5GHz N radio to perform the capture.

Chrome OS was 51.0.2704.103 

Thanks for the log, schickler!  It doesn't point to any partcilar thing being slow - sometimes DNS lookup is really slow, sometimes connecting a socket is slow, sometimes negotiating SSL is slow, sometimes getting a response after a request is sent is slow.  Everything also happens quickly sometimes, too.

I'd say the issue is either problems with the system TCP stack (Though we see both TCP and UDP issues), or the CPU or IO thread is busy at certain times, causing everything to be unresponsive.  When this is happening, are other fully loaded tabs responsive?  Do they smoothly scroll?

The Chromebook itself is still responsive. New tabs are able to be opened, scrolling is smooth. Just when the network is accessed the ping times skyrocket and pages are unable to load.

Thanks!  Punting to the Chrome OS systems team, then.

Here is a net-internals/#chromeos wifi debug capture using chrome 52.0 connecting to an HP MSM430.

Deleted: 52-debug-logs_20160823-114129.tgz 4.5 MB

52-debug-logs_20160823-114129.tgz 4.5 MB Download

We have multiple log files available for the issue. 

I cant image what in the wifi access point can impact the OS in this way.

Falco.4389.92.0 works.
Kip.5216.227.58 works.
Nyan_Blaze.5771.63.0 is the problem.

Can you please take a wireless packet capture while running the speed test? Thanks,

I hope this is what you're looking for.

Deleted: documents-export-2016-08-29.zip 7.5 MB

documents-export-2016-08-29.zip 7.5 MB Download

I am able to stream video on any 5 GHz N channel (20MHz and 20/40 MHz) provided the VSC allowed wireless rates did not go below 48 Mbps. 

Deleted: wireless rates.PNG 18.1 KB

	wireless rates.PNG 18.1 KB View Download

Do you have minimum bitrate configured for the MR18?

Sorry, all my posts are applicable to HP access points and controllers. We are having the same issues as the folks in the Meraki environment. 

Ah, got it. I've looked at some PCAPs and it looks like the STA is not advancing its BA SSC the way I would expect. I've tried the same client out-of-box and upgraded. The factory ChromeOS image works and the upgraded image does not.

Factory: 39.0.2171.96, Platform 6310.68.0 (Official Build) stable-channel nyan_blaze, Firmware Google_Nyan_Blaze.5771.63.0

Upgraded: 52.0.2743.116, Platform 8350.68.0 (Official Build) stable-channel nyan_blaze, Firmware Google_Nyan_Blaze.5771.63.0

My current working theory (based on an in-house test rig) is that the BA is not being RXed by the AP because of some TX change by the STA.

Is there any way of modifying the "allowed wireless rates" in the Meraki management system? Maybe this will make the MR16 and MR18 usable.

We're having similar issues with Samsung Chromebook 2s on MR16 access points. Have tried multiple Chrome OS versions (stable, beta, dev), but looking at the signal strength on one of the Chromebooks, it varies wildly, from 0 dB to 100 dB+, and then back to 0 dB, all within a matter of seconds. Tried modifying the radio settings on the MR16, forcing the Chromebook to 2.4 GHz, which seemed more stable, but the signal still varied.  We do have our min. bitrate set (to 6Mbps).  Will post net-internals.  

Here's the net-internals log.

Deleted: net-internals-log.json 989 KB

net-internals-log.json 989 KB View Download

friendly ping

yoshiat@, please triage.

@snanda
Do we have cycles to look into this?

We've looped in Marvell wifi team to help with this.

pushing up to P1 because the issue seems to be effecting multiple domains and multiple vendors. 

Any updates?

We're trying reproduce the issue with our partners.

I'm also experiencing this issue with our acer Chromebook 13 C810 series. After updating is when we started having this issue as well. The latest version so far that I've seen that was still working fine was v49. Not sure if this issue would be present in 50 or 51, but did start with ones updated to 52 and at 53. We have the same Meraki access points as others that have reported this issue (M16). 

We've confirmed with Google that we're having this same issue with our Samsung 2 11" (XE503C12) and Meraki MR16 access points at 5 GHz. I contacted Meraki and was able to get the "2.4 GHz only" option under band selection.  Just a workaround until a fix comes out.

Is there a known list from google of models affected by this problem?  We have multiple models in our school districts but I have yet to find another model with these issues.  However, I also have not been looking, given I thought it was just the HP chromebook 14 g3 and some other samsung model.

Samsung models with Marvel chipsets on intel motherboards are affected.
Meraki enabled 2.4GHz only option for our District.
We have a separate ssid for Chromebooks.
Enabled it today and all of the Chromebooks are working.

Samsung models with Marvel chipsets on intel motherboards are affected.
Meraki enabled 2.4GHz only option for our District.
We have a separate ssid for Chromebooks.
Enabled it today and all of the Chromebooks are working.

Thank You



Frank Brooks


Information Service Specialist
Department of Instructional &Information Technology

Felix Festa Middle School

Clarkstown Central School District

30 Parrott Rd.

West Nyack, NY 10994

845-639-6300 Ext. 5437

845-406-7024



Click link to read our email disclaimer:
www.ccsd.edu/emaildisclaimer

After looking some more at the PCAPs, it appears that in the bad case the ChromeOS device is sending ACKs at MCS0 13.5Mb/s (sometimes with the greenfield bit set), which is not in the basic MCS set. In the working case, the ChromeOS device is sending ACKs at legacy 24Mb/s. This just means that the AP is not RXing the ACKs, so it is retrying, leading to excessive RF utilization and DOSing the RF environment.

Adding M-54 to highlight the urgency. This is not a recent regression so not blocking stable. We have meraki directly engaged so hopefully we can get resources to triage this.

Good Afternoon.  I am also receiving issue with V53.  We have another Chromebook Cart with V50 that is working fine.  Below is the information on this issue which should be resolved with the next update, and how to get on the internet in the meantime:

Thank you for contacting Google Cloud Support.

I understand you are experiencing issue connecting your HP Chromebooks to your Wireless access points. The description of the issue you are experiencing matches the behavior of a known issue our engineering team is investigating. 

The issue affects Chrome devices trying to connect to access points using the 5GHZ signal. As a temporary workaround, you can configure your access points to transmit a 2.4GHZ signal only, which should allow those devices to properly connect to your access points.

This issue will likely be fixed through a Chrome OS update, which is currently targeted at version 54, but it is still to be defined by engineering. I encourage you to follow the public tracker to receive updates when the issue is resolved.

Have this been confirmed as fixed in M54 (Beta)?

Sameer, is there another bug that is tracking the progress/fix with Marvell?

Yes, it is being tracked here: crosbug.com/p/58417

We have received firmware from Marvell that has the fixes.  That firmware is in TOT and has been cherry-picked to M55 and should be hitting dev channel in the next day or two.  Once we have enough bake time on dev, we will cherry-pick it into M54 stable branch in a week or so.

Hi all,

Is there an update on this issue? Has this been fixed in 54?

Thanks!

Yes, the fix was pushed out in version 8743.76.0/ 54.0.2840.79.

@ jeremy/ schickler can you close this as verified, if you no longer see this issue with the latest stable release?

I did not open this case, so I don't think I can close it.