On Wed, Nov 9, 2022 at 8:27 AM Herbert Wolverson via LibreQoS <libreqos@lists.bufferbloat.net> 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 > protocol, 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 (Cambium's > "turn CPEs into Cambium SMs" program that turned into lawsuit city) makes > 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 <dave.t...@gmail.com> 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 >> <libreqos@lists.bufferbloat.net> 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 "mimosa" >> > record. >> > A second radius record is added that matches Option 82 headers to see that >> > a request passed through the Mimosa. This will always hand out the IP >> > 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, >> > ensuring that no matter what device the customer plugged in - it gets the >> > Service 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 >> > additional 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 handling of suspended accounts and similar. >> > >> > People have been begging Ubiquiti to a) support option 82 properly on the >> > M5/M2 line (I have a 10 year old request still unanswered!), and b) >> > provide 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 UISP as a "source of truth". (Obviously, when your clients are >> > bridged you need to take precautions - client isolation, switch port >> > isolation and DHCP snooping) >> > >> > >> > On Wed, Nov 9, 2022 at 10:07 AM dan <danden...@gmail.com> wrote: >> >> >> >> How are you linking UISP to RADIUS? >> >> >> >> On Sat, Nov 5, 2022 at 10:29 AM Robert Chacón via LibreQoS >> >> <libreqos@lists.bufferbloat.net> 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 >> >>> output of IPs detected in traffic that are in the "shaped subnets" >> >>> groups, but 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 >> >>> <libreqos@lists.bufferbloat.net> wrote: >> >>>> >> >>>> As we approach the v1.3 pre-release feature freeze, I've been thinking >> >>>> a little bit about nice things to have. One thing I found useful in >> >>>> both BracketQoS and Preseem was the ability to grab a list of IP >> >>>> addresses that 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 Internet!). >> >>>> >> >>>> In Preseem, there's a link to download a CSV file containing all the >> >>>> unmapped IP addresses and how much traffic they have consumed. >> >>>> BracketQoS (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 lets you >> >>>> find: >> >>>> >> >>>> * the times that a device was installed, but the on-boarding process >> >>>> 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 see >> >>>> "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 pping >> >>>> output and listing addresses that didn't match a shaping rule. That >> >>>> doesn'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 subnets, >> >>>> 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 if >> >>>> I'm the only one who wants the feature. >> >>>> _______________________________________________ >> >>>> LibreQoS mailing list >> >>>> LibreQoS@lists.bufferbloat.net >> >>>> https://lists.bufferbloat.net/listinfo/libreqos >> >>> >> >>> >> >>> >> >>> -- >> >>> Robert Chacón >> >>> 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-6981366665607352320-FXtz >> Dave Täht 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-6981366665607352320-FXtz Dave Täht CEO, TekLibre, LLC _______________________________________________ LibreQoS mailing list LibreQoS@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/libreqos
