From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 B4C953CB35; Mon, 4 Oct 2021 14:57:31 -0400 (EDT) Received: by mail-wr1-x42d.google.com with SMTP id v17so32525599wrv.9; Mon, 04 Oct 2021 11:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wfN3sWiSwuF+fsfQmm3wAW7QfpT9qeHMoT99xgOyqHY=; b=TzYUQDencUgFIWl84We+7uhSFiBXSsWQmnyxVaIrlN5QzrfvZ+cFLe7/ADq42wXH6Y sBRNU5aQg8CWRbaGMUSRg9xlW5kAOFHaalhAuMVU0vVAjomFlBOaLtSXlR+GM4DYx7AU NJq5jPCGgTXfAwHqn31SlSBeNKvgAsFoJ6+mgD0ThTK/D93k12VTNFEu1hw4S3buiEBO Pt2zjXJpPQesTyXCKHXyTCeNwyBGIcUzEEMTOSNZTe6yLfUiJprUmCJPveA6/aa09Jzr zWNUFuqiPoY2SPyIxm4m4dQD+/wZr1Ceoq1GxE7f/AKqcZDOdSCNjrvs6jYgj4/+Vptu xnHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wfN3sWiSwuF+fsfQmm3wAW7QfpT9qeHMoT99xgOyqHY=; b=Q2/26gRAVuo2KUuZ8hC3ESIGfZPM10n2jG9mDZQ45T+2jc6Ym8YVqv6CZ9XUR9QDTc +H8x16F9+MNVLwDo/rmfX8v9RQy+a5U9Sc0kHHedFHKYT6SK3uH64g/ePWe4tLBCIeau R0rTfcNLMiIAPASfaYHXJf5RhRlfXBJkX7pfWP4+E0rdUIghlMinmx9P4Gd0mg0+NhLn Oiioa7v2wnDvcbAJJ7sthYD/XPw/nRQQRMOr9UxPQe47TNYOdO+eESdz0MXKCIBG7dwH cnycJ3peNRk4cHCJ+cinj9JoyjukXvSnyxQHvBtcO4DkWfZaH4rhbidSERYOW4k1Fztw Wk1w== X-Gm-Message-State: AOAM5337Mx5Xq2kYNgYZvoClBa618Ezo54oM1SDZ1BWCecQs65V+VUGX 2pZHivMOkkFr82ymznnltVedLlzLU9VhkoiKMHg= X-Google-Smtp-Source: ABdhPJw8NlN49Ez++7l9gwlBceRwBn4yLUFfBkDlf4rw+P8FgdW5AetFJn0gIACfNMz2LP389FLKDiWAOeRyq+cZvKE= X-Received: by 2002:a5d:6292:: with SMTP id k18mr16412782wru.110.1633373850514; Mon, 04 Oct 2021 11:57:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?0JrQuNGA0LjQu9C7INCb0YPQutC+0L3QuNC9?= Date: Mon, 4 Oct 2021 21:57:18 +0300 Message-ID: To: Dave Taht Cc: Make-Wifi-fast , cerowrt-devel , starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="00000000000025378c05cd8b7ce6" X-Mailman-Approved-At: Mon, 04 Oct 2021 16:19:18 -0400 Subject: Re: [Cerowrt-devel] [Make-wifi-fast] resuming the right to repair fight in particular X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 18:57:32 -0000 --00000000000025378c05cd8b7ce6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is a big another issue. Even if we work with softMAC driver, it can ignore or override wireless-regdb. For example, iwlfifi could advertise, but ignore MCS 9-11 according to LAR decision. More then that, LAR can spread it's logic and disable some channels globally for all systems. That's why, for example, if somebody use both QCA and Intel Wi-Fi modules, the last one will force right use it's settings through cfg80211 API. So there is a huge issue in kernel restrictions and rules, I think. Where wireless API is mostly developed by... Intel. More transparency and fairness required there, I think. No kernel module should be able to become a dictator. What about a certification process, well, I saw the dark side. Certification firmwares are very-very-very far from regular firmwares. That's how it works today. FCC can certify a product, but then it's firmware cold be modified without any control from FCC. FCC tries to do the best they can with AFC (I think). But today there are no any mechanisms to 1) Force vendors to use regular firmware for certification 2) Certify firmware updates. We'll have to invent something about that. Best regards, Kirill Lukonin =D0=BF=D0=BD, 4 =D0=BE=D0=BA=D1=82. 2021 =D0=B3., 19:54 Dave Taht : > On Sun, Jul 25, 2021 at 7:48 AM Dave Taht wrote: > > > > Early on in the FLOSS podcast ( > > https://twit.tv/shows/floss-weekly/episodes/638?autostart=3Dfalse ) I > > harped on what is basically my biggest issue with the world of IoT - > > home routers only being a tiny subset - being able to fix the stuff > > you bought, and KNOWING that the stuff you bought isn't going to > > betray you. The cell phone universe is about as well handled in this > > department as seems feasible > > I take it back. > > > https://www.vice.com/en/article/z3xpm8/company-that-routes-billions-of-te= xt-messages-quietly-says-it-was-hacked > > >, but the rest... ugh! > > > > I know our lists are mostly technically oriented but does anyone know > > of a site, a forum, a slack channel, a linked in group, a faceboook > > group, some legal advisory group... somewhere??, where I, at least, > > could vent in something in a productive direction? I'm very happy to > > finally be in BITAG but that's just about lag. > > > > I often look back on our 2015 fcc fight with remorse, as we didn't > > have enough capital to capitalize on it, and I just went back to > > finishing up our research. We knocked 'em down FLAT with that one > > broadside but nobody read the filing itself, just the press release, > > and the vogons got up again, like a tarbaby, and resumed bad > > governance of the future as usual. > > > > For the record, if you haven't read: > > > > http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf > > > > Our proposal buried on page 12: > > > > 1. Any vendor of SDR, wireless, or Wi=C2=ADFi radio must make public th= e > > full and maintained source > > code for the device driver and radio firmware in order to maintain FCC > > compliance. The source > > code should be in a buildable, change controlled source code > > repository on the Internet, > > available for review and improvement by all. > > > > 2. The vendor must assure that secure update of firmware be working at > > shipment, and that update streams be under ultimate control of the > > owner of the equipment. Problems with compliance can then be fixed > > going forward by the person legally responsible for the router being > > in compliance. > > > > 3. The vendor must supply a continuous stream of source and binary > > updates that must respond to regulatory transgressions and Common > > Vulnerability and Exposure reports (CVEs) within 45 > > days of disclosure, for the warranted lifetime of the product, the > > business lifetime of the vendor, > > or until five years after the last customer shipment, whichever is > longer. > > > > 4. Failure to comply with these regulations should result in FCC > > decertification of the existing > > product and, in severe cases, bar new products from that vendor from > > being considered for > > certification. > > > > 5. Additionally, we ask the FCC to review and rescind any rules for > > anything that conflict with > > open source best practices, produce unmaintainable hardware, or cause > > vendors to believe they > > must only ship undocumented =E2=80=9Cbinary blobs=E2=80=9D of compiled = code or use > > lockdown mechanisms > > that forbid user patching. This is an ongoing problem for the Internet > > community committed to > > best practice change control and error correction on safety=C2=AD criti= cal > systems > > > > > > -- > > Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xr= wgw > > > > Dave T=C3=A4ht CEO, TekLibre, LLC > > > > -- > Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xrwg= w > > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --00000000000025378c05cd8b7ce6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a big another issue. Even if w= e work with softMAC driver, it can ignore or override wireless-regdb.=C2=A0=

For example, iwlfifi could ad= vertise, but ignore MCS 9-11 according to LAR decision. More then that, LAR= can spread it's logic and disable some channels globally for all syste= ms.=C2=A0


That's why, for example, if somebody use both QCA and Int= el Wi-Fi modules, the last one will force right use it's settings throu= gh cfg80211 API.=C2=A0

S= o there is a huge issue in kernel restrictions and rules, I think.=C2=A0
Where wireless API is mostly developed by... Intel.
More transparency and fairness required there, I think= . No kernel module should be able to become a dictator.=C2=A0


What abou= t a certification process, well, I saw the dark side.=C2=A0
Certification firmwares are very-very-very far from regular firmw= ares. That's how it works today.=C2=A0
FCC can c= ertify a product, but then it's firmware cold be modified without any c= ontrol from FCC.
FCC tries to do the best they can w= ith AFC (I think).=C2=A0
But today there are no any = mechanisms to=C2=A0
1) Force vendors to use regular = firmware for certification
2) Certify firmware updat= es.=C2=A0

We'll have= to invent something about that.=C2=A0


Bes= t regards,
Kirill Lukonin

=D0=BF=D0=BD, 4 =D0=BE=D0=BA=D1=82.= 2021 =D0=B3., 19:54 Dave Taht <dave.taht@gmail.com>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Sun, Jul 25, 2021 at 7:48 AM Dave Taht <= ;dave.taht@gmail.com> wrote:
>
> Early on in the FLOSS podcast (
> https:= //twit.tv/shows/floss-weekly/episodes/638?autostart=3Dfalse ) I
> harped on what is basically my biggest issue with the world of IoT - > home routers only being a tiny subset - being able to fix the stuff > you bought, and KNOWING that the stuff you bought isn't going to > betray you. The cell phone universe is about as well handled in this > department as seems feasible

I take it back.

https://www.vice.com/en/article/z3xpm8/com= pany-that-routes-billions-of-text-messages-quietly-says-it-was-hacked
>, but the rest... ugh!
>
> I know our lists are mostly technically oriented but does anyone know<= br> > of a site, a forum, a slack channel, a linked in group, a faceboook > group, some legal advisory group... somewhere??, where I, at least, > could vent in something in a productive direction? I'm very happy = to
> finally be in BITAG but that's just about lag.
>
> I often look back on our 2015 fcc fight with remorse, as we didn't=
> have enough capital to capitalize on it, and I just went back to
> finishing up our research. We knocked 'em down FLAT with that one<= br> > broadside but nobody read the filing itself, just the press release, > and the vogons got up again, like a tarbaby, and resumed bad
> governance of the future as usual.
>
> For the record, if you haven't read:
>
> http://= fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf
>
> Our proposal buried on page 12:
>
> 1. Any vendor of SDR, wireless, or Wi=C2=ADFi radio must make public t= he
> full and maintained source
> code for the device driver and radio firmware in order to maintain FCC=
> compliance. The source
> code should be in a buildable, change controlled source code
> repository on the Internet,
> available for review and improvement by all.
>
> 2. The vendor must assure that secure update of firmware be working at=
> shipment, and that update streams be under ultimate control of the
> owner of the equipment. Problems with compliance can then be fixed
> going forward by the person legally responsible for the router being > in compliance.
>
> 3. The vendor must supply a continuous stream of source and binary
> updates that must respond to regulatory transgressions and Common
> Vulnerability and Exposure reports (CVEs) within 45
> days of disclosure, for the warranted lifetime of the product, the
> business lifetime of the vendor,
> or until five years after the last customer shipment, whichever is lon= ger.
>
> 4. Failure to comply with these regulations should result in FCC
> decertification of the existing
> product and, in severe cases, bar new products from that vendor from > being considered for
> certification.
>
> 5. Additionally, we ask the FCC to review and rescind any rules for > anything that conflict with
> open source best practices, produce unmaintainable hardware, or cause<= br> > vendors to believe they
> must only ship undocumented =E2=80=9Cbinary blobs=E2=80=9D of compiled= code or use
> lockdown mechanisms
> that forbid user patching. This is an ongoing problem for the Internet=
> community committed to
> best practice change control and error correction on safety=C2=AD crit= ical systems
>
>
> --
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=3Dc9gLo6Xrwgw
>
> Dave T=C3=A4ht CEO, TekLibre, LLC



--
Fixing Starlink's Latencies: = https://www.youtube.com/watch?v=3Dc9gLo6Xrwgw

Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat= .net/listinfo/make-wifi-fast
--00000000000025378c05cd8b7ce6--