From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 04AEB3B2A4 for ; Wed, 9 Nov 2022 11:27:16 -0500 (EST) Received: by mail-pg1-x52d.google.com with SMTP id f63so16665060pgc.2 for ; Wed, 09 Nov 2022 08:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=auOV9wuMJCFnQ7T07SpZx2h1nTbB06TxyAykmS6l7OI=; b=IIwhOg4QwNS+ZhJRMQOx73w6F/1APKy8p51G8Fxz5exIsW2KrjZ8gQ91nzOphYvvgT 3q8ckaejIogTdFmcr60wr0rAzvI7ImNKfapShK2bcfdBrTZ7W5mQQJ+Wn83fVifrLb6O FynbXVtATS12nlJM+kC70eKsEsS4Nwwa+6AGqgXTfowpFD5+cwDuHoHywwy5SnbdzZU3 l83Etk5h+evn08YlMww104d4FAL209PQL8uSPufqZ4BOG//iLx8ziRVc/AnBMuIjJ6d2 vmTsXC//Ti6270vERfbmUlSiJCmfFAUqzMX9OPdu/uz7QXob/QADzAKF59waNrAZGLRF n/gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc: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=auOV9wuMJCFnQ7T07SpZx2h1nTbB06TxyAykmS6l7OI=; b=YyoQkJLxKV1qkioXfXU+5dCDaKcWIxSQMcL4mI4ZcZ4Ik5UoqqXF2cWC/5WzHIBRcQ /0erkXo3r6Zk2zujEOUXtppMm53RGA8oJXZR3aFgvmYMZGM6twThMfILIg2Q/0dtl6C1 CeCsufbKxOKWua07xMdyRA+z+FVlldKTQ44NRrQUTKnWSOW0Dk0zbp9w9bVc0Vh5wXnd UBmERgz4e89PLrhzoSoQAE/wXxuzNGueHCiZAvRbDzKokhhX+idu4UZks2D2pIsbUczr p8LhHlWq/M9YWC2IXq2x36gYO/8h0m8xP5CPLm5v4+Yl5NfXnedBOwdwexbjWjB2gAQq l5PQ== X-Gm-Message-State: ACrzQf3MoAWFGtLqQA8jWLKXHi7HiX9w89WAya9DWqm5OumOxqmqd2Fg 3SerwZdwGduS+4Pvrmu6dJ9uV/y3scdmy9DlilVwZUhw X-Google-Smtp-Source: AMsMyM7lcpXM4rwl93/w+kDsWY43eZXB9XgrErpqmMWCh2CvJAwZ3LT4G/OQm9rmJqc3UF2Ol/F1g/JEXS8zCuziZXE= X-Received: by 2002:aa7:96c7:0:b0:56b:c569:99c with SMTP id h7-20020aa796c7000000b0056bc569099cmr61426911pfq.4.1668011235635; Wed, 09 Nov 2022 08:27:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Herbert Wolverson Date: Wed, 9 Nov 2022 10:27:04 -0600 Message-ID: Cc: libreqos Content-Type: multipart/alternative; boundary="0000000000002e78a305ed0c2184" Subject: Re: [LibreQoS] Tracking unknown IPs (maybe for 1.4?) 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 16:27:17 -0000 --0000000000002e78a305ed0c2184 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 mor= e > 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 sin= ce > we have everything from apartment complexes with Ethernet jacks to regula= r > Ubiquiti devices in bridge mode): > > > > A server contains an instance of FreeRADIUS. > > Periodically, a script runs and queries UISP. It finds client sites wit= h > 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 th= e > 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 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 Radiu= s, > 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 happe= n, > 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 yo= u > need to take precautions - client isolation, switch port isolation and DH= CP > 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 < > libreqos@lists.bufferbloat.net> wrote: > >>> > >>> In our particular case we use RADIUS tied to UISP so we don't have th= e > 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 real= ly > 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 fo= r > 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=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-698136666= 5607352320-FXtz > Dave T=C3=A4ht CEO, TekLibre, LLC > --0000000000002e78a305ed0c2184 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 neith= er an open nor standard protocol, I don't think OpenWRT would work for = us.

I have no doubt that it outperforms the Mx cod= e, though. Elevate (Cambium's "turn CPEs into Cambium SMs" pr= ogram 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
<lib= reqos@lists.bufferbloat.net> wrote:
>
> We have a bespoke solution to do similar (I keep meaning to make it mo= re generic and open source it). The basic operation is (using our Mimosa de= vices as an example; it's actually a lot more complicated than that sin= ce we have everything from apartment complexes with Ethernet jacks to regul= ar Ubiquiti devices in bridge mode):
>
> A server contains an instance of FreeRADIUS.
> Periodically, a script runs and queries UISP. It finds client sites wi= th a device matching the type "Mimosa C5x" and an "other dev= ice" entitled "Service IP".
>
> A radius record is then added for the CPE (using the MAC and IP from t= he Mimosa device), placing the Mimosa CPE on the IP address in the "mi= mosa" 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 th= e MAC address matches a RADIUS record, the device is assigned to the CPE ad= dress from the RADIUS records.
> When a customer's device sends a DHCP request, it passes through t= he CPE. The CPE's "option 82" support decorates the DHCP requ= est with the CPE's MAC address in a header. This then matches the secon= d 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 th= e customer's router has the IP address of the Service IP record in thei= r client site.
>
> It took about an afternoon to setup, and is really nice. We have addit= ional rules like "place unknown CPEs into a block that is redirected t= o a page reminding the installer to call in the account for setup", sp= ecial 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) pro= vide 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 a= re bridged you need to take precautions - client isolation, switch port iso= lation 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=C3=B3n via LibreQoS &l= t;libre= qos@lists.bufferbloat.net> wrote:
>>>
>>> In our particular case we use RADIUS tied to UISP so we don= 9;t have the immediate need, but I think it's an important feature to a= dd.
>>>
>>> Perhaps cpumap-pping can have a feature to define "shaped= subnets" during the filter setup, and then we could query cpumap-ppin= g 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 = <lib= reqos@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 que= ue (obviously, only from within the "allowed IP" range - we'r= e not trying to map the Internet!).
>>>>
>>>> In Preseem, there's a link to download a CSV file cont= aining all the unmapped IP addresses and how much traffic they have consume= d. 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 ma= pped lets you find:
>>>>
>>>> * the times that a device was installed, but the on-boardi= ng process wasn't completed. Yes, that shouldn't happen. And - unfo= rtunately - it occasionally does. If you're using RADIUS-based authenti= cation, 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 specia= l 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 add= resses.
>>>> * With a default rule in place, and handling for IPv6 and = IPv4 subnets, an IP address might not exactly match an entry (requires an L= PM trie lookup) - and IPs matching a default rule (::/0 or 0.0.0.0/0) will alway= s 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 pl= anning/design if I'm the only one who wants the feature.
>>>> _______________________________________________
>>>> LibreQoS mailing list
>>>> LibreQoS@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listin= fo/libreqos
>>>
>>>
>>>
>>> --
>>> Robert Chac=C3=B3n
>>> CEO | JackRabbit Wireless LLC
>>> Dev | LibreQoS.io
>>>
>>> _______________________________________________
>>> LibreQoS mailing list
>>> LibreQoS@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/l= ibreqos
>
> _______________________________________________
> LibreQoS mailing list
> Li= breQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos<= /a>



--
This song goes out to all the folk that thought Stadia would work:
https://www.= linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXt= z
Dave T=C3=A4ht CEO, TekLibre, LLC
--0000000000002e78a305ed0c2184--