Feature Request Thread For Firmware v3


#41

The Gl-iNet firmware has some proprietary drivers that give better performance, so it’s always recommend you use that one if there is no need for something else :slight_smile:


#42

You can do this now; that’s how I set it up (just use the same SSID). Now, if you mean explicit “band steering” by the router, so far it hasn’t been strictly necessary, as dual-band-capable clients work that out well on their own.


#43

any ETA for a stable v3 release?


#44

maybe you should ask beta first.


#45

@alzhao @kyson-lok Testing, Alpha 1, Alpha 2, Beta, Release Candidate 1, 2, 3, …10, Stable

:joy: :joy: :joy: :joy: :joy: :joy:


#46

You’re right, it speeds lots of time in testing.


#47
  1. Cloud portal access to manage all my GL.iNet devices, because I’m behind a double NAT.
  2. Continued refinement for the LTE configuration (tools, signal strength, AT commands, etc). But specifically, Band and/or tower locking control in the GUI.
    2a) A real time, precise -dB meter for alignment of antennas and accurate signal strength measurement, like what Mikrotik does in their LTE CPE devices.
    2b)A GUI option to toggle LTE/QMI, so we don’t have to config things manually.
    3)A better GUI for failover/load balancing would be nice, Mwan3 is confusing in places, with redundant and vague metric values.
    4)Put the drivers in the MiFI firmware into other devices, so we can install Quectel modems via mPCIe to USB adapters in things like the AR-750S.

#48

@lucidtek Added to the list, and great suggestions :smiley:

@alzhao @kyson-lok I especially want the real time dB status for myself :smiley:


#49

API usage

  1. The subscriber types this information in the GUI

    user name
    password
    URL for the server API

  2. Wireguard public & private keys are generated using the standard method

  3. The following data is transmitted to the VPN providers API:

$ curl -d list=1 -d username=abcd1234 --data-urlencode password=sample --data-urlencode pubkey=PrXyc.N(n4k77#L!eVdAfp9PrXyc.N(n4k77#L!eVdA= https://api.2018vpn.com/v1/wireguard/connect/site1

  1. Router configuration is returned in this format

{
“status”: “success”,
“data”: {
“endpoint_pubkey”: “49A5404BEBE1E02813DF14A80C3A4973A4654F2F45C=”,
“endpoint_ipv4_dns_addr”: “99.233.155.2”,
“endpoint_ipv4_dns_port”: 53,
“endpoint_ipv4_addr”: “site1.wg.2018vpn.net”,
“endpoint_ipv4_port”: 51820,
“ipv4_addr”: “10.10.20.135”,
“ipv4_gw”: “10.10.0.1”,
“ipv4_addr_netmask”: 19,
}
}

[not a real working VPN account]

Do you mean vlan?

Basically the same thing. In DD-WRT firmware, the VLAN “access point isolation” can be established with one mouse click, like this:

"On the Wireless->Basic Settings tab, click ‘Add’ in the ‘Virtual Interfaces’ section. Enable AP isolation so that guests can not see each other. AP Isolation drops all traffic between clients connected to the Virtual Access Point."

https://wiki.dd-wrt.com/wiki/index.php/Guest_WiFi_+_abuse_control_for_beginners


#50

Thanks for your feedback. Actually 3rd-party wireguard provider has supported, like Mullvad and AzireVPN. For AP isolation, not support at present yet.


#51

Add a Prefer this Network option to Saved Stations in the UI. It would reconnect to that SSID if it returns after failing over to another network in the saved list.

I think this would require extending gl_health. I was looking around for the source code for that – is it available?


#52

@nopro404 Added to the list but rephrased it a bit, i hope for the better?


#53

@Johnex looks good – thx!


#54

This sounds great and I saw the post on Cloudflare’s blog with a few details. I hope this is compatible with captive portals or has a way to see if the IPs are unreachable for easy troubleshooting.


#55

Isn’t AP isolation just a simple option in UCI?


#56

Good question. This is indeed a problem. Considering how to solve this.


#57

There are two main problems I’ve been struggling to solve that don’t have a native solution (as far as I know). I know there have been some efforts to improve these areas but they are tricky:

  1. How to initially authenticate the router to a captive portal
  2. At the same time, how to prevent my PC from connecting to dozens of sites automatically before I’ve established the VPN

What I’ve been doing (still not a 100% clean solution but the best I’ve been able to think of so far) is adding tinyproxy to the mini router, and configuring a browser extension on my PC with a separate profile that uses only that proxy. Then I configure the router to reject all connections other than that proxy (I used the side switch to enter that mode).

With that in place, when establishing a new connection (say at a hotel), I use my alternate browser profile to connect through the proxy (different port number) and do the captive portal login. Once that is successful (and of course there are still some portals where that will fail for some reason), I can flip the switch to enable the VPN and then the internet should work normally from my client machines.

What do you think of this solution? Or do you have a better suggested approach? And if you like my suggestion, my more specific request would be to install/configure the proxy support by default and then add an option to disable all non-proxy access until a connection has been established (or possibly until the switch is flipped).


#58

I think this is too complicated for the user to use the router. The router should work as a transparent proxy and it should do everything itself.

An idea solution is to develop on the router:

  • Detect if there is a portal and resolve the link
  • Only allow data to the portal itself before ahthentication
  • After authentication, it allows all data to vpn
  • The router itself should not work behind the vpn so that it can detect the status of the Internet
  • It is better to pop up the portal page on user’s device because it may ask for username/password, given by the hotel
  • The router itself should be able to pop up window if Internet or VPN is down. So the user knows why he don’t have Internet.

Although not implemented, I think this is possible and we will go this direction.


#59

Thanks alzhao! There is definitely some complexity there, trying to handle all the different portal schemes out there. But I’m glad to see you thinking in that way, and I would be very happy to see you doing something in that direction. :+1:


#60

@alzhao

Maybe you know how Captive Portal Detection works but its quite simple.
To test if there is internet on connection, try to access a well known page. For example:
detect.gl-inet.com or something like this.
The router gets a static page that the router also has, and you compare the 2. If you don’t get the same page, it means there is a captive portal that has modified the request.

Then you do all what you wrote above.

The router could basically do the same, replace all requests the user tries to make in their browser with a GL-iNet mini portal, telling the user they need to sign in to the captive portal, similar to the popup you get on android. In a frame show the captive portal or just let the captive portal do the rebinding for all.