Re: Retrieve the saved Wi-Fi profiles which are not in range
On 3 Dec 2014, at 7:35 pm, Patrik Flykt patrik.fl...@linux.intel.com wrote: On Wed, 2014-12-03 at 14:45 +0530, Siddhartha Sikder wrote: Is there any way to retrieve the saved Wi-Fi profiles which are not in range and are not found via scanning? There is no way to retrieve saved services that are not in range or otherwise unavailable. Jolla's connman code does exactly this. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] Fix UTF-8 ssid's
On 1/08/2014 8:12 pm, Patrik Flykt wrote: Hi, On Fri, 2014-08-01 at 12:53 +0300, Jukka Rissanen wrote: Hi Lorn, + result = g_convert_with_fallback((const char *)ssid, -1, + UTF-8, ISO-8859-1, + 0, 0, + bytes_written, error); SSID's are just byte arrays, how can we know which codeset we are converting from (you assume ISO-8859-1 here)? hmm true. They can also contain mixed codeset characters. We do not know the charset used for the SSID, so we can't do it like this. The code below this patch goes through the SSID character by character until it encounters a non-UTF-8 one. The offending characters are replaced by the U+FFFD replacement character and thus the procedure stitches up the name to be UTF-8 compliant. That code results in an ssid configured on the AP as LT-test-Å which from wpa_supplicant is this: LT-test-\xc5 to have ? at the end. g_utf8_validate seems to be failing in this instance, which makes the string to have that undecipherable ? at the end. With mixed codeset characters, this completely fails (but mixed fails on every desktop platform I checked too) ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] Fix UTF-8 ssid's
On 01/08/14 19:53, Jukka Rissanen wrote:
Hi Lorn,
I just wonder what is the issue that this patch is fixing, isn't the
current implementation working?
I would say it isn't, or something isn't working as it should.
My device seems to using ANSI_X3.4-1968
For an AP with ssid set to LT-Test-ÅÅЀ
connman shows: LT-Test-??#1024;
wpa_cli shows it as: LT-Test-\xc5\xc5#1024;
(on my laptop it's LT-Test-__#1024;)
(consequently, only nm-applet comes closest to showing it:
LT-Test-ÅÅ#1024;)
I dug a bit deeper and wpa_supplicant seems to be using a mixture of
UTF-16 and XML decimal (according to kcharselect) for unicode characters.
On pe, 2014-08-01 at 19:42 +1000, Lorn Potter wrote:
I found an old patch that crashed, and fixed it up.
Enjoy!
---
gsupplicant/supplicant.c | 20
1 file changed, 20 insertions(+)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 534944b..19dbb1a 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -1256,6 +1256,26 @@ static void
interface_network_removed(DBusMessageIter *iter, void *user_data)
static char *create_name(unsigned char *ssid, int ssid_len)
{
+ SUPPLICANT_DBG(%s, %i, ssid, ssid_len)
+
+ gchar *result;
+ GError *error = 0;
+ gsize bytes_written = 0;
+
+ if (g_utf8_validate((const char *)ssid, ssid_len, NULL) == TRUE)
+ return g_strndup((const char *)ssid, ssid_len);
+
+ result = g_convert_with_fallback((const char *)ssid, -1,
+ UTF-8, ISO-8859-1,
+ 0, 0,
+ bytes_written, error);
SSID's are just byte arrays, how can we know which codeset we are
converting from (you assume ISO-8859-1 here)?
+ if (result) {
+ return result;
+ } else {
+ SUPPLICANT_DBG(Error converting to UTF-8: %s,
error-message);
+ g_error_free (error);
+ }
+
GString *string;
const gchar *remainder, *invalid;
int valid_bytes, remaining_bytes;
C++ style code here, the variables should be declared at the beginning
of func.
Cheers,
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH] Fix UTF-8 ssid's
I found an old patch that crashed, and fixed it up.
Enjoy!
---
gsupplicant/supplicant.c | 20
1 file changed, 20 insertions(+)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 534944b..19dbb1a 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -1256,6 +1256,26 @@ static void
interface_network_removed(DBusMessageIter *iter, void *user_data)
static char *create_name(unsigned char *ssid, int ssid_len)
{
+ SUPPLICANT_DBG(%s, %i, ssid, ssid_len)
+
+ gchar *result;
+ GError *error = 0;
+ gsize bytes_written = 0;
+
+ if (g_utf8_validate((const char *)ssid, ssid_len, NULL) == TRUE)
+ return g_strndup((const char *)ssid, ssid_len);
+
+ result = g_convert_with_fallback((const char *)ssid, -1,
+ UTF-8, ISO-8859-1,
+ 0, 0,
+ bytes_written, error);
+ if (result) {
+ return result;
+ } else {
+ SUPPLICANT_DBG(Error converting to UTF-8: %s,
error-message);
+ g_error_free (error);
+ }
+
GString *string;
const gchar *remainder, *invalid;
int valid_bytes, remaining_bytes;
--
1.7.10.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: Unreachable favorite network
On 14 May 2014, at 11:27 pm, Julien Massot jmas...@aldebaran-robotics.com wrote: Hi ConnMan developers, My users are requesting stronger than before to be able to remove unreachable favorites services. At the moment it's not possible with ConnMan API. I understand that returning unreachable networks is quiet confusing, but I think their request is legitimate. Often they think they remove all the favorite networks in the UI list, and they don't understand that some networks are still stored. Sometimes it results in unwanted wifi passphrase leaks, or connection to a no longer wanted network. The naive way of thinking is to return these networks with GetServices method of net.connman.Manager interface. These services may required a new unreachable state. Does someone already think about a possible implementation for this use case ? Jolla had such a use case, and so we created a patch in our connman repo, which exposes those saved/known out of range AP's through dbus. Editing them is only possible when in range, except for 'removing' them. So yes. It is possible. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Functional test suite for connman
On 28 Mar 2014, at 1:13 am, Patrik Flykt patrik.fl...@linux.intel.com wrote: Hi, On Mon, 2014-03-24 at 17:06 +0100, Simon Busch wrote: I know there was once ago a functional test suite for connman as part of the Meego project. By searching through the web I just found the old meego references. Is there still a up to date and used functional test suite for connman available somehwere? The Meego one, if it still works to some extent, would need an overhaul to catch up with current ConnMan. I don't know of any up to date ones, does anybody else? I didn't know about the meego QA test suite. Thanks! :) Jolla QA _might_ be able to spend some time getting some of those up to date. I will poke around to see if they want to use them at all. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Anybody wants to help SailfishOS and Jolla?
On 14 Mar 2014, at 8:46 am, Lorn Potter lorn.pot...@jolla.com wrote: Autoconnecting works as a charm with the following line added to /etc/connman/main.conf and a restart of ConnMan: PreferredTechnologies = wifi,cellular As the ordering says, WiFi is preferred over cellular; should a WiFi network be discovered and successfully connected while using cellular, ConnMan shifts the default route over to WiFi. This has never worked right. It would be awesome if this was fixed post 1.15. One thing about this is that there is no way to tell connman to make cellular the default route if wifi already is there, other than disconnecting wifi. Just tested this with 1.21 with our autconnecting code not running. This is working as expected now. \0/ ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
dnsproxy signaling
Hi, Just wondering if there are any dbus signals to be had when there is no connection and something makes a request? i.e. (no connection) user tries to opens link - udp_listener_event - parse_request - send_response[MSG_NOSIGNAL] - dbus - [some client pops up Do you want to connect? Select connection ...] ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
