Yup, “Share via LAN” is always enabled. We can’t disable it.
It works for me perfectly. Do you upgrade it without keep settings? Please check the log, you can find it on luci → Status → System Log.
Thanks for replying.
I have not kept the settings.I actually did a revert from the gli ui and the luci ui.
it works OK on known hotspots with password (my cellphone hotspot, or my home’s guest accont). BUT on public hotspots where a captive portal is involved, traffic doesn’t seem to flow.
I can get it to connect, but no traffic. At one public hotspot, it did connect to regular internet, but as soon as I added an .ovpn profile, all traffic stopped.
What’s weird is, even if i revert back to 2.264, the behavior is same. It used to be fine on the older firmware. I will try to get logs when i’m out again.
Thanks!
-
SMS icon only appears once when refreshing the entire page. Navigating within the UI will cause the new SMS icon on modem interface to disappear. Although the API did returns the number of new SMSs.
-
In repeater mode, different base stations will be treated as different Wi-Fi networks. But in “saved networks” only shows the SSID, no BSSID or channel info are presented. It’s kinda confusing. (More like a feature request) Wish the repeater simply ignores the difference of the BSSID and channel settings and try to connect to the same SSID every time.
Thanks for your feedback.
You’re right, it should show BSSID as well. Actually, there is an issue if we ignore BSSID to try to connect the same SSID every time, as different SSID might have a different password.
But identifying WLAN networks using SSID instead of SSID + BSSID + Channel (I guess this is how GLv3 firmware and OpenWRT built-in wireless client mode does) is pretty much the industry standard, I guess? Like any iPhone, Mac, Windows and Android devices. They all consider networks with the same SSID will have the same password. And this is how things should be and will be in most of the cases. Since this allows wireless roaming to be possible.
So like my original bug report (or more like feature request, sorry for not putting it in the v3 feature request thread) states: It would be nice if the wireless repeater actually remembers SSID only and tries to connect to the known networks ignoring the channel and BSSID differences. (or offers a choice to users) Otherwise every single time you go to a new places, like Starbucks, you have to scan and add a new network again. Even though there are already like 5 “Starbucks” in your “saved network” list.
Agree it’s possible - but most like Hotel WiFi - mass transit free wifi, ISP wifi, all have same or no password. So when moving within their covered locations, it’s no ideal to have to reconnect to new BSSID.
What about having a toggle on wifi page? Something like Allow AP roaming? or AP Agnostic? This way for public AP where it’s known shared you can set to allow and ignore BSSID.
If friend A and friend B both have home AP set as “NETGEAR” - toggle OFF so that you can specify two.
BTW - my issue with WISP still happens - so far the only way I can connect is to connect phone, then clone mac. old firmware worked without needing that (at least on Android)
Exactly, just like what I said in this following post:
It would be nice if there is a toggle that allows AP roaming.
As for WISP (captive portal pages) issue, try toggling “DNS Rebinding Attack Protection” off under “MORE SETTINGS → Custom DNS Server”. Also toggle off any other DNS related settings that might affect the redirection of the captive portal pages. Which includes VPN, proxies, etc…
Which firmware do you use? We have fixed this issue on v3.005.
Sorry for the misleading expressions. I mean:
- But identifying WLAN networks using SSID instead of “SSID + BSSID + Channel” is pretty much the industry standard.
- Using “SSID + BSSID + Channel” is how GLv3 firmware and OpenWRT built-in wireless client mode identifies networks.
I’m running v3.005 on GL-MIFI. Confirms the wireless repeater will treat AP with same SSID but different BSSID as separate networks. Therefore AP roaming is not possible.
Yes, I agree. We had fixed this issue. Only using SSID now.
I apologize for any inconvenience caused, MIFI didn’t update the testing firmware yet.
Neither is AR-750S, please update.
I’m in a hotel now and can’t use my Slate because of the SSID roaming issue
FW 3.005.
Dude, thanks … so far, so good!
Device: GL-MT300N-V2
Version: 3.004 (gl-mt300n-v2-3.004-1017.bin)
(Yes, I read the first post where you only want reports on the AR750s and Mifi but I’m seeing reports along with replies about other devices, so I’m posting here.)
Using OpenVPN using Repeater mode to wirelessly connect to the internet is successful in most situations.
However, there is one network I use where it doesn’t work. When I click VPN > OpenVPN Client > Status > Connect, I’m briefly shown a yellow dropdown with “WARNING: No Internet” and OpenVPN is not started This is despite the fact that I have browser connectivity through this configuration but just can’t activate VPN. When I ssh to my (GL.Inet) device I can use curl to connect to web pages and can connect to the IP address of the VPN server so my GL.Inet device definitely has internet connectivity. Additionally, when I run OpenVPN from the command line to connect to my server, it is successful.
How is the Admin Panel determining there is no internet? Could there be a problem here and is there a way to work around it?
Could you ssh to the router, and issue those command? The code we use to check the internet status as follow.
wget -t 1 -T 3 --user-agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)" -O - http://myip.com.tw/ 2>/dev/null | grep -m 1 -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}'
wget -t 1 -T 3 --user-agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)" -O - http://checkip.dyndns.org 2>/dev/null | grep -m 1 -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}'
Awesome. That’s the kind of info I was looking for. I seem to be behind a strict guest AP where these checks fail, but I can still create a VPN if I could get past this Admin Panel check.
The http://myip.com.tw/ gives me 403 errors no matter which variation I try but if I replace it with the equivalent curl command and also remove the user agent string, I’m successful:
curl -s --retry 1 --max-time 3 http://myip.com.tw/ 2>/dev/null | grep -m 1 -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}'
When checking against http://checkip.dyndns.org I also get 403 errors but if I remove the user agent string I get the proper result (external IP) using wget. As above, using the equivalent curl command without the user agent string also works:
curl -s --retry 1 --max-time 3 http://checkip.dyndns.org 2>/dev/null | grep -m 1 -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}'
Finally, when inspecting what’s going on with curl I find the root of the problem is Zscalar cloud security is being used and Firefox 3.6 is not allowed through this AP. Changing the user agent string to a more modern version of Firefox solves everything. Both of these commands work for me:
wget -t 1 -T 3 --user-agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100101 Firefox/63.0 (.NET CLR 3.5.30729)" -O - http://myip.com.tw/ 2>/dev/null | grep -m 1 -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}'
wget -t 1 -T 3 --user-agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100101 Firefox/63.0 (.NET CLR 3.5.30729)" -O - http://checkip.dyndns.org 2>/dev/null | grep -m 1 -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}'
It seems without at least being able to remove or change the user agent string I won’t be able to get OpenVPN working through the Admin Panel. Are these user agent strings stored somewhere, or are they in a script I can customize?
FWIW, I hacked a couple of scripts to move the following files off my device and into a Linux machine, use bbe (binary block editor) to replace “3.6.3” with "63.0 " in the files (yielding "Firefox/63.0 " as the user agent), move them back and reboot. I now have OpenVPN working via the Admin Panel.
/usr/bin/gen_ovpn
/usr/lib/gl/libglsdk.so
/usr/lib/gl/libovpnsrvapi.so
/usr/lib/gl/libsoftwareapi.so
/usr/share/glweb1/bin/gl_fcgithread
/usr/share/glweb1/bin/gl_html
You little hacker you 
Glad you got it working 
Thanks - I’ve tried disabling the rebind protection, etc.
My older MT300A works fine with redirection of portal.
Weird. Cloned MAC works so at least there’s that.