So these models all fail to connect to Mango.
- Acer C732 Chromebook
- HP Chromebook model 14-da0011dx
- Lenovo Yoga C630
- Acer Chromebook model cp315-1h-p8qy
- Dell Chromebook model c3181
Yes, all those models have failed to connect at least two times.
I have provided a pcap trace for each of them. The thing they all have in common is:
- Wireshark’s vendor database reports all are using an Intel Corp wifi chip.
- The Chromebook constantly retransmits Association Requests. (The retransmit flag bits are set and the SN does not change.)
- The mango response to each Association Request with a new Association Response.
- The mango does not start the 4-way handshake.
- The Chromebook often stops the retransmissions.
- After between 5 and 6 seconds, the mango sends a Deauthentication message with an error code of 15.
I tested all these units against this mango:
I tested my Acer Chromebook C732 against this second mango to make sure it wasn’t a single mango hardware error:
These were purchased at different times.
The test against the other models was done with wifi settings:
- WPA2 PSK
- AES encryption
- SSID Test or TestGuest
- password “testtest”
- distance between chromebook and router 1 to 2 meters
- version 3.025 compiled on 2019-08-05 10:04:08 installed
The second mango I used to double-check was a brand new, right out of the box unit from Amazon unit running factory installed version 3.012. And, I have a third mango (an older one with colored LEDs) that rarely connects with my Acer C732.
I have tried all versions of PSK WPA/WPA2 and WPA2, AES and AES/TKIP. Problem shows with all. I have also tried OPEN connections. I see the same Association Request retransmissions though, obviously, there won’t be a 4 way handshake. These still time out on the chromebook side many times.
My suspicion is that there is something in the Association Request produced by a driver common to all these Chromebooks that is causing the mango to return an Association Response that is not acceptable to the Chromebooks. Since the Association Responses are acknowledged by the Chromebook, it looks like they have been received successfully. It’s possible, however, that the mango’s response is failing some validation and the response does not get recognized by the Chromebook. Furthermore, there must be something or some internal condition that prevents the mango from regularly starting the 4-way handshake. (I say “regularly” since the mango occasionally connects successfully after a stream of Association Requests/Responses.)
On a non-technical note, I want to let GL-iNet as a company, and the support team in particular, know that your responsiveness and engagement is excellent and is very much appreciated.
By contrast, I posted an issue on the Acer forums (here) and have received absolutely no response.
I submitted a problem report using the mechanism built into the Chromebook and - surprise - have received absolutely no response.
Thank You.
I see I was asked to test on an open network.
In general, the Acer Chromebook will connect at least half the time, though it usually takes a while.
I did a number of runs and found:
- There are often a number of Association Requests retransmitted, but not so many.
- It still takes a long time for the Chromebook to show “Connected”. I captured traffic and it seems to be more about DHCP than the 802.11 association.
In Trace 1 10-52-17 pcap file, authentication starts around packet 1746 and the connection completes pretty quickly.
However, there is a long DHCP sequence…
The Chromebook’s requests are never answered. And it’s over 12 seconds for the mango to send a DHCP Offer after the Chromebook sent a DHCP DIscover.
This happens quite a bit. Another sample with similar traffic and timing, Trace 2 110-6-22
Now, I tried connecting on two other computers and see different DHCP activity:
Trace 3
This sequence difers because the computer is requesting an address from an old lease that is not in the mango’s subnet. Hence the NAK. But the mango answers the first DHCP discover in about 4 seconds. That still seems way too long. Note that the two DHCP Offers differ by less than 7 msec.
Another try (Trace 4 11-17-15) with a different computer that had had an old address from a different subnet, produced essentially the same result:
We can see that Requests can be NAK’d quickly, but DIscovers take a while to get a response. Is this normal?
Once an address has been assigned (and the Request should not produce a NAK), things go differently (Trace 5 12-06-41)
The good news is that I can eventually get connected on an open network. Unless these are the expected DHCP response times, you might want to have a look in that area as well.
Again, with these tests, SSID is “Test” and the mac addresses are visible in the display filter on the above screenshots.
The zip of these trace files is too big to upload here, so I put them on my google drive here.
Thanks for the update. These are enough information. Pls give us some time to find a solution.
Chromebooks tend to use linux in-tree drivers for WiFi, and the supplicant is fairly strict…
WPA/WPA2 mixed means TKIP for the Group Key, and either TKIP/AES for the pairwise key.
For 11n - one needs WPA2/AES, and not mixed mode - the intel driver is a bit strict here, and so is the WPA Supplicant.
Look at the Association Request first, Intel may offer more than it can, but it can put mediatek into a bad place if configured for WPA/WPA2…
WPA2-AES has been around for a long time - there’s really not much reason to even have WPA as an option.
After reading this, thought I’d confirm with mango set to WPA2 only.
Two interesting runs. Both eventually connected after a series of failed attempts; all failures due to 4-way handshake timeout.
For the first run, I had the mango hard wired with an internet connection. Note that when I tested all the non-Acer C732 Chromebooks a few days ago, I had NO internet connection and the WAN side could have been attempting to connect to a previous connection.
First run (Trace1 pcap file) is an attempt to connect to TestGuest with a valid wired internet connection.
Authentication packet # / Deauthenticate packet #
1980 / 3422
3641 / 4749
5072 / 6156
Then, a successful connection! Authentication at #6361 quickly followed by a key exchange.
The second run was the same configuration, except that there was no internet connection, wired or wireless.
Authentication packet # / Deauthenticate packet #
498 / 1818
2121 / 3348
4116 / 5359
5587 / 6780
7021 / 8161
Then success at 8411.
Life is easier with this display filter:
wlan.ta==68:ec:c5:24:59:0a or wlan.ta==e6:95:6e:5c:5c:32
Pcap traces:
Traces 2019-08-28 WPA2-AES Only.zip (643.9 KB)
I have a working theory as to what is going on - I have a Chromebook with an Intel 7260 wifi adapter (and another with a QC-Atheros ath10k adapter), challenge here is that I don’t have a GL Mango device to validate the theory, as all my GL-iNet devices are Atheros based (AR9531, AT9331, or IPQ40xx with the B1300
Any updates on this issue?
I don’t have much to add - really busy with work stuff at the moment.
sfx2000 - perhaps i can test out your theory as long as it doesn’t require compiling or debugging drivers.
I was also hoping to hear from some of the GL-iNet staffaaaaaa if this has gone anywhere.
I’m deploying these as little WireGuard APs and all devices except the Chromebooks are working fine. Just that one hiccup…
Thanks,
Chris
Nothing new on this?
Sorry we don’t have new update on this issue. Still do not have a chromebook for testing. Let me find out what we can do.
Seems I’m not the only one with this issue.
This entry was just posted to the forum.
https://forum.gl-inet.com/t/gl-mt300n-v2-won-t-connect-to-chromebook-any-help/8888
Finally we had chance to find a chromebook and test. Thanks to Hong Kong’s peaceful days.
Surprisingly we can connect to MT300N-V2 without problem.
We asked a friend to test in the US. She cannot connect to MT300N-V2 with firmware v3.012. But after she upgrade to v3.025 she can connect without problem.
Google Chromebook 78.0.3904.92
Intel 7256 （Rev b9）
Alas, not all chromebooks show that problem… Here’s a list posted from before:
- Acer C732 Chromebook
- HP Chromebook model 14-da0011dx
- Lenovo Yoga C630
- Acer Chromebook model cp315-1h-p8qy
- Dell Chromebook model c3181
I appreciate the effort… maybe someone will come by with a chromebook that is affected.
Quite a few chromebooks I tested did work. I have to presume that it’s the driver that comes with the particular chip set on the motherboard.
Sadly, I have no way to find out which chip is in the machine from the mac address (e.g. 68:EC"C5:24:59:0a).
I have this issue as well, and while I don’t understand the dialog going on, I thought it might be helpful to mention that for me, this issue started when I upgraded the firmware to version 3. I used this router with my Chromebook for a long time with version 2, which I think is what it came to me with, and never had a problem. But as soon as I upgraded to version 3, it quit working. (The router works fine with devices other than my Chromebook.)
You can see the problem in the wifi connection in the Chromebook setup. There is a setting called “Proxy–Connection type”, which is ordinarily set to “Direct internet connection” and is greyed out so you can’t change it. That’s what it is for any other router, and what I think it used to be for the GL.inet router with the version 2 firmware. But in version 3, it’s a dropdown list, which I think means the router is not identifying itself to the Chromebook correctly. Sorry, I know that’s not much of a description but I’m not technical.
Hope that helps. I bought the router primarily to use the Chromebook with unsecured networks, and it worked fine for a long time, so I was disappointed when the firmware upgrade broke it.
Is it firmware v3.025 you are trying?
The firmware on mine is 3.024, and it isn’t showing any updates available.
Mine is a different router from the one here: a GL-AR300M-337. But as my problem is the same I thought it might shed light on what is happening.
I’ve been through resets, etc., but as the router (in WISP mode, haven’t tried any of the others) works with devices other than a Chromebook without problem, I concluded the problem is specific to Chromebooks.
Thanks.