[NNagain] Internet Education for Non-technorati?

Robert McMahon rjmcmahon at rjmcmahon.com
Fri Oct 13 11:55:45 EDT 2023 

That's interesting. It's basically saying the security risk is openwrt sw. The chips themselves aren't, and signal processing is not either. 

I'll add that to FiWi's remote radio head argument, i.e. it's inherently more secure. Security is a huge problem for everyone.

⁣Bob

On Oct 13, 2023, 1:34 AM, at 1:34 AM, David Lang <david at lang.hm> wrote:
>On Thu, 12 Oct 2023, rjmcmahon wrote:
>
>> I think we're looking at different parts of the elephant. I perceive
>huge 
>> advances in WiFi (phy, dsp, radios, fems, etc.) and residential
>gateway chips 
>> of late.
>
>My point is that the chips behavior doesn't change when you switch to a
>newer 
>release of openwrt on the same chipset. When you do  a new hardware
>version, you 
>need to do all the testing that was mentioned (and more) but if you are
>looking 
>at updating the opewrt image, you have far less that you need to check.
>
>David Lang
>
>> Not sure the state of chips used by the openwrt folks here, though 
>> they may be lagging a bit - not sure.
>>
>>
>https://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
>>
>> Broadcom’s Wi-Fi 7 ecosystem product portfolio includes the BCM6765, 
>> BCM47722, and BCM4390.
>>
>> The BCM6765 is optimized for the residential Wi-Fi access point
>market. Key 
>> features include:
>> ...
>> The BCM47722 is an enterprise access point platform SoC supporting
>Wi-Fi 7, 
>> Bluetooth Low Energy, and 802.15.4 protocols. Key features include:
>> ...
>> The BCM4390 is a highly-integrated Wi-Fi 7 and Bluetooth 5 combo chip
>
>> optimized for mobile handset applications. Key features include:
>> ...
>>
>> Bob
>>> On Thu, 12 Oct 2023, rjmcmahon via Nnagain wrote:
>>> 
>>>> I looked at openwrt packages and iperf 2 is  at version 2.1.3 which
>is a 
>>>> few years old.
>>>> 
>>>> The number of CPE/AP systems to test against is quite large. Then
>throwing 
>>>> in versions for backwards compatibility testing adds yet another
>vector.
>>> 
>>> for the market as a whole, yes, it's a hard problem. But for an
>>> individual manfacturer, they only have to work with their equipment,
>>> not all the others. The RF side isn't changing from release to
>release
>>> (and usually the firmware for the Wifi isn't changing), so that
>>> eliminates a lot of the work. They need to do more smoke testing of
>>> new releases than a full regression/performance test. Some
>>> incompatibility creeping in is the most likely problem, not a subtle
>>> performance issue.
>>> 
>>> For the Scale conference, we have a Pi tied to a couple relays
>hooked
>>> to the motherboard of the router we use and it's tied in to our
>github
>>> repo, so every PR gets auto-flashed to the router and simple checks
>>> done. Things like this should be easy to setup and will catch most
>>> issues.
>>> 
>>> David Lang
>>> 
>>>> Since it's performance related, statistical techniques are required
>
>>>> against multiple metrics to measure statistically the same or not.
>Finally 
>>>> with WiFi, one needs to throw in some controlled, repeatable RF 
>>>> variability around the d-matrices (range) & h-matrices (frequency 
>>>> responses in both phase and amplitudes per the MIMO spatial
>streams.)
>>>> 
>>>> I can see why vendors (& system integrators) might be slow to adopt
>the 
>>>> latest if there is not some sort of extensive qualification ahead
>of that 
>>>> adoption.
>>>> 
>>>> Bob
>>>> 
>>>> PS. Iperf 2 now has 2.5+ million downloads (if sourceforge is to be
>
>>>> believed.) My wife suggested I write a book titled, "How to create 
>>>> software with 2.5M downloads, a zero marginal cost to produce, and
>get 
>>>> paid zero dollars!!" I suspect many openwrt & other programmers
>could add 
>>>> multiple chapters to such a book.
>>>> 
>>>>> On Thu, Oct 12, 2023 at 9:04 AM rjmcmahon via Nnagain
>>>>> <nnagain at lists.bufferbloat.net> wrote:
>>>>>> 
>>>>>> Sorry, my openwrt information seems to be incorrect and more
>vendors use
>>>>>> openwrt then I realized. So, I really don't know the numbers
>here.
>>>>> 
>>>>> There are not a lot of choices in the market. On the high end,
>like
>>>>> eero, we are seeing Debian derived systems, also some chromeOS
>>>>> devices. Lower end there is "buildroot", and forked openwrts like
>>>>> Meraki.
>>>>> 
>>>>> So the whole home router and cpe market has some, usually
>obsolete,
>>>>> hacked up, and unmaintained version of openwrt at its heart, on
>>>>> everything from SFPs to the routers and a lot of iOt, despite many
>>>>> advancements and security patches in the main build.
>>>>> 
>>>>> It would be my earnest hope, with a clear upgrade path, downstream
>>>>> manufacturers would release within a few months of the main
>OpenWrt
>>>>> releases, or even at the same time, having worked with their
>customers
>>>>> through the 6 month release candidate cycle. Microsoft
>accomplishes
>>>>> this, at least.
>>>>> 
>>>>> 
>>>>
>https://www.reddit.com/r/openwrt/comments/175z8t9/imminent_release_of_openwrt_2305/
>>>>> 
>>>>>> I do agree with the idea that fixes should be pushed to the
>mainline and
>>>>>> that incremental upgrades should be standard practice.
>>>>> 
>>>>> +1000
>>>>> 
>>>>>> Arista's SW VP gave a talk where he said that 80% of their
>customer
>>>>>> calls about bugs were already fixed but their customer wasn't
>following
>>>>>> an upgrade policy. This approach applies to most any sw based
>product.
>>>>> 
>>>>> +100
>>>>> 
>>>>>> 
>>>>>> Bob
>>>>>> > Hi David,
>>>>>> >
>>>>>> > The vendors I know don't roll their own os code either. The
>make their
>>>>>> > own release still mostly based from Linux and they aren't tied
>to the
>>>>>> > openwrt release process.
>>>>>> >
>>>>>> > I think GUIs on CPEs are the wrong direction. Consumer network
>>>>>> > equipment does best when it's plug and play. Consumers don't
>have all
>>>>>> > the skills needed to manage an in home packet network that
>includes
>>>>>> > wifi.
>>>>>> >
>>>>>> > I recently fixed a home network for my inlaws. It's a combo of
>>>>>> > structured wire and WiFi APs. I purchased the latest equipment
>from
>>>>>> > Amazon vs use the ISP provided equipment. I can do this
>reasonably
>>>>>> > well because I'm familiar with the chips inside.
>>>>>> >
>>>>>> > The online tech support started with trepidation as he was
>concerned
>>>>>> > that the home owner, i.e me, wasn't as skilled as the ISP
>technicians.
>>>>>> > He suggested we schedule that but I said we were good to go w/o
>one.
>>>>>> >
>>>>>> > He asked to speak to my father in law when we were all done. He
>told
>>>>>> > him, "You're lucky to have a son in law that know what he's
>doing. My
>>>>>> > techs aren't as good, and I really liked working with him too."
>>>>>> >
>>>>>> > I say this not to brag, as many on this list could do the
>equivalent,
>>>>>> > but to show that we really need to train lots of technicians on
>things
>>>>>> > like RF and structured wiring. Nobody should be "lucky" to get
>a
>>>>>> > quality in home network.  We're not lucky to have a flush
>toilet
>>>>>> > anymore. This stuff is too important to rely on luck.
>>>>>> >
>>>>>> > Bob
>>>>>> > On Oct 11, 2023, at 3:58 PM, David Lang <david at lang.hm> wrote:
>>>>>> >
>>>>>> >> On Wed, 11 Oct 2023, rjmcmahon wrote:
>>>>>> >>
>>>>>> >>> I don't know the numbers but a guess is that a majority of
>SoCs
>>>>>> >>> with WiFi
>>>>>> >>> radios aren't based on openwrt.
>>>>>> >>
>>>>>> >> From what I've seen, the majority of APs out there are based
>on
>>>>>> >> OpenWRT or one
>>>>>> >> of the competing open projects, very few roll their own OS
>from
>>>>>> >> scratch
>>>>>> >>
>>>>>> >>> I think many on this list use openwrt but
>>>>>> >>> that may not be representative of the actuals. Also, the
>trend is
>>>>>> >>> less sw in
>>>>>> >>> a CPU forwarding plane and more hw, one day, linux at the
>CPEs 
>>>>>>
>mayhttps://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
>>>>>> >>> not be
>>>>>> >>> needed at all (if we get to remote radio heads - though this
>is
>>>>>> >>> highly
>>>>>> >>> speculative.)Peregrine - 112G PAM4
>>>>>> >>
>>>>>> >> that is countered by the trend to do more (fancier GUI, media
>>>>>> >> center, etc) The
>>>>>> >> vendors all want to differentiate themselves, that's hard to
>do if
>>>>>> >> it's baked
>>>>>> >> into the chips
>>>>>> >>
>>>>>> >>> From my experience, sw is defined by the number & frequency
>of
>>>>>> >>> commits, and
>>>>>> >>> of timeliness to issues more than a version number or compile
>>>>>> >>> date. So the
>>>>>> >>> size and quality of the software staff can be informative.
>>>>>> >>>
>>>>>> >>> I'm more interested in mfg node process then the mfg location
>&
>>>>>> >>> date as the
>>>>>> >>> node process gives an idea if the design is keeping up or
>not.
>>>>>> >>> Chips designed
>>>>>> >>> in 2012 are woefully behind and consume too much energy and
>>>>>> >>> generate too much
>>>>>> >>> heat. I think Intel provides this information on all its
>chips as
>>>>>> >>> an example.
>>>>>> >>
>>>>>> >> I'm far less concerned about the chips than the software.
>Security
>>>>>> >> holes are far
>>>>>> >> more likely in the software than the chips. The chips may
>limit the
>>>>>> >> max
>>>>>> >> performance of the devices, but the focus of this is on the
>>>>>> >> security, not the
>>>>>> >> throughput or the power efficiency (I don't mind that extra
>info,
>>>>>> >> but what makes
>>>>>> >> some device unsafe to use isn't the age of the chips, but the
>age of
>>>>>> >> the
>>>>>> >> software)
>>>>>> >>
>>>>>> >> David Lang
>>>>>> >>
>>>>>> >> Bob
>>>>>> >> On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
>>>>>> >>
>>>>>> >> There's also the concern about how do startups roll-out such a
>>>>>> >> label for
>>>>>> >> their tech in the early iteration phase? How do they afford to
>do
>>>>>> >> the
>>>>>> >> extra
>>>>>> >> work for the label vs. a big company (does this become a
>regulatory
>>>>>> >> moat?)
>>>>>> >>
>>>>>> >> And let's say we have these labels. Will only consumers with
>the
>>>>>> >> money to
>>>>>> >> purchase the more expensive equipment that has more privacy
>and
>>>>>> >> security
>>>>>> >> features buy that one - leaving those who cannot afford
>privacy and
>>>>>> >> security bad alternatives?
>>>>>> >>
>>>>>> >> As far as security goes, I would argue that the easy answer is
>to
>>>>>> >> ship
>>>>>> >> a current version of openwrt instead of a forked, ancient
>version,
>>>>>> >> and
>>>>>> >> get their changes submitted upstream (or at least maintained
>against
>>>>>> >> upstream). It's a different paradigm than they are used to,
>and
>>>>>> >> right
>>>>>> >> now the suppliers tend to also work with ancient versions of
>>>>>> >> openwrt,
>>>>>> >> but in all the companies that I have worked at, it's proven to
>be
>>>>>> >> less
>>>>>> >> ongoing work (and far less risk) to keep up with current
>versions
>>>>>> >> than
>>>>>> >> it is to stick with old versions and then do periodic 'big
>jump'
>>>>>> >> upgrades.
>>>>>> >>
>>>>>> >> it's like car maintinance, it seems easier to ignore your
>tires,
>>>>>> >> brakes, and oil changes, but the minimal cost of maintaining
>those
>>>>>> >> systems pays off in a big way over time
>>>>>> >>
>>>>>> >> David Lang
>>>>>> >>
>>>>>> >> -------------------------
>>>>>> >>
>>>>>> >> Nnagain mailing list
>>>>>> >> Nnagain at lists.bufferbloat.net
>>>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> >>
>>>>>> >> -------------------------
>>>>>> >>
>>>>>> >> Nnagain mailing list
>>>>>> >> Nnagain at lists.bufferbloat.net
>>>>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> > _______________________________________________
>>>>>> > Nnagain mailing list
>>>>>> > Nnagain at lists.bufferbloat.net
>>>>>> > https://lists.bufferbloat.net/listinfo/nnagain
>>>>>> _______________________________________________
>>>>>> Nnagain mailing list
>>>>>> Nnagain at lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain at lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> 
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/nnagain/attachments/20231013/328fee51/attachment-0001.html>

More information about the Nnagain mailing list