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 680310 - Sorting of access points by strengh not working
Sorting of access points by strengh not working
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: network-indicator
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-07-20 11:05 UTC by Matthias Clasen
Modified: 2013-02-12 04:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
iwconfig output (292 bytes, application/octet-stream)
2012-07-20 11:57 UTC, Matthias Clasen
  Details
dmesg output (244.64 KB, application/octet-stream)
2012-07-20 11:57 UTC, Matthias Clasen
  Details
some log output while reconnecting - it ended up with the ... in the status, while the connection works fine (48.66 KB, text/x-log)
2012-07-20 12:07 UTC, Matthias Clasen
  Details
GKeyFile: fix introspection annotation (1.08 KB, patch)
2012-07-20 14:30 UTC, Giovanni Campagna
rejected Details | Review
Revert unintential IAPI break for g_key_file_load_from_data() (1.24 KB, patch)
2012-07-20 14:47 UTC, Colin Walters
committed Details | Review

Description Matthias Clasen 2012-07-20 11:05:28 UTC
1. I have a wireless connection, but the statusicon still shows disconnected. The menu itself also doesn't have the bullet next to the connected ap.

I see lots of

 access point?
      JS LOG: An active wireless connection, in infrastructure mode, involves no

in the logs - may be related ?

2. The sorting of aps by strength seems to have been lost again. Sorting is random, here

3. Activating a vpn connection fails with

    JS ERROR: !!!   error while reading VPN plugin output keyfile
    JS ERROR: !!!     message = '"Cannot convert string to array of 'utf8'"'
    JS ERROR: !!!     fileName = '"/usr/share/gnome-shell/js/ui/networkAgent.js"'
    JS ERROR: !!!     lineNumber = '536'
    JS ERROR: !!!     stack = '"()@/usr/share/gnome-shell/js/ui/networkAgent.js:536
wrapper()@/usr/share/gjs-1.0/lang.js:204
Comment 1 Giovanni Campagna 2012-07-20 11:14:38 UTC
1) Needs to see iwconfig / dmesg to debug. Could be duplicate of bug 679942 or (more likely) bug 676345. Or it could be another GAsyncInitable fallout, if libnm-glib fails to construct the NMAccessPoint (but there should be a critical somewhere)

3) It's a introspection problem. g_key_file_load_from_data is mistakenly marked to take an array of utf8 (char**) instead of an array of uint8 (char*), or a string like it used to do when this code was last tested.
Comment 2 Matthias Clasen 2012-07-20 11:57:00 UTC
Created attachment 219318 [details]
iwconfig output
Comment 3 Matthias Clasen 2012-07-20 11:57:39 UTC
Created attachment 219319 [details]
dmesg output
Comment 4 Matthias Clasen 2012-07-20 11:58:25 UTC
Do we have a fix for the introspection problem in 3) ?
Comment 5 Matthias Clasen 2012-07-20 12:07:01 UTC
Created attachment 219322 [details]
some log output while reconnecting - it ended up with the ... in the status, while the connection works fine
Comment 6 Giovanni Campagna 2012-07-20 12:16:35 UTC
Ok, so 1) is dup of bug 676345 - you're Not-Associated, according to iwconfig (which directly polls the kernel), but kernel logs shows that are actually associated. And gnome-shell doesn't like wireless connections without an access point.
The interesting line is (from syslog)
Jul 20 08:05:47 golem NetworkManager[4141]: <info> (wlan0): roamed from BSSID 98:FC:11:67:0C:91 (clasen_home) to (none) ((none))

For 3), I'll prepare a patch. Do you prefer a new bug against glib?
Comment 7 Matthias Clasen 2012-07-20 14:28:31 UTC
Putting the patch here is fine
Comment 8 Giovanni Campagna 2012-07-20 14:30:57 UTC
Created attachment 219328 [details] [review]
GKeyFile: fix introspection annotation

(array) on an argument of type gchar* without (element-type) makes
an array of strings, not an array of characters. Fix it to be an
array of bytes, like originally intended.
Comment 9 Colin Walters 2012-07-20 14:46:46 UTC
Review of attachment 219328 [details] [review]:

I think we should just go back to what we had before.  Changing it to an array of bytes is a change from how it was originally exposed was as utf8.
Comment 10 Colin Walters 2012-07-20 14:47:07 UTC
Created attachment 219330 [details] [review]
Revert unintential IAPI break for g_key_file_load_from_data()

The old (length) annotation actually wasn't being read.  Changing
it to an array was telling g-i that it was an array of utf8, which
is clearly not true.

We *could* add (element-type guint8), but that would change it to a
byte array, as opposed to the original utf8 version.

Just removing the annotation should bring us back to where we
were, which was fine.
Comment 11 Colin Walters 2012-07-20 14:49:05 UTC
It's pretty clear the intention of the person adding the annotation was to make it a bytestring, but...

Oh hah, we're in a cycle.  Run:

git log -p glib/gkeyfile.c

This turns up:

https://bugzilla.gnome.org/show_bug.cgi?id=658484
Comment 12 Colin Walters 2012-07-20 14:51:11 UTC
And it looks like then Jasper changed it in:
https://bugzilla.gnome.org/show_bug.cgi?id=675309
Comment 13 Matthias Clasen 2012-07-20 14:58:47 UTC
I guess I'll just stop looking at annotation patches...
Comment 14 Jasper St. Pierre (not reading bugmail) 2012-07-20 15:40:24 UTC
(In reply to comment #12)
> And it looks like then Jasper changed it in:
> https://bugzilla.gnome.org/show_bug.cgi?id=675309

Wow, seriously? I don't remember why I needed that at all.
Comment 15 Matthias Clasen 2012-07-20 18:06:53 UTC
Review of attachment 219328 [details] [review]:

.
Comment 16 Matthias Clasen 2012-07-20 18:07:10 UTC
Review of attachment 219330 [details] [review]:

committed this one
Comment 17 Matthias Clasen 2012-07-20 18:18:19 UTC
If we accept that 1) is a kernel issue, then the only issue left here now is the sorting by strength
Comment 18 Jasper St. Pierre (not reading bugmail) 2012-07-20 18:31:20 UTC
Review of attachment 219330 [details] [review]:

"unintential"?
Comment 19 Matthias Clasen 2013-02-12 04:23:52 UTC
its working now, so I'll close this