Bug 1496

Created attachment 1215 [details]
screenshot showing the problem

I cannot replicate this issue in my initial testing.  Does tdenetworkmanager work properly if you use the Plastik widget style?

Created attachment 1304 [details]
with the plastik theme

I just tested with the latest nightlies and plastik. It doesn't work then either. I've attached another screenshot.

Still using Ubuntu 12.10.

OK, thanks!  That test helped to rule out any potential widget-related problems.

If you don't mind (i.e. there is no sensitive information displayed), can you post the output of "sudo iwlist wlan0 scan" when the TDE network manager is malfunctioning?  I am specifically looking for ESSID strings that might cause display problems, but the complete command output would be helpful.

Thanks!

Created attachment 1305 [details]
output of 'sudo iwlist wlan0 scan'

The list tends to vary a bit from time to time and I didn't really see anything suspicious, but here it is.

Thanks for the additional information.  I don't see anything immediately suspicious either.

If you run tdenetworkmanager from the command line, do you see any warning message printed to the console when accessing the wireless network list?

Also, what happens if you try to add a new wireless connection via the "New connection" menu option?  Do the wireless networks show up in the new connection dialog?   A screenshot of the first page of the new wireless connection dialog might be helpful as well.

Hopefully I can gather enough information to properly reproduce the problem and get this fixed for you soon...

Thanks!

Created attachment 1306 [details]
screenshot with the connections dialog

It seems it's indeed not something with the text labels. In the connection dialog also the signal strength cannot be displayed. Clicking on any of the items doesn't fill the text box below with anything either.

I forgot to add: Nothing relevant is printed when I start tdenetworkmanager through a Konsole and try to access the list.

(In reply to comment #8)
> I forgot to add: Nothing relevant is printed when I start tdenetworkmanager
> through a Konsole and try to access the list.

Interesting.  It almost looks like tdenetworkmanager cannot obtain the required information from network-manager over DBUS.  Let me look into this on a 12.10 VM and try to reproduce it there.

Out of curiosity (and so I can more precisely match your system), are you using 32 or 64 bit Ubuntu?

I'm using the AMD64 version.
Yes, it seems the only thing that comes across is the number of APs in the area. 

Btw. Gnome's Network Manager sees them all without problems (at the same time).

(In reply to comment #10)
> I'm using the AMD64 version.
> Yes, it seems the only thing that comes across is the number of APs in the
> area. 
> 
> Btw. Gnome's Network Manager sees them all without problems (at the same time).

Interesting.  I installed Ubuntu Quantal 64-bit and can see my wireless network just fine.  I will try setting up a test network with some of the SSIDs you posted earlier to rule out an SSID problem.

network-manager-gnome is developed by the same people as network-manager, so I would expect it to work properly with any particular version of network-manager.  Thus, it is useful for testing whether or not network-manager is broken, but not useful for verifying that network-manager is actually following its API documentation. ;-)

This should be at least partially resolved in GIT hash b6a20f0 (knetworkmanager9).  I am also in the process of fixing a few other network-manager related problems, including a failure to properly connect to an unsecured wireless network.

A second batch of fixes went into tdelibs in GIT hash b4eb5d6.

Can you please re-test with the latest nightly builds once both tdelibs and network-manager-tde have been rebuilt?

Thanks!

It seems that an update just came through. Unfortunately, with the current packages, the problem is still there. Everything still looks exactly like it does in the screenshots.

Sorry to hear that.  Changing status back to NEW for more analysis.

I have the same problem on Debian Wheezy 32 bit.
New previously unknown networks are not correctly displayed or communicated to the 'add new network' dialogues.
Adding a connection manually with the 'add connection' dialogues works correctly.

Unsure if this is relevant, probably not.
The behaviour of NetworkManager has changed in Wheezy in that known networks are recorded in the system file under /etc/NetworkManager/system-connections.
Known networks are automatically connected system wide when the 'profile' is tagged to autoconnect. A previous version (lenny) would only use user defined connections and were dependant on a user logging in to obtain credentials.

(In reply to comment #16)
> I have the same problem on Debian Wheezy 32 bit.
> New previously unknown networks are not correctly displayed or communicated to
> the 'add new network' dialogues.
> Adding a connection manually with the 'add connection' dialogues works
> correctly.
> 
> Unsure if this is relevant, probably not.
> The behaviour of NetworkManager has changed in Wheezy in that known networks
> are recorded in the system file under /etc/NetworkManager/system-connections.
> Known networks are automatically connected system wide when the 'profile' is
> tagged to autoconnect. A previous version (lenny) would only use user defined
> connections and were dependant on a user logging in to obtain credentials.

I still cannot replicate this, though I do not doubt it is occurring in (as of yet undetermined) certain circumstances.

Can you please attach the output of 'sudo iwlist wlan0 scan' to this bug report?  Hopefully there will be some point of commonality with the other output above that will help to narrow down what is triggering this problem.

Thanks!

Created attachment 1334 [details]
output from 'sudo iwlist wlan1 scan > scanresults.txt'

[FIXME] UNCLASSIFIED DEVICE name: tifm0 type: (null) subsystem: tifm_adapter driver: tifm_7xx1 [Node Path: (null)] [Syspath: /sys/devices/pci0000:00/0000:00:1e.0/0000:0a:09.2/tifm_adapter/tifm0] [104c:803b]
[TDE NM Backend ERROR] [/build/buildd/tdelibs-trinity-14.0.0-r854/tdecore/networkbackends/network-manager/network-manager.cpp:1868] org.freedesktop.DBus.Error.AccessDenied: Property "Autoconnect" of interface "org.freedesktop.NetworkManager.Device" isn't exported (or may not exist)
[TDE NM Backend ERROR] [/build/buildd/tdelibs-trinity-14.0.0-r854/tdecore/networkbackends/network-manager/network-manager.cpp:1819] Attempting to access the network-manager VPN service returned: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.NetworkManager.VPN.Plugin was not provided by any .service files

Is the output in konsole when run manually.

Unsure of relevance but the system is not a 'full' Trinity installation but packages have been cherry picked. The session is started by tdm and the desktop environment is purely trinity i.e. kdesktop, kwin, kicker, ksmserver, konqueror. No gnome or xfce programs are present. Iceweasel and LibreOffice are on the machine.

(In reply to comment #20)
> Unsure of relevance but the system is not a 'full' Trinity installation but
> packages have been cherry picked. The session is started by tdm and the desktop
> environment is purely trinity i.e. kdesktop, kwin, kicker, ksmserver,
> konqueror. No gnome or xfce programs are present. Iceweasel and LibreOffice are
> on the machine.

This should not matter at all.  I also don't see anything unusual in the iwlist scan results.

The reported failures are puzzling to me as I am typing this from an R14 test machine with at least 11 networks visible (many with strange names) and tdenetworkmanager is working perfectly.

If you don't mind, can you please try two things that might help track this down:
1.) Post the output of 'nmcli dev wifi list' (to see if NetworkManager is reporting different networks than the more standard iwlist command)
2.) Try quitting tdenetworkmanager and relaunching it as root via 'tdesudo tdenetworkmanager'.  This is to check for any strange permissions issues that might be preventing tdenetworkmanager from obtaining wireless network information.

Thanks!

Created attachment 1335 [details]
output from 'sudo iwlist wlan1 scan > iwlistoutput.txt'

I have moved location so new set of networks.

Created attachment 1336 [details]
output from 'nmcli dev wifi list > nmclioutput.txt'

tdesudo /opt/trinity/bin/tdenetworkmanager
DCOPClient::attachInternal. Attach failed Could not open network socket

DCOPClient::attachInternal. Attach failed Could not open network socket

[tdebuildsycoca] tdebuildsycoca running...

[tdebuildsycoca] Reusing existing tdesycoca.

[FIXME] UNCLASSIFIED DEVICE name: tifm0 type: (null) subsystem: tifm_adapter driver: tifm_7xx1 [Node Path: (null)] [Syspath: /sys/devices/pci0000:00/0000:00:1e.0/0000:0a:09.2/tifm_adapter/tifm0] [104c:803b]

The list of 'new' networks is still blank.

The plot thickens.
I moved the harddisk from the laptop which does not work (ACER Travelmate 3010)  to another laptop (Lenovo T60) and the results from the unknown networks are displayed correctly!

Both machines have the same type of wireless chipset.

Here are lsmod, lspci, dmesg and the output from nmcli for both machines.

I thought that the fault may have been connected to the udev name assignment, but no. The fault followed the ACER even with network port name conditions reversed.

Created attachment 1340 [details]
collection of text ouput files

(In reply to comment #26)
> Created attachment 1340 [details]
> collection of text ouput files

This is very, very strange!  I don't see any difference *whatsoever* between the wireless hardware of the two machines, yet one works while the other does not!

As most of my test hardware is IBM/Lenovo, I am going to load TDE onto an old HP laptop to see if I can trigger this bug.  Julius, what type of laptop did your fault occur on?

Thanks!

My notebook is an Ahtec, Compal notebook with an Intel chipset. Compal makes notebooks for a variety of brands, so maybe you have one by them as well.

I was finally able to reproduce this bug by adding a second wireless network card to my laptop.  It should be fixed in GIT hash efda5c3, please let me know if this is truly the case!

How do we (users) know when that GIT commit is built? How can we see that?

(In reply to comment #30)
> How do we (users) know when that GIT commit is built? How can we see that?

The only user-visible change will be (in this case) an updated tdelibs package.  The GIT hashes are mentioned in each bug report primarily so that other developers know what was changed and why.

If anyone is curious, the hashes given can be used to look up a particular patch here: http://trinitydesktop.org/patches/

My point being that I would some point of reference when to report back. i.e. which package to look out for. Thanks.

It's working here now! I think this bug can be closed now! Thanks a lot!!

Martin, at least the tdelibs packages for Ubuntu Quantal with version number 4:14.0.0-r856-0ubuntu12.10.0+pr49 on 64-bit are working. I suspect a working version for your system should appear similarly.

(In reply to comment #33)
> It's working here now! I think this bug can be closed now! Thanks a lot!!

Glad to hear it!  This was one of the more unusual bugs I have had to track down. :-)

Closing as requested by original reporter.