[LibreQoS] Tracking unknown IPs (maybe for 1.4?)

[LibreQoS] Tracking unknown IPs (maybe for 1.4?)

[Herbert Wolverson]

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2286 bytes --]

Re: [LibreQoS] Tracking unknown IPs (maybe for 1.4?)

[Robert Chacón]

[-- Attachment #1: Type: text/plain, Size: 2842 bytes --]

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 <http://jackrabbitwireless.com>
Dev | LibreQoS.io

[-- Attachment #2: Type: text/html, Size: 3908 bytes --]

Re: [LibreQoS] Tracking unknown IPs (maybe for 1.4?)

[dan]

[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]

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 <http://jackrabbitwireless.com>
> Dev | LibreQoS.io
>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

[-- Attachment #2: Type: text/html, Size: 4668 bytes --]

Re: [LibreQoS] Tracking unknown IPs (maybe for 1.4?)

[Herbert Wolverson]

[-- Attachment #1: Type: text/plain, Size: 5803 bytes --]

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 <dandenson@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 <http://jackrabbitwireless.com>
>> Dev | LibreQoS.io
>>
>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>>
>

[-- Attachment #2: Type: text/html, Size: 7606 bytes --]

Re: [LibreQoS] Tracking unknown IPs (maybe for 1.4?)

[Dave Taht]

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 <dandenson@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

Re: [LibreQoS] Tracking unknown IPs (maybe for 1.4?)

[Herbert Wolverson]

[-- Attachment #1: Type: text/plain, Size: 7076 bytes --]

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.

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.

On Wed, Nov 9, 2022 at 10:23 AM Dave Taht <dave.taht@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 <dandenson@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
>

[-- Attachment #2: Type: text/html, Size: 9255 bytes --]

Re: [LibreQoS] Tracking unknown IPs (maybe for 1.4?)

[Dave Taht]

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.taht@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 <dandenson@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] on building better router software on older routers (cambium/ubnt lawsuit)

[Dave Taht]

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-settles-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 <dave.taht@gmail.com> wrote:
>
> 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.taht@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 <dandenson@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



-- 
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

Re: [LibreQoS] on building better router software on older routers (cambium/ubnt lawsuit)

[dan]

[-- Attachment #1: Type: text/plain, Size: 15297 bytes --]

Just to clear it up a hair.  Cambium screwed that up.  They literally broke
the law by providing instructions to bypass encryption (The provided it to
me, their claims to the contrary are lies.), which is a DMCA violation and
isn't covered in fair use because cambium didn't own the devices.  They
also used a contract encumbered beta firmware they weren't allowed to touch
per various trade secret laws and that was provided by a wisp that was also
sued for confidentiality breach.  Ubiquiti basically had no choice but to
sue them.  Plenty of rules on the book about having to defend your
copyrights, trademarks, and contracts else they are void.  Cambium was who
screwed up here, big time.  They could have and should have made the
elevated firmware OR offered it as an openwrt module and published
supported chipsets.  The community would have figured the rest out from
tftp recovery installs or their own beta firmwares which they had fair use
on and Ubiquiti would have no obligation to defend anything and no
standing.

I don't like how Ubiquiti handled it, but legally speaking they had little
choice but to do something.  Cambium on the other hand royally screwed up.
As evidenced by Ubiquiti losing nothing, changing nothing except tightening
up even more and even disengaging in the community and Cambium lost a
product line entirely with immediate halt of sales and barred from
distribution or even support and even stroked UI a check...  That's an
exceptionally one sided settlement.

open source licenses of course stomped on pretty hard by both parties.

IMO, there is no practical way to target the CPE with updated firmwares to
provide AQM there.  Too many vendors, no compliance on GPL for firmware
though they are all using openwrt underneath except Mikrotik and cambiums
450 line.  Operators have fair use on our products so as long as LibreQOS
never provides instructions to bypass or break encryption then that's not
an issue, just the practicalities of actually doing this.

The type of wISP that is really interested in AQM in any way is also likely
the ones quickly leaving the old hardware behind.  I have a dominantly
ubiquiti network and <5% of them are old enough that they came with an
unencrypted bootloader or anyone at openwrt has figured out how to work
around, and even if I did I wouldnt get airmax anymore, I'd have to go to
straight 802.11ac which is substantially inferior.

In other words, a LOT of work for little to no gain practically speaking.

Slight divergence here... If you search the mikrotik forums, I've asked for
an outdoor device with an ARM CPU that has 12-60V PoE IN and matching PoE
out to function as a bump in the wire.  Could be used as a bridge device
injecting option 82 and doing a bridge shaper, or could act as a router, or
even just to capture packets etc.  You could use a device like this to sit
between an access point and it's POP switch or router, or whatever novel
network design you can think of... Then push customer upload shaping off to
that device as well.    Go bump that if you like the idea.  They have the
wAP AC that is very close, but it doesn't pass through PoE.

So I think that the only practical option is to either target just the
edge, or edge + tower sites, or find a device that can act as the dmarc for
customers like mikrotik's GPEN21 which runs their SWOS and I don't know if
you could get openwrt on there.


On Wed, Nov 9, 2022 at 10:50 AM Dave Taht via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> 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-settles-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 <dave.taht@gmail.com> wrote:
> >
> > 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.taht@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 <dandenson@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
>
>
>
> --
> 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
>

[-- Attachment #2: Type: text/html, Size: 20050 bytes --]