[sf-lug] (forw) Re: (forw) Trouble ticket # CR109553011 diagnostic data

Rick Moen rick at linuxmafia.com
Sun Sep 24 16:56:48 PDT 2023


Quoting Ronald Barnes (ron at ronaldbarnes.ca):

> First, kudos to Shawna in Denver.

Quite.

> Glad things have worked out.

I'll gladly take the victory.  But here's the disquieting bit:


Date: Sun, 24 Sep 2023 16:53:48 -0700
>From rick at linuxmafia.com Sun Sep 24 16: 3:48 2023
From: Rick Moen <rick at linuxmafia.com>
To: Al <aw009 at sunnyside.com>
Cc: Michael Paoli <Michael.Paoli at cal.berkeley.edu>
Subject: Re: When it (that Comcast gateway device) broke
Organization: If you lived here, you'd be $HOME already.

Quoting Al Whaley (aw009 at sunnyside.com):

> Yeah, well maybe it isn't firmware updates.

That possibility troubles me, too.

It might have _not_ been a firmware upgrade at all, but rather
just frobbing a toggle in Comcast's customer records database
marked "SecurityEdge enabled".  It may be that _all_ of the
Comcast-captive Technicolor devices have built-in logic to hijack DNS if
so instructed by Corporate.

See, one of the reasons I was fanatically devoted to Mike Durkin's Raw
Bandwidth Communications was that _none of this bullshit_ existed.
Mike sent me a dirt-simple Westell ADSLv1 terminal adapter, with
several blinkenlights, the most important of which showed sync to
Mike's DSLAM in the telco central office.  There was nothing to
configure.  There were no "firmware upgrades".  There was no invisible
firmware functionality.  It had one job.  It did that job.

Everything inbound from the ethernet side of that terminal adapter was
provided by me, and my responsibility.  And, IMO, that's the way it
should be.

"Maybe my ISP transparently rolled out some DNS fuckery" shouldn't even
need to be in the diagnostic tree.



More information about the sf-lug mailing list