From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 3EC0E3B2A4 for ; Wed, 9 Nov 2022 11:40:10 -0500 (EST) Received: by mail-wr1-x42b.google.com with SMTP id o4so26643460wrq.6 for ; Wed, 09 Nov 2022 08:40:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=E3hQvsiSVppJXiEPKGgifCKQcOk6GVd3mWS9YI4YAVk=; b=b6nN0xN/ti3YMelGzsPjGaDStHaHQfiWMJ89AF861ZWI9Twp/iqA+gGGIIvlxapkLZ SWBhXWhBT5cZ/Orga3KBXCSTKcp7be5TpObQc1ly/zj1pBHi2BZ0roBpeMbZ+eR7Vnno NXnEF4ga+hTo4YIKcii/dJwOFpwjuZ7T84e+PNGUvOvdGIJE6+FmhHniKmIKlWjKVch5 /UeQ0t/ON3Gw2GvQZfWqF21HHgZLcohe2th8nMWGW68j/KbLCaOKUPAlfDyvGrP1e4zc Q159EZKGpUdgOkflKPP/orYBdKQhLUAebLPirZTRjh7gNKubsIyWdRwcEwuSLZ/Uo+Lu +3Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to: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=E3hQvsiSVppJXiEPKGgifCKQcOk6GVd3mWS9YI4YAVk=; b=Yqd+GbN6SbIsGOStcNz3LdbcWqO//tuGmThfvkTmJ9L8g1KDDq1YSspCO1RI48SY7S Qyl1pISfpa36vF+DPLuYRCEjfvPN09XQLhGqjLpTA6xqT43MPrgP1pIoJc7GAq6/3XNH 9+YuDbcoWTuoALuvS35wHHP/nCNVoesVkkmwn/Zl9vLHm9PEw9ZgHTUuBNBG7VVx7b7Q H8ysfhDBO03BVucL4FRupjcJclId/wVSFTuUxxOGt/KThRvSNg0yemiMMU0XEuR0uieQ SkPA8+yG+9qUdGaDyXRq3E4nqqXgVdQ7nN/BOvg0s9esmJ0VC9j06iNvyke5/3kAGECJ av/A== X-Gm-Message-State: ACrzQf3ZIL//SjthMiKLHHNqNUzGiwrBA1Kk25GaMBcwpUdMDkwaHKP9 4keJgVSim3TlAqibqaJwF7Ybry3ZuSLk2r+wP3IIwvOh X-Google-Smtp-Source: AMsMyM4alKhFeizy6Z3dD5cH64r8lwz3zMPfHEcO2aXAbUbVZqhshEMPmY2WKMJb+4JMcZ56cXU3kPuf3vS6FS833y4= X-Received: by 2002:adf:f242:0:b0:236:68ef:e76e with SMTP id b2-20020adff242000000b0023668efe76emr39990119wrp.482.1668012009134; Wed, 09 Nov 2022 08:40:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Wed, 9 Nov 2022 08:39:56 -0800 Message-ID: To: Herbert Wolverson Cc: libreqos Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:40:10 -0000 On Wed, Nov 9, 2022 at 8:27 AM Herbert Wolverson via LibreQoS wrote: > > I've no idea. We only have a few M2/M5 CPEs left, and all of the access p= oints are running AirMax AC. Since that's neither an open nor standard prot= ocol, 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) make= s 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 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 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 since w= e have everything from apartment complexes with Ethernet jacks to regular U= biquiti 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 device" 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 "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 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 the C= PE. 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, ensu= ring that no matter what device the customer plugged in - it gets the Servi= ce 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 their cl= ient 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 to a p= age reminding the installer to call in the account for setup", special hand= ling 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, be= cause it reduces vendor lock-in. But it's really easy to setup, and use UIS= P as a "source of truth". (Obviously, when your clients are bridged you nee= d to take precautions - client isolation, switch port isolation and DHCP sn= ooping) >> > >> > >> > 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 wrote: >> >>> >> >>> In our particular case we use RADIUS tied to UISP so we don't have t= he immediate need, but I think it's an important feature to add. >> >>> >> >>> Perhaps cpumap-pping can have a feature to define "shaped subnets" d= uring the filter setup, and then we could query cpumap-pping for a JSON out= put 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 or= der to adopt LibreQoS? >> >>> >> >>> >> >>> On Sat, Nov 5, 2022 at 7:33 AM Herbert Wolverson via LibreQoS wrote: >> >>>> >> >>>> As we approach the v1.3 pre-release feature freeze, I've been think= ing a little bit about nice things to have. One thing I found useful in bot= h BracketQoS and Preseem was the ability to grab a list of IP addresses tha= t had been through the shaper, but weren't mapped to a queue (obviously, on= ly from within the "allowed IP" range - we're not trying to map the Interne= t!). >> >>>> >> >>>> In Preseem, there's a link to download a CSV file containing all th= e 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 proces= s wasn't completed. Yes, that shouldn't happen. And - unfortunately - it oc= casionally does. If you're using RADIUS-based authentication, it's really d= ifficult 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 subn= ets, an IP address might not exactly match an entry (requires an LPM trie l= ookup) - and IPs matching a default rule (::/0 or 0.0.0.0/0) will always co= me 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 f= or 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-69813666= 65607352320-FXtz >> Dave T=C3=A4ht CEO, TekLibre, LLC > > _______________________________________________ > LibreQoS mailing list > LibreQoS@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/libreqos --=20 This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656= 07352320-FXtz Dave T=C3=A4ht CEO, TekLibre, LLC