$31.50 plus tax/shipping with some nice specs. They say OpenWRT is preinstalled with wireguard kernel support. I suspect there might be some minor issues with the product but I will report my experience for those who are interested. According this thread the SoC is fairly new, but Gl.iNet seems to be a good vendor in general.
Chances for that device getting supported by OpenWrt are approximately zero.
1 Like
it says " OpenWrt pre-installed" in the description
probably v.18_6 w old kernel but who cares
OpenWrt does not support the SOC, never has and isn't very likely to in the future.
pretty much all consumer routers have Openwrt (or LEDE) "preinstalled".
It's like selling a new car, and bragging it being shipped with tires.
if you don't care about "proper" OpenWRT support, get https://www.ebay.com/itm/284337082024 instead, although it was $29.99 a couple of days ago, from the same seller.
Your's came with tires?? 
i don't like off-topic but how "proper" is asus rt-ac68u support in openwrt ?
That's my point, it isn't - it uses a Broadcom chipset.
But since OP doesn't seem to care, the ac68u would simply be a better deal, IMHO.
1 Like
To clarify - GL.iNet maintains a fork of OpenWRT, so you can PROBABLY generate a custom build from their source.
But many of their patches don't meet OpenWRT's code quality standards, so it takes a long time for some of their products to be fully supported because they usually put little to no effort into upstreaming beyond "hey here are some patches, they work for us". See the ath79 NAND efforts as one example of this... Eventually it wound up in OpenWRT mainline, but something like 1-2 years or more after the products in question where released
1 Like
To be fair, upstreaming is much more than what the opensource license asks them to do. Even just sending a PR or an email to mailing list with their device support patches is going "above and beyond" what the license requires.
The issue with Broadcomm hardware is that drivers are proprietary and work only with a specific (and probably older) kernel, so no amount of anything will get those in OpenWrt. It's been like this since the beginning, and won't change.
But many people just want the modularity or whatever that OpenWrt provides and they are fine with it being an old and hacked OEM version.
1 Like
Thanks for clarifying. I get that building a kernel or patching a critical vulnerability when the vendor stops maintaining their fork can suck. But honestly the main reason I would compile OpenWRT is to enable wireguard, which is done in the stock build. The specs on this thing are quite good and the price is great.
I'm investigating how well the wifi drivers work tomorrow when I receive it. I will report back for anyone who is interested.
Good to know, if I recall correctly those older Broadcomm drivers are pretty robust? I run a lot of older hardware and don't mind it. I like stable software, and older Linux versions are still quite secure. I've got a stripped down (no luci etc) 4/16MB OpenWRT router running 18.06.1 around the clock and I never need to reboot it.
Those Broadcom blobs (usually) use some 10 years old v3 Linux kernel, and are tightly integrated with it.
This is the reason why you won't see wireshark supported - its not a stand alone application, like openvpn, but a kernel mod, which won't ever going to get back ported into a v3 kernel.
Out of kernel functionality/features can be added, but if you need to change the Broadcom fw blob, or the kernel, you're screwed.
I'd stay away from Broadcom, not because they hw is bad in any way, but because they don't cooperate with the open source community.
I have no idea.
No they are not. The bigger problem is the rest of the OS and if you use old drivers too, the wifi drivers that are not patched for the 4-ish wifi vulnerabilities in the last 4 years. Even ssh from 4 years ago is vulnerable to heartbleed I think
I never need to reboot any of my OpenWrt devices running dev snapshot either with a full-fat image so I don't see the benefit of running ancient and unsecure versions
It's a consumer product developed by an OEM and using binary drivers from the hardware manufacturer, why should the wifi drivers suck? Broadcomm devices in general work normally (i.e. as expected) with stock firmware.
The issue is when someone replaces the stock firmware with OpenWrt, that has only opensource drivers (or no drivers) for them
ahem
Opal provides the best encryption and authentication with OpenVPN & WireGuard®, just like the other GL.iNet products. Keeping your Internet connection private with multiple VPN protocol support.
Also how do Windows and Mac Wireguard "clients" work? There is a userspace cross-platform Wireguard application https://www.wireguard.com/xplatform/ that is functionally identical to the in-kernel one, and still faster than OpenVPN (although not as much as the in-kernel one).
I can't say if they backported wireguard in-kernel or if they just chickened out and used this application, but Firewall appliance OSes based on FreeBSD like OPNSense have been offering Wireguard for years now, using the userspace wireguard application. (I mean well before bigger and more well-funded projects like pfSense started developing the FreeBSD kernel module)
1 Like
looks like it's supported at kernel level
PROS
- this device is running nicely, gigabit ethernet and >500Mbps WAN over fiber
- will know more about stability soon
- OpenWRT version 18.0.6.1 w/v4.16 kernel
- packages are up to date on their repo, adblock and openvpn work fine etc
CONS
- 16MB flash is not enough space
- advanced configuration requires luci package on top of stock UI
it's probably the most common problem I've run into w WRT distros. Also sometimes there are vendor interop issues
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.