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