[sf-lug] Wi-Fi woes

James Stockford jim at well.com
Wed Jan 9 12:27:04 PST 2019


I've discovered another post-disaster symptom
that may relate:

I use Thunderbird to get my email from
The Well's email server, iris.well.com

Now I click to reply to an email, write
my comment, then click the Send button.
The system responds with a message that
iris.well.com is unknown.
I click the Send button a second time
and the system sends the message.

Looks to me that something is funky with
respect to dns resolution.

Using wired access:
$ ping iris.well.com
PING zimbra.well.com (52.7.49.239) 56(84) bytes of data.
64 bytes from ec2-52-7-49-239.compute-1.amazonaws.com (52.7.49.239): 
icmp_seq=1 ttl=39 time=78.0 ms





On 1/9/19 12:10 PM, James Stockford wrote:
>
> 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>
>>
>
>
> _______________________________________________
> 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>




More information about the sf-lug mailing list