@chromebook
Please provide me with an email address, I will provide you with a modified firmware, thank you.
let me just add that the two AR150s I bought are crap and glinet does not seem to give a rat’s behind.
its an unamanged dell 5190 on stable channel, but apart from the wifi chipset, all corals should have the same board design no?
I think it’s a fair warning more than a threat - the first experiences with this device were very poor and one should expect better so I think it is a fair complaint.
The selling point of these devices is the software they put on top of openwrt so I did not expect the defaults to be so unusable.
I have spent an afternoon diving into this, even tried the official openwrt build with the open source drivers and now have a better overall picture.
I can now connect to the mango since I went back to the official gl.inet firmware but the setup process to get there is super erratic. I found that it’s easier to reset the mango until the chromebook connects first time than to try and force the wifi connection from the chromebook. Waiting at least 5 minutes also helped to ensure a successful first connection.
Once the initial setup has passed and the connection has survived any settings that bring the wifi down (such as renaming the network), my chromebook now connects to the mango relatively reliably.
What is obvious: often it will arbitrarily struggle to connect - and sometimes not being able to connect at all (after booting up the mango it can get really stuck and the chromebook gives up altogether).
Anything that brings the wireless down can cause this unreliable behavior to emerge also - such as scanning for wifi repeater clients. This makes using the repeater function quite tedious and mostly impossible fromt he chromebook.
We’ll just have to see what happens.
I have given @wellnw my email address and will see if there is some improvement. Once I have tested the experimental firmware I will report back.
Might as well join this thread as the other one (here) is getting awfully long. (If the moderator prefers otherwise, please let me know.)
I took a mango with 3.025 and a mango with the firmware @wellnw provided to a local electronics store with a selection of Chromebooks for sale.
I was unable to find any model which absolutely refused to connect. However, I found a number of models which would connect rather erratically. Sometimes they would just time out with an unspecified “error”, other times they connected in a couple seconds and some times it took over 10 seconds to connect.
I’m still going through the pcap files I gathered. First a qualifier:
- I’m not sure that all the traffic was captured. I seem to have many Response messages without a matching Request message. This would make it useless for recreating the problem, though I can still do things like count the number of requests or measure the time between Authentication and the Key exchange.
- Also, being an electronics store, there is a huge amount of other WiFi activity going on. Most of the captured packets were for other equipment and have to be filtered out.
Observations:
- Problematic models Acer Spin 11 (CP311-HN, 48:f1:7f:49:cd:d9), PIxelbooks GA00122-US (f8:94:c2:c1:67:90) and GA00345-US (40:74:e0:e4:41:84), Dell P54G, and ASUS C433 (90:78:41:d5:b3:94).
- Not surprisingly, all these mac addresses are associated with Intel corp. Probably all have the same driver. However, there are units with Intel mac addresses which DO work. I don’t have any way to map a mac address to a chip set, however.
- We do get into the case reported (3.025 firmware) where the Association Requests eventually stop getting sent and a Deauthentification is sent with a 4-way handshake timeout code.
- Once a model connects, it’s more likey to connect again, but timing is still wildly variable. Even after a successful connection, future connection attempts can fail.
- The Acer R751T (a4:c3:f0:bb:b9:17) connected pretty quickly, however, it still sent many Association Requests after the Authentication and before the key exchange. The HP was much cleaner - not tons of repeat Association Requests.
- The HP x360a (0c:dd:24:c7:2e:be) connected quickly and reliably. Its mac address is also assigned to Intel.
Now for the bad new… I didn’t see any real difference between connecting to a mango with 3.025 or the test firmware @wellnw sent me.
There is still enormous variation in connect times and some of these chromebooks do fail to connect at any given time.
I will take a another look into the pcap files when I get a chance. The “best” circumstance for me, however, is to wait until I get home and can test in a quiet environment with a chromebook which has failed to connect consistently.
@chromebook
The latest firmware has been sent to you by email, and I look forward to your feedback. I also analyzed the data packets provided by czsmith here. The Chromebook and routing AP configuration negotiation is not consistent, so there is no four-way handshake. Thanks again.
hello @wellnw,
thanks for sending me the firmware. I spent a couple of hours testing it and it seems to react in the same way as the original 3.0.25 unfortunately.
Some small differences were noticed (like slightly better signal level) but the main problem still persists.
BTW: I had a look around the test firmware and noticed that there is a miss-spelling: ‘enabeld’ should be ‘enabled’ - I noticed this in two of the new feature’s settings.
Anyway, the easiest test for me to confirm the chromebook issue was still present was to try connect as a repeater from the chromebook - it is almost impossible to achieve from my chromebook - the network drops and reconnects too slowly to even see the scanned list of available networks most of the time. There are constant ‘timed out’ messages when it does reconnect. Manually entering the network details does not usually succeed either.
It seems like the mango ‘gets the message’ even though on the chromebook side nothing looks to be working however because I can watch the mango switch wifi channels and appear to connect to the host network via wifi analyser app.
So it’s weird.
It looks like the mango is doing the right thing from the wifi analyser app on a spare android I have… But from the gl.inet admin interface on the chromebook, there are lots of ‘timed-out’ messages, no successes or ‘successes’ without a repeated network actually being made available.
FWIW I was only able to connect to a repeated network 1 or 2 times on either firmware from my chromebook. The network was usually open, though I did also try an encrypted network which I managed to connect to once.
Without having any evidence, my gut feeling is that the chromebook - which often struggles to connect and reconnect to the mango - is somehow causing the mango to fail in its tasks. It seems like there is a vicious circle.
If I can watch the mango switch channels then it must be connecting to the other network so it is confusing that there is rarely any success in doing so.
@chromebook
First of all, thank you for your feedback and for pointing out the misspelling of our new features
Secondly, you said that the recurrence problem is to use mango to relay the superior, and then the chromebook is connected to mango’s wifi?
Finally, what I am currently positioning here is that when mango and chromebook negotiated the configuration, they did not reach an agreement, which caused the connection to fail. Since I do n’t have a chromebook that can be tested, after modifying the firmware, it is more troublesome if it is indeed available.
I’m a new Mango user. Bought it specifically for traveling so I can use OpenVPN to get internet from my home ISP for watching my local Spectrum cable TV on my Roku…and for use with my old, cheap Toshiba Chromebook 2 (2015).
I was doing some last minute checking for firmware updates before leaving for a stretch deep in Mexico. I saw this thread and thought, “Oh S&*^!” my Chromebook won’t work!
I just checked…it works fine. I already configured Mango with my Windows laptop, which will not be coming with me to Mexico. My Chromebook is a gandof build with Intel wifi. No problems at all.
I know that knowing what works is just as important as knowing what doesn’t work when troubleshooting, so I thought I’d chime in with my own experience.
Good luck to everyone having trouble. I’m looking forward to what is hopefully a successful test run down in Mexico.
@chromebook … You don’t happen to have a macbook or linux laptop handy, do you?
All the packet captures I took that timed out pretty much failed because the mango responded to the chromebook, but failed to initiate a key exchange. Something in the behavior of the chromebook causes the mango to get messed up.
If you have a macbook, you can download the free “airtool” app. From it, you can capture all the wifi traffic while you try to connect for further analysis (and possible replay). It does help if you know the channel the mango is using. (In relay mode, it’ll be the same channel as the network being relayed.) Then do a 2.4GHz capture on that channel and upload the resulting pcap files.
If you have linux box, try using tcpdump, kismet or wireshark. (In monitor mode.)
I’ll be glad to look through the file to see if your connection is failing for the same reasons I’ve documented.
I might have some time next week, if I get a clean pcap file with the failing connection attempt, to recreate it using aireplay-ng. If so, we can send this off to GL-iNet so they can replay the offending connection sequence for diagnostic/troubleshooting.
You can also install Linux as a subsystem on a Windows 10 installation now.
Don’t know if/how tcpdump, kismet or wireshark would work on a subsystem.
Thank you for your message.
The problem is cleary as you say, the negotiation.
Sometimes the chromebook connects super fast… other times it just refuses to connect seemingly forever.
The error messages I receive when it fails are the exact same that @czsmith mentioned ‘unrecognised’ error or ‘bad configuration’… The chromebook will often ask me to input the password again because it believes that the configuration is wrong despite it being able to connect later with the exact same config.
So it is pretty clear that the problem is the handshake process because once connected, the router works really great with the chromebook.
However this connection problem is exacerbated by the repeater function which really suffers with this bug. Because of this, I have only been able to connect the Mango as wifi repeater to the chromebook successfully only 3 times during hours of testing.
I understand that you do not have access to a chromebook. However, I believe that you should try to borrow some by asking around. Otherwise, perhaps you could send your Mango to someone who has access to chromebooks to debug it for you - I beleieve that @sfx2000 offered to do this.
Perhaps you could also reach out to your suppliers / mediatek and they will be be able to explain what the specific issue with these chromebooks with intel chips is? Perhaps a bug report on the chromium tracker with @czsmith’s pcaps would be enough to get to the bottom of this problem?
It is probably something really basic like KRACK mitigations etc. It seems a shame for me to throw away the router because it just cannot work with chromebooks.
If this doesn’t seem feasible to you then the only option I see would be for you to compile several firmwares for @czsmith and I to test and we will let you know if there is any improvement. I could easily test a handful of firmwares in less than an hour. It’s quite easy to test the bug with the repeater function so there is no need to spend hours getting a feeling on whether it’s working or not - just try the repeater function and see if it works… if it works try a couple more times. A functioning firmware will be very easy to observe.
But really this is not what I want to do with my time so I really hope that you can find a timely solution to this.
I only have this chromebook handy… It has linux container but wireshark would not see anything from the container. I don’t have anything on hand available to run a monitor mode packet capture.
But in any case, I don’t expect that the anymore pcaps will help to get to the bottom of this anyway.
I think we can safely say at this stage that we are both suffering from the same bug… we’ve looked at packet captures, hardware revisions and are now into the realm of testing pre-release firmwares.
At this stage, it really depends entirely on gl.inet and how far they are willing to go to resolve this glaring issue… Beyond testing more firmwares for them, I don’t really see any more that we can do to debug their issues.
probably not, but even if it did, I really don’t see how this could help solve the chromebook problem.
@chromebook 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?
Late Edit
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.
Today I had to reconfigure my Mango OpenVPN due to a home modem IP change and tried to reconfigure Mango with my Chromebook. I connected to my Mango network which was not connected to the internet. I imported the new OpenVPN file no problem, but that was quick. Shortly thereafter, my Chromebook changed its connection back to a saved network which had an internet connection, and of course I then had no more connection to the Admin pages of the Mango.
I again switched my wifi back to my Mango network and tried to set it up as a repeater to test my new OpenVPN connection. Mango had no saved networks, so I had scan for networks. 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 did not try deleting my known network connections on my Chromebook to test (which I probably should have) to see if that would have kept me on my Mango network. Instead I used my Pixel 2 XL with Android 10 to connect to Mango. Android gave a warning that there was no internet connection and asked if I would like to stay connected. I said I did. I was then able to go to the Admin pages, scan for networks, and successfully set up the repeater.
Is the problem here possibly that your Chromebook is switching the connection from your Mango SSID to a different known network without you noticing before setup is complete?
I’m just spitballing here and trying to help.
@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.