The good:
- 20, 300, and 1000Mbit/s rates available ($45 - $100/month base rate)
- Router/WiFi AP included in base rate
- Static IP is just $5/month
- symmetric connection speeds
- helpful staff
- No bandwidth caps, but "if you’re breaking the law, be assured you’ll be hearing from us."
- TV and telephone, if you're into that sort of thing
The bad:
- Except for static IP, you're behind "Carrier Grade NAT", so no "I'll cope with dynamic IP but still be able to SSH in"
- Your existing eqipment might not be able to keep up
- Given google's chat product also called "allo", these guys can be hard to search for
- No bandwidth caps, but "if you’re breaking the law, be assured you’ll be hearing from us."
- Small service area (9 Nebraska towns + Fort Morgan Colorado)
- No IPv6(!?), possibly deploying v6 in 2020.
- My static IP is listed in spamhaus "PBL" (but there is a self-service removal process, so it's fine)
The main headache I had was that first "the bad" bullet point: Despite having a phone app(!!) that acts like it can set up port forwarding, nothing I did could open up an incoming port. Staff were interested in helping me (including calling me back later to try one last idea), but ultimately the solution was just to add the Static IP option to my service.
The lesser headache, and the one which was totally my problem to solve, is that my firewall and NAT was being done by an older Buffalo wifi access point, WZR-HP-G300NH2 with an ancient version of DD-WRT. It simply couldn't get beyond about 160Mbit/s when doing NAT/forwarding. So I rejiggered my wires a little bit so that my i7 Linux desktop would take over those tasks. Additionally, all the "modern wifi" devices were already connecting to a newer Netgear R6220 in Access Point mode (routing functions disabled).
I had a second headache, which is apparently a decade-old bug in Linux's Intel e1000e driver. I was getting really poor rates on my internal network, and the kernel was logging "eth2: Detected Hardware Unit Hang". There are two main fixes that the internet suggests: modifying something about power saving modes, or disabling several advanced features of the NIC. In my case, I determined that using "ethtool --offload eth2 tso off" to disable tcp-segmentation-offload resolved the problem I was seeing. What's weird is that this NIC, eth2, is the one that I had been using all along; I had lots of network traffic on it for months. But the message never appeared in my local logs before I started also using "eth1" and doing NAT/packet forwarding yesterday.
Now from my desktop I get 960Mbit/s down, 720Mbit/s up (according to speedtest-cli), and 6ms pings to my office. My fastest wireless device gets somewhat over 200Mbit/s in each direction. Connecting to a VNC session at my office feels just as good as being there, which is primarily due to the extremely short packet turnaround; the bandwidth is a nice bonus though.
Right now it all feels pretty magical, and I'm looking forward to calling the cable company (spectrum) on Monday to cancel the service. I'm paying more (not quite 2x as much) but getting MUCH more service.
I'm contemplating buying one of these little embedded PCs with 2 NICs, they cost around $200 with RAM and a small SSD and it is claimed that they can forward at gigabit rates. They're literally just PCs inside (x86 CPU and BIOS booting), so all the headaches that attend little embedded ARM systems are nonexistent. But is an Intel Celeron "J1800" CPU actually up to pushing (including NAT) a quarter million packets a second?
I have a bittorrent client running with a bunch of Linux ISOs being seeded. I
saw peak download rates of up to 92MB/s and typically 30-60MB/s, which is
great. Right at the moment it's only clocking about 2MB/s of data "up"—the
torrents seem to be pretty adequately seeded. I'm doing this primarily to see
whether Allo treats "any traffic identifiable as bittorrent" as something that
they'll tell you off about, or whether they are trying to distinguish "licit"
from "illicit" when it comes to bittorrent traffic. I'm not sure which idea I
like less.
Entry first conceived on 20 April 2019, 15:11 UTC, last modified on 20 April 2019, 17:38 UTC
Website Copyright © 2004-2024 Jeff Epler