[NNagain] upgrading old routers to modern, secure FOSS

Tue Oct 24 01:39:55 EDT 2023

And, as a dogfooding, I'm personally using that router in Seattle! to make
sure the experience I'm providing to my customers in Mexico is
high-quality. I haven't had any problem either (limiting the up-link and
down-link as well).

[image: image.png]

On Mon, Oct 23, 2023 at 11:34 PM Ignacio Ocampo <nafiux at gmail.com> wrote:

> Hi there, a quick update since I published the post
> <https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_cake/>.
> We've now deployed 50+ units (out of the 200+ goal) so far, and it's
> working really well!
>
> The fact that I now have full-control and visibility on what is going on
> within the system is making a huge difference that ultimately benefits the
> end user.
>
> IPv6 works out of the box, shaping the up-link with Cake, being able to
> easily configure system parameters (SSID, key, etc) with UCI, and just
> seeing a clean `ps` in comparison to the stock firmware with some weird
> processes.
>
> As a next step, we're planning to deploy a TR-069 client (or why not write
> a simple REST API to consume basic system params and interface with UCI to
> set up things).
>
> As David said, we're shaping up-link close to the IBR, and the up-link
> close to the customer.
>
> Having full-control on the router is a huge advantage as operator, that
> again, benefits the end user.
>
> Thanks!
>
> On Mon, Oct 23, 2023 at 12:11 PM Dave Taht via Nnagain <
> nnagain at lists.bufferbloat.net> wrote:
>
>> On Mon, Oct 23, 2023 at 10:47 AM Frantisek Borsik via Nnagain
>> <nnagain at lists.bufferbloat.net> wrote:
>> >
>> > Such a great thing to read! Another LibreQoS man aboard.
>>
>> Well, here is me trying to counter the now-too-popular idea that you
>> can shape everything at the middlebox at the ISP. It is a good start
>> to do that! The packet shaping *and* observability REALLY helps! But
>> in the end everything always works better if you have competent fq +
>> rfc7567 support at every possible bottleneck link, especially on
>> variable rate wireless transports, and especially in the face of
>> potentially difficult traffic like bittorrent, nat awareness and per
>> host/per flow fq have to happen at the customer site....
>>
>> Correct backpressure at the right point, further modified by smart
>> algorithms is 20x less cpu intensive than shaping. The thing that bugs
>> me most is I see people trying to shape wifi to a fixed rate, which
>> works if you only test one device at "the right distance",  and never
>> otherwise. A lot of wifi manufactures like eero and google wifi got
>> this, but so far my testing of wifi6 was so miserable I decided to
>> stop working on it. I REALLY hope someone at the wifi conference this
>> week can show test results with multiple stations at multiple
>> distances doing the right things, as we did at gfiber here, back in
>> *2014*, see page 13:
>>
>>
>> http://flent-newark.bufferbloat.net/~d/Airtime%20based%20queue%20limit%20for%20FQ_CoDel%20in%20wireless%20interface.pdf
>>
>> Because wifi6 and 7 are otherwise a huge step backwards.
>>
>> > Btw, Ignacio might be here, but cc'ing him anyway.
>>
>> i loved so much that *starting from scratch* he was able to assemble a
>> good solution out of OpenWrt. It restores my faith in the engineering
>> world, to know many folk younger than me still have basic C and
>> makefile skills. Thx, man!
>>
>> I have been doing embedded linux software since 1998, and am often a
>> bit grouchy about "the kids today" being unable to compile a kernel,
>> write a bit of xml for the dts stuff, and boom, have a totally custom
>> machine that does exactly what is needed. I see many wifi
>> manufacturers completely unable to build or modify or modify the
>> ancient crap they get from the chip manufacturer, including the chip
>> manufacturer!
>>
>> Training AIs or engaging in social media are far more popular and
>> highly paid skills nowadays.
>>
>>
>> >
>> > All the best,
>> >
>> > Frank
>> >
>> > Frantisek (Frank) Borsik
>> >
>> >
>> >
>> > https://www.linkedin.com/in/frantisekborsik
>> >
>> > Signal, Telegram, WhatsApp: +421919416714
>> >
>> > iMessage, mobile: +420775230885
>> >
>> > Skype: casioa5302ca
>> >
>> > frantisek.borsik at gmail.com
>> >
>> >
>> >
>> > On Mon, Oct 23, 2023 at 7:44 PM le berger des photons via Nnagain <
>> nnagain at lists.bufferbloat.net> wrote:
>> >>
>> >> you've convinced me to go see libre qos.  thanks.
>> >>
>> >> On Mon, Oct 23, 2023 at 7:04 PM Dave Taht via Nnagain <
>> nnagain at lists.bufferbloat.net> wrote:
>> >>>
>> >>> I loved that this guy and his ISP burned a couple weeks learning how
>> >>> to build openwrt, built something exactly to the need, *had it work
>> >>> the first time* and are in progress to update in place 200+ routers to
>> >>> better router software, that just works, with videoconferencing, IPv6
>> >>> support, and OTA functionality. No need for a truck roll, and while
>> >>> the available bandwidth deep in these mountains in Mexico is meager,
>> >>> it is now enough for most purposes.
>> >>>
>> >>>
>> https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_cake/
>> >>>
>> >>> I have no idea how many of this model routers were sold or are still
>> >>> deployed (?), but the modest up front cost of this sort of development
>> >>> dwarves that of deployment. Ongoing maintenance is a problem, but at
>> >>> least they are in a position now to rapidly respond to CVEs and other
>> >>> problems when they happen, having "seized control of the methods of
>> >>> computation" again.
>> >>>
>> >>> OpenWrt is known to run on 1700 different models, already, (with easy
>> >>> ports to obscure ones like this box) - going back over a decade in
>> >>> some cases.
>> >>>
>> >>> Another favorite story of mine was the ISP in New Zealand that
>> >>> deployed LibreQos and had all their support calls (from gamers and
>> >>> videoconferencers) cease overnight. The support tech, formerly drowned
>> >>> in angst from the users, set to work automating an reflashing 600 old
>> >>> agw routers they had "retired" on the shelf, and then distributing
>> >>> them to customers as extenders because the wifi finally worked right
>> >>> with the fq_codel stuff now in that release.
>> >>>
>> >>> I feel like I am tooting my own horn here a bit too much, but solving
>> >>> the right problems like MTTR, MTBF, bufferbloat, and taking back
>> >>> control of your software infrastructure while being able to customize
>> >>> it for purpose, and turning what otherwise would be ewaste into
>> >>> something that will last a decade more, is my inner "green", my inner
>> >>> stewart brand.
>> >>>
>> >>> Compare that to so many others being marketed to, to death, that buy
>> >>> the latest (and often inferior) thing, every few months, perpetually
>> >>> fooled by promises that do not pay off in the field, and often, really
>> >>> lousy MTBF. Good embedded software takes many years to develop, say,
>> >>> oh, 7, while the hardware cycle is closer to 2, nowadays, and requires
>> >>> many eyeballs to fully debug and get to lots of 9s of reliability.
>> >>>
>> >>> Back when I was even more radical about good, open, embedded, software
>> >>> than now, I used to say: "Friends don't let friends run factory
>> >>> firmware.". I do wish somehow the long term maintence costs of
>> >>> hardware with a decade plus service lifetime would be adaquately
>> >>> covered. Insurance? by law? a formal setaside from the purchase price?
>> >>> Otherwise we run the risk of turning the world's internet into a giant
>> >>> toxic waste dump that will require Superfund levels of cleanup, one
>> >>> day, and ever more contributions to trillions of dollars of fraud, and
>> >>> persistent actors having first broken down the front door, perpetually
>> >>> on the inside, wreaking more havoc. Somehow preventing that mess, up
>> >>> front, seems cheaper.
>> >>>
>> >>> Take this string of vulns:
>> >>> https://www.google.com/search?q=cisco+router+vulnerability
>> >>>
>> >>> (try that search string with *any* manufacturer - juniper, netgear,
>> tplink,
>> >>>
>> >>> There is a new vuln going around about some very old software in a
>> >>> cisco mx series which is ancient and yet 100k+ are vulnerable -  (I
>> >>> worked on this while at montavista in the early 00s!)  - abandonware,
>> >>> toxic waste...
>> >>>
>> >>> Anyway, in Mexico at least, 200+ routers are going to be a lot better,
>> >>> through the actions of all that contribute to linux, openwrt, and one
>> >>> smart and caring engineer.
>> >>>
>> >>> --
>> >>> Oct 30:
>> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
>> >>> Dave Täht CSO, LibreQos
>> >>> _______________________________________________
>> >>> Nnagain mailing list
>> >>> Nnagain at lists.bufferbloat.net
>> >>> https://lists.bufferbloat.net/listinfo/nnagain
>> >>
>> >> _______________________________________________
>> >> Nnagain mailing list
>> >> Nnagain at lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/nnagain
>> >
>> > _______________________________________________
>> > Nnagain mailing list
>> > Nnagain at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/nnagain
>>
>>
>>
>> --
>> Oct 30:
>> https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
>> Dave Täht CSO, LibreQos
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
>
>
> --
> Ignacio Ocampo
>

-- 
Ignacio Ocampo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/nnagain/attachments/20231023/9ed21cc8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 167329 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/nnagain/attachments/20231023/9ed21cc8/attachment-0001.png>