Hi Bob,
> On Oct 13, 2023, at 19:20, rjmcmahon <rjmcma...@rjmcmahon.com> wrote:
>
> Hi Sebastian,
>
> It was the ISP tech support over the phone. Trying to help install a home
> network over the phone w/o a technician isn't easy.
[SM] Ah, okay. I would never even think about calling my ISP when
considering changes to my home network (for one, I would rather McGywer this,
and also my ISP does not really offer that as a servicedsdw), I guess different
service offerings in different countries.
> In many U.S. states, smoke detectors are required to be no more that 30'
> apart, must be AC powered, battery backed up and must communicate with one
> another. The smoke sensor needs to be replaced every ten years max.
[SM] Intersting! Over here detectors are also mandatory (but no
distance or networking requirements, it is special rooms like bed rooms that
need to have one). Also over here no AC requirement.
> It's a good place to install remote radio heads, or even full blown APs, for
> both internet access points and for life support sensors.
[SM] I agree, and with an AC requirement powering such APs/radio heads
is not rocket science either, heck in a first iteration one might even use PLC
to bring data to the APs...
> 10G NRE spends stopped over a decade ago. Early adopters aren't likely going
> to wire 10G over copper in their homes.
[SM] Over here active 2.5 Gbps ethernet are just becoming cheap enough
for enthusiasts to switch over to, and 2.5 has the advantage of operating well
even over most cat5 wiring (few homes I know will push anywhere close to the
typical 100m copper ethernet limit, most will be fine with < 30m).
> 100G only goes 4 meters so copper really isn't an option for future proof
> comm cable throughout buildings.
[SM] Indeed, but I am not 100% sure what use-case would justify going
100Gbps in a typical home? Sure if one switches to fiber wiring and 100Gbps is
only marginally more expensive than 1 or 10 Gbps why not?
> Fiber to WiFi seems straight forward to me.
[SM] This might be related to your professional background though? ;)
Just kidding, I think you are simply a few years ahead of the rest of us, as
you know what is in the pipeline.
> People don't want to be leashed to plugs so the last meters have to be
> wireless.
[SM] Yes and no. People did not bother about wiring office desks or
even smart TVs, but smart phones and tablets are a different kettle of fish, as
are laptops, that might be operated wired on the desk but wireless in the rest
of the house. I also note that more and more laptops come without built in
ethernet (personally I detest that, an rj45 jack is not that thick that a
laptop body can not be planned around that, leaving some more room for e.g.
NVMe sockets or simplify cooling a bit, ultra-thin is IMHO not really in the
end-users' interest, but I digress).
> We need to standardized to the extent that we can on one wireless tech
> (similar to Ethernet for wired) and a proposal is to use 802.11 since that's
> selling in volume, driven by mobile hand sets.
[SM] Sure 802.11 is likely to stay by virtue of being relatively
ubiquitous and by being generally already good enough for many use cases (with
road-maps for tackling more demanding use-cases, and I very much include your
fiwi proposal here).
>
> Bob
>> Hi Bob,
>>> On Oct 12, 2023, at 17:55, Robert McMahon via Nnagain
>>> <nnagain@lists.bufferbloat.net> wrote:
>>> 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.
>> [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.
>>> 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.
>> [SM] What "online tech support"? From 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."
>>> 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)?
>>> Bob
>>> On Oct 11, 2023, at 3:58 PM, David Lang <da...@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 may not be
>>> needed at all (if we get to remote radio heads - though this is highly
>>> speculative.)
>>> 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@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
_______________________________________________
Nnagain mailing list
Nnagain@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/nnagain
