[sf-lug] Wi-Fi woes

maestro maestro415 at gmail.com
Wed Jan 9 10:37:28 PST 2019


michael p.;
a very enjoyable read indeed... ^^^


message ends
__________________


/'m'/


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Jan 8, 2019 at 9:24 PM Michael Paoli <Michael.Paoli at cal.berkeley.edu>
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>
>


-- 

*~the quieter you become, the more you are able to hear...*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20190109/927bed91/attachment-0001.html>


More information about the sf-lug mailing list