Hacker News Reader

Comment by coolspot | Hacker News Reader

Having similar issue myself, I have found simpler and cheaper alternative - $20 Gl.inet mini router [1] that runs OpenWRT, but also has frienly UI where you can turn STA mode, connect it to your wireless network and have wired internet on the ethernet port.

I use it for wireless Wake-on-Lan for my homelab PC, integrated with homeassistant and Google Assistant voice command “Hey Google, turn on homelab”.

[1] - perhaps due to chip shortage, it is closer to $30 now - https://www.amazon.com/dp/B073TSK26W

View on HN

I ended up doing something very similar, if for different reasons. There was an elongated period of time when I had no home Internet service. It was more or less a nonissue, since I had 5GB of LTE-speed tethering, and most of my devices spoke Wi-Fi.

Note that I said most, not all. I had a few Raspberry Pi's, and an old Xbox and 486 PC that I used for old games.

I ended up using DD-WRT in access point mode, and rather than having it run in station mode, it would connect to my phone as a Wi-Fi client, and forward Wi-Fi packets out the Ethernet switch.

It was quite handy, and made the summer much more bearable. As an added bonus, I now keep that router config as a backup. If my actual ISP is ever having an outage, I can reupload that config, and get all of the devices on my network back online, without having to switch them over to Wi-Fi.

I use one of those GL.inet routers. It's been reliable for 1.5 years. I configured it to route all traffic through a proxy service (aka VPN). Most VPN clients fail open, which defeats the purpose of using a proxy for privacy. The GL.inet firmware has an option to fail-closed when the proxy connection is down.

I use a ZTE MF820B USB 4G LTE modem as a backup Internet connection. I configured the GL.inet router to talk to the modem on /dev/cdc-wdm0 and added my LTE service provider's APN hostname. With those two settings, it just works. I keep the LTE modem unplugged and on-hand for when my fiber (Webpass) goes down.

GL.inet is based in Hong Kong and is now under the control of the Chinese red party.

> I use a ZTE MF820B USB 4G LTE modem as a backup Internet connection...GL.inet is based in Hong Kong and is now under the control of the Chinese red party.

ZTE is a Chinese state-owned enterprise, so if CCP-sanctioned action is part of your threat model I'm not sure GL.inet would be the most concerning part of that stack.

Yes, and several points reduce the risk of the ZTE device:

1. The ZTE device is on the untrusted side of the network. It carries encrypted OpenVPN packets.

2. The ZTE device does not download new firmware.

3. The ZTE device is not addressable on the public Internet. It participates in the GSM network. It tunnels data between its USB interface and the NAT proxy server (APN) provided by the carrier.

And one point increases the risk: The ZTE device is physically attached to the USB port of the router.

CCP-sanctioned action directed at me is not part of my thread model. I'm more concerned with them breaking the security of the firmware to facilitate monitoring of PRC citizens who use GL.inet devices. There is precedent for this. For example CCP forces everyone in an entire province to install spyware on their phones that logs their activities and communications and transmits them to a central server unencrypted. The data goes over whatever network the user is connected to, with zero privacy or even any protection against MITM.

If GL.inet broke their firmware security, how long would the blackhats use it before the rest of us found out about the problem?

Those little radios also have use in ham radio, there's a project to flash them with a cool self-healing mesh networking system called AREDN.

I played with it some, with two nodes, although there's nobody near me to mesh with unfortunately.

Those little devices are in high demand. I've been buying them in quantities of 10-at-a-time (Especially when they were cheaper) since they are useful for putting VOIP phones securley behind VPN. I've seen a lot of folks recommend them on HN. They support OpenVPN + Wireguard out of the box and are easy enough for non-techs to reconfigure in the field w/ remote instructions.

Betcha it wouldn't be too hard to use an rpi to do these tasks. ;)

Hence why I love seeing posts like the one's submitted: lessons learned, that we can all possibly use to upgrade ourselves.

It would be nice for mainstream linux (not just openwrt) to grow more user-friendly tooling. I look at opnsense in envy, but I'm not really interest in splitting my expertise, taking on learning FreeBSD too. I know I wouldn't really have to touch the OS much, that opnsense is a pretty complete UI package, but I like to keep a fuller-stack view of things, have some up & down mastery.

I deployed a remote/home office printer sharing setup with these little guys for my friend's company. The VPN integration is fantastic, at least for low bandwidth uses like that.

Make sure you flash them / check their traffic. They make some telemetry requests IIRC.

By extracting the firmware^1 one can see that GL.inet provides a cloud storage service. This is opt-in. It is not enabled by default. The cloud storage has a telemetry address listed in /etc/config/glbigdata (and a ping address to Google at 8.8.8.8). Perhaps one could use the service and change "telemetry.goodcloud.xyz" to the loopback or delete it. I have no inclination to test this as I do not use cloud storage.

1. https://s3.us-east-2.amazonaws.com/download.gl-inet.com/firm...

With default configs IME one will see some constant traffic to 8.8.8.8. This is from OpenWRT mwan3's default configs. These defaults are left unchanged by GL.inet and probably other routers running OpenWRT. I have never seen anyone complain about this traffic. I doubt this is what is being referred to as "telemetry" in the above comment. Nevertheless, it is constant pinging to Google, OpenDNS or some other third party. In typical Linux fashion, mwan3, a daemon not every user is going to need, is enabled by default anyway.

https://github.com/gl-inet/gli-pub/raw/master/mwan3/files/et...

simpler is boring & un-educatuonal but thanks anyways for the good resources. those trying to learn & improve ought know what provided offerings there are about. that is openwrt based is extra compelling that we should better document & explain explain what is really afoot here!!!

OpenWRT is unfortunately rather limiting.

For example: can you run tcpflow on your mini router?

this is a terrible post! almost all software will compile on openwrt. the sdk build option builds a very nice self contained toolset that builds aost anything. it's just linux. this "openwett is unfortunately rather limiting" shallow posting sounds like ridiculously unsubstantiated corporate anti-open-source software droneposting. spreading shit to confuse the field. f this. bad posting. stop kneecapping great flexible distros. this shallow challenge made, "tcpflow", is some ultra ultra particular horseshit that doesnt reflection what we could do, creates a sense of limit where really possibilities are endless as we wish. terrible conservative posting, I hate it.

this is just a really narrow gripe, picking on one very tiny small perspective angle. and it doesn't take any responsibility for what it might take to do better. this is extremely cheap talk shade casting. i'm incredibly unimpressed. it reeks of sabotage.

I'd rather run Debian too. but everything about this post stinks of meanspirited senseless misonfo sabotage.

https://bitkeks.eu/blog/2016/08/collecting-netflow-v9-on-ope...

Haven't played with softflow, thanks will definitely try it, but an initial quick look shows me it's not as easy and straightforward as tcpflow.

I might be wrong, will look at it longer.

But my initial point, which I should have elaborated on: compiling stuff for openwrt is a gigantic pain in the butt.

I tried to compile tcpflow for OpenWRT, installed a VM with the whole toolchain, messed with it for 4 hours and finally gave up when I realized I would have to also recompile a recent openssl to to get tcpflow to link.

Much better to run a "proper" linux distro on these firewall/routers hardware.

Reply on news.ycombinator.com