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).

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. 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