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)
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.
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.
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.
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.
I do use airtool to capture frames. But I don’t think it can replay (inject) frames that were previously captured. I’ll try Kali in a VM with a suitable usb adapter.
I want to replay a successful authenticate request and see the handshake start. Then replay the one from the chromebook which doesn’t work. If that falls, then gl-inet can do the same to tell re produce the problem.