[sf-lug] Wi-Fi woes

[Michael Paoli]

> From: "James Stockford" <jim at well.com>
> Subject: Re: [sf-lug] thanks for the help
> Date: Tue, 8 Jan 2019 19:04:25 -0800

> # /etc/init.d/network/restart
> -su: /etc/init.d/network/restart: No such file or directory

As I suspected.  Jim caught and corrected 1 of the original typo
issues, tried it literally, but then soon determined that there was
no "there there", as the originally presumptive also failed to match
the target anyway, and hence no corresponding
/etc/init.d/network at all.

> There are two shell scripts within /etc/init.d/ ;
> they are networking and network-manager.
>
> ## Did you mean
> # /etc/init.d/networking restart
> ## or
> # /etc/init.d/network-manager restart

Ew, yuck, network-manager.  Well, if you only deal with relatively simple
networks and want an Ewey-GUI networky thingy that many distros install
by default, ... then network-manager is your answer ... for certain
definitions of "answer".  On the other slight very possible plus side,
it does also have a CLI interface ... a horrible non-standard
abomination of an interface, but nevertheless probably pretty functional
and reasonably well documented (Debian has nmcli(1), does your distro not?).
(you can also leave the sucker installed, but not enabled - which is what
I do most of the time ... if/when I ever come up with reasonable reason
to mess around with network-manager- it's already all installed for me).

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, as the playing field tends to often
be regularly changing (I'm presuming you didn't work in some highly isolated
radio signals environment, where all but the desired Wi-Fi client, and access
point, all their radio signals blocked well below the levels that any  
commodity
Wi-Fi equipment would be able to use at all - and hopefully not even detect).

There are other commands that might be useful - after the system reasonably
sees the hardware and Wi-Fi device.  In the meantime I think we're awaiting
your updated reporting results.

< message continues ... maybe 'till I feel like ending it or cutting off
< or trimming content of (marginal?/insufficient?) relevance

>> On Tue, Jan 8, 2019 at 11:13 AM James Stockford <jim at well.com> wrote:
>>
>>> both Sunday, from Ken, Bobby, and John,
>>> and, hopefully, in subsequent emails.
>>>
>>> My Ubuntu 18.04 laptop was successfully

Are you *sure* it's Ubuntu 18.04?
Ubuntu 18.04 is soon approaching a year old.
Are you not to ... well, I'm too annoyed to click through
Canonical's begware please give money to your favorite company
Canonical screens ... oh, I don't know, like 18.04.1 (or .2 or .3 or .4)
by now?
What command did you run that tells you it's Ubuntu 18.04?
And what was the output of that command?
What about the architecture (might be moot ... or maybe not, depending
upon the "spin"/"flavor", or whatever *buntu call it of *buntu)?
Again, what command did you use and what did it show you?
Some of these might be useful:
$ lsb_release -d
$ uname -m
$ more /etc/*rel* /etc/*ver* 2>>/dev/null | cat

And peeking a bit, even if you are, in fact, running Ubuntu 18.04,
rather than 18.04.1, not too horrible, it's at least still supported
thus far:
https://wiki.ubuntu.com/Releases
But if you want to stay with the LTS track,
you'd probably want to upgrade to 18.04.1 (security, bug fixes)

What model of gizmo?
Hmmm, gizmo, don't know that make,
if that's the actual manufacturer's make labeling on it,
I think we'd all be curious to see it.
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.

>>> using wifi until my wifi gizmo died, maybe
>>> with a last electronic shriek. I've got
Really?  What manner of death?  Wi-Fi hardware is generally quite
quiet - generally silent, so a "shreik" sounds comparatively unprecedented.
Was that before or after the funeral pyre, and did the attending confirm
death before that, and were the proper hazardous materials and burn
permits obtained in advance?

And if the Wi-Fi hardware is in fact confirmed dead,
what exactly are you trying establish Wi-Fi connectivity through? ...
Specifically between the (presumed) Ubuntu 18.04 host and the
Access Point (AP)?

Have you taken a look at rfkill(8)?
$ rfkill list wifi
0: dell-wifi: Wireless LAN
         Soft blocked: no
         Hard blocked: yes
2: phy0: Wireless LAN
         Soft blocked: no
         Hard blocked: yes
$
Sometimes turning it on helps, see the difference?:
$ rfkill list wifi
0: dell-wifi: Wireless LAN
         Soft blocked: no
         Hard blocked: no
2: phy0: Wireless LAN
         Soft blocked: no
         Hard blocked: no
$
If you get it Hard (typically hardware switch) and Soft(ware)
unblocked (blocked: no), you might be able to do something with it,
and notably also rfkill might tell you quite concisely if it's recognizing
any type of Wi-Fi hardware.

>>> wired networking up, but not wifi. So far
>>> I've encountered only the unhelpful tips
>>> via the internet.
>>>
>>> I do not know what commands will yield
>>> information helpful to any of you. If you
>>> can, please let me know what commands
>>> to type and I'll paste in the results.
>>>
>>> When I use the settings feature for wifi,
>>> the system returns "No Wi-Fi Adapter Found
>>> Make sure you have a wifi adapter plugged and turned on"
>>>
>>>
>>> $ dmesg | grep iwl
>>> [    4.308557] iwlwifi 0000:3b:00.0: enabling device (0000 -> 0002)
>>> [    4.367856] iwlwifi 0000:3b:00.0: loaded firmware version 34.0.0
>>> op_mode iwlmvm
>>> [    4.450350] iwlwifi 0000:3b:00.0: Detected Intel(R) Dual Band
>>> Wireless AC 9260, REV=0x324
>>> [    4.502421] iwlwifi 0000:3b:00.0: base HW address: 0c:54:15:1b:e6:d5
>>> [    4.573033] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
>>> [    4.608201] iwlwifi 0000:3b:00.0 wlp59s0: renamed from wlan0
>>> $

Hmmmm, looks like you ended up with a wlp59s0 Wi-Fi device under Linux,
is it Hard and Soft unblocked?

>>> root at UltraLap-6440:~# lspci
>>> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core
>>> Processor Host Bridge/DRAM Registers (rev 08)
>>> 00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620
>>> (rev 07)
>>> 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
>>> Controller (rev 21)
>>> 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP
>>> Thermal subsystem (rev 21)
>>> 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP
>>> CSME HECI #1 (rev 21)
>>> 00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA
>>> Controller [AHCI mode] (rev 21)
>>> 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root
>>> Port (rev f1)
>>> 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root
>>> Port #5 (rev f1)
>>> 00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root
>>> Port #6 (rev f1)
>>> 00:1f.0 ISA bridge: Intel Corporation Device 9d4e (rev 21)
>>> 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
>>> 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
>>> 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
>>> 3a:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
>>> RTL8411B PCI Express Card Reader (rev 01)
>>> 3a:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd.
>>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12)
>>> 3b:00.0 Network controller: Intel Corporation Device 2526 (rev 29)

Don't presume the bus or bus type of the Wi-Fi.  Sure, PCI or the like is
common, but that's not the only place these things show up.

Caveat: viruses may cause snarkiness and other malfunctions, mostly a non-
         issue for Linux (at least reasonably cared for), the human(s),
         however ...

HAL: Well, I don't think there is any question about it. It can only be
      attributable to human error. This sort of thing has cropped up before,
      and it has always been due to human error.