WiFi Association Issues on Chromebook

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.


  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?


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)

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

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

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

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. (https://ark.intel.com/content/www/us/en/ark/products/94854/intel-dual-band-wireless-ac-3168.html).

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

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

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)

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:

They are associated:

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.

The successful Chromebook:

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.

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.


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)