Opened 9 years ago

Closed 7 years ago

Last modified 6 years ago

#2023 closed defect (fixed)

SSID gets treated as UTF-8 character sequence

Reported by: cgaray Owned by: sascha_silbe
Priority: High Milestone:
Component: Sugar Version: 0.84.x
Severity: Critical Keywords: sugar-love dextrose
Cc: smparrish, bernie, RafaelOrtiz, sascha_silbe, fran Distribution/OS:
Bug Status: Assigned

Description (last modified by sascha_silbe)

Sugar is unable to handle Access Points that have non-UTF-8 SSIDs. The name doesn't get displayed in the Neighborhood; the user is unable to connect to the Access Point by clicking on the AP icon.

This happens with any version of Sugar so far. cgaray originally tested Sugar 0.82 / OLPC OS build 801, Sugar 0.84 / OLPC OS build 170py, Sugar 0.84 / OLPC OS build 179py.

Recent versions of Sugar may even trigger a segfault in glib.markup_escape_text() (see e.g. OLPC#11698).

Change History (20)

comment:1 Changed 9 years ago by cgaray

  • Cc bernie added

comment:2 Changed 9 years ago by RafaelOrtiz

  • Cc RafaelOrtiz added
  • Priority changed from Unspecified by Maintainer to High

comment:3 Changed 9 years ago by sascha_silbe

  • Cc sascha_silbe added
  • Distribution/OS Unspecified deleted
  • Keywords sugar-love added
  • Severity changed from Unspecified to Major
  • Summary changed from UTF-8 support required to non-ASCII SSIDs not rendered in Neighbourhood
  • Version changed from Unspecified to 0.84.x

comment:4 Changed 9 years ago by cgaray

1276621138.215026 ERROR root: No gsm connection was set in GConf.
None
/usr/lib/python2.6/site-packages/sugar/graphics/palette.py:241: GtkWarning: Failed to set text from markup due to error parsing markup: Error en la línea 1, carácter 18: Texto codificado como UTF-8 inválido; «<b>asunción</b>» no válido
  self._label.set_markup('<b>%s</b>' % label)
/usr/lib/python2.6/site-packages/sugar/graphics/palette.py:131: GtkWarning: Failed to set text from markup due to error parsing markup: Error en la línea 1, carácter 18: Texto codificado como UTF-8 inválido; «<b>asunción</b>» no válido
  self.add(palette_box)
1276621184.817054 ERROR dbus.service: Unable to append ({'802-11-wireless': {'ssid': dbus.ByteArray('asunci\xf3n', variant_level=1), 'mode': 'infrastructure'}, 'connection': {'autoconnect': False, 'type': '802-11-wireless', 'id': 'Auto asunci\xf3n', 'uuid': '15533e97f9ec2d4538d8227edd74827a62c75060'}},) to message with signature a{sa{sv}}: <type 'exceptions.UnicodeError'>: String parameters to be sent over D-Bus must be valid UTF-8
1276621190.007076 ERROR root: Failed to activate connection: org.freedesktop.NetworkManager.UnknownConnection: Connection was not provided by any settings service 

comment:5 Changed 9 years ago by bernie

  • Owner changed from tomeu to tch
  • Status changed from new to assigned

comment:6 Changed 9 years ago by sascha_silbe

  • Cc fran added

Related issue: #2099 (special characters in SSID not escaped)

comment:7 Changed 9 years ago by fran

  • Bug Status changed from Unconfirmed to Needinfo
  • Summary changed from non-ASCII SSIDs not rendered in Neighbourhood to non-UTF-8 SSIDs not rendered in Neighbourhood

It looks like the problem is the use of encodings other than UTF-8 (of which ASCII is a strict subset). Cgaray's SSID is named 'asunci\xf3n' - this is 'asunción' in Latin-1, but invalid UTF-8, hence the UnicodeError in the log above.

This is more complicated than the purely cosmetic bug #2099 - it looks like NetworkManager is itself choking on the non-UTF-8 SSID, since D-Bus requires UTF-8 strings. (Cgaray, are you still able to connect to the network, even though the SSID doesn't render?)

There's also no reliable way to consistently detect which encoding is in use, so while it's important that Sugar/NetworkManager be able to _connect_ to non-UTF-8 SSIDs, it's unlikely that SSIDs with other encodings will ever be rendered properly in the interface without compromising Unicode support.

comment:8 Changed 9 years ago by cgaray

Cgaray, are you still able to connect to the network, even though the SSID doesn't render?
No, the XO won't connect.

comment:9 Changed 9 years ago by bernie

Does it also choke in Gnome? I seem to remember that it was working.

Perhaps we could catch the unicode error and render something meaningful anyway?

comment:10 Changed 9 years ago by erikos

  • Milestone changed from Unspecified by Release Team to 0.90

As far as I have seen network-manager-applet is using nm_utils_ssid_to_utf8 [1] from NM to render the SSID to something displayable.

[1] http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/libnm-util/nm-utils.c#n306

comment:11 Changed 9 years ago by erikos

I closed #1735 as a dup of this issue as there is more info in here.

comment:12 Changed 9 years ago by smparrish

  • Cc smparrish added

comment:13 Changed 9 years ago by bernie

  • Keywords dextrose added

comment:14 Changed 8 years ago by erikos

  • Description modified (diff)
  • Milestone changed from 0.90 to 0.98
  • Summary changed from non-UTF-8 SSIDs not rendered in Neighbourhood to use "nm_utils_ssid_to_utf8" from libnm to handle the guessing of the AP name

Please see http://dev.laptop.org/ticket/11698 for the latest assesment of the situation. When we port the shell we would like to use "nm_utils_ssid_to_utf8" from libnm to handle the guessing of the AP name.

comment:15 Changed 8 years ago by sascha_silbe

  • Bug Status changed from Needinfo to Assigned
  • Description modified (diff)
  • Owner changed from tch to sascha_silbe
  • Severity changed from Major to Critical
  • Status changed from assigned to accepted

Fix landed as 7f8ba95 in master. Keeping the ticket open while the backport to Sugar 0.94 is getting tested.

comment:16 Changed 8 years ago by sascha_silbe

  • Summary changed from use "nm_utils_ssid_to_utf8" from libnm to handle the guessing of the AP name to SSID gets treated as UTF-8 character sequence

comment:17 Changed 8 years ago by erikos

#3451 will track the porting to use "nm_utils_ssid_to_utf8" from libnm.

comment:18 Changed 7 years ago by erikos

  • Resolution set to fixed
  • Status changed from accepted to closed

comment:19 Changed 6 years ago by dnarvaez

  • Milestone 0.98 deleted

Milestone 0.98 deleted

comment:20 Changed 6 years ago by Christofer Yael Roibal Perez

Unnecessary checkout for getting file size, Fixes: #2303

Avoid the unnecessary checkout for get the file size from joural. Fix #2023

Changeset: 035cadb48626b70ed5561a6e61239b820d393bbd

Note: See TracTickets for help on using tickets.