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