Complaint: cannot connect to mango v2 with chromebook (solved)

@czsmith @chromebook
I read the problem mentioned in this link(How To Fix The WiFi Out Of Range Problem On A Chromebook | The Fake Geek),and it is very similar to the problem you encountered. Can you modify the wifi configuration according to the following screenshot,add ht_distkip and wmm to wifi-device. If you cannot modify the routing background configuration, I can provide you with new test firmware.


The steps are as follows:
1.ssh login to the routing background, you can refer to the following link
SSH to the Router - GL.iNet Docs
2. After login, add ht_distkip and wmm options to / etc / config / wireless file wifi-device
config wifi-device ‘mt7628’
option type ‘mt7628’
option htmode ‘HT40’
option ht_txstream ‘2’
option ht_rxstream ‘2’
option hwmode ‘11g’
option ht_distkip ‘1’
option channel ‘6’
option noscan ‘0’
option txpower ‘20’
option txpower_max ‘20’
option wmm ‘0’
option country ‘US’
option region ‘0’
option band ‘2G’
3. Restart the router, wait for the routing to complete, and try to connect again.

Looking forward to your feedback, thanks again.

One other minor thing I’ve gleaned from reading the forums…TKIP seems to cause problems for a lot of Chromebooks where as AES does not. Are you using WPA2-AES?

That is definitely true… We are aware of that… but it doesn’t seem to be the problem here…

I compared the Association Requests of chromebooks which successfully connected with those which didn’t. The section of the Association Request calling out the encryption (RSN) is identical in both. The request is calling for CCMP (AES) and PSK, so we’ve got WPA2/AES and not WPA/TKIP.

I also went into the openwrt configuration on the mango and forced encryption to AES-only but it made no difference.

One other thing I just noticed. Chromebooks have a tendency to disconnect from networks which don’t have an internet connection and switch to a saved network that does without giving any notification or asking if I want to stay connected to my Mango SSID which doesn’t have internet.

I have to agree with that in part… I’ve seen cases where a connection to the mango is lost and the chromebook moves on to a different connection when a connection attempt (or reattempt) fails. Of course, it only connects to known networks with the “connect automatically” option selected.

It wouldn’t surprise me that if the mango or chromebook drops a connection if the source wifi network is unavailable that the chromebook would go hunting for a new network, especially if the dropped network is not the first one by priority. It is also the case that some types of mango reconfiguration restart the network… something which happens to momentarily drop the wifi connection causing the chromebook to go looking for an alternative.

Each time I did this, the scan would get to 99% but would never finish, as the Chromebook would switch back to my wifi network which had an internet connection.

I would guess that the scan process might kill your connection momentarily (take its network offline momentarily), causing the chromebook to look for another network. The obvious solution is to use a hard-wired connection from the chromebook to the mango’s LAN port. If your chromebook lacks an ethernet port, there are plenty of cheap USB-Ethernet adapters which work OOB with chromebooks.

Alas @wellnw, I’m heading to the mountains without any chromebook. Can check back in with you at the end of December.

Out of curiosity, what do these two parameters change? I’ve use this page to get the parameters for the wireless file, but don’t see these. Searching the openwrt web site for “ht_distkip” or “distkip” returned nothing.

@wellnw - Not sure if you looked at the captures back in August, but I’m uploading a simple case of one chromebook which works and one which didn’t.

2019-08-21 Chromebook Testing Revised.zip (433.4 KB)

There are noticeable differences int he Association Requests. If you take a simple text comparison tool (say BBEdit) and compare the files “Successful Conection R13.txt” with “Failed Connection Spin 11-Reordered.txt”, you can see just what’s different. Obviously, ignore the stuff that doesn’t matter like times stamps, time measurements, sequence numbers, addresses and the like.

Note: the “Failed Connection Spin 11-Reordered” file had some Association Request elements reordered simply to line them up side by side and make a text comparison (diff) work better. The file “Failed Connection Spin 11.txt” has the original decode.

[The pcap files are also included if you want to see the whole sessions.]

I don’t think it’s caused by anything simply contained in the request - we have chromebooks which sometimes connect very quickly and sometimes which take forever to connect and sometimes never connect - yet send identical Association Requests. It could be the number of them or the timing of them or a combination of the request contents and timing.

For example, I can see that many devices (such as my iPhone) will send multiple Association Requests. The iPhone SE happens to send one AssReq. Then up to 3 more (flagged as retransmits using the same sequence number, not new requests) every 4 milliseconds. Then it stops and eventually the mango starts the key exchange.

Some chromebooks, send way more than 4 requests. The number and timing doesn’t seem to be in any particular pattern. Look at the failing pcap in WireShark, using the display filter “wlan.addr == 20:79:18:ec:20:39” starting at packet 1161 and ending at 1833. Lots of resends (verify by flag and the same SN). There are 9 AssReq’s over the course of about 50 msec, then over 6 seconds before the mango deauthenticates.

There are additional elements in the failing Association requests that are not in the failing ones.

Something is preventing the mango from advancing to the key exchange after this burst of Association requests and responses.

The Association Responses are identical in the successful and unsuccessful case. So the “end result” of the association negotiation is probably the same.

Looking at the successful case, There’s only a single Association Request sent followed by a key exchange 114 msec later. Wow…t that’s a long time.

This makes me wonder if there’s just a different resend threshold (remember, the iPhone also sent multiple times and still connected).

Or if the chromebook is really not receiving all those Association Responses correctly, causing the resends. It can’t really be anything “fixed” in the response since there are cases when the connection fails sometimes but not others and the response contents are identical. Just different timing or internal state.

Of course, there’s no guarantee that what my wifi monitor captured was successfully captured by the chromebook. Maybe the mango has some frame timing that’s marginal during the connection setup. The chromebooks could be doing all those resends because they aren’t receiving the Association Responses. That is, however, no excuse for the mango not to start key negotiation after sending an Association Response.

@czsmith
ht_distkip, this is the parameter option of MTK closed source driver, disable TKIP encryption
wmm is to disable wmm, I see that link said that many chromebooks do not support these configurations

I am no 802.11 expert, but didn’t see any reference to TKIP in the RSN sections of the Probe Response or Association Response sent from the mango. I don’t see how any TKIP indicators would have been received by the chromebook except from in these two messages. You can look through the pcap files I uploaded earlier today.

@czsmith
OK, I will analyze these data packets today. I also checked the data packets you uploaded before, but I only found that there was a problem in the configuration negotiation, so no key exchange was performed. This needs further analysis.
Thank you for your analysis and the data package provided, it is very useful for us to analyze the problem

I always had it set to only aes only, definitely no TKIP

When testing I either remove other networks from the chrome book completely or at least they are set to never connect automatically.

I changed the configuration as requested and verified that it stuck after boot.

Unfortunately there was no change observed with the new settings - the problem very much still persists.

Thanks

@chromebook
Thanks for the feedback, I will continue to study this issue

I took a look at @czsmith pcaps - one thing interesting is in the failure case, the Mango is not starting the key exchange for WPA2 (aka the 4-way handshake).

It’s not TKIP, that much is certain, and the Intel use-case, the Association Request/Response actually is successful, just that the WPA2 handshake doesn’t start - so this is something on the Ralink/Mediatek driver side.

Weird…

@chromebook @czsmith @sfx2000

I got a new version of the driver from MTK today. I will adapt it to MT300N-V2 as soon as possible. MTK also provides corresponding patches. I will first test the basic functions and then give you the new version of the firmware.

@czsmith @chromebook
I gave the problem and the results of our analysis to MTK. They provided suggestions for modification. It was in the assoc req / rsp phase. The SMPS parameter negotiation problem, but I need your help to confirm whether the modification is effective. Thanks again.

Hello @wellnw

Thanks for your message. I received and tested second firmware that you sent.

The bug is still very much present - the wifi will often fail to reconnect and continue to fail upon further attempts.

However, the new config does reconnect more effectively and the waiting times for a successful connection are rarely longer than a minute and a handful of manual attempts to connect (once the auto-reconnect has given up).

I was able to connect more frequently as wifi repeater with this firmware. I did not experience times where it would not reconnect for 5+minutes either.

So there is some noticeable improvement but the root issue persists.

I would say that wifi repeater was at a 95% failure rate before, but now it seems more like 50% failure rate.

I also have since acquired an AR750s and can compare the two - there is definitely black on white difference with the functionality between the two. For instance, switching between the two device’s wifi networks from the chromebook, the AR750s will always quickly succeed to connect but after a few switches, the MT300N will inevitably fail and have to try multiple times to reconnect (sometimes not able to reconnect by itself at all).

I hope that helps.

Looks like definite progress.

SMPS negotiation could be an issue…

The HT Capabilities have definite differences in that area:

The Successful connection has SM Power Save disabled. The failing connection has it enabled (SM Power Save mode 0x01). The differences are easily noted when comparing the two attempts: (Successful on the left, failed on the right)

Now, if encryption is turned off, then connections with the normally failing HT Capabilities work just fine. Of course, the key exchange would be skipped anyway.

There are other areas of difference that could be explored:

  • Modulation & Coding scheme - highest data rate
  • Transmit Beam forming - Rx null packet, uncompressed beam forming

  • The failing request also includes an Extended capabilities section not present in the successful case. Enabled (Supported) items include WVM Sleep mode, BSS transition, SSID list, QoS map and Operating Mode Notification. These are lines 275 thru 347 in the Failed file uploaded in an earlier post.

The same differences in the failing Association Request are also found on some other models: HP 14 Chromebook, Lenovo Yoga C630 and Acer C732. (I’m guessing they all use the exact same driver.)

Alas, there is one case, the Acer C316, which has the same HT Capabilities, including SMPS, that DID connect. Look at the connection sequence starting at packets 5754. (It helps to have a display filter “(wlan.addr == 04:d3:b0:b4:22:7e) || (wlan.addr == e6:95:6e:5c:5c:32)”.) Key exchange begins at 5814.

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

This one case suggests that there is more than the SMPS negotiation involved in the failure to start a key exchange.

I’ve been in Mexico for a few days now. Tried connecting my Chromebook to the resort’s wifi through the captive portal, and the internet was dodgy at best. Constant reconnects and errors. A friend’s Macbook also had the same trouble.

Finally found the time to set up my Mango as a repeater. First tried to connect Mango through the captive portal after connecting to the resort’s wifi, no go. Then set the Mango MAC as a clone of my laptop’s MAC, and connected right away, then set up my OpenVPN connection back home in the USA. Rock solid ever since, and neither the Mango or Chromebook or Macbook have had any disconnects.

So…to connect through a captive portal…connect your Chromebook first, then clone the MAC to Mango and connect.

@czsmith
Thank you for your feedback, the information you provided is very helpful, I will continue to look at the problem of MTK driver

@chromebook
Thank you for your testing, I will continue to look at this problem. From the current point of view, it is the compatibility of MTK driver and chromebook network card.

Likely is, typically this is disabled on the AP side… but clients will do what they do.

Oh nothing is ever easy…

I modified the aireplay-ng utility (part of the aircrack.ng suite) to be able to replay the body (WiFi data part) of captured Association Request packets.

With this change, I was able to transmit the AR packets that connected and others which didn’t into a mango without having to have the chromebook present.

Surprise - the packets from failed connections still elicited a key exchange from the mango.

So I would have to conclude there is more at play than just the data elements (e.g. SMPS) in the request. This suggests that other, more difficult to identify differences are involved.

These tests were run using an enhanced aireplay-ng program running in a Kali VM on a macbook pro.

I am attaching the source and binary for the modified aireplay-ng if anyone is interested.

To make it work, add a -U parameter with the hex stream copied from an AR packet on WireShark. (Just right-click on the “IEEE 802.11 Wireless LAN” decode line (all data is highlighted in the frame below), select “Copy” and then “-as a hex stream”. Paste that as the value after the -U option.) Another option, -A, allows multiple AR packets to be sent without intervening Authorization packets.

Sample command line:

root@kali:~/Dev/aircrack-ng-1.5.2/src# ./aireplay-ng -1 1 -e Test -o 20 -q 1 -T 1 -a 94:83:c4:00:4d:8e -c 94:83:c4:00:4d:8e -x 1 -U 31040a00000454657374010802040b160c12182432043048606c30140100000fac040100000fac040100000fac0200002d1ae71117ffff00000000000000002c0101000000000000000000007f0800000a0201000040dd070050f202000100 -A wlan0

This replays the AR from the Failure Connection pcap file uploaded earlier.

Eventually, the mango send that start of a key exchange.

I’ve played with a few timing options, but cannot get it to reproduce the problem simply by reinjecting failed ARs.

Guess someone’ll just have to find one of the failing models of Chromebook.

I appreciate the work GL-iNet is putting in on this. Is your vendor (MTK?) aware of this problem? Are they working on it? Could they lay their hands on any of the failing Chromebook models? I have to believe if you’re affected, they have other customers who are also affected.

aireplay-ng modified.zip (66.5 KB)

InjectFailingPacket.pcapng.zip (2.0 KB)