GL.inet and older Firefox

I’m pairing the Mango GL.inet (GL-MT300N-V2) with legacy computers using Firefox 45. These computers cannot be upgraded. The old GL.inet interface worked fine, but with the new routers, as soon as I log in, I get a blank screen.

Showing page source shows that it was running some Javascript that never finishes. Since I cannot upgrade the browser, can I downgrade GL.inet? The old version worked so well.

Is there some other way to avoid the GL.inet screens?

I don’t think the old GL UI is compatible with the new firmware, so it should be better to access LuCi directly.

Cannot fully understand what you mean.

Maybe luci is not installed and you need to install it first.

Thanks for the suggestion to use LuCi. I did give that a try. While the normal GL.inet interface yields blank pages (and page source reveals it is trying to load a JS library that Firefox 45 cannot run), LuCi comes up and all the pages at least partly render.

But most pages warn the JavaScript is not running, and many fields, like the ones to choose an access point, do not fill out enough to do anything useful.

Firefox45 is running JavaScript as well as it can. But not well enough to run GL.inet or LuCi.

I have one machine with winXP with Firefox 52.8.0 (32-bit) and GL.iNet interface from firmware v.3.201beta2 in AR750S opened correctly. No blanks, Thats what I can say to help. Not having old Firefox v45… May be you can try in another PC using Virtual machines?

I am still looking for a work-around. I got a TP-Link router and that works well. I still would like to find a way to make GL.inet-based router to work. I tried SeaMonkey and Qupzilla browsers, but still blank pages with incomplete loading of JS-based content. I wish there was a more simple interface that didn’t need so much style to display a simple configuration program.

Actually, I tried booting a Linux stick on the computer, programming the router from there, then allowing the computer to boot natively, and the router then quietly does its job.

Most features should be able to be called using HTTP (HTTPS) requests. It is the simplest interface for a computer.
(Tips I know: )

But, please note that for whatever reason, there will be no new support for past execution environments and you shouldn’t re-use what’s stuck again.
So you need some skill to fix it yourself to get it to work the way you want.

No node wants to communicate with an unmaintained node, so if an older vulnerable browser requests a connection, the other party may force an error. but that’s not a bug.
It’s like coming to a social gathering with clothes that haven’t been washed for several years. It is essentially only the person who is willing to talk to such a person.

1 Like

Thank you for the pointer to the API.

But the situation regarding the unwashed may be worse than you imagine. I am trying to make the GL.iNet router work because there is no WiFi driver on my operating system, IBM OS/2. But there is a recent curl, and the REXX scripting language. So I have put the router in a repeater mode, and I am communicating using some scripts.

I even found a JSON facility written in REXX.

So now, I can logon, and scan for hotspots and print a list using ```

I can get information about the current router settings using ```

What I have not yet been able to figure out is how to join a new hotspot. Where do I set the password?

Thanks for your help.

Just a quick follow on that I have found the undocumented parameter key= that sets the password for the hotspot. I can now join a hotspot from OS/2. Thanks for the curl API, without which I could not succeed.