> Lenovo x131e devices won't connect to most WiFi points

It looks like this device was released in Dec 2012; presumably it has not been this way for 5 years, so maybe something recently regressed.

Is this happening for every stout device that we can test, or just one unit?

Can you run `iw reg get` from a shell?

It would also be useful to look at results from parrot, stumpy, and link, since they use the same AR9462 wifi chipset.

I tried our x131e device with same chipset and it would connect without a problem. I also asked about .ac APs, thinking that they might've disabled .n on them for some frequencies, but it seems not be the reason either.

There must be something I'm missing in their environment, I think.

Hello Team, I would like to know if there is any updated about this. 

I haven't heard any updates about this situation.  I see your post above stating "There must be something I'm missing in their environment, I think." What other information do you need to see why we can only use certain channels?

cernekee@
As you requested, the customer has provided the output.

localhost / # iw reg get 
country US: DFS-UNSET 
(2402 - 2472 @ 40), (N/A, 30), (N/A) 
(5170 - 5250 @ 80), (N/A, 17), (N/A) 
(5250 - 5330 @ 80), (N/A, 23), (N/A), DFS 
(5490 - 5730 @ 160), (N/A, 23), (N/A), DFS 
(5735 - 5835 @ 80), (N/A, 30), (N/A) 
(57240 - 63720 @ 2160), (N/A, 40), (N/A) 
localhost / # - 5330 @ 80), (N/A, 23), (N/A), DFS 

cernekee@
Is there any update that can be shared with the customer?
Please let us know if you need additional info.

Is this happening for every stout device that we can test, or just one unit?

It would also be useful to look at results from parrot, stumpy, and link, since they use the same AR9462 wifi chipset.

-Multiple devices are affected.
-Customer has problems only with Lenovo x131e, they do not have other models being affected and unfortunately none of the mentioned on this comment.

we got additional information from the customer listed below.

=============================
- When did the issue start, or what triggered the issue? 
There are some Chromebooks that are on version 47 not working, so customer is not sure when this issue started. 

- How about latest OS version. 
Customer has same problem on 65.0.3325.184 

- What devices are able to connect? 
ThinkPad 11e Chromebook 3rd Gen. Stays connected 

- All Lenovo x131e are not able to connect or only some? None of the Lenovo Thinkpad X131e Chromebook are able to connect with any channels but the 36 and 161. 

Customer has tried many channels, including 132 and 149 and none of them worked except for 36 and 161. They don't want to have all of the classrooms running on the same wifi channels to help with load distribution.
==========================

Please let us know if you need additional info.

This issue has been occurring since January and we haven't really had any movement other than have us run a few tests.  We are frustrated with this issue and the support we are receiving.  If you want to state that Google support will not fix the issue I can let our administration know and we can move on to another device. 

Thanks,

Alex   

> Debug log -
> https://drive.google.com/file/d/1qP4dWCyp5ZGa5LhW62Bf4FX3wIhn_cVy/view?usp=sharing

These logs appear to be from an ultima (Intel AC7265 + Linux 3.18) not a stout (Atheros AR9462 + Linux 3.8 + Wireless 3.4).  Does ultima show the same problem as stout?

In the log I see APs on a bunch of different channels, and multiple successful connections at 5320 MHz = channel 64.

Channel 64 is a DFS channel; is it possible that the stout Chromebooks are able to connect on non-DFS channels but not on DFS channels?  132 is another DFS channel; 149 is not.

Can you provide the output of `iw dev wlan0 scan` (it should be several pages long) and any debug_logs from failed connection attempts to APs on the "bad" channels?

Attached are the log files.  

Note the WiFi that should remain connected is "Wolves" and no other.  Please note that my test included getting a stronger signal and move to another room with an AP that doens't have the known good channels and the chromebook can't switch to that AP.  Again we have Cisco AP's and a Cisco AP controller.  Chromebook 11e models work as expected with the variety of channels or auto. 

Thanks,

Alex 

Deleted: debug-logs_20180424-143044 260 KB

debug-logs_20180424-143044 260 KB View Download

Deleted: Log File.docx 16.1 KB

Log File.docx 16.1 KB Download

Looks like debug-logs_20180424-143044 is from a stout.  It shows a successful association with the BSSID ending in :3f:3e at 5765 MHz (channel 153).

The `iw dev wlan0 scan` results show one "Wolves" AP on 5805.  This Chromebook does not see any other "Wolves" APs.  I do not see AP :3f:3e in the scan results.

The scan results do show other APs on channels 1 (2412), 4 (2427), 6 (2437), 9 (2452), 11 (2462), 36 (5180), 40 (5200), 48 (5240), 52 (5260), 64 (5320), and 153 (5765).  14 of these APs show a hidden SSID ("\x00").

Based on this information I don't think the radio is having any trouble tuning to different channels; it is more likely that the problem is related to hidden SSIDs.  Could you please check:

1) Does the problem go away if all APs are set to broadcast their SSIDs?  (You can verify this with `iw dev wlan0 scan | grep SSID:`)

2) If you navigate to chrome://network then click the (+) icon next to "Wolves", do you see a HiddenSSID property somewhere in the configuration properties?  Is it true or false?

Our goal is to leave ournetwork SSID's hidden?  If the test comes back successful with the broadcasting SSID will you continue to work towards getting this to work with the hidden SSID?

Yes, it's just an experiment.  If we establish that stout is having trouble connecting to hidden SSIDs that are properly configured as such, we'll get that fixed.

Note that there are some hardware limitations around hidden SSID support, because they require a special scanning procedure:

https://support.google.com/chrome/a/answer/6357444?hl=en

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

We are experiencing something possibly similar. Dell Chromebook 11 (3180 model) with the Intel AC7265. Logs here: https://drive.google.com/drive/folders/1G1xDwCkoLpAEWzl8SGRmVB_xA6Yz6tkv

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.