Bug Reporting Thread For Firmware v3

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.

Here is an emergency build for you @kennethrc

Dropbox - File Deleted

2 Likes

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 :smiley:
Glad you got it working :slight_smile:

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.

awesome, edit the binary file directly.

After more experiments and thought, I consider attempting to detect a valid internet connection before launching OpenVPN a bug rather than a feature. It should be removed, allowing OpenVPN to launch and fail or succeed on its own.

In addition, wget is being launched to detect an internet connection by connecting to http://myip.com.tw/ every 10 seconds. This is being done in the background with no notification to the user of the device.

I can easily think of four use cases where detecting an internet connection before launching the OpenVPN client causes problems. I have experienced all of them.

Information Leaks

Because a wget connection to http://myip.com.tw/ is made before launching the OpenVPN client, it is impossible to create an OpenVPN client connection without leaking information to that site, in the clear (it’s not an https connection), and open to all the hops in between. While I’m not overly sensitive to information leaks I’ve seen posts by others in this forum that are extremely sensitive to these leaks. Separate from the check for OpenVPN, because this is also done every 10 seconds, information is constantly being leaked.

Failure on Restrictive Networks

If the device is on a restrictive network that blocks this check, OpenVPN will never be allowed a chance to succeed because it is never launched. If the network blocks access to this site, blocks access to port 80, etc., this check fails. For example, if a network severely restricts outbound traffic and only allows it on port 22 this check fails, however OpenVPN should be allowed to proceed if the user was successfully able to set up an OpenVPN server on port 22 somewhere. Launch OpenVPN anyway and allow it to fail or succeed on its own.

Failure on Private Networks

This check makes using OpenVPN connectivity between sites with no internet access impossible. For example, if you have two networks (labs) each on different private subnets with no internet connectivity and you wish to connect them using these devices with OpenVPN you can’t do it because the Admin Panel is enforcing internet connectivity as a requirement before OpenVPN is launched. Again, launch OpenVPN and allow it to fail or succeed on its own.

Failure on IPv6-only Networks

The check is used to detect an IP address but only supports IPv4 addresses. If the device is on an IPv6-only network the check will fail because http://myip.com.tw is an IPv4 only site. Even if the site was IPv6 enabled the check would still fail because the grep expression to which it is piped only checks for IPv4 addresses. Admittedly, a user will never see this situation because I have been unable to set this device up on an IPv6-only network anyway, but this is still a breaking point that must be remediated if you ever decide to make the Admin Panel useful on IPv6-only networks. Apparently this IPv6-only situation does happen and is something Microsoft wrote about less than 2 months ago. I sometimes use an internet connected IPv6-only network for testing.

Work-around

For anyone where these checks are causing a problem or you don’t want your information leaked, you can use the following script as a work-around. You may wish to use something more robust than this script but it will at least get you started. If you wish to monitor all the calls to wget and how often they’re made, leave the logging enabled otherwise you may comment the logging out.

Rename /usr/bin/wget to /usr/bin/wget-original then drop this script into a file at /usr/bin/wget and don’t forget to make it executable.

#!/bin/ash
EXTERNAL_IP=192.168.1.1
LOG_TAG=wget
echo "$@" | logger -t "$LOG_TAG"
echo "$@" | grep -e '^-t 2 -T 6.*http://myip.com.tw/$' > /dev/null
if [ $? -eq 0 ]; then
  logger -t "$LOG_TAG" "Injecting fake IP $EXTERNAL_IP"
  echo "$EXTERNAL_IP"
  exit 0
fi
/usr/bin/wget-original "$@"

I used an MT300N-V2 on 3.005 (gl-mt300n-v2-3.005-1031.bin) for my testing.

4 Likes

@Boozer What a fabulous, in-depth post. Thanks for your input, much of which I agree with!

I agree with @Boozer detailed, informative and well explained posts like this make the forum so useful.

Hopefully GL-iNet will take this informed comment on board and remove this checking for internet process as it appears to have no real benefit and a lot of serious disadvantages.

Looking forward to Alzhao and Kyson-lok’s response !

Pseudonoise

1 Like

Thanks for the compliments. But I want to make it clear my intention is not to take away from all the work being done for these devices. I think the work on the user friendly Admin Panel is admirable and I’d rather use it than Luci or Uci when possible. It’s so good I’m thinking about getting one of these for a family member that doesn’t know much about access points or routers so they can travel with it and have an OpenVPN connection from anywhere. It takes just a few minutes to configure one of these things from first boot and I plan on using them on my next family trip to provide a private network to our travel vehicle and in our hotel rooms. IMO, they blow away the competition’s travel routers. My comments are a bit selfish in that I’d like to see them become even more frictionless to deploy in my various environments even if my use cases are on the edge.

I own both the MT300N-V2 and the AR750 and will probably add a third to my collection, making them some of my favorite tech toys up there with my Raspberry Pi collection.

Hello!
Bug with Auto Channel in last 3.00x firmwares.
My config:
One AR750S (xxx.8.1) 2G wifi in WISP mode (wlan-sta).
2G (Radio1.Master) for devices and the 5G (Radio0.Master) is for WDS to connect 2 AR750 wifi bridged, each connected to the AR750S (xxx.8.2 and xxx.8.3).
AR750S 2G wifi named xxxx-2Ghz and 5G named xxxx-5Ghz.
DHCP is only enabled in AR750S.
All work fine. I can connect devices to every router and have internet.
No problems.

The 2 WDS AR750 create 2G wifi (same name as AR750S xxxx-2Ghz ) network for all devices, all OK but the problem begins when I try to make a 5G wlan also. Clients WDS (Radio0.client) work and connect fine to the AR750S on channel 36, 149, etc including when Auto mode but Radio0.Master 5G in Auto mode wifi stucks on 5.000 Ghz (says Wireless is not Associated) even in 36,149,etc channel. If I put manually channel 36, 149,etc… Radio0.Master works fine. Wifi name is also xxxx-5Ghz same as AR750S’ 5G wifi.
ALL wifis same WPA2 password
AR750S 2G channel 11 for WISP
AR750 2G channel 1 and the other 6.

See picture. That happens on the 2 AR750.
Bug%20AR750%20WDS%20small

Why is that happening?

I have just tried also last gl-ar750s-3.006-1102 for AR750S firmware
and gl-ar750-3.005-1030 for AR750
Same results.

Thx

Thanks for sharing your mind and solution here. Yup, there are many security issues worthy of attention. We should focus on optimizing those issues.

Will remove all potential data leak code from C program and the Internet connection check.

We haven’t been compatible with IPv6 now.

1 Like

Then stop handing out IPv6 ULAs on your interfaces then :slight_smile:

eth1      Link encap:Ethernet  HWaddr a0:8c:fd:f0:41:46  
          inet addr:192.168.8.160  Bcast:192.168.8.255  Mask:255.255.255.0
          inet6 addr: fd9d:1aa7:4d5b:0:21e1:463f:a711:10f4/64 Scope:Global
          inet6 addr: fd9d:1aa7:4d5b:0:a28c:fdff:fef0:4146/64 Scope:Global
          inet6 addr: fe80::a28c:fdff:fef0:4146/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3065666 errors:0 dropped:62 overruns:0 frame:0
          TX packets:2056296 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1193983133 (1.1 GB)  TX bytes:495516914 (495.5 MB)
          Interrupt:20 Memory:d0200000-d0220000

(… OK, don’t really stop handing them out, but please at least try and enhance what you already do!)

(BTW, that was after a full wipe as suggested.)

On AR300M with gl-ar300m-3.0-1011_clean.tar firmware the interface eth1 has a ramdom MAC address every boot. And I think that interface eth0 takes the MAC address that had eth1with version 2.264.

For example:

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP qlen 1000
    link/ether ee:03:d3:95:98:97 brd ff:ff:ff:ff:ff:ff

And after reboot:

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-lan state UP qlen 1000
    link/ether 0a:9c:8f:e1:aa:aa brd ff:ff:ff:ff:ff:ff