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

I have been reading the forum extensively and I realize that others are having issues with chromebooks.

I felt the need to create a new post however just to express my discontent at the time wasted trying to get this stupid router to function only to discover the ridiculous efforts users here are going to to make it work and the minimal effort made by gl.inet in return.

Having only a chromebook has made this process very complicated and time-consuming for me.

My chipset is intel 7265 and my chromebook is a google coral edition.

The mango is running latest firmware.

I could connect without encryption on the network but once setup I can no longer connect.

The router is not expensive but the time I wasted waiting for delivery and attempting to set it up are invaluable to me.

This router is not fit for purpose and unless I see a real effort to fix the issue I will be leaving very damning amazon reviews.

Thank you

Sounds good :slight_smile:

People are working on it, both in the community and at GL-iNet

Might be more helpful if you ID which exact Chromebook you have, Coral refers to the board design, which covers the follow models. Also would be helpful to ID the specific version of ChromeOS you’re currently running, and whether or not this is a “managed” ChromeBook (common in EDU/Corporate space, uncommon with consumer owned devices)

  1. Acer Chromebook 11 (C732, C732T, C732L, C732LT),
  2. ASUS Chromebook C403,
  3. ASUS Chromebook C223,
  4. ASUS Chromebook C523,
  5. Positivo Chromebook N2110,
  6. Edxis Chromebook 11,
  7. CTL chromebook NL7,
  8. Positivo Chromebook N2112,
  9. Viglen Chromebook 360C,
  10. Edxis Chromebook X11,
  11. CTL Chromebook NL7 / NL7T-360 / NL7TW-360,
  12. CTL Chromebook NL7 LTE,
  13. Acer Chromebook 15 (CB315-1H, CB315-1HT),
  14. Acer Chromebook Spin 15 (CP315),
  15. Acer Chromebook 514,
  16. Acer Chromebook Spin 11 (CP311-H1, CP311-1HN),
  17. Dell Chromebook 11 (5190),
  18. Dell Chromebook 11 2-in-1 (5190),
  19. ASUS Chromebook C423,
  20. Lenovo 100e Chromebook,
  21. Lenovo 500e Chromebook,
  22. Acer Chromebook 11 (CB311-8H, CB311-8HT),
  23. Viglen Chromebook 11C,
  24. PCmerge Chromebook AL116,
  25. Sector 5 E3 Chromebook,
  26. Prowise Chromebook Eduline,
  27. CTL Chromebook J41 / J41T

Be patient - like mentioned above, folks are working it.

Threats rarely motivate folks, it just becomes part of the problem rather that the solution.

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.


  • 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.

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.

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.