Any updates on this issue?
I don’t have much to add - really busy with work stuff at the moment.
sfx2000 - perhaps i can test out your theory as long as it doesn’t require compiling or debugging drivers.
I was also hoping to hear from some of the GL-iNet staffaaaaaa if this has gone anywhere.
I’m deploying these as little WireGuard APs and all devices except the Chromebooks are working fine. Just that one hiccup…
Thanks,
Chris
Nothing new on this?
Sorry we don’t have new update on this issue. Still do not have a chromebook for testing. Let me find out what we can do.
Seems I’m not the only one with this issue.
This entry was just posted to the forum.
https://forum.gl-inet.com/t/gl-mt300n-v2-won-t-connect-to-chromebook-any-help/8888
Finally we had chance to find a chromebook and test. Thanks to Hong Kong’s peaceful days.
Surprisingly we can connect to MT300N-V2 without problem.
We asked a friend to test in the US. She cannot connect to MT300N-V2 with firmware v3.012. But after she upgrade to v3.025 she can connect without problem.
Google Chromebook 78.0.3904.92
Intel 7256 （Rev b9）
Alas, not all chromebooks show that problem… Here’s a list posted from before:
- Acer C732 Chromebook
- HP Chromebook model 14-da0011dx
- Lenovo Yoga C630
- Acer Chromebook model cp315-1h-p8qy
- Dell Chromebook model c3181
I appreciate the effort… maybe someone will come by with a chromebook that is affected.
Quite a few chromebooks I tested did work. I have to presume that it’s the driver that comes with the particular chip set on the motherboard.
Sadly, I have no way to find out which chip is in the machine from the mac address (e.g. 68:EC"C5:24:59:0a).
I have this issue as well, and while I don’t understand the dialog going on, I thought it might be helpful to mention that for me, this issue started when I upgraded the firmware to version 3. I used this router with my Chromebook for a long time with version 2, which I think is what it came to me with, and never had a problem. But as soon as I upgraded to version 3, it quit working. (The router works fine with devices other than my Chromebook.)
You can see the problem in the wifi connection in the Chromebook setup. There is a setting called “Proxy–Connection type”, which is ordinarily set to “Direct internet connection” and is greyed out so you can’t change it. That’s what it is for any other router, and what I think it used to be for the GL.inet router with the version 2 firmware. But in version 3, it’s a dropdown list, which I think means the router is not identifying itself to the Chromebook correctly. Sorry, I know that’s not much of a description but I’m not technical.
Hope that helps. I bought the router primarily to use the Chromebook with unsecured networks, and it worked fine for a long time, so I was disappointed when the firmware upgrade broke it.
Is it firmware v3.025 you are trying?
The firmware on mine is 3.024, and it isn’t showing any updates available.
Mine is a different router from the one here: a GL-AR300M-337. But as my problem is the same I thought it might shed light on what is happening.
I’ve been through resets, etc., but as the router (in WISP mode, haven’t tried any of the others) works with devices other than a Chromebook without problem, I concluded the problem is specific to Chromebooks.
Thanks.
Probably would take some research to see what wifi chipsets are on the ChromeBook.
I’ve got two on hand -
- Lenovo N22-Touch - Intel N3160 with Intel 7265
- HP Chrombook 14a - AMD A4-9120C with QCA 6174A (ath10k wave 2)
To determine which wireless card your Chromebook uses, open a browser and do the following:
- In the URL field (Google calls this the “Omnibox”), enter
chrome://system. - Scroll down to the section labeled “lspci”. Click the Expand… button.
- In the list that appears, look for the line with the words “Network Controller” (not the line that says “Ethernet Controller”; that refers to the wired network adapter). The manufacturer and chipset model number will be on the right.
Glad to see some activity on this problem.
It’s a long thread, so I’ll summarize some of the highlighrts for people newly joining the discussion.
-
I started out writh 3.012 and upgraded to 3.025. Both showed the problem.
-
I would not be surprised if any version 2.x worked. The GL-iNet literature says that there’s a new driver in the v2 product (presumably in the 3.x software.) The problem is almost surely in the MT300N-v2’s driver software.
-
The problem is that the MT300N-v2 is NOT proceeding to start the 4-way handshake needed to enable encryption following an Association Request packet form the Chromebook. The failure to start (or complete) the handshake is causing the Chromebook to keep sending Association Requests and eventually to timeout and display an error.
-
The bunch of Chromebooks which worked seem to have a different wifi chipset than the ones which don’t. Thank you sfx2000 for instructions on how to identify the chipset. Alas, I’m across the country for the next month and don’t have access to the failing Chromebook. If Black Friday weren’t coming up, I’d go back to Best Buy and would look this up in one of the other failing models. (See post #37 above here.)
The Associate Request is slightly different in the models which do connect from those that do not. The difference is probably what is driving the MT300N-v2 not to start the handshake, eventually leading to a timeout.
-
Since these Chromebooks connect without problem to other routers (including other GL-iNet models), any correction really should come from GL-iNet and not the provider of the Chromebook driver. Regardless, I got no response when I submitted multiple problem reports to Google or Acer.
-
Until the tech staff gets their hands on a model which shows this problem, I understand it’ll be difficult to debug.
I would ask if GL-iNet is willing to take trace (pcap) files previously submitted and replay-them to the router. If so, we would have the ability to push Association Requests to the router without needing to have one of these Chromebook models. There are a number of tools available for this: airreplay-ng (here) or tcpreplay (here).
I looked at mine, an old Samsung Chromebook 303C. Unfortunately, the “lspci” entry is blank, and I can’t find any indication of the network controller elsewhere.
Great… Ordered a suitable USB wifi adapter so I can use airreplay-ng. I’ll try to get some pcap files that work and don’t work. Only have a macbook here, but I do have two mangos to play with.
If you’re on a MacBook, just use AirTool - it’s free…
Works well for me - still on Mojave there…
That’s an older chromebook - so depends on what version of ChromeOS you have…