Justin thanks very much for the detailed response and testing. That was what I was looking for.
Alzhao thanks for the details on disabling ddns checks. As for compiling openwrt you mention to get your patch and patch openwrt - what is that patch?
Thanks
@heavymetal, it is the daemon used to connect saved repeater stations. It doesn’t send any data outside.
@je66, all the patches to openwrt-cc is here: openwrt-cc/patches at master · domino-team/openwrt-cc · GitHub , you can get this patch and patch your own openwrt cc1505.1. But I am not sure it will be able to patch the latest openwrt-cc, as openwrt cc 1505.1 also has new commit after we pull.
alzhao wrote:
“Yes you have checked all our script. From v2.2 you can just disable ddns and all the ip checks will be gone. You can can just disable /usr/lib/ddns/glddnsupdater.sh”
“The script for firmware update is /usr/bin/glautoupdater, you can delete this file as well. Then, there is really no background connection any more.”
Hi.
Can you kindly implement a check box in your GUI to make this easier? I do not want any “outside” activity / “call-backs” without my express permission.
Also, with the firmware update enabled, does this “call-home” before or after my VPN service kicks in (ie. does the connection go through the VPN or otherwise)?
Regards,
Glitch
Also, I just found this: /etc/config/mwan3, which appears to have a load of DNS settings, namely Google (arrgghhh, I don’t trust them with anything!) and OpenDNS.
Can someone kindly explain what this file does?
Glitch
@Glitch, there is a check box already in recent firmware. You just untick it to disable WAN access and ddns will be disabled.
The call home function goes through VPN, which is not what we wanted. It should not go through VPN. Yet we didn’t implement this.
mwan3 is used for load balancing when you have multiple WAN, e.g. cable, repeater and 4G at the same time. It has to use active ping to determine if one connection is live. The IP of google and OpenDNS is used for ping, not for DNS.
@Glitch, the mwan3 is a stock OpenWrt package, which handles multiple Wan connections (redundancy, load balancing, etc.). It checks periodically if the Wan connection is up by pinging some outside services: Google and OpenDNS in my tests. I can see 4 pings every 5 seconds on my network. These pings exist even if you don’t have multiple Wan connections.
I just removed the packages luci-app-mwan3 (which gives the Network => Load balancing page in LuCI web interface) and mwan3 (which contains the /usr/sbin/mwan3track executable). Then you can remove also the /etc/config/mwan3 config file.
From the command line:
opkg remove luci-app-mwan3 mwan3
rm /etc/config/mwan3
Please @Alzhao can you give us some more info about the gl_health daemon? I see that it incorporates pieces of other software, like the wpa_cli client, and I don’t understand what are the functions it provides, beyond OpenWrt software.
What if I disable /usr/bin/gl_health altogether?
Is the source code of gl_health available somewhere?
Thank you very much for any hints.
I use for private purposes a pair gl-mt300n routers with poe modules at my own risk and knowing that at the start of the firewall it rises in the last stages and before that the router is transparent. You can use dd-wrt on the site written as flash firmware, or clear yourself compiled open-wrt for MTK. In information technology can not be trusted even (especially) very large companies remember the scandals associated with Cisco or Juniper, D-link, the list can continue indefinitely …
gl_health is the repeater manager. I only checks your repeater connection. It will auto connect to your saved SSIDs. If none can be connected it will just disable sta. There is no information sent to the Internet during this process.
Can’t tell you, because when I plugged it in and NMap’d it, it had Telnet and Samba (smbd/nmbd) ports open. I didn’t have time for a full security audit, but that appeared concerning enough, so I just reflashed it with the latest LEDE and that’s working great.
I have no idea what benefits the factory images has, apart from a more user friendly UI than LUCI (which would be an understandable thing to change from a mass-market vendor perspective).
I still wish LEDE/OpenWRT were based on a more hardened foundation, like Alpine Linux uses (but would need more instruction set and boards support than Alpine offers).
LEDE is another fork OpenWRT with very small developer team…
Almost a year from them nothing is audible.
@dm What I consider one of the important features of the GLi firmware is the station management tools. this allows one to choose from multiple saved stations and add new stations. There is no easy way to do this in OpenWrt\LEDE (Luci is NOT easy or fast). The GUI is also usable on a phone and the OpenWrt\LEDE gui is not.
As a road warrior I consider this tool set a must. I have tried a number of other tools and this is the easiest to use.
I also like the included USB support.
I have taken the steps to disable the DDNS server described here and in other posts, but otherwise comfortable that the device is secure.
@passter, What do you mean nothing is audible from LEDE? It’s an enormous number of improvements on OpenWRT and vastly more secure. The good news, is that they’re in discussions to merge again.
_________ / /\ _ ___ ___ ___ / LE / \ | | | __| \| __| / DE / \ | |__| _|| |) | _| /________/ LE \ |____|___|___/|___| lede-project.org \ \ DE / \ LE \ / ———————————————————– \ DE \ / Reboot (17.01.0, r3205-59508e3) \________\/ ———————————————————–The LEDE Project (“Linux Embedded Development Environment”) is a Linux operating system emerged from the OpenWrtproject. It is a complete replacement for the vendor-supplied firmware of a wide range of wireless routers and non-network devices. See the Table of Hardware for supported devices. For more information about LEDE Project organization, see the About LEDE pages.
Get LEDE Firmware at: Index of /releases/
The LEDE Community is proud to announce the first stable release of the LEDE 17.01 version series. It incorporates thousands of commits over the last nine months of effort. With this release, the LEDE development team closes out an intense effort to modernize many parts of OpenWrt and incorporate many new modules, packages, and technologies. These are some of the highlights compared to OpenWrt Chaos Calmer:
Have fun!
The LEDE Community
Well that copy-paste went terribly… Looked great in WYSINWYG. 
@RangerZ, How does the station management compare to TravelMate on LEDE/OpenWRT? (Sorry, I didn’t get to try it.)
Yeah, LUCI isn’t great for newcomers. Haven’t tried the newer alpha Luci2 version.
I hope you’re able to maintain security well. Don’t take my switch personally, it’s just that without knowing you, I have more existing trust in larger upstream distribution communities to be able to continue releasing security fixes on time. I have no reason or knowledge to believe you can’t personally, it’s just been my experience with the vast majority of device vendors, that it’s been easier to go upstream for me. (Plus I want newer kernel features, etc)
I’d much rather see any software improvements (like station management) upstreamed, or made available as optional packages.
I wouldn’t see firmware as a significant competitive market differentiator. Most vendors seem to think it is.
The major reason I just bought my first GLi, was the great hardware. Particularly, compatible hardware and the ability to flash LEDE on it. The hardware’s been FANTASTIC too! This is DEFINITELY not my last GLi purchase.
I’m currently doing another postgrad, Masters in Cybersecurity. Just completed a “Wireless, Mobile and IoT Security” unit, with a strong focus on Wi-Fi. It’s been great to be able to install the full “wpad” (not mini), FreeRadius v3, SSL libraries etc on such a portable device and configure WPA2 Enterprise EAP-TLS/TTLS (for strong mutual certificate authentication). Although not strictly necessary, I’ve added a second radio for performance when as a bridge (TL-WN722N via USB). With VPN added (WireGuard), I’ll be able to can securely connect to the GLi, then have traffic over untrusted networks (whether it’s hotel Wi-Fi, ethernet WANs, etc) protected to an upstream (e.g. my own cloud-hosted VPN server, regularly rotated). Router admin UI, captive portal authentication and the VPN protected networks, all on separated onto different Wi-Fi SSIDs (Admin UI not available during regular browsing) and each SSID only accessed from dedicated hosts (e.g. for captive portal auth, a disposable VMs).
I recommended GLi hardware to others in the course too. It’s fantastic to be able to buy cheap enough that even if I somehow managed to brick it, it wouldn’t be a catastrophic financial disaster.
I guess the other reason I like community builds, is that too many vendors stop releasing updates after a year or so. They’ve moved on to new models and can’t afford to support lots of older ones. Meanwhile, the devices either become botnet members, or have to end up as landfill. I hope you’re not one of those vendors, but understand it’s tough for them. Anyway, long-term availability is another reason I usually go for community builds when I can.
Glad you’ve been satisfied with your gl-inet purchase, dm.
Regarding the future patches and updates for gl-inet, they seem like a very reliable company when it comes to software updates. And if for whatever reason they did decide one day to stop pushing new updates, we have all the information on how to compile our own OpenWRT images for the devices, so I’m sure the community here would be more than happy to continue building new and updated images.
alzhao, Any reason why telnet and samba ports were open by default? It adds unnecessary attack surface. (I’d at least want fail2ban running if those were open.)
For Telnet I think the first time you set the password it will disable telnet and enable SSH by default.
Only the LAN side can access those services.
@dm
As you said, “I didn’t have time for a full security audit” so it’s reasonable to give Justin and GLI the benefit of the doubt until you do so and can detail otherwise.
Regarding travelmate, I have been testing it and it appears to work as advertised. It’s a great solution for a stock OpenWrt\LEDE device, however it relies upon manually editing the wireless file to add STAtions, making it really not usable for a road warrior who frequently needs to add new STAtions. If you rotate exclusively between a fixed set of stations (home, office vacation home, etc) then it’s fine. I have not tried the 4.x versions as yet.
All but one station is disabled in the wireless file. I would rather a separate file for stations and update wireless, but I did not design this. Related, there is a LuCi bug which, if I recall, displays incorrect station names in the Luci Wireless display. Bug has been reported, but it’s not likely to get fixed anytime soon. Again, it’s NOT a travelmate issue, it’s a Luci issue. I have not been successful adding or manually changing STAtions with Luci while travelmate is running.
You may want to see this solution, which I still run on a Kingston MLWG2, but it has some issues. Not sure if it is the tool or device, but about half the time I end up with a 169.254 address on boot. 404 Page not found - GL.iNet Again, it’s problematic with needing to add new stations like travelmate.
I have been an evangelist for adding this functionality to OpenWrt, but there is just not enough interest by those with the correct skills. I also would like to see a phone app (preferable). Search OpenWrt for my user name. There are dozens of solutions, but the only one that seems to work every time is to remove the STAtion on boot, forcing the user to create a new STAtion in Luci, however as noted, I find anything done in Luci just is to tedious to do at Starbucks etc when I want to connect for ten minutes. ( I use openVPN)
The Gli gui is still the best tool. Details and comments can be seen here: Overview - GL.iNet Docs
…AND I CAN USE IT ON A PHONE’S DISPLAY
I will suggest that there may be a trade off between security and functionality, but personaly do not feel I am giving up ANYTHING.
Regarding using a USB device as a second radio, did this (edimax-7811). It solved the AP-STAtion hang issue, but wireless performance was reduced as compared to using the single radio (not intuitive). Since given up. It is unknown why. Some users have reported improved performance by placing the USB radio on an extension cable.
Regarding telent, not sure if was in 15.05 or LEDE 17.01 telent is replaced by SSH.