From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 368033B2A4 for ; Tue, 24 Oct 2023 01:34:39 -0400 (EDT) Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-27d2b814912so2732706a91.0 for ; Mon, 23 Oct 2023 22:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698125678; x=1698730478; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GTGPoKD/fmmY0RUOEbIeieac7m9vHgc4CCNdHmk4YCg=; b=GpfGA+YOeLOGpLH7z4J7AOBbiFpzyANJtx/J9kA/xp+t2JBY9/Sk/C1wG/J/rQVmX4 0+lBov5rn86EUHnf7AUHCXMNps+W/oV+I3zLIMBB7M2zSltqAvd+Ef263yNyJwQi+UKy hIl2XNcFFs5Zt0fGRAjGdoRsbgRUo/mEINXYDwLasKwyVbDbBEdCuQj56TIoZ0/csDkH fg7sYHrIn8hnGfOLXbo0kOIjYxxzpK0hJ+G4EnBOh8tORFyEIz5Yd2+Idky8YGTdnWM4 bYlHv/QaBH7J6UfHBwxAeXYs8e0dz0afC+GiHLdarQAbl/YNQa0jP+1nbyA1g9VWzs86 eQXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698125678; x=1698730478; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GTGPoKD/fmmY0RUOEbIeieac7m9vHgc4CCNdHmk4YCg=; b=DOmlwmq2m/l2qftUDiF6WM89pznke8M1ZRxyMTshnor3p3TJ7JwxDZCFc+eWYwugv2 KtXp2DWK2gqxod8u4ZTNQTteUuxYS/ZNRww+8zPK8SuPrLZAIR+RO2Df0wicr1Pii27F scCIhkpUTWYN4nk2r0Ob0yGeed/UaUZUDQqIzwLYj7FcO6u8eup9Pr3EgM6pcFwMb2rC mVdDKCxUqssThgFwC/5Q6Yo6iSgBlqlwUlZguAjYeOAFLF7txU9IOHrv5DV352r2fIB9 y0n19W8gVKWvB9qyynMAGvRtPhmBbKhFmLXmJFLB7Etk4nmlRyfEGtUxDQnsoKj0YCtY EzuQ== X-Gm-Message-State: AOJu0YxXyhjdq3j1VN4qIkSeoavIw52dltrKF/gTIvS0POtNwU6adHU+ nBLjR5ZXUsvDRRT1k/d8JBsaLmXQjGisM6izV1XTQkDuKqGONg== X-Google-Smtp-Source: AGHT+IFZkoOSpavmWb/m/v0qBr90KZgqZBkZ0SAGAxyucZrl4JTrerlmWuIqWfI35IIHNSaJ+NANdtMplas4Ist8XSc= X-Received: by 2002:a17:90b:1d88:b0:27d:1379:6271 with SMTP id pf8-20020a17090b1d8800b0027d13796271mr8493468pjb.46.1698125677736; Mon, 23 Oct 2023 22:34:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ignacio Ocampo Date: Mon, 23 Oct 2023 23:34:26 -0600 Message-ID: To: =?UTF-8?Q?Network_Neutrality_is_back=21_Let=C2=B4s_make_the_technical_asp?= =?UTF-8?Q?ects_heard_this_time=21?= Cc: Dave Taht , thejoff@mail.com Content-Type: multipart/alternative; boundary="000000000000ce352a06086fb1eb" Subject: Re: [NNagain] upgrading old routers to modern, secure FOSS X-BeenThere: nnagain@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: =?utf-8?q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_aspects_heard_this_time!?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2023 05:34:39 -0000 --000000000000ce352a06086fb1eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Dave Taht via Nnagain < nnagain@lists.bufferbloat.net> wrote: > On Mon, Oct 23, 2023 at 10:47=E2=80=AFAM Frantisek Borsik via Nnagain > 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%20= for%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=E2=80=AFPM le berger des photons via Nnaga= in < > nnagain@lists.bufferbloat.net> wrote: > >> > >> you've convinced me to go see libre qos. thanks. > >> > >> On Mon, Oct 23, 2023 at 7:04=E2=80=AFPM 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 t= o > >>> 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_c= ake/ > >>> > >>> 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 developmen= t > >>> 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 drowne= d > >>> 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, reall= y > >>> lousy MTBF. Good embedded software takes many years to develop, say, > >>> oh, 7, while the hardware cycle is closer to 2, nowadays, and require= s > >>> many eyeballs to fully debug and get to lots of 9s of reliability. > >>> > >>> Back when I was even more radical about good, open, embedded, softwar= e > >>> 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 gian= t > >>> toxic waste dump that will require Superfund levels of cleanup, one > >>> day, and ever more contributions to trillions of dollars of fraud, an= d > >>> persistent actors having first broken down the front door, perpetuall= y > >>> 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=3Dcisco+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=C3=A4ht 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=C3=A4ht CSO, LibreQos > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain > --=20 Ignacio Ocampo --000000000000ce352a06086fb1eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there, a quick update since I published the=C2=A0post. 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 syste= m is making a huge difference that ultimately=C2=A0benefits the end user.

IPv6 works out of the box, shaping=C2=A0the up= -link with Cake, being able to easily configure system parameters (SSID, ke= y, etc) with UCI, and just seeing a clean `ps` in comparison to the stock f= irmware with some weird processes.

As a next s= tep, we're planning to deploy a TR-069 client (or why not write a simpl= e REST API to consume basic system params and interface with UCI to set up = things).

As David said, we're shaping up-l= ink close to the IBR, and the up-link close to the customer.
=
Having full-control on the router is a huge=C2=A0advantage= =C2=A0as operator, that again, benefits the end user.

<= div>Thanks!

On Mon, Oct 23, 2023 at 12:11=E2=80=AFPM Dave Taht v= ia Nnagain <nnagain@lis= ts.bufferbloat.net> wrote:
On Mon, Oct 23, 2023 at 10:47=E2=80=AFAM Frantisek Borsik= via Nnagain
<nnag= ain@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",=C2=A0 = 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%2= 0queue%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 kern= el,
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
>
> franti= sek.borsik@gmail.com
>
>
>
> On Mon, Oct 23, 2023 at 7:44=E2=80=AFPM le berger des photons via Nnag= ain <= nnagain@lists.bufferbloat.net> wrote:
>>
>> you've convinced me to go see libre qos.=C2=A0 thanks.
>>
>> On Mon, Oct 23, 2023 at 7:04=E2=80=AFPM Dave Taht via Nnagain <= nnagain@= lists.bufferbloat.net> wrote:
>>>
>>> I loved that this guy and his ISP burned a couple weeks learni= ng 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+ ro= uters to
>>> better router software, that just works, with videoconferencin= g, IPv6
>>> support, and OTA functionality. No need for a truck roll, and = while
>>> the available bandwidth deep in these mountains in Mexico is m= eager,
>>> it is now enough for most purposes.
>>>
>>> https://bl= og.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 dev= elopment
>>> dwarves that of deployment. Ongoing maintenance is a problem, = but at
>>> least they are in a position now to rapidly respond to CVEs an= d other
>>> problems when they happen, having "seized control of the = methods of
>>> computation" again.
>>>
>>> OpenWrt is known to run on 1700 different models, already, (wi= th easy
>>> ports to obscure ones like this box) - going back over a decad= e 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 the= n 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 ba= ck
>>> control of your software infrastructure while being able to cu= stomize
>>> it for purpose, and turning what otherwise would be ewaste int= o
>>> something that will last a decade more, is my inner "gree= n", my inner
>>> stewart brand.
>>>
>>> Compare that to so many others being marketed to, to death, th= at buy
>>> the latest (and often inferior) thing, every few months, perpe= tually
>>> 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 reliabil= ity.
>>>
>>> Back when I was even more radical about good, open, embedded, = software
>>> than now, I used to say: "Friends don't let friends r= un factory
>>> firmware.". I do wish somehow the long term maintence cos= ts of
>>> hardware with a decade plus service lifetime would be adaquate= ly
>>> covered. Insurance? by law? a formal setaside from the purchas= e 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 fr= aud, and
>>> persistent actors having first broken down the front door, per= petually
>>> on the inside, wreaking more havoc. Somehow preventing that me= ss, up
>>> front, seems cheaper.
>>>
>>> Take this string of vulns:
>>> https://www.google.com/sear= ch?q=3Dcisco+router+vulnerability
>>>
>>> (try that search string with *any* manufacturer - juniper, net= gear, 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 = -=C2=A0 (I
>>> worked on this while at montavista in the early 00s!)=C2=A0 - = 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://net= devconf.info/0x17/news/the-maestro-and-the-music-bof.html
>>> Dave T=C3=A4ht CSO, LibreQos
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nn= again
>>
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagai= n
>
> _______________________________________________
> Nnagain mailing list
> Nna= gain@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=C3=A4ht CSO, LibreQos
_______________________________________________
Nnagain mailing list
Nnagain@= lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain


--
Ignacio Ocampo
--000000000000ce352a06086fb1eb--