<div dir="ltr"><div>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):</div><div><br></div><div><ul><li>A server contains an instance of FreeRADIUS.</li><li>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".</li><ul><li>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.</li><li>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.</li><li>The radius database is refreshed with this information.</li></ul><li>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.</li><li>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.</li></ul><div>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.</div><div><br></div><div>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.</div><div><br></div><div>People have been <i>begging</i> 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></div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 9, 2022 at 10:07 AM dan <<a href="mailto:dandenson@gmail.com">dandenson@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"><div dir="ltr">How are you linking UISP to RADIUS?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Curious to hear what others think here. Would others need this in order to adopt LibreQoS?<br></div><div><br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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!).</div><div><br></div><div>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></div><div><br></div><div>*Why is this useful?*</div><div><br></div><div>Knowing which local IP addresses were processed but not mapped lets you find:</div><div><br></div><div>* 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.</div><div>* If there's a bug in your shaper integration, it's helpful to see "oops, I put X on the default"</div><div>* Just occasionally, you get a customer who needs a special setup; it's helpful to see that it worked.<br></div><div><br></div><div>*Current Status*<br></div><div><br></div><div>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:</div><div><br></div><div>* xdp_pping is spitting out TC handles, rather than IP addresses.</div><div>* 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" target="_blank">0.0.0.0/0</a>) will always come back with the "default" handle.</div><div><br></div><div>It's currently pretty tricky to do.</div><div><br></div><div>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></div></div>
_______________________________________________<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>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr">Robert Chacón<br><div>CEO | <a href="http://jackrabbitwireless.com" target="_blank">JackRabbit Wireless LLC</a></div><div>Dev | <a href="http://LibreQoS.io" target="_blank">LibreQoS.io</a><br></div><br></div></div>
_______________________________________________<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>
</blockquote></div>
</blockquote></div>