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