<div dir="ltr"><div>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.</div><div><br></div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 9, 2022 at 10:23 AM Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">does dhcp option 82 work on openwrt?<br>
<br>
I long ago reflashed all my m2 and m5s to openwrt. outperforms ubnts<br>
default build across the board if you tune down the txop size to<br>
2.5ms.<br>
<br>
On Wed, Nov 9, 2022 at 8:20 AM Herbert Wolverson via LibreQoS<br>
<<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br>
><br>
> 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):<br>
><br>
> A server contains an instance of FreeRADIUS.<br>
> 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".<br>
><br>
> 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.<br>
> 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.<br>
> The radius database is refreshed with this information.<br>
><br>
> 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.<br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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)<br>
><br>
><br>
> On Wed, Nov 9, 2022 at 10:07 AM dan <<a href="mailto:dandenson@gmail.com" target="_blank">dandenson@gmail.com</a>> wrote:<br>
>><br>
>> How are you linking UISP to RADIUS?<br>
>><br>
>> On Sat, Nov 5, 2022 at 10:29 AM Robert Chacón via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> Curious to hear what others think here. Would others need this in order to adopt LibreQoS?<br>
>>><br>
>>><br>
>>> On Sat, Nov 5, 2022 at 7:33 AM Herbert Wolverson via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br>
>>>><br>
>>>> 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!).<br>
>>>><br>
>>>> 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).<br>
>>>><br>
>>>> *Why is this useful?*<br>
>>>><br>
>>>> Knowing which local IP addresses were processed but not mapped lets you find:<br>
>>>><br>
>>>> * 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.<br>
>>>> * If there's a bug in your shaper integration, it's helpful to see "oops, I put X on the default"<br>
>>>> * Just occasionally, you get a customer who needs a special setup; it's helpful to see that it worked.<br>
>>>><br>
>>>> *Current Status*<br>
>>>><br>
>>>> 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:<br>
>>>><br>
>>>> * xdp_pping is spitting out TC handles, rather than IP addresses.<br>
>>>> * 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 <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a>) will always come back with the "default" handle.<br>
>>>><br>
>>>> It's currently pretty tricky to do.<br>
>>>><br>
>>>> 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.<br>
>>>> _______________________________________________<br>
>>>> LibreQoS mailing list<br>
>>>> <a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
>>>> <a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Robert Chacón<br>
>>> CEO | JackRabbit Wireless LLC<br>
>>> Dev | LibreQoS.io<br>
>>><br>
>>> _______________________________________________<br>
>>> LibreQoS mailing list<br>
>>> <a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
>>> <a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
><br>
> _______________________________________________<br>
> LibreQoS mailing list<br>
> <a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
<br>
<br>
<br>
-- <br>
This song goes out to all the folk that thought Stadia would work:<br>
<a href="https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz" rel="noreferrer" target="_blank">https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz</a><br>
Dave Täht CEO, TekLibre, LLC<br>
</blockquote></div>