[sf-lug] Wi-Fi woes

James Stockford jim at well.com
Wed Jan 9 12:20:30 PST 2019



$ cat /etc/issue
Ubuntu 18.04.1 LTS \n \l

$ uname -a
Linux UltraLap-6440 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/os-release | grep VERSION=
VERSION="18.04.1 LTS (Bionic Beaver)"

My reference to "gizmo", aka "doohickey" was
to an external device, not to an internal wifi
adapter that requires correct firmware and
modules and libraries (I suppose).


On 1/8/19 10:07 PM, Rick Moen wrote:
> 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.
>
> JS Seems non-destructive to run /etc/init.d/* restart
> Good to know if that's wrong.
>> 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.
>
>
> _______________________________________________
> 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