Network Neutrality is back! Let´s make the technical aspects heard this time!
 help / color / mirror / Atom feed
From: Ignacio Ocampo <nafiux@gmail.com>
To: "Network Neutrality is back! Let´s make the technical aspects
	heard this time!" <nnagain@lists.bufferbloat.net>
Cc: Dave Taht <dave.taht@gmail.com>, thejoff@mail.com
Subject: Re: [NNagain] upgrading old routers to modern, secure FOSS
Date: Mon, 23 Oct 2023 23:34:26 -0600	[thread overview]
Message-ID: <CAAGqNknOePHQry0SyP-5C24NwJO2R_49ePipkPpoacHONUQ9uw@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw6mBfZ+CShKq6kUKCEQPvBZuUH5stF7weGFtv92vT7YNw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 9142 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 12644 bytes --]

  parent reply	other threads:[~2023-10-24  5:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-23 17:04 Dave Taht
2023-10-23 17:43 ` le berger des photons
2023-10-23 17:46   ` Frantisek Borsik
2023-10-23 18:11     ` Dave Taht
2023-10-23 18:38       ` Frantisek Borsik
2023-10-24  5:34       ` Ignacio Ocampo [this message]
2023-10-24  5:39         ` Ignacio Ocampo
2023-10-24 12:10           ` Frantisek Borsik
2023-10-24  0:36   ` Dave Taht
2023-10-23 17:58 ` Dave Taht
2023-10-23 18:20   ` David Lang
2023-10-23 18:39   ` Sebastian Moeller
2023-10-23 18:53   ` Jack Haverty
2023-10-23 19:01     ` David Lang
2023-10-23 19:37     ` Karl Auerbach
2023-10-23 21:54       ` rjmcmahon
2023-10-23 23:22         ` Karl Auerbach
2023-10-23 23:39           ` David Lang
2023-10-24  0:13             ` Karl Auerbach
2023-10-24  5:16           ` Robert McMahon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/nnagain.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAGqNknOePHQry0SyP-5C24NwJO2R_49ePipkPpoacHONUQ9uw@mail.gmail.com \
    --to=nafiux@gmail.com \
    --cc=dave.taht@gmail.com \
    --cc=nnagain@lists.bufferbloat.net \
    --cc=thejoff@mail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox