WiFi Association Issues on Chromebook

Technical Support for Routers
1

I have an Acer Chromebook which can connect to pretty much every AP I’ve ever tried.

Except for the MT300N-v2. I get various errors, lately all pretty much “Failed to connect to network. Unknown error.”

There are known problems with Chromebooks. No exact explanation, however, the belief is that there is a problem with WPA or WPA2 encryption using TKIP. Google Chrome does not support it. Other reports indicate that restarting the router can solve the problem.

Whatever the cause, there is clearly something a bit non-standard about the MT300Nv2. I do NOT see this problem at all on the AR-750S (Slate) router on either band.

I’ve tested in Router mode with wired and wireless connections on the WAN side.

I am always able to connect when the network is in OPEN mode, though it seems to take a bit of time.

I am almost always able to connect the FIRST time to the network. After than, almost never and I get that error message. If I “forget” the network and reenter the password, I am generally able to reconnect.

Reconnecting to a network, however fails most of the time.

I realize the problem is almost certainly in the Chromebook OS, but since this appears only on the MT300Nv2 router, I’m guessing there’s something a bit marginal about its confirmation or operation.

I have tried going into the wireless config file and changing the encryption options to “psk2” and “psk2+aes” and “psk-mixed+AES”, but all exhibit the same symptoms…

I tried to change settings in /etc/wireless/mt7628/mtmt7628.dat for AUTHMODE, but they got overwritten.

Questions…

  1. IS there an ability to log the details of the WiFi association exchange to see if we can further pinpoint the problem?

  2. I’ve googled in general and searched the forums here without luck. Is this problem known to GL-iNet? Are there any solutions or recommendations?

    50%20PM

    02%20PM
    02%20PM813×475 23.6 KB

2

No response yet? Still unable to connect most of the time.

A bit of digging with Airtool & Wireshark find that there’s a interruption and after 6 seconds, the M300Nv2 disconnects with a reason code of 15 - 4-way handshake timeout. Prior to the failure, the Chromebook has sent multiple (>10) retransmissions of an authentication request. Seems the mango is replying to them separately. At some point this stops and then the mango times out.

I was able to get connected once and capture a trace of that too. Alas, it’s not too clear what the difference is to me.

Can anyone look at these traces and see if they can see some difference between the successful and unsuccessful association attempts?
Connection Traces.zip (5.3 KB)

3

Thanks for reporting this. Do not have a chromebook at hand. But asking if anybody has chromebook so that we can try.

4

MT300N-V2 uses AES encryption by default, not TKIP.

If you use your laptop connects to MT300N-V2, is it working fine?

5

Regarding “TKIP”, I was just reporting what the talk in the Chromebook community was. I mentioned that because it’s not clear from the GL-iNet web app that when I pick “WPA2/PSK” or “WPA/WPA2 PSK” just what ciphers are actually selected. I eventually (manually) specified “psk2+aes” and the problem remains.

I’ve been able to connect multiple laptops (Windows and Mac), ROKU devices and Amazon FireTV devices to the mango. None have problems connecting… I’m afraid this is the only Chromebook I have. Perhaps .I can go to an electronics retailer and try another brand of Chromebook. (Rather convenient because it can be powered from the USB port.)

For the record, this Chromebook is an Acer 11.6" 32GB Chromebook 11 C732 model with a N3350 CPU running at 1.1GHz. Not sure exactly how to find out what chipset is used.

The mac address says it’s an Intel device. Googling “which chipset 68:ec:c5” will send me to [this] page. (Intel Dual Band WirelessAC 3168 Product Specifications).

What is interesting is that at least once it was able to connect. Most of the time, however, it times out.

6

Appreciate it if you can go and testing. I didn’t find a lot of chromebook on sale locally here.

7

Had an opportunity to check out two more Acer Chromebooks (seems to be most popular brand in stores)

One, and Acer Chromebook R13, worked fine.

The other, an Acer Spin 11, failed with the same timeout error as my Chromebook. Mosty - because it did connect one time out of the many I tried.

Looking thru the decodes, I notice that the Chromebook is retransmitting an Association Request over and over. It’s a retransmission - same SN and the retransmit indicator frame control flag field is set.)

The mango is responding to each request with an Association Response message, but those have increasing SNs.

This leads me to think that the Chromebook is not accepting the mango’s responses in some way. That would lead to the Chromebook simply retransmitting the request over and over.After some number of retries/time/response/whatever, the Chromebook stops sending. 5 or 6 seconds later, the mango times out and deauthenticates. Thus the :4-way handshake timeout".

When I llook at the successful connection on the acer R13 (always succeeds), I see only two Association Requests going out and one response. Then the parties go into an immediate EAPOL key exchange.

I’ve got two pcaps of the successful (Acer R13) and failure (Acer Spin 11). to upload.

Now, the ‘failure’ trace first has a timeout (packet 1344). But there’s a 2nd connection attempt in that file that succeeds (look after packet 2920. Except for the SN, the Association Responses look identical to me.

In the successful case there are 16 total association requests over 0…07 second (packets 2846 to 2922.

in the failing case, the Chromebook sent only 7 requests over 0.035 sec. Then the Chromebook stopped sending association requests and the mango timed out.

The mango’s mac is 68:ec:c5:24:59:0a (use as a display filter). The SSID is “Test”.

Hopefully someone can look over these pcaps and see something unusual.
2019-08-21 Chromebook Testing.zip (410.6 KB)

8

Maybe it is caused by compatibility.

Thanks for your informations. MT300N-V2 didn’t start 4-way handshake after authenticated and associated, but not sure why.

They are authenticated:

image
image773×58 3.33 KB

They are associated:

image
image936×245 7.51 KB

But MT300N-V2 didn’t start 4-way handshake, InterCor_ec:20:39 continues to send association request.

I saw InterCor_ec:20:39 enabled short preamble, while mt300n-v2 is disabled it by default.

image
image757×307 13.6 KB

The successful Chromebook:

image
image1038×523 23.5 KB

9

Your are correct about who is sending the Association Requests.

My first question is “Is the Chromebook receiving but rejecting the Association Response messages, or is it not receiving them at all?”

When I look at the Association Response, it’s followed by an Acknowledgement. I have to assume that that means the Chromebook has, at the least, received the Acknowledgement packet.

Looking at the Association Requests for the ultimately successful attempt:

Avg 0.006
Min 0.001
Max 0.015
Count 16
Time to 4-Way 0.021

(The Count above includes the original AssReq and all retransmissions.)

For the unsuccessful attempt,

Avg 0.007
Min 0.001
Max 0.022
Count 11
Time to Dissassoc 6.239

I don’t see anything particularly different. Clearly it takes a bunch of AssReq/AssResp’s before the handshake. But then sometimes, it down’t work.

Nothing obvious.

Looking at the successful attempt from a different Acer device (R13), I see only two AssReq’s, one AssResp and the 4-way starts before the mango even sends a 2nd AssResp.

If I compare the failing Chromebooks (Spin 11 and C732) to the successful one, there are a decent number of differences in the AssReq.

The best way I know to see them is to export a full dissection from wireshark and then compare them side by side in a comparison tool. I use BBedit’s compare capability.

I’m attaching two text files and you can see a decent number of differences. And, yes, Short Preamble is not allowed on the successful R13 connect.

24%20AM
24%20AM1322×141 26.1 KB

But, then there are a lot of other differences in the request. E.g. in HT Capabilities Info, A-MPDU parameters, RX Supported Modulated & Coding, Transmit beam forming, and extended HT capabilities.

19%20AM
19%20AM1528×171 36.5 KB

58%20AM
58%20AM1613×332 87 KB

42%20AM
42%20AM1581×320 87.4 KB
!

So it seems there are still two open questions…

  1. Why do some Chromebook models continue to retransmit AssReq packets after receiving a response from the mango?

  2. Regardless of the above, why doesn’t the mango start the 4-way handshake after sending a response?

Connection Traces 2.zip (426.6 KB)
:

10

I think it didn’t receive the associated response packet from mango, and mango didn’t start 4-way handshake.

AP will do security validation before start 4-way handshake, something may have gone wrong, we need to reproduce this issue and debug the wireless driver.

Sorry, I am not sure as well. I don’t have a Chromebook in my hand. It needs debug the Wireless’s driver.

11

I have to assume the Chomebook did receive the Association Response since every there is an Acknowledge packet for every response going back to the mango.

Question: if the mango sees “something wrong” or incompatible with the Association Request, will it still give a response but not proceed to the next step?

Also, are there any options to trigger additional logging in the wifi driver so I can get additional detail about what the mango is doing?

I will try to find out just what chip is in the Chromebook and see if I can find another laptop or tablet using that chip. Hopefully this can be determined from the mac address. OTW, I’ll have to open the Chromebook up.

I also posted a version of this problem on the Acer Community forum here, here but got no responses yet.

Perhaps you could contact Acer China? There are phone numbers and email addresses on this page. If you explain the situation, they might loan you one. My particular model is C732-C6WU. I don’t have teh full model number for the Spin 11. I will be going out again to a store today and will try to find more devices with this problem.

12

A bit more troubleshooting information.

There was a capabilities mismatch with short preamble. This shouldn’t have mattered as negotiation should settle on “disable”. Still, I disabled short preamble on the Chromebook and that made no difference.

Also, the mango was using a 40Mhz band while most of the APs I connected with quickly were 20MHz. Forcing 20Mhz (set speed to 150 instead of 300) did not make any difference.

One final variation: With encryption turned off, the unit connects most - but not all - of the time, but it takes a long time. I will capture traces later.

13

Seems none encryption doesn’t need 4-way handshake.

The main issue should be mango doesn’t start 4-way handshake. I consider the wireless driver has some flaws.

Could you please capture the traffic without encryption?

14

Spent over an hour at an electronics store. I have a whole bunch of captures on a number of Chromebooks from different manufacturers which didn’t work.

Give me some time to sort them out and document the captures.

Also, I tried this on a different mango which failed, but I’m going to double check this and try my Slate (which seemed to work) just to confirm that it’s a general mango problem and not a problem with one unit.

15

Thanks. Pls let us know which model that does not work. We may search around and find the same model.

16

As a sanity check, I tried connecting the troublesome Acer Chromebook to another mango I have. It failed to connect. I tried with a Slate unit. That one connected perfectly.

Summary:

Acer C732 Chromebook against a 2nd mango
Fail
Trace: Fail C732-Second Mango 1.pcap
Chromebook mac 68:ec:c5:24:59:0a
Mango mac e4:95:6e:4d:3d:af
Authentication at packet 384
Multiple retransmissions of Association Request (SN 16)
Eventually stops. No Deauthorize message this time… Mango never sends key exchange.

Acer C732 Chromebook against Slate
Trace File: Success C732-Slate 1.pcap
Chromebook mac 68:ec:c5:24:59:0a
Slate mac: e6:95:6e:49:af:18
Success
Only a single Association Request. Slate immediately starts key exchange.
Traces 2019-08-26.zip (89.1 KB)

17

Test with HP Chromebook model 14-da0011dx.

Fails with Deauthorization for timeout on 4-way handshake.
Device mac address: b4:69:21:04:c0:b8
Mango mac address: e6:95:6e:5c:5c:32

After first failure, I rebooted the router (remove power, wait, power) and it still failed.

pcat trace attached.

Fail HP 14-da0011dx-Mango 2.pcap.zip (418.6 KB)

18

Tested mango against Lenovo Yoga C630. It failed to connect multiple times with 4-way handshake timeout before connecting.

Lenovo mac address: 00:bb:60:60:ca:11
Multiple Association Request retransmissions first at 3554, last at 3598
Deauthentication at 6294, about 6 seconds after last Association Request

Fail Lenovo Yoga C630 1.pcap.zip (800.6 KB)

Failed more than once. pcap included as well.

Fail Lenovo Yoga C630 2.pcap.zip (962.4 KB)

19

Tested Acer Chromebook model cp315-1h-p8qy

It took a long time to connect the first time and then reprompted for password. I’ll assume I had mistyped the password. It connected the second time.

Still, there are a huge number of Association Requests that are retransmitted before the key exchange finally happens.

Acer mac address is 04:d3:b0:b4:22:7e

While all the mac addresses in these reports look different, on Wireshark they all decode to something starting with “Intel_Cor_” based on the first three bytes of the mac address.

Could all these devices be using the same Intel WiFi chip? Or a family of chips with the same driver?

Does GL-iNet have a way to reach out to Google (Chrome division) and raise this issue or submit a problem request? Even if you fix the mango driver, it looks like the Chromebook is also misbehaving.

Success Acer cp315-1h-p8qy.pcap.zip (771.1 KB)

20

Tested Dell Chromebook model c3181

mac address 74:70:fd:ef:ec:4b

Initially got a connection, but it dropped on its own.

Looking at another trace where it didn’t connect, I see the multiple Association request retransmissions and responses, a 6 second delay and a Deauthenticate (packet 3932) for handshake timeout.

Mixed Dell c3181 1.pcap.zip (765.8 KB)

Oh, by the way, Wireshark also decodes this mac as Intel Corp.