[sf-lug] Wi-Fi woes

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> >## Did you mean
> ># /etc/init.d/networking restart
> >## or
> ># /etc/init.d/network-manager restart
> 
> Ew, yuck, network-manager.

Fortunately, not actually relevant to Jim's problem.

Some shell extension on his Ubuntu box attempted to suggest possible
intended commands that were vaguely like the erroneous one Maestro
suggested.  But, point is, Jim should not type _any_ shell commands, let
alone ones with root authority, unless he understands them, what they
do, and why he's running them.

> Sometimes for troubleshooting, it may be more convenient, to at least
> temporarily disable Network Manager - your results may vary (typically
> by default, network manager tries to automagically do a lot of stuff,
> often changing dynamically ... that can get in the way of figuring out
> what the hell is actually going on....

Word!

Incidentally, the fact that NetworkManager provides nmcli unfortunately
doesn't prevent it from being a horrifically overengineered piece o'crud
that is more likely to hopelessly confuse diagnosis than anything else.  
I would stay far away.

> 
> >>>My Ubuntu 18.04 laptop was successfully
> 
> Are you *sure* it's Ubuntu 18.04?

Oh, he's probably being a bit imprecise, but, seriously, the specific
point release is irrelevant to his problem.  (Jim, if you want to know
for certain, look at /etc/os-release .)

> What command did you run that tells you it's Ubuntu 18.04?
> And what was the output of that command?

This'll do it:

  $ cat /etc/os-release | grep VERSION=

> What about the architecture (might be moot ... or maybe not, depending
> upon the "spin"/"flavor", or whatever *buntu call it of *buntu)?

_Seriously_ doesn't matter.  But yes, Jim really ought to learn to
_show_, not just tell -- if he expects help.

> So, yes, make and model would be useful.
> Also, Linux and the related Wi-Fi bits don't care much about who's
> label/branding is slapped on the thing, but they do quite care about
> the chipsets, so while make/model can be useful,
> they chipset(s) seen is often both more informative and definitive.

After many years of asking people what chipset the question concerns,
and getting back either no information or _wrong_ information, I stopped
asking, and fell back on make + model, which fairly reliably permits
determining the chipset.

> And if the Wi-Fi hardware is in fact confirmed dead,
> what exactly are you trying establish Wi-Fi connectivity through? ...
[...]
> Hmmmm, looks like you ended up with a wlp59s0 Wi-Fi device under Linux,
> is it Hard and Soft unblocked?

I'm pretty sure that's just a weird-ass network device name, i.e., his 
Intel model Wireless AC 9260 card (that requires driver iwlwifi) has been
assigned network device name wlp59s0 rather than something sane like
wlan0 or eth1.

FWIW, I'm guesstimating that this in Jim's lspci output is the wireless
device:

> >>>root at UltraLap-6440:~# lspci
[...]
> >>>3b:00.0 Network controller: Intel Corporation Device 2526 (rev 29)
[...]

That (with PCI ID 8086:2526) appears to be an Intel Wireless-AC 9260
(802.11AC + Bluetooth) device.
https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/dual-band-wireless-ac-9260-brief.pdf

If I'm wrong, and, e.g., Jim's is a USB device, 'lsusb' would be
enlightening -- or whatever tool is appropriate to the non-PCI bus if
such is the case.  But I'm pretty sure the above is correct.