> On 30 Jun, 2018, at 6:28 pm, Dave Taht <dave.t...@gmail.com> wrote: > > There are some lessons here for getting anti-bufferbloat fixes into > std hardware. > > http://esr.ibiblio.org/?p=8063
Certainly most of the CPE out there is standard hardware bolted together in the same general fashion and stuck in a plastic case, with a crummy "hack on the BSP until we get the feature boxes ticked" firmware and no thought whatsoever for future-proofing or elegance, whose only configuration interface is through a Web browser and exposes a correspondingly large attack surface, while in the process *mandating* a NAT layer. Case in point, my new 4G router. Today, at the ripe old age of 2 weeks, it started crashing repeatedly when subjected to what I now consider to be quite a light traffic load (Steam and Elite Dangerous were updating at the same time). Power-cycling that thing a dozen times an hour got old *really* quickly. It mostly stabilised once they were finished. Oh, and it advertises IPv6 support, but no sign of an actual IPv6 address on the wire. I'm pretty sure it has double-NAT built in, too, in addition to whatever the ISP does behind the scenes. The built-in 4G module apparently runs Android all by itself - so this thing is basically permanently tethered to a cheap smartphone with no screen or keypad, and at least 3 CPUs are involved on the way (one in the router, one in the "phone", and one in the modem within the "phone"). What the actual *fuck* happened to building a simple goddamned modem that just passes packets through? It did so even after I finally managed to get the vendor's firmware update to take, which required first unplugging all the cables until only one computer, dedicated to uploading the firmware image, was connected. Anything less would, at best, cause it to go through all the motions of a firmware upgrade including a reboot after the appropriate delay, but the version number remained the same upon subsequent examination. Presumably OpenWRT would work somewhat better, but currently support is for the v1 hardware; I have v2.1 hardware, and according to the vendor's website there is already v3 in the retail channel. Possibly they are all similar enough to consider identical from OpenWRT's point of view, but we've seen vendors change *CPU architecture* without changing the model number before. Until I figure out how to pry the case open without smashing it to smithereens, I literally can't tell. So yeah, exactly like your average toaster - commoditised to within a micron of its life. > One thought, though, if you look at the (oft hysterical) comment > thread - if you make your point loud enough, toaster experts will come > out of the woodwork to help. > > "[dualit]s don’t use springs–you lift the toast by hand–and they use a > mechanical timer. It’s like someone made a list of all the toaster > parts that break, then designed a toaster that contains none of them." > > If only we could apply more of these design principles to the internet. It just so happens that I'm trying once again to figure out the best toolchain to use with the ONetSwitch30's FPGA. So far it looks like MyHDL (based on Python) is a tolerable alternative to coding directly in VHDL or Verilog, and can output the latter to be consumed by Xilinx' official toolchains somehow. I still dream of putting something very like Cake into hardware *and* not having to configure a router with a Web browser. But I should probably start with something simpler, like a CPU... - Jonathan Morton _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
