GL.iNet GL-AR750S is disappointing (due to Wifi disconnects / drops)

jeffsf · 2019-10-07T03:42:26.358Z

Anyone considering the TP-Link OEM firmware should be aware of their dismal security record, both in as-delivered as well as failure to patch over time, along with the FCC consent decree.

If you need VPN or DNS over TLS of any sort, you should examine your options with any OEM firmware. Generally these features are lacking.

I have found my GL-AR750S that runs GL.iNet v3 firmware to be a reliable business-travel companion, US and Europe so far, on extended, multi-country trips. On these trips, OpenVPN and WireGuard, along with DNS over TLS have all been critical. This includes carrying VOIP over the VPN tunnel.

(Personally, I have not experienced any of the mentioned connectivity issues withe either of my GL-AR750S units. I also believe that the thermal design of the GL-AR750S is far superior to other consumer units in its class. Opening the unit you will find a custom heatsink that covers the SoC and wireless chip, not some stick-on piece of crap or, as other manufacturers do, bare.)

RK_aus_S · 2019-10-07T13:48:38.390Z

Anyone considering the TP-Link OEM firmware should be aware of their dismal security record, both in as-delivered as well as failure to patch over time, along with the FCC consent decree.

That may be an issue, you are right.

But the price for a more secure firmware should not (at least in my case) be a poorer reliability, right? Otherwise, I decide for the unsafer firmware. Why? Because if I have to worry about security in the network in general, then I should first of all question my phone, with dozens or hundreds of apps from different manufacturers - all on my most personal device ever.

So I personally can live with routers with OEM firmware. All my stationary routers and access points in my home (they come from Asus, Zyxel or whatever) do run on OEM firmware anyway…

jeffsf · 2019-10-07T17:02:58.300Z

Your decision is yours, though your decision impacts others as your Internet-exposed router, if insecure, can be used as a jump point or as part of a botnet that inflicts damage on others.

Here’s one individuals chronicle of OEM router vulnerabilities: Router Bugs Flaws Hacks and Vulnerabilities

For specifics, the KRACK, 802.11 vulnerability is well known at this time and many manufacturers don’t appear to have patched to eliminate it.

Just because you have a home router doesn’t mean that you’re not the target of “advanced, likely state-sponsored or state-affiliated actor’s widespread” attacks on your device.

Cisco Talos Blog – 23 May 18

New VPNFilter malware targets at least 500K networking devices worldwide

For several months, Talos has been working with public- and private-sector threat intelligence partners and law enforcement in researching an advanced, likely state-sponsored or state-affiliated actor's widespread use of a sophisticated modular...

I think you should also determine if there is actually a meaningful connectivity loss. Most portable devices “sleep” their wireless connections when not actively used to reduce power consumption. Minstrel HT is the default power-control algorithm for 802.11 itself, and is what is used by most drivers that I am aware of. As ping is generally ICMP, which is best-effort and not guaranteed by specification¹, it is not surprising to loose a few from time to time (with no meaningful impact on end-to-end connectivity).

¹ Internet Control Message Protocol - Wikipedia for a general description, RFC 792: Internet Control Message Protocol et. seq., for the specifications themselves.

RK_aus_S · 2019-10-07T18:18:24.148Z

Hi @jeffsf

The list of vulnerabilities is impressive, of course. But I wonder how big the risk is, if I use my TP-Link as a WISP Hotspot Router only? I don’t know…
But anyway, my home routers may be insecure in the same way(s). As you described, firmware updates are very rare.

The connectivity losses are annoying, especially when my whole family in the hotel relies on the Wifi. Of course, I can live with it, my son should live with it. But after the bad experience with OpenWRT on my old RAVPower and the whole bleating of my family during the holidays, I just do not want the same happening again, next hotel, next holidays

When I unpacked the GL-AR750S at home and set it to operation for testing, there were really no two hours until my son first time complained. And when, after a few hours, I asked my wife if she could work on the new router, she replied that her tablet sometime switched back to the old access point, although it is weaker.

That’s not all that bad, but that does not happen with the TP-Link. They connect to the TP-Link, they stay on the TP-Link. That’s all I want, not more, but also not less. Belive me, if, comparatively, the GL-AR750S would not be that expensive, I might have kept it, but it costs almost three times(!) as much as the TP-Link. I had no choice…

Johnex · 2019-10-08T13:57:25.981Z

Honestly if the wifi router doesn’t even have a password and all encryption is off, as long as you have a VPN app on all your devices with a kill switch (as in no internet if there is no VPN) and all default services off such as samba, ftp etc that might be running on your devices, then you can be running the must insecure router on the planet and it won’t matter, since all the traffic is secured.

The only things you would worry about is people using your internet for free, and doing potentially illegal things on your wifi, that is all really.

As you said, use the device that performs the best for you, security is another level

waponwapoff · 2019-10-17T10:54:26.830Z

I can’t believe that I read and reply to this thread one week ago, but hoped that the problems were isolated to a few select people.

I end up purchasing one of the devices and here I am having significantly worse disconnections as described as the person in this thread.

This thing is virtually unusable.

wellnw · 2019-10-18T01:37:25.381Z

@waponwapoff
I am very sorry about the problem with the equipment. We now suspect that there may be a problem with the hardware of this equipment. You can contact the sales and send it back to us. We analyze the problem, thank you.

waponwapoff · 2019-10-29T06:04:48.463Z

Replacement arrived.

This is truly ridiculous - how can this be my fault? AT ALL?
How can this possibly be my fault at all? I don’t understand.
No WAN plugged in
No ETH clients of any kind.
No Wifi passwords saved, no bridging, no sharing, it’s not connected to anything.
VPN disabled.
It’s just sitting there, waiting for someone to log in, set it up.

NOTE: Tried manually selecting different wifi channels (forced) - the WHOLE SSSID DROPS OFFLINE - as if the wifichip is faulty / too hot / not enough power.
Using the official 2A adapter which comes with it.

AC/DC Adapter LA1503-0502000AUU
Output = 5V / 2000ma

I’ve had enough - refund and avoid going forward! I spent so much damn time on this product. Seriously. Atrocious hardware, be warned I’m not the only one complaining.

RK_aus_S · 2019-10-29T08:42:15.952Z

@waponwapoff

Wow. That’s really depressing. It seems like your device is even worse than mine - as I opened this thread. I can not even think about how much time I wasted …

Will you give the TP-Link TL-WR902AC a try as well? I would be interested what do you think of it…

Regards

waponwapoff · 2019-10-29T09:51:29.786Z

Can you please describe your symptoms? Are they similar?

I am very frustrated because this device on paper should be fantastic.

it has a good price and pretty great specs it’s very small and the reviews are good.

I don’t understand why it is disconnecting so incredibly often.
It’s occurring so frequently at the most random times under the least possible load the only thing I can think of is a huge batch of faulty models?

I was very disappointed with the replacement, I figured I would test even more thoroughly this time. Having no Wan connection, no Wi-Fi incoming connection just sitting there only thing I’ve changed is the SSID and passwords.

I even had the mango model and it was cute small and basic and unfortunately slow at VPN however it was completely reliable.

thank goodness I purchased these through Amazon and their return policy is pretty decent.

I wonder if it’ll be a slate version 3 or something later on? I just don’t know. Seems a good product except reliability.

RK_aus_S · 2019-10-29T10:12:33.076Z

@waponwapoff

I opened this thread and I (think?) described my symptoms quite clearly - they were quite same as yours, may be not so often. I had Wifi drops all 2 or 3 hours. Please read my first post at the top.

The reviews are fantastic and I wonder the same as you. But I have some reservations because - as I already wrote - my earlier RAVPower Travelrouter got the same issue as soon as I flashed OpenWRT on it(!).

And as I said; the TP-Link is smaller, faster, cheaper and last but not least; very reliable.

waponwapoff · 2019-10-29T10:30:15.496Z

Sorry I didn’t realise you responded to the thread previously!

I noticed that your username has aus in it?
Another Aussie?

Perhaps the bad batch is in Australia?
I don’t know?

The stupid thing is I don’t even need this thing that badly. I bought the mango as a fun toy for $30 which might allow my wife to watch Netflix America easily (on the PS4) without me having to mess with the raspberry pi for 5 days…

So it seemed to work fine and I had a friend who needed a small bridge, so perfect to sell to him Mango at cost price and upgrade to the fancy model getting me faster VPN the process…!

I got both mine on Amazon and I think they ship out of Dandenong at the main Amazon headquarters in Melbourne.

RK_aus_S · 2019-10-29T10:57:32.717Z

No. I live in Switzerland.
And, I personally don’t believe in a “bad batch”. I have no evidence, but my gut tells me that it’s more a problem with OpenWRT. But these are pure speculations, and speculation does not help.

alzhao · 2019-10-29T12:15:59.637Z

This seems frustrating.

Can you label the router and box and return.

I need the exact router and power adapter to find out what is wrong about it.

PaddyX · 2019-10-29T14:12:53.969Z

we got a GL-AR750 several months ago for a project.
Had the latest firmware and was doing the same… Every 24hrs the wifi drops to the repeater and have
Tried all the versions of firware on GL.Net site and all suffer from the same issue.

As of a few weeks ago I removed it so could run tests and monitor in the lab… Every morning when would come in it would have lost the link and would need a wifi service restart or reboot to restore…

As of 2 weeks ago I found there was a later version of openwrt available for it: 18.06.4
Powered by LuCI openwrt-18.06 branch (git-19.170.32094-4d6d8bc) / OpenWrt 18.06.4 r7808-ef686b7292

Flashed it to this and found good and bad…
The down side is you lose the main config screen and are stuck with Luci… (not to bad)
The up side!!! Since putting this on the WiFi has been rock solid with the connection being up for many many days now!

So looks like there was something fixed in the latest openwrt and now what we need from GL.Net is to work on updating their version to the latest!

Recommend checking OpenWRT site to see if they have a newer version and updating to it to check… In my testing previously had tried older versions and they had not helped so am happier now as it is at least more stable!

jeffsf · 2019-10-29T16:35:20.250Z

Get on the openwrt-devel mailing list and tell them to meaningfully review and merge

github.com/openwrt/openwrt

ath79: Enable target for SPI-NAND; Support NAND for GL-AR300M and GL-AR750S

openwrt:master ← jeffsf:ath79-nand-pr

opened 07:29PM - 30 Jun 19 UTC

jeffsf

+363 -118

# Overview This series of commits prepares for use of SPI-NAND from the upstr…eam Linux MTD framework for the ath79 target. It addresses upgrade issues associated with tar-style files and metadata, allowing "force-less" upgrade paths from ar71xx to ath79 builds, including from previous NOR builds to ath79 builds that support NAND. Addresses comments in previous PRs around SPI-NAND support, including https://github.com/openwrt/openwrt/pull/615 https://github.com/openwrt/openwrt/pull/1428#issuecomment-441594401 in the manner requested by @mkresin > Please re-spin [PR 1428] as soon as we have kernel 4.19 support. SPI-NAND support in this PR utilizes the upstream Linux framework, as requested. The GL.iNet GL-AR300M and GL-AR750S devices are then supported using NAND with this framework. The commits have been resequenced here from the order in which they were developed to provide clearer patches, rather than the original "find a problem and fix it" order. As a result, the reasoning behind some of the preliminary set of commits may not be completely clear until the devices are added in subsequent commits. Original development done on `master` prior to the 19.07 branch and the change to Linux 4.19 for the ath79 target. This series should be able to be backported to v19 by adding `KERNEL_PATCHVER:=4.19` to `target/linux/ath79/nand/target.mk` Boot logs and/or upgrade logs of any configuration or transition available on request. # Roadmap of Commits These logical "chunks" of commits are denoted in [my GitHub repo](https://github.com/jeffsf/openwrt) as tags. The links within each chunk's description below will show the commits and changes associated with each chunk. The tags will be updated should this PR be rebased or changed prior to merge, keeping the tag-based links usable. In addition to the supplied links, the tags are available in clones of my repo for local examination and exploration of the commits in this PR, without the need to apply remote patches to a local repo. ``` pr2184-00-merge_base pr2184-04-Prepare_ath79-nand_target pr2184-05-Enable_robust_upgrades pr2184-06-GL-AR300M_NAND_support pr2184-07-Add_GL-AR300M16 pr2184-08-GL-AR750S_NAND_support ``` Accepted from Patchwork: * <strike>pr2184-01-Add_I2C_support</strike> * <strike>pr2184-02-uboot-envtools_support_for_GL-AR300M-Lite</strike> Superseded by commit 5b6a809092 and related: * <strike>pr2184-03-Refactor_of_common_functions</strike> ## Prepare ath79-nand Target <strike>* ath79: Remove legacy GL.iNet GL-AR300M NAND target Removal for reimplementation [confirmed with original author](http://lists.infradead.org/pipermail/openwrt-devel/2019-May/017190.html).</strike> Retained and _replaced_ on suggestion of @adrianschmutzler * ath79: Prepare NAND subtarget for upstream support of SPI NAND Use of subtarget-specific `nand/base-files/` makes this a lot cleaner and doesn't impact the generic or tiny targets. Examination of the tiny target (and the one-board nature of `base-files/lib/functions/k2t.sh`) suggest that a few kB might be saved for the tiny target by similarly splitting out its own files from those for the generic target. This refactoring of the generic and tiny sub-targets was not performed. _(See further https://patchwork.ozlabs.org/patch/1181653/ by @adrianschmutzler for the ath79 target and https://github.com/openwrt/openwrt/pull/2513 for the ramips target.)_ https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-00-merge_base...jeffsf:pr2184-04-Prepare_ath79-nand_target _Also available as https://patchwork.ozlabs.org/patch/1186259/_ ## Enable Robust Upgrades * build: sysupgrade-tar alt-board= for legacy upgrades Existing sysupgrade tooling on the ar71xx platform isn't able to upgrade to ath79 NAND images, even with the use of SUPPORTED_DEVICES. * sysupgrade: NAND: Prefer CONTROL for board, improve robustness Rather than taking the first directory found in the tar as that from which the assets are obtained, trust the contents of the CONTROL file found. Though the CONTROL file could be fed to sh, parse it somewhat robustly to allow for a transition to JSON or other formats in the future. grep -m 1 -o -E "\bBOARD=[^[:space:]'\"]+" Exploration of legacy flashing revealed some "interesting" behavior of the NAND upgrade process off the "happy path". The most egregious were addressed. Unmodified, `nand_do_upgrade_success()` continues to perform a reboot rather than returning. This continues to prevent boards from checking that the flash was successful prior to changing the next-boot partition. Do to the invasiveness of changing this, it was not refactored at this time. Future refactor of this should also consider using the existing `$CONF_TAR` rather than the hard-coded `local conf_tar="/tmp/sysupgrade.tgz"` Error-checking was examined, but between the above concerns and the challenges on getting return codes from pipelined commands under `sh` (neither `pipefail` nor `PIPESTATUS` are available) it was not further pursued. Initial thoughts were that non-zero error codes might be split into those that were still bootable ("warnings") and those that were not bootable ("errors"), perhaps as positive and negative for ease of consistent implementation. https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-04-Prepare_ath79-nand_target...jeffsf:pr2184-05-Enable_robust_upgrades _Also available as https://patchwork.ozlabs.org/project/openwrt/list/?series=138554_ ## GL-AR300M NAND Support With the previous support in place, the boards can be added. Features such as access to NAND storage while booted under NOR (intentionally, or as a result of boot-count based fail over) and flashing either NOR-based or NAND-based firmware are provided. Legacy NOR boards may be transitioned to full support of NAND without serial, U-Boot access, or use of "force" in sysupgrade. For example Legacy NOR ==> glinet,gl-ar300m-nor ==> glinet,gl-ar300m-nand Direct transition to glinet,gl-ar300m-nand from a NOR kernel is not possible and is prevented by checks already in place within sysupgrade. For example: ``` LEDE_RELEASE="OpenWrt 18.06.2 r7676-cddd7b4c77" "model": { "id": "gl-ar300m", "name": "GL.iNet GL-AR300M" }, root@OpenWrt:/# sysupgrade /tmp/OpenWrt-2019-06-29_0807-0700-ath79-nand-glinet_g l-ar300m-nand-squashfs-sysupgrade.bin Invalid image type. Image check 'platform_check_image' failed. ``` https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-05-Enable_robust_upgrades...jeffsf:pr2184-06-GL-AR300M_NAND_support ## Add GL-AR300M16 As the glinet,gl-ar300m-nor board was moved to the NAND target in the previous commits, there is not a "generic" build suitable for the dual-port, NAND-less GL-AR300M16, or for users of the GL-AR300M that do not need access to the NAND (which adds ~320 kB at this time). This commit clearly disambiguates the "generic" (NOR-only) build and its primary, intended device from the NAND-aware build. [https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-06-GL-AR300M\_NAND\_support...jeffsf:pr2184-07-Add\_GL-AR300M16](https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-06-GL-AR300M_NAND_support...jeffsf:pr2184-07-Add_GL-AR300M16) ## GL-AR750S NAND Support Two variants are provided, one with root file system on NOR flash, the other with it on NAND flash. Consistent with the OEM firmware at this time, the kernel always resides on NOR flash. As noted in the commit message, the "glinet,gl-ar750s-nand" board name is reserved for a potential, future build that boots its kernel from NAND flash. It is likely that change to the U-Boot would be required to boot off NAND, either from the manufacturer or a third party. The current U-Boot provides for updating itself through an HTTP interface, without serial connectivity being required. [https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-07-Add\_GL-AR300M16...pr2184-08-GL-AR750S\_NAND\_support](https://github.com/jeffsf/openwrt/compare/jeffsf:pr2184-07-Add_GL-AR300M16...pr2184-08-GL-AR750S_NAND_support)

I have had no issues running firmware based on that code.

GL.iNet is stuck with code from a year and a half ago (with the older wireless drivers and firmware) until that is merged. Past that, OpenWrt needs to get it into a release or backport it to v19 if they’re not going to make good on the promise of releases every six months.

alzhao · 2019-10-30T01:38:41.567Z

@waponwapoff and @RK_aus_S

We understand you both met problems with AR750S and feel frustrating. We welcome your feedback and we do take your words seriously.

Before we did solve some problems of AR750S by upgrading the firmware and optimizing Repeater Manager. But seems this does not solve the problem you met.

Most of the wifi drop is caused by power adapters, but seems this is not your case as well. Can we do this to find a solution?

You send back the product with problems back to us (Hong Kong address) directly and we will investigate. Don’t worry we will be in charge of the shipping and refund.
Tell me your operating system, with wifi card chipset model and wifi driver version. We will do the same testing here.
We do not believe that the problem happens in batch. But we will do a batch testing immediately again, focusing on wifi stability.
We are Testing the product you mentioned and trying to find out the differences.
We will upgrade the kernel and wifi drivers to test as @PaddyX and @jeffsf said.

I hope you can be patient and stay with us.

Thanks for your cooperation.

robotluo · 2019-10-30T01:58:17.291Z

@waponwapoff @RK_aus_S
When the interference is strong, there must be a balance between performance and stability.
You can try to slow down the WIFI speed by setting it to 144M. In this mode, the stability will be improved.

RK_aus_S · 2019-10-30T08:47:48.909Z

@alzhao
Thank you for your offer, but I have already sent my AR750S back to the seller.

@robotluo
I have almost no interferences; I live in the countryside, there are not many access points around me. And besides, my new TP-Link is subject to the same conditions, concerning interferences. But this one has no problems.

waponwapoff · 2019-10-30T11:04:21.425Z

Surely the Mango uses the same OpenWRT base though?