[sf-lug] Wi-Fi woes

[James Stockford]

I wish I knew enough to avoid NetworkManager.
I'm comfortable using CLI, even comfortable
looking at /bin and /sbin and such. But the
richness leaves me cautious; many commands,
many options, and necessary sequence
requirements.


On 1/8/19 9:19 PM, Michael Paoli wrote:
>> 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.
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/<br>
> Related Information <br>
> http://www.shallowsky.com/blog/<br>
> http://explainshell.com/ <br>
>