From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 5FD053B2A4 for ; Wed, 9 Nov 2022 12:50:25 -0500 (EST) Received: by mail-wr1-x436.google.com with SMTP id bk15so26848131wrb.13 for ; Wed, 09 Nov 2022 09:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HJllMw+nd9+zvuvCtAOTYFftPaCkB+eD6849EQ51ZTk=; b=Z6GNuKzgh5X0nNqf77z6xNYzfJOSiUPhH7NWhDA1fBivhqIDscmMMA2Mpy1vT6X0ji zmoKRKQDMQfBr+pVacdeEEf3d9rqXmfqutNU57YJFFVkJbJAnxUtPaL7kLm134CYHiGb +DK0ACpH+46l7K1FrZtak0hoNIG/9tgDBRPoLbcnMazwq3/Dt6C4VBPnobRKYAsVV/R+ 5evzjNeAlVzmLNOEwuL/5+OG477TLJItVbAGaI87Q8AyYHxVGQfJYYPtznEDzSZI7EBO 5J3BqN8W4c0cLqNJktTnUKY13FK692RMWoSJIgRIQFD2CG2kt8Sapa+WnMI/tGJonOcx lYFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=HJllMw+nd9+zvuvCtAOTYFftPaCkB+eD6849EQ51ZTk=; b=HoYqrM635C+eXpsVIRDq6//K48K21I5Td4wDN1OmaGrgMxE4MFLpjF/KvEwngsWpjR Yv9zZPlR0WyCBdC57Z/t2SK3TRQBzTo4TpfZahgIPiZZ8FWjwU+RCFBVFZrMIdykeZGV Gd/xJ31261hKHOV+F9UWeijP1l3TpyoS38Ffk0AHwsR18dZ/IuFI0Ai3baY5inlgb2V3 zbsIe3hvWjD1EylsDKOCxlJN1WQPXJ0euNofVnWiUZsH4vDGOpdOapgBaK1R1IQCVF+I JSxDdNBO1pdGOmlkZRdnV7zSK19xX7wvY0MudGHp0Dn1R7sUtPhEFpk3tMmDEL6IGJow thOg== X-Gm-Message-State: ACrzQf1y+IG+IiHAqgMn3cLuahAzpReCvXnSOoejrxBHA47lACdVpVVW RsWX5WvsnOuexLY1C+M/oj/lHrrah6+/zw684co= X-Google-Smtp-Source: AMsMyM554EYJHNbQT4mkH5DX1I3tshM8epqDrvQYT0f5gihE9XrV5C/1KhlDlcRj8I1dY8PdQiwGpMXuwZDP1C/237g= X-Received: by 2002:adf:aa8c:0:b0:236:6e59:99ff with SMTP id h12-20020adfaa8c000000b002366e5999ffmr37816128wrc.688.1668016223924; Wed, 09 Nov 2022 09:50:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Wed, 9 Nov 2022 09:50:11 -0800 Message-ID: To: Herbert Wolverson Cc: libreqos , compliance@sfconservancy.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [LibreQoS] on building better router software on older routers (cambium/ubnt lawsuit) X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2022 17:50:25 -0000 the outcome of the "elevate" tiff between cambium and ubnt was *extremely* unacceptable to the FOSS community. Both sides stopped publishing source code entirely, and I was long ago in touch with the software conservancy about this. I will ping them again on this front. (for those of you that are not aware, cambium produced software that ran on some ubnt radios and then... Some backing details: http://www.mtin.net/blog/ubnt-vs-cambium/ https://www.channelfutures.com/regulation-compliance/cambium-networks-settl= es-federal-lawsuit-by-rival-ubiquiti https://sfconservancy.org/blog/2019/oct/02/cambium-ubiquiti-gpl-violations/ The elevate was a great product (it leveraged all bufferbloat.net's work on BQL, fq_codel, etc, etc) and I was *enraged* to see it die, particularly on the arguments that were used in court, and then settled and sealed. Microsoft has no say over installing linux on their hardware, and it is/was insane for anyone to prevent installing better software on your router - I don't get it, you lose some new sales, perhaps, but if you built good hardware, it's very green to keep it running until you need to replace it... and I'm convinced that mikrotik and ubnt at least actually have a large userbase that ignores the default (crappy) software and just installs openwrt on top of it, and that's where at least some of their R&D come from. They still get the hardware sale and then they have no support costs... Anyway, moving forward with libreqos.io v.1.5 - so long as there is no "sale" involved, us (IMHO) doing something elevate-like for free on *old* ubnt or cambium hardware leveraging the openwrt builds, is untouchable, legally, and of huge benefit (and savings on capex) to ISPs given how much better modern software works on this old hardware, in particular. fq_codel "just works" on the wifi and ethernet interfaces, there's BQL, and IPv6, supported. The ubnt M5s were my first target for the fq_codel work, the first to get fq_codel for wifi, and the backbone of my network at lupin. Vastly better than the original firmware. There is limited flash so the m5s were obsoleted by openwrt 22.03, but there is another build for them within those memory requirements elsewhere, and 19.x was more than good enough. So for the old hardware, openwrt is not presently affected by their noncompliance. But IMHO moving forward! on newer gear they are producing, their lack of gpl compliance is becoming a real problem, and lag on things like ipv6, etc, also. Ideally we find ways of integrating with their current products (or they end up using our stuff!) and otherwise, we should steer clear of the lawyers in our pursuit of a better internet for everyone, running on everything. We're all in this bloat together. PS Also to this day, I love the ubnt Picostations. Incredible range compared to what you can get today, and they last forever.... On Wed, Nov 9, 2022 at 8:39 AM Dave Taht wrote: > > On Wed, Nov 9, 2022 at 8:27 AM Herbert Wolverson via LibreQoS > wrote: > > > > I've no idea. We only have a few M2/M5 CPEs left, and all of the access= points are running AirMax AC. Since that's neither an open nor standard pr= otocol, I don't think OpenWRT would work for us. > > You just update both sides. > > > > > I have no doubt that it outperforms the Mx code, though. Elevate (Cambi= um's "turn CPEs into Cambium SMs" program that turned into lawsuit city) ma= kes them perform really, really well. > > I know. They were running "my stuff", inside, on all interfaces. > > > > > On Wed, Nov 9, 2022 at 10:23 AM Dave Taht wrote: > >> > >> does dhcp option 82 work on openwrt? > >> > >> I long ago reflashed all my m2 and m5s to openwrt. outperforms ubnts > >> default build across the board if you tune down the txop size to > >> 2.5ms. > >> > >> On Wed, Nov 9, 2022 at 8:20 AM Herbert Wolverson via LibreQoS > >> wrote: > >> > > >> > We have a bespoke solution to do similar (I keep meaning to make it = more generic and open source it). The basic operation is (using our Mimosa = devices as an example; it's actually a lot more complicated than that since= we have everything from apartment complexes with Ethernet jacks to regular= Ubiquiti devices in bridge mode): > >> > > >> > A server contains an instance of FreeRADIUS. > >> > Periodically, a script runs and queries UISP. It finds client sites = with a device matching the type "Mimosa C5x" and an "other device" entitled= "Service IP". > >> > > >> > A radius record is then added for the CPE (using the MAC and IP from= the Mimosa device), placing the Mimosa CPE on the IP address in the "mimos= a" record. > >> > A second radius record is added that matches Option 82 headers to se= e that a request passed through the Mimosa. This will always hand out the I= P address from the "Service IP" record. > >> > The radius database is refreshed with this information. > >> > > >> > When a CPE comes online, the DHCP server sends a RADIUS request. If = the MAC address matches a RADIUS record, the device is assigned to the CPE = address from the RADIUS records. > >> > When a customer's device sends a DHCP request, it passes through the= CPE. The CPE's "option 82" support decorates the DHCP request with the CPE= 's MAC address in a header. This then matches the second rule in Radius, en= suring that no matter what device the customer plugged in - it gets the Ser= vice IP. > >> > > >> > This then dovetails into the QoS - because we can be 100% sure that = the customer's router has the IP address of the Service IP record in their = client site. > >> > > >> > It took about an afternoon to setup, and is really nice. We have add= itional rules like "place unknown CPEs into a block that is redirected to a= page reminding the installer to call in the account for setup", special ha= ndling of suspended accounts and similar. > >> > > >> > People have been begging Ubiquiti to a) support option 82 properly o= n the M5/M2 line (I have a 10 year old request still unanswered!), and b) p= rovide some sort of RADIUS setup baked into UISP. The latter won't happen, = because it reduces vendor lock-in. But it's really easy to setup, and use U= ISP as a "source of truth". (Obviously, when your clients are bridged you n= eed to take precautions - client isolation, switch port isolation and DHCP = snooping) > >> > > >> > > >> > On Wed, Nov 9, 2022 at 10:07 AM dan wrote: > >> >> > >> >> How are you linking UISP to RADIUS? > >> >> > >> >> On Sat, Nov 5, 2022 at 10:29 AM Robert Chac=C3=B3n via LibreQoS wrote: > >> >>> > >> >>> In our particular case we use RADIUS tied to UISP so we don't have= the immediate need, but I think it's an important feature to add. > >> >>> > >> >>> Perhaps cpumap-pping can have a feature to define "shaped subnets"= during the filter setup, and then we could query cpumap-pping for a JSON o= utput of IPs detected in traffic that are in the "shaped subnets" groups, b= ut not defined in the hash map. > >> >>> > >> >>> Curious to hear what others think here. Would others need this in = order to adopt LibreQoS? > >> >>> > >> >>> > >> >>> On Sat, Nov 5, 2022 at 7:33 AM Herbert Wolverson via LibreQoS wrote: > >> >>>> > >> >>>> As we approach the v1.3 pre-release feature freeze, I've been thi= nking a little bit about nice things to have. One thing I found useful in b= oth BracketQoS and Preseem was the ability to grab a list of IP addresses t= hat had been through the shaper, but weren't mapped to a queue (obviously, = only from within the "allowed IP" range - we're not trying to map the Inter= net!). > >> >>>> > >> >>>> In Preseem, there's a link to download a CSV file containing all = the unmapped IP addresses and how much traffic they have consumed. BracketQ= oS (pre cpumap-pping) has a report showing the IPs (no traffic). > >> >>>> > >> >>>> *Why is this useful?* > >> >>>> > >> >>>> Knowing which local IP addresses were processed but not mapped le= ts you find: > >> >>>> > >> >>>> * the times that a device was installed, but the on-boarding proc= ess wasn't completed. Yes, that shouldn't happen. And - unfortunately - it = occasionally does. If you're using RADIUS-based authentication, it's really= difficult for this to happen - but not everyone is. > >> >>>> * If there's a bug in your shaper integration, it's helpful to se= e "oops, I put X on the default" > >> >>>> * Just occasionally, you get a customer who needs a special setup= ; it's helpful to see that it worked. > >> >>>> > >> >>>> *Current Status* > >> >>>> > >> >>>> Before cpumap-pping, Bracket was grabbing them by reading the ppi= ng output and listing addresses that didn't match a shaping rule. That does= n't work now: > >> >>>> > >> >>>> * xdp_pping is spitting out TC handles, rather than IP addresses. > >> >>>> * With a default rule in place, and handling for IPv6 and IPv4 su= bnets, an IP address might not exactly match an entry (requires an LPM trie= lookup) - and IPs matching a default rule (::/0 or 0.0.0.0/0) will always = come back with the "default" handle. > >> >>>> > >> >>>> It's currently pretty tricky to do. > >> >>>> > >> >>>> So I'm curious; would others like to see this? I have a few ideas= for how to make it work, but don't want to start serious planning/design i= f I'm the only one who wants the feature. > >> >>>> _______________________________________________ > >> >>>> LibreQoS mailing list > >> >>>> LibreQoS@lists.bufferbloat.net > >> >>>> https://lists.bufferbloat.net/listinfo/libreqos > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Robert Chac=C3=B3n > >> >>> CEO | JackRabbit Wireless LLC > >> >>> Dev | LibreQoS.io > >> >>> > >> >>> _______________________________________________ > >> >>> LibreQoS mailing list > >> >>> LibreQoS@lists.bufferbloat.net > >> >>> https://lists.bufferbloat.net/listinfo/libreqos > >> > > >> > _______________________________________________ > >> > LibreQoS mailing list > >> > LibreQoS@lists.bufferbloat.net > >> > https://lists.bufferbloat.net/listinfo/libreqos > >> > >> > >> > >> -- > >> This song goes out to all the folk that thought Stadia would work: > >> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698136= 6665607352320-FXtz > >> Dave T=C3=A4ht CEO, TekLibre, LLC > > > > _______________________________________________ > > LibreQoS mailing list > > LibreQoS@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/libreqos > > > > -- > This song goes out to all the folk that thought Stadia would work: > https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698136666= 5607352320-FXtz > Dave T=C3=A4ht CEO, TekLibre, LLC --=20 This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656= 07352320-FXtz Dave T=C3=A4ht CEO, TekLibre, LLC