From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 0DFA53CB39 for ; Fri, 13 Oct 2023 02:36:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1697178959; x=1697783759; i=moeller0@gmx.de; bh=/7zp4KXRkVmWpHUeG/qPp8w8o3Pifbe4okVF9+45pDE=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=WyqAcMcpmE6ecPqyPJFYoeEX2jsnlDyiFxgoDWfyeDjQ6IbrdQIdOkh2Cti2yaz+lldaM0UVO8d SJlOkdv5W4JbEIWDk+tSlG7aIGrT5Mk4CHDauy3Tv1RfazHkBPJ2sWTA1LIj+j11kRNMFb6jICkOj QSsTc30atgkQp5Pmtjia13oy67objz6BXJAw0YlMUGhqbOL4XlSe1DoQ/PyMEwUqmi1xcm+g3ciGg KI+cs8gzNYjLncZT7XWNnZOselVvGn7kz8b3y/O7thVwcrMCCS3tBst4HXQO6FTIzKsneuZB5ZNhX 2r0LQheowZTaeOgrMepKTMavaJYUD/ysyi4w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MFsZ3-1qmVDk0Jax-00HMEo; Fri, 13 Oct 2023 08:35:59 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\)) From: Sebastian Moeller In-Reply-To: <6a03ab3b-8e1c-4727-9fd9-07a38db4fb73@rjmcmahon.com> Date: Fri, 13 Oct 2023 08:35:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2084BE53-6EAD-4480-B265-374C6A0F4874@gmx.de> References: <9f79b6f4b45c45c6d2fd2a43783f0157@rjmcmahon.com> <6a03ab3b-8e1c-4727-9fd9-07a38db4fb73@rjmcmahon.com> To: =?utf-8?Q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_as?= =?utf-8?Q?pects_heard_this_time!?= X-Mailer: Apple Mail (2.3696.120.41.1.4) X-Provags-ID: V03:K1:STQfbbkt2StYJJI8H0fncJ0mQdIZxod3Uj44PW86iHuC6uFk3/Q or7Nk1odAo2+/nVfQUYNN7X1poE7A4rZd37qx1q0ZUuMg594A9ALm6aNHKiF++aWQScLGpn CMhFxTSaFlemEz6mNOJQuwNsOixg9kHYUjZxZFdE+497ANP2NzaOgmebQjWvWufmvvIFaxj 70577sqEI5b2epWBLAXRg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:IppEYbkfe8E=;2rt6B8AgIxBid84hfhCivgElYj7 GHUPOkgyRDTLJ8TCy8cr5oKvd/z2jSaDwx3Wa+SzAmvNtiBIrwV6eLAgJHXr7dMJWCvIME9mg MdGtoowwihQIAxMUz/Ekbd7QhWOd63HqjctXxt0uHU+UZ65c6qEAA/DiDEyvU1LLoTuLfUV9x i+mvSO1bgYkzOtt/pvLZoywPtQW1Vhe8ol+urd4/Ibyt2frAmkSM27V4EbAK5Na6a3gJ43oyj amHf0aNcznU4SPLyWy7SwnBCtC4L0y9eOKb+6ur5blbG6FsMz2RgAjjhAQlB01kz+9RLqDgnh AQOmojy78TOmuozR3bEnRTXPEDxTeqmeJhDnLu0gRXsJ3eaiIkrTETeyDHLacrXVnBkx9FwLC yNPiigMynGTs46ad0oVnJrd4Thtmv7Os4js3jXQ61+KJBilarGTKN9BUICqalv4ebbemeYuJw u2C0y47TFAxHp9v+hryDPtI7zKKNlMo30lfrTWzJrX+qIbswIcP9JBQyIHDN7kV30I2MBMctz UodtrA5E2DqBCvr0A3V0I7JbOdx16r+i51q5DAXhZrQqrh1nDkcD0EAaYimnZA20RhsZsBh+y s8+jzt/Rl1QaVxzWeQulJjvscDOtXcwmI5IRy/Fq+A9T4Q9U4XIN0xLA4UMXZ5IN4wYt7b3mx J829hwzn8h4mzLl63+FHc5RpvIavNodcLPPnG2hqetMaReU0utVM870aDPKrxE7zLx3OCPRw/ fcG6DRJylNBy3ogVcCYn1ACfCOAjAfHtQv+ZSr8i7cgTbZNBvax8vJDisRwwTH1KhdjZIORM8 /dfXftMFUCBYkTCtcM4b6B6vlxJPYdqWGM5bT+LjwIUEO2riR40pTepjCOtSvX5BKrj4la8hL 9w5OckC7vVjV34TXod7BqNub22yvlXRwWrCKOeDtozogHfYOPrU4azc4bca7csBFoxfyZwLJ8 kbBntYQBhPPCXelLjbf52E98uos= Subject: Re: [NNagain] Internet Education for Non-technorati? X-BeenThere: nnagain@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: =?utf-8?q?Network_Neutrality_is_back!_Let=C2=B4s_make_the_technical_aspects_heard_this_time!?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2023 06:36:08 -0000 Hi Bob, > On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain = wrote: >=20 > Hi David,=20 >=20 > 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.=20 >=20 > 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. [SM] That is both true, and (currently?) unachievable. To run a = network connected to the internet securely requires to make a number of = policy decisions trading-off the required/desired connectivity versus = the cost in security (either cost as effort of maintaining security or = cost in an increase in attack surface). The in-side the home situation, has IMHO drastically improved = with the availability of off-the-shelf mesh network gear from commercial = vendors, with easy to follow instructions and/or apps to find decent AP = placement. For structured wiring, I would agree that requires both an = unusual skill set (even though doing structured wiring itself is not = hard, just doing it in a way that blends into an apartment without = signaling DIY-ness is more involved). > 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. >=20 > 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.=20 [SM] What "online tech support"? =46rom the AP vendor or from = the ISP? The latter might have a script recommending ISP technicians = more for commercial considerations than technical ones... > 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." >=20 > 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. [SM] Mmmh, that got me thinking, maybe we should think about = always running network wiring parallel to electric cables so each power = socket could easily house an ethernet plug as well... (or one per room = to keep the cost lower and avoid overly much "dark" copper)? Sort of put = this into the building codes/best current practice documents... (I = understand starting now, will still only solve the issue over many = decades, but at least we would be making some inroads; and speaking of = decades, maybe putting fiber there instead of copper might be a more = future-oriented approach)? >=20 > Bob > On Oct 11, 2023, at 3:58 PM, David Lang wrote: > On Wed, 11 Oct 2023, rjmcmahon wrote: >=20 > I don't know the numbers but a guess is that a majority of SoCs with = WiFi=20 > radios aren't based on openwrt. >=20 > =46rom what I've seen, the majority of APs out there are based on = OpenWRT or one=20 > of the competing open projects, very few roll their own OS from = scratch >=20 > I think many on this list use openwrt but=20 > that may not be representative of the actuals. Also, the trend is = less sw in=20 > a CPU forwarding plane and more hw, one day, linux at the CPEs may = not be=20 > needed at all (if we get to remote radio heads - though this is = highly=20 > speculative.) >=20 > that is countered by the trend to do more (fancier GUI, media center, = etc) The=20 > vendors all want to differentiate themselves, that's hard to do if = it's baked=20 > into the chips >=20 > =46rom my experience, sw is defined by the number & frequency of = commits, and=20 > of timeliness to issues more than a version number or compile date. = So the=20 > size and quality of the software staff can be informative. >=20 > I'm more interested in mfg node process then the mfg location & date = as the=20 > node process gives an idea if the design is keeping up or not. Chips = designed=20 > in 2012 are woefully behind and consume too much energy and generate = too much=20 > heat. I think Intel provides this information on all its chips as an = example. >=20 > I'm far less concerned about the chips than the software. Security = holes are far=20 > more likely in the software than the chips. The chips may limit the = max=20 > performance of the devices, but the focus of this is on the security, = not the=20 > throughput or the power efficiency (I don't mind that extra info, but = what makes=20 > some device unsafe to use isn't the age of the chips, but the age of = the=20 > software) >=20 > David Lang >=20 > Bob > On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote: > =20 > 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=20= > extra > work for the label vs. a big company (does this become a regulatory = moat?) > =20 > 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? > =20 > 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. > =20 > 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 > =20 > David Lang >=20 > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain > =20 >=20 > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain >=20 > _______________________________________________ > Nnagain mailing list > Nnagain@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/nnagain