Re: [NNagain] upgrading old routers to modern, secure FOSS

[Frantisek Borsik <frantisek.borsik@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 10708 bytes --]

Thanks for weighing-in, Ignacio. And great job, again!
Looking forward to hear about TR-069 implementation - hope you will write a
blog post documenting it as well.


All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Tue, Oct 24, 2023 at 7:40 AM Ignacio Ocampo via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> 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@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@lists.bufferbloat.net> wrote:
>>
>>> On Mon, Oct 23, 2023 at 10:47 AM Frantisek Borsik via Nnagain
>>> <nnagain@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@gmail.com
>>> >
>>> >
>>> >
>>> > On Mon, Oct 23, 2023 at 7:44 PM le berger des photons via Nnagain <
>>> nnagain@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@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@lists.bufferbloat.net
>>> >>> https://lists.bufferbloat.net/listinfo/nnagain
>>> >>
>>> >> _______________________________________________
>>> >> Nnagain mailing list
>>> >> Nnagain@lists.bufferbloat.net
>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>> >
>>> > _______________________________________________
>>> > Nnagain mailing list
>>> > Nnagain@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@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>
>>
>>
>> --
>> Ignacio Ocampo
>>
>
>
> --
> Ignacio Ocampo
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

[-- Attachment #1.2: Type: text/html, Size: 15933 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 167329 bytes --]