After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 682233 - nm-applet doesn't show wireless networks
nm-applet doesn't show wireless networks
Status: RESOLVED NOTABUG
Product: NetworkManager
Classification: Platform
Component: nm-applet
0.8.x
Other Linux
: Normal minor
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2012-08-20 08:53 UTC by ich.freak
Modified: 2016-11-24 11:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
this is what my nm-applet menu looks like, no wireless networks there... (9.12 KB, image/jpeg)
2012-08-20 08:53 UTC, ich.freak
Details

Description ich.freak 2012-08-20 08:53:41 UTC
Created attachment 221795 [details]
this is what my nm-applet menu looks like, no wireless networks there...

hey, since neither the IRC support nor the mailinglist could solve my problem, I'm opening this bugreport. I'll just paste the email I wrote to the mailinglist:

>>
>> So I gave networkmanager a shot and am kinda stuck with my wireless. I
>> can't get nm-applet to display the networks in range, even when started
>> as root. Maybe I misunderstood the usage of nm-applet but I though it
>> would display the available wireless networks on right clicking. I'll
>> attach a jpg with what right-clicking the nm-applet produces.
>>
>> Currently, I have version 0.8.4 of both networkmanager and nm-applet
>> installed. Oh and, in case this is any good: my wired interface works
>> with nm (meaning that nm connects if I plug in ethernet (with dhcp))
> Only the NM daemon needs to be run as root, to get access to kernel wifi
> APIs.  nm-applet should be run as whatever user you're logged in as, and
> communicates with the main NM daemon via the D-Bus IPC protocol.
I am aware of that, however, I in the spirit of debugging my wifi
problem, I wanted to not mix permission problems with nm/wifi problems.
Hence, I started the applet as root thinking that polkit/dbus/ck would
allow anything issued from a program called as root.

> If you're having problems with wifi, a few questions to narrow it down:
>
> 1) does the applet show your wifi device at all, but no networks?  or
> does it not even show your wifi?  If the wifi device isn't shown at all,
> the contents of /var/log/messages, /var/log/daemon.log,
> or /var/log/NetworkManager.log (depending on your distro) are helpful to
> figure out what's going on.
I don't quite understand where it should show my wifi device - The only
place where it does show up is in the "Network Connections" dialog,
under "wireless" called "System (wlan0)".

I do not have a "/var/log/NetworkManager.log", does nm use the syslog
facilities? Then it should show up in /var/log/messages (my syslog-ng is
configured to dump everything there); However, a
# grep wlan0 /var/log/messages
revealed
Aug 13 10:39:44 localhost NetworkManager[3797]:    SCPlugin-Ifnet: wireless_setting added for wlan0
Aug 13 10:39:44 localhost NetworkManager[3797]:    SCPlugin-Ifnet: Using dhcp method for wlan0
Aug 13 10:39:44 localhost NetworkManager[3797]:    SCPlugin-Ifnet: Connection verified wlan0:1
Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): driver supports SSID scans (scan_capa 0x01).
Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): new 802.11 WiFi device (driver: 'ath9k' ifindex: 4)
Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): exported as /org/freedesktop/NetworkManager/Devices/0
Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): now managed
Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): device state change: 1 -> 2 (reason 2)
Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): preparing device.
Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): deactivating device (reason: 2).
Aug 13 10:39:44 localhost dhcpcd[2837]: wlan0: removing interface
Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): supplicant manager state:  down -> idle
Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): device state change: 2 -> 3 (reason 0)
Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): supplicant interface state:  starting -> ready

So I take it nm is aware of my wifi device!


> 2) what distro?  If you're using Debian or Ubuntu, what's in
> your /etc/network/interfaces file?  NM is sometimes told to ignore
> interfaces that are listed in there, to ensure that when it's installed
> it doesn't unexpectedly change your network config.
My system runs gentoo linux x64, kernel is
# uname -a
Linux <hostname> 3.4.4-gentoo #5 SMP PREEMPT Thu Jul 12 14:59:41 CEST
2012 x86_64 Intel(R) Core(TM)2 Duo CPU T5900 @ 2.20GHz GenuineIntel
GNU/Linux

But I seriously doubt that the gentoo guys would default-configure nm to
ignore some device without telling me in the ebuild. Also, nm wouldn't
fiddle with wlan0 the way it does (see /var/log/messages above) if it
was told to ignore it, right?

> 3) what kernel version and wifi hardware do you have?  Many drivers that
> are not stable upstream kernel wifi drivers (ie, anything direct from a
> vendor or in the 'staging' kernel drivers) often don't conform to the
> standard kernel APIs, and often have small bugs that prevent them from
> working smoothly; they simply don't get as much attention as the
> standard drivers.  Sometimes a simple fix makes them work, or switching
> to a standard kernel driver makes things better.
kernel version is 3.4.4 with some gentoo patches, nothing serious
concerning wifi I guess. As seen in the above /var/log/messages snip my
wireless driver is ath9k which works just fine in say wicd (and no, I
did not run both wicd and nm deamons at the same time when conducting
experiments).
Comment 1 André Klapper 2012-08-20 09:52:20 UTC
(In reply to comment #0)
> Aug 13 10:39:44 localhost NetworkManager[3797]: <info> (wlan0): new 802.11 WiFi
> device (driver: 'ath9k' ifindex: 4)

My wild guess is that you run into the same problem as https://bugzilla.redhat.com/show_bug.cgi?id=794710 .

As a start, please provide output of the following commands:

lspci -nnvv | grep Network
dmesg | grep wlan0
dmesg | grep ath
nmcli dev wifi
more /var/log/wpa_supplicant.log
modinfo ath9k
rfkill list
Comment 2 ich.freak 2012-08-20 11:32:28 UTC
Gladly!

# lspci -nnvv | grep Network
03:00.0 Network controller [0280]: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) [168c:002a] (rev 01)

# dmesg | grep wlan0
[   11.919399] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   27.077020] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   34.112953] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[11328.697869] ADDRCONF(NETDEV_UP): wlan0: link is not ready

# dmesg | grep ath
[    3.065264] ath: EEPROM regdomain: 0x60
[    3.065270] ath: EEPROM indicates we should expect a direct regpair map
[    3.065276] ath: Country alpha2 being used: 00
[    3.065279] ath: Regpair used: 0x60
[    3.067220] ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control'
[    3.067915] Registered led device: ath9k-phy0

# nmcli dev wifi (please note that I tried to anonymize the output, rest assured that the actual SSIDs are shown there)
SSID                              BSSID               MODE             FREQ       RATE       SIGNAL   SECURITY   ACTIVE  
<anonymized>                       64:AE:0C:BF:BF:B2   Infrastructure   2462 MHz   54 MB/s    48       --         no      
<anonymized>                       64:AE:0C:BF:AA:52   Infrastructure   2437 MHz   54 MB/s    58       --         no      
<anonymized>                       00:1E:58:3A:8D:85   Infrastructure   2457 MHz   54 MB/s    28       WPA2       no      
<anonymized>                       C0:C5:20:23:6E:08   Infrastructure   2417 MHz   54 MB/s    44       --         no      
<anonymized>                       00:24:A8:BE:2A:D1   Infrastructure   2437 MHz   54 MB/s    65       --         no      
<anonymized>                       C0:C5:20:29:F7:C8   Infrastructure   2427 MHz   54 MB/s    91       --         no      
<anonymized>                       64:AE:0C:BF:BF:B1   Infrastructure   2462 MHz   54 MB/s    54       WPA WPA2 Enterprise no      
<anonymized>                       64:AE:0C:BF:AA:51   Infrastructure   2437 MHz   54 MB/s    58       WPA WPA2 Enterprise no      
<anonymized>                       00:24:A8:BE:2A:D0   Infrastructure   2437 MHz   54 MB/s    67       WPA2 Enterprise no      

# more /var/log/wpa_supplicant.log
/var/log/wpa_supplicant.log: No such file or directory
(as it turns out, I do not have a wpa_supplicant.log anywhere)

# modinfo ath9k 
filename:       /lib/modules/3.4.4-gentoo/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko
license:        Dual BSD/GPL
description:    Support for Atheros 802.11n wireless LAN cards.
author:         Atheros Communications
alias:          pci:v0000168Cd00000034sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000033sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000032sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000030sv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Esv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Dsv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Csv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Bsv*sd*bc*sc*i*
alias:          pci:v0000168Cd0000002Asv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000029sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000027sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000024sv*sd*bc*sc*i*
alias:          pci:v0000168Cd00000023sv*sd*bc*sc*i*
depends:        ath9k_hw,ath9k_common
intree:         Y
vermagic:       3.4.4-gentoo SMP preempt mod_unload 
parm:           debug:Debugging mask (uint)
parm:           nohwcrypt:Disable hardware encryption (int)
parm:           blink:Enable LED blink on activity (int)
parm:           btcoex_enable:Enable wifi-BT coexistence (int)


# rfkill list
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no


thanks for considering this!


Regarding the bug you linked in the redhat bugzilla, I don't think it has anything to do with what I am experiencing, since I lack the "restoring config space at offset" messages and my rf is not killed.

greets
-igel
Comment 3 André Klapper 2012-08-20 11:49:35 UTC
(In reply to comment #2)
> # rfkill list
> 0: phy0: Wireless LAN
>     Soft blocked: no
>     Hard blocked: no

If that's the only device then I wonder where your wired ethernet hides... :)
Comment 4 ich.freak 2012-08-20 13:12:49 UTC
oO
your wired ethernet has an rfkill switch? Awesome!

In other news:
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:26:18:05:f0:b4  
          inet addr:130.149.208.195  Bcast:130.149.208.255  Mask:255.255.255.192
          inet6 addr: fe80::226:18ff:fe05:f0b4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:27200 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17168 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:16356764 (15.5 MiB)  TX bytes:2247206 (2.1 MiB)
Comment 5 Jiri Klimes 2012-09-04 07:24:29 UTC
When 'nmcli dev wifi' shows the Wi-Fi networks, it means that NM is working properly and also NM clients have no problem to get the data. So nm-applet should work as well.

Do you get the same output when you run 'nmcli dev wifi' as a normal user? (Actually, you should always run nmcli as well as nm-applet as a ordinary user and not root)

Click nm-applet icon with *left* mouse button and ther should be a list of available Wi-Fi networks' SSIDs.

Do you see any errors from nm-applet in ~/.xsession-errors?
Comment 6 ich.freak 2012-09-04 08:58:56 UTC
there was no reaction to left-clicking whatsoever for nm-applet.

However, yesterday, I entered the credentials to one of the wireless
networks under the "Edit Connection -> Wireless" right-click menu as
"Wireless connection 1" and now, I cannot reproduce the problem any
more, so I consider the issue resolved, although I have no clue what
actually caused this in the first place.
Comment 7 dmnc 2016-11-04 08:44:04 UTC
This problem still remains in nm-applet v. 1.4.2 (distro Archlinux) - not showing WL networks, but it's connected to one of them and nmcli and nmtui is working well (both are showing networks). I'm not sure if I have to fire a new bug or what to do ...

Probably it has something to do with sleep/wake cycles of my laptop because sometimes it works, sometimes not. Now I've tried to kill nm-applet and re-run, then suspend and wake my laptop and it is still working so I can't reproduce it for 100%.
Comment 8 dmnc 2016-11-04 08:48:53 UTC
.xsession-errors: http://pastebin.com/e889QKFA
... grep nm-applet: http://pastebin.com/HSxVfW2U
Comment 9 Jiri Klimes 2016-11-24 11:08:46 UTC
(In reply to dmnc from comment #8)
> .xsession-errors: http://pastebin.com/e889QKFA
> ... grep nm-applet: http://pastebin.com/HSxVfW2U

Well, the log contains the error "nm-applet-CRITICAL **: get_menu_item_for_ap: assertion 'dup_data.hash != NULL' failed". For further progress, please follow bug 774268 or bug 767317.