Re: Connman behavior with marginally stabe wifi
On to, 2014-09-18 at 08:57 +, Thiemo van Engelen wrote: > Hello all, > > Or is this typically solved in the controlling application on embedded > devices and if this is the case, does anyone have some pointers and what and > what not to do to get it going again without user interaction? > The controlling application can use the ConnMan session API to create the connections. See API description at http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/session-api.txt Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 0/2] dnsproxy: Check whether cache cleanup needs to be scheduled
On Wed, 2014-09-17 at 14:22 +0300, Hannu Mallat wrote: > One more reworking: unit test needs a few more stubs when compiling > without optimization. > > Hannu Mallat (2): > dnsproxy: Check whether cache cleanup needs to be scheduled I applied only patch 1/2 as it wasn't really clear from running the unit test whether the refcounting underrun condition actually got tested or not. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] manager: Do not recurse one more level for upnp basic type
On Tue, 2014-09-16 at 08:48 -0400, Eduardo Abinader wrote: > Just recurse one more level for the byte array that > corresponds to bonjour data and not for the variant holding > upnp data. This patch prevents a segmentation fault > occuring by dereferencing null upnp data. Applied, thanks! Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2 0/3] Peer service registration fixes
On Wed, 2014-09-17 at 08:27 -0400, Eduardo Abinader wrote: > This set aims to solve observed issues during peer service > register and unregister scenarios. Applied, thanks! Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] timeserver: Cleanup comments and clarify debug message
On Mon, 2014-09-15 at 17:03 +0200, Peter Meerwald wrote: > From: Peter Meerwald > > Signed-off-by: Peter Meerwald Applied, thanks! As we have a "flat" contributor structure in ConnMan, the Author field already records the developer information for each patch. Thus we haven't needed signed-off-bys in Connman. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connman behavior with marginally stabe wifi
Just a small comment: It is solved if the network is timed out by wpa_supplicant. At that point all temporary knowledge of the network and its state is cleared from ConnMan. Once it re-appears, it won't have any previous failed state associated with it and can be retried. The network should be timed-out by wpa_supplicant after 2 minutes or so. As long as there is no scan update for a period long enough to reach this timeout. I think this should work already. The automatic scanning in connman takes some retries to reach a timeout long enough (~5 minutes) so the network will be removed in the middle. Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH v2 3/5] plugins: Add a wifi.conf configuration file template for the wifi plugin
This specific file, installed in /etc/connman/, can be used to set specific values related to wifi plugin only. --- forgot to mention it's experimental Makefile.plugins | 1 + plugins/wifi.conf | 14 ++ 2 files changed, 15 insertions(+) create mode 100644 plugins/wifi.conf diff --git a/Makefile.plugins b/Makefile.plugins index e90ad19..140332b 100644 --- a/Makefile.plugins +++ b/Makefile.plugins @@ -24,6 +24,7 @@ gsupplicant_sources = gsupplicant/gsupplicant.h gsupplicant/dbus.h \ if WIFI builtin_modules += wifi builtin_sources += plugins/wifi.c $(gsupplicant_sources) +EXTRA_DIST += plugins/wifi.conf endif if BLUETOOTH diff --git a/plugins/wifi.conf b/plugins/wifi.conf new file mode 100644 index 000..58e56b9 --- /dev/null +++ b/plugins/wifi.conf @@ -0,0 +1,14 @@ +# This is an EXPERIMENTAL configuration file + +[General] + +# Set the P2P primary device type. It follows such format: +# +# Where all elements are expressed in hexadecimal. +# Category and subcategory are in network byte order. +# For the OUI, follow the WSC specification. +# PrimaryDeviceType = + +# Set the P2P secondary device types. Same format as PrimaryDeviceType +# but you can pile a maximum of 5 types here separated by a space. +# SecondaryDeviceTypes = -- 1.8.5.5 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Connman behavior with marginally stabe wifi
Hi, On Thu, 2014-09-18 at 08:57 +, Thiemo van Engelen wrote: > We however have problems with the wifi connection, especially when it > is installed such that the wifi connection is marginally stable (and > there is no ethernet connection) > What we see is that when the connection is dropped (due to bad > reception for example), connman tries to reconnect which can fail, in > which case connman goes into the "failure" state with one of 2 errors: > "connect-failed" or "invalid-key". This depends on what wpa_supplicant actually reports back to ConnMan. My guess is that the connection was broken in the middle of the key exchange or similar in the second case. > What we also see is that connman does not try to reconnect, once it is > in the failure state. I would say that this is not the behaviour you > would want from an embedded device, as connman would need some > "attention" to come out of the failure state and retry. The other side of the coin is that if we do not disable retries to a failed network, we'd end up constantly banging on the network whenever we have a wrong passphrase or bad reception as in your case. This will lock out ConnMan from certain set of networks that allow only a limited amount of connection attempts. And since those access points put the ConnMan device on hold for quite a few hours before allowing further (re)connects, it's quite a mess. > When I look at my (android) phone, it retries to connect to my home > WIFI for example, even when I am at the edge of the router range. I > certainly never have to go into the WIFI menu because it is in some > failure state. > What is the reasoning behind this "failure" behaviour of connman and > can it perhaps be adjusted via the configuration? > Or is this typically solved in the controlling application on embedded > devices and if this is the case, does anyone have some pointers and > what and what not to do to get it going again without user > interaction? It is solved if the network is timed out by wpa_supplicant. At that point all temporary knowledge of the network and its state is cleared from ConnMan. Once it re-appears, it won't have any previous failed state associated with it and can be retried. When there is at least some form of UI, the user can always mitigate the issue by forcefully connecting to the failed network. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 1/5] gsupplicant: Add a way to set primary and secondary P2P devices types
This will be used by the wifi plugin to set specific devices types.
---
gsupplicant/dbus.c| 1 +
gsupplicant/gsupplicant.h | 4 ++-
gsupplicant/supplicant.c | 90 +--
plugins/wifi.c| 3 +-
4 files changed, 93 insertions(+), 5 deletions(-)
diff --git a/gsupplicant/dbus.c b/gsupplicant/dbus.c
index 4ff5d50..2957979 100644
--- a/gsupplicant/dbus.c
+++ b/gsupplicant/dbus.c
@@ -624,6 +624,7 @@ void supplicant_dbus_property_append_array(DBusMessageIter
*iter,
switch (type) {
case DBUS_TYPE_STRING:
+ case DBUS_TYPE_BYTE:
variant_sig = DBUS_TYPE_ARRAY_AS_STRING
DBUS_TYPE_ARRAY_AS_STRING
DBUS_TYPE_BYTE_AS_STRING;
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gsupplicant.h
index e820381..631e846 100644
--- a/gsupplicant/gsupplicant.h
+++ b/gsupplicant/gsupplicant.h
@@ -286,7 +286,9 @@ int g_supplicant_interface_set_country(GSupplicantInterface
*interface,
void *user_data);
bool g_supplicant_interface_has_p2p(GSupplicantInterface *interface);
int g_supplicant_interface_set_p2p_device_config(GSupplicantInterface
*interface,
- const char *device_name);
+ const char *device_name,
+ const char *primary_dev_type,
+ const char *secondary_dev_types);
GSupplicantPeer *g_supplicant_interface_peer_lookup(GSupplicantInterface
*interface,
const char *identifier);
bool g_supplicant_interface_is_p2p_finding(GSupplicantInterface *interface);
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 83d4c1c..83c6dae 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -3186,6 +3187,8 @@ bool g_supplicant_interface_has_p2p(GSupplicantInterface
*interface)
struct supplicant_p2p_dev_config {
char *device_name;
+ char *dev_type;
+ char **sec_dev_types;
};
static void p2p_device_config_result(const char *error,
@@ -3194,12 +3197,63 @@ static void p2p_device_config_result(const char *error,
struct supplicant_p2p_dev_config *config = user_data;
if (error)
- SUPPLICANT_DBG("Unable to set P2P Device configuration");
+ SUPPLICANT_DBG("Unable to set P2P Device configuration: %s",
+ error);
g_free(config->device_name);
+ g_free(config->dev_type);
+ g_strfreev(config->sec_dev_types);
dbus_free(config);
}
+static int dev_type_str2bin(const char *type, unsigned char dev_type[8])
+{
+ int length, pos, end;
+ char b[3] = {};
+ char *e = NULL;
+
+ end = strlen(type);
+ for (length = pos = 0; type[pos] != '\0' && length < 8; length++) {
+ if (pos+2 > end)
+ return 0;
+
+ b[0] = type[pos];
+ b[1] = type[pos+1];
+
+ dev_type[length] = strtol(b, &e, 16);
+ if (e && *e != '\0')
+ return 0;
+
+ pos += 2;
+ }
+
+ return 8;
+}
+
+static void append_secondary_dev_types(DBusMessageIter *iter, void *user_data)
+{
+ struct supplicant_p2p_dev_config *config = user_data;
+ unsigned char dev_type[8] = {}, *type;
+ char **types;
+ int len;
+
+ type = dev_type;
+
+ for (types = config->sec_dev_types; *types; types++) {
+ DBusMessageIter array;
+
+ len = dev_type_str2bin(*types, dev_type);
+ if (!len)
+ continue;
+
+ dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY,
+ DBUS_TYPE_BYTE_AS_STRING, &array);
+ dbus_message_iter_append_fixed_array(&array, DBUS_TYPE_BYTE,
+ &type, len);
+ dbus_message_iter_close_container(iter, &array);
+ }
+}
+
static void p2p_device_config_params(DBusMessageIter *iter, void *user_data)
{
struct supplicant_p2p_dev_config *config = user_data;
@@ -3210,6 +3264,27 @@ static void p2p_device_config_params(DBusMessageIter
*iter, void *user_data)
supplicant_dbus_dict_append_basic(&dict, "DeviceName",
DBUS_TYPE_STRING, &config->device_name);
+
+ if (config->dev_type) {
+ unsigned char dev_type[8] = {}, *type;
+ int len;
+
+ len = dev_type_str2bin(config->dev_type, dev_type);
+ if (len) {
+ type = dev_type;
+ supplicant_dbus_dict_append_fixed_array(&dict,
+
[PATCH 2/5] wifi: Support a dedicated configuration file
In order not to overload ConnMan's main.conf with wifi plugin specific
settings (aka wpa_supplicant's settings...), let's have a quick
dedicated config file. Currently the 2 supported settings are used for
P2P and thus are not mandatory to be set, thus ignoring any errors
related to parsing this file to make it simple.
---
plugins/wifi.c | 53 -
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index eaacfbf..82f90e3 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -58,6 +58,9 @@
#include
+#define CONF_FILE "wifi.conf"
+#define WIFI_CONFIG_FILE CONFIGDIR "/" CONF_FILE
+
#define CLEANUP_TIMEOUT 8/* in seconds */
#define INACTIVE_TIMEOUT 12 /* in seconds */
#define FAVORITE_MAXIMUM_RETRIES 2
@@ -70,6 +73,17 @@
#define P2P_LISTEN_PERIOD 500
#define P2P_LISTEN_INTERVAL 2000
+static struct {
+ char *primary_dev_type;
+ char *secondary_dev_types;
+} wifi_settings = {
+ .primary_dev_type = NULL,
+ .secondary_dev_types = NULL,
+};
+
+#define CONF_PRIMARY_DEV_TYPE"PrimaryDeviceType"
+#define CONF_SECONDARY_DEV_TYPES "SecondaryDeviceTypes"
+
static struct connman_technology *wifi_technology = NULL;
static struct connman_technology *p2p_technology = NULL;
@@ -2317,7 +2331,8 @@ static void p2p_support(GSupplicantInterface *interface)
hostname = "ConnMan";
g_supplicant_interface_set_p2p_device_config(interface,
- hostname, NULL, NULL);
+ hostname, wifi_settings.primary_dev_type,
+ wifi_settings.secondary_dev_types);
connman_peer_driver_register(&peer_driver);
}
@@ -2893,6 +2908,38 @@ static struct connman_technology_driver tech_driver = {
.set_regdom = tech_set_regdom,
};
+static void load_wifi_settings(void)
+{
+ GKeyFile *keyfile;
+ char *str;
+
+ keyfile = g_key_file_new();
+
+ if (!g_key_file_load_from_file(keyfile, WIFI_CONFIG_FILE, 0, NULL))
+ goto out;
+
+ str = g_key_file_get_string(keyfile, "General",
+ CONF_PRIMARY_DEV_TYPE, NULL);
+ if (str)
+ wifi_settings.primary_dev_type = g_strchomp(str);
+
+ str = g_key_file_get_string(keyfile, "General",
+ CONF_SECONDARY_DEV_TYPES, NULL);
+ if (str)
+ wifi_settings.secondary_dev_types = g_strchomp(str);
+out:
+ g_key_file_free(keyfile);
+}
+
+static void unload_wifi_settings(void)
+{
+ g_free(wifi_settings.primary_dev_type);
+ wifi_settings.primary_dev_type = NULL;
+
+ g_free(wifi_settings.secondary_dev_types);
+ wifi_settings.secondary_dev_types = NULL;
+}
+
static int wifi_init(void)
{
int err;
@@ -2914,6 +2961,8 @@ static int wifi_init(void)
return err;
}
+ load_wifi_settings();
+
return 0;
}
@@ -2926,6 +2975,8 @@ static void wifi_exit(void)
g_supplicant_unregister(&callbacks);
connman_network_driver_unregister(&network_driver);
+
+ unload_wifi_settings();
}
CONNMAN_PLUGIN_DEFINE(wifi, "WiFi interface plugin", VERSION,
--
1.8.5.5
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 3/5] plugins: Add a wifi.conf configuration file template for the wifi plugin
This specific file, installed in /etc/connman/, can be used to set specific values related to wifi plugin only. --- Makefile.plugins | 1 + plugins/wifi.conf | 10 ++ 2 files changed, 11 insertions(+) create mode 100644 plugins/wifi.conf diff --git a/Makefile.plugins b/Makefile.plugins index e90ad19..140332b 100644 --- a/Makefile.plugins +++ b/Makefile.plugins @@ -24,6 +24,7 @@ gsupplicant_sources = gsupplicant/gsupplicant.h gsupplicant/dbus.h \ if WIFI builtin_modules += wifi builtin_sources += plugins/wifi.c $(gsupplicant_sources) +EXTRA_DIST += plugins/wifi.conf endif if BLUETOOTH diff --git a/plugins/wifi.conf b/plugins/wifi.conf new file mode 100644 index 000..5439709 --- /dev/null +++ b/plugins/wifi.conf @@ -0,0 +1,12 @@ +[General] + +# Set the P2P primary device type. It follows such format: +# +# Where all elements are expressed in hexadecimal. +# Category and subcategory are in network byte order. +# For the OUI, follow the WSC specification. +# PrimaryDeviceType = + +# Set the P2P secondary device types. Same format as PrimaryDeviceType +# but you can pile a maximum of 5 types here separated by a space. +# SecondaryDeviceTypes = -- 1.8.5.5 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH 5/5] wifi: Silently go back to idle if a peer failed on incoming connection
Thus peer core will not report any error and ask for a usuless retry.
Reported-by: Jussi Kukkonen
---
plugins/wifi.c | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 82f90e3..68e6e63 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -137,6 +137,7 @@ struct wifi_data {
unsigned int p2p_find_timeout;
unsigned int p2p_connection_timeout;
struct connman_peer *pending_peer;
+ GSupplicantPeer *peer;
bool p2p_connecting;
bool p2p_device;
int servicing;
@@ -233,15 +234,24 @@ static void peer_cancel_timeout(struct wifi_data *wifi)
wifi->p2p_connecting = false;
connman_peer_unref(wifi->pending_peer);
wifi->pending_peer = NULL;
+ wifi->peer = NULL;
}
static gboolean peer_connect_timeout(gpointer data)
{
struct wifi_data *wifi = data;
- if (wifi->p2p_connecting)
- connman_peer_set_state(wifi->pending_peer,
- CONNMAN_PEER_STATE_FAILURE);
+ DBG("");
+
+ if (wifi->p2p_connecting) {
+ enum connman_peer_state state = CONNMAN_PEER_STATE_FAILURE;
+
+ if (g_supplicant_peer_has_requested_connection(wifi->peer))
+ state = CONNMAN_PEER_STATE_IDLE;
+
+ connman_peer_set_state(wifi->pending_peer, state);
+ }
+
peer_cancel_timeout(wifi);
return FALSE;
@@ -259,7 +269,7 @@ static void peer_connect_callback(int result,
GSupplicantInterface *interface,
return;
if (result < 0) {
- connman_peer_set_state(peer, CONNMAN_PEER_STATE_FAILURE);
+ peer_connect_timeout(wifi);
return;
}
@@ -293,6 +303,8 @@ static int peer_connect(struct connman_peer *peer,
if (wifi->p2p_connecting)
return -EBUSY;
+ wifi->peer = NULL;
+
gs_peer = g_supplicant_interface_peer_lookup(wifi->interface,
connman_peer_get_identifier(peer));
if (!gs_peer)
@@ -329,6 +341,7 @@ static int peer_connect(struct connman_peer *peer,
peer_connect_callback, wifi);
if (ret == -EINPROGRESS) {
wifi->pending_peer = connman_peer_ref(peer);
+ wifi->peer = gs_peer;
wifi->p2p_connecting = true;
} else if (ret < 0)
g_free(peer_params);
@@ -2553,9 +2566,7 @@ static void peer_lost(GSupplicantPeer *peer)
if (connman_peer) {
if (wifi->p2p_connecting &&
wifi->pending_peer == connman_peer) {
- connman_peer_set_state(connman_peer,
- CONNMAN_PEER_STATE_FAILURE);
- peer_cancel_timeout(wifi);
+ peer_connect_timeout(wifi);
}
connman_peer_unregister(connman_peer);
connman_peer_unref(connman_peer);
@@ -2600,7 +2611,10 @@ static void peer_changed(GSupplicantPeer *peer,
p_state = CONNMAN_PEER_STATE_IDLE;
break;
case G_SUPPLICANT_PEER_GROUP_FAILED:
- p_state = CONNMAN_PEER_STATE_FAILURE;
+ if (g_supplicant_peer_has_requested_connection(peer))
+ p_state = CONNMAN_PEER_STATE_IDLE;
+ else
+ p_state = CONNMAN_PEER_STATE_FAILURE;
break;
}
--
1.8.5.5
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 4/5] gsupplicant: Add a way to know a peer that tried an incoming connection
Thus it will be possible to handle a connection failure properly in the
wifi plugin, so it will not request the agent for a retry.
---
gsupplicant/gsupplicant.h | 1 +
gsupplicant/supplicant.c | 15 +++
2 files changed, 16 insertions(+)
diff --git a/gsupplicant/gsupplicant.h b/gsupplicant/gsupplicant.h
index 631e846..cc93d32 100644
--- a/gsupplicant/gsupplicant.h
+++ b/gsupplicant/gsupplicant.h
@@ -325,6 +325,7 @@ bool g_supplicant_peer_is_wps_pin(GSupplicantPeer *peer);
bool g_supplicant_peer_is_in_a_group(GSupplicantPeer *peer);
GSupplicantInterface *g_supplicant_peer_get_group_interface(GSupplicantPeer
*peer);
bool g_supplicant_peer_is_client(GSupplicantPeer *peer);
+bool g_supplicant_peer_has_requested_connection(GSupplicantPeer *peer);
struct _GSupplicantCallbacks {
void (*system_ready) (void);
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 83c6dae..c9c875f 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -235,6 +235,7 @@ struct _GSupplicantPeer {
GSList *groups;
bool groups_changed;
const GSupplicantInterface *current_group_iface;
+ bool connection_requested;
};
struct _GSupplicantGroup {
@@ -515,6 +516,8 @@ static void callback_peer_request(GSupplicantPeer *peer)
if (!callbacks_pointer->peer_request)
return;
+ peer->connection_requested = true;
+
callbacks_pointer->peer_request(peer);
}
@@ -1147,6 +1150,14 @@ bool g_supplicant_peer_is_client(GSupplicantPeer *peer)
return false;
}
+bool g_supplicant_peer_has_requested_connection(GSupplicantPeer *peer)
+{
+ if (!peer)
+ return false;
+
+ return peer->connection_requested;
+}
+
static void merge_network(GSupplicantNetwork *network)
{
GString *str;
@@ -2733,6 +2744,8 @@ static void signal_peer_changed(const char *path,
DBusMessageIter *iter)
callback_peer_changed(peer, G_SUPPLICANT_PEER_GROUP_CHANGED);
+ if (!g_supplicant_peer_is_in_a_group(peer))
+ peer->connection_requested = false;
peer->groups_changed = false;
}
@@ -2825,6 +2838,7 @@ static void signal_group_failure(const char *path,
DBusMessageIter *iter)
return;
callback_peer_changed(peer, G_SUPPLICANT_PEER_GROUP_FAILED);
+ peer->connection_requested = false;
}
static void signal_group_started(const char *path, DBusMessageIter *iter)
@@ -3018,6 +3032,7 @@ static void signal_group_peer_disconnected(const char
*path, DBusMessageIter *it
return;
callback_peer_changed(peer, G_SUPPLICANT_PEER_GROUP_DISCONNECTED);
+ peer->connection_requested = false;
}
static struct {
--
1.8.5.5
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[PATCH 0/5] Peer API improvements
Here are 2 functionalities meant to improve Peer API experience: - patch 1 to 3: this helps to configure a primary and secondary device types. Thus you can tell what device (PC-Laptop, Display-Television etc...) you are. - patch 4 and 5: that's a fix on incoming connection. There is no need to report any error and ask for a retry if an incoming connection failed. Tomasz Bursztyka (5): gsupplicant: Add a way to set primary and secondary P2P devices types wifi: Support a dedicated configuration file plugins: Add a wifi.conf configuration file template for the wifi plugin gsupplicant: Add a way to know a peer that tried an incoming connection wifi: Silently go back to idle if a peer failed on incoming connection Makefile.plugins | 1 + gsupplicant/dbus.c| 1 + gsupplicant/gsupplicant.h | 5 ++- gsupplicant/supplicant.c | 105 -- plugins/wifi.c| 84 + plugins/wifi.conf | 10 + 6 files changed, 193 insertions(+), 13 deletions(-) create mode 100644 plugins/wifi.conf -- 1.8.5.5 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Using connman to 'monitor' while tethering
On 18-09-14 13:46, Patrik Flykt wrote: Hi, On Thu, 2014-09-18 at 12:24 +0200, Olliver Schinagl wrote: Well our specific use-case is, that a device is in 'listening' mode as an Accesspoint, a device connects to it (first use wizard like thing) to setup the local network. The the app then via dbus tells connman to stop tethering and be a regular wifi device. To do this however, a result of the available networks is required. So yes, tethering is 'abused' to have an accesspoint. But as mentioned below, irrelevant. That sounds like a decent solution to the problem. You were perhaps trying to verify that the network exists while being an Access Point? I'd assume that if the local network cannot be found or connected during the first use wizard lookalike stage, the device should return to its Access Point state whereby the setup step can be retried? Yeah, we are going this route now, start in AP mode and every 30? seconds do a quick scan for available AccessPoints and then return to AP mode. Should be reliable eough I hope ;) The only exception is when we do not want to connect to any network, but have the device just actually be an AP so that wireless clients can directly connect. Since hostapd and WiFi scanning was verified by you earlier in the mail, the WiFi device driver has the proper capabilities to perform both of the requested tasks at the same timne. It is thus wpa_supplicant that is the roadblock here. It apparently does not have the capabilities of scanning while in AP mode. I'm not sure I follow 100%. wpa_supplicant is invoked/implemented via gsupplicant, correct? gsupplicant is an internal abstraction that tries to make the use of wpa_supplicant easier. gsupplicant doesn't do any processing on the wifi handling itself. Anyway, scanning using iw dev wlan0 scan when hostapd is running fails actually, so it looks like the hardware cannot do it anyway? I guess openwrt does it by stopping AP mode, scan and restart AP mode quickly enough so that the client doesn't disconnect. I was actually wrong on this one. There are these two lines in plugins/wifi.c: if (wifi->tethering) return 0; So scanning via wpa_supplicant is not even attempted, thus I was a bit quick saying that wpa_supplicant isn't supporting scanning while being an access point. But as you noticed scanning failed in the end even with hostapd. So no matter what wpa_supplicant does or does not do in this case is irrelevant for the outcome. Well then if the driver does start to support this, I guess we'll have to work on a connmand patch too. Thanks again for your time! Olliver Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman -- Met vriendelijke groeten, Kind regards, 与亲切的问候 Olliver Schinagl Research & Development Ultimaker B.V. http://www.ultimaker.com ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Using connman to 'monitor' while tethering
Hi, On Thu, 2014-09-18 at 12:24 +0200, Olliver Schinagl wrote: > Well our specific use-case is, that a device is in 'listening' mode as > an Accesspoint, a device connects to it (first use wizard like thing) > to setup the local network. The the app then via dbus tells connman to > stop tethering and be a regular wifi device. To do this however, a > result of the available networks is required. So yes, tethering is > 'abused' to have an accesspoint. But as mentioned below, irrelevant. That sounds like a decent solution to the problem. You were perhaps trying to verify that the network exists while being an Access Point? I'd assume that if the local network cannot be found or connected during the first use wizard lookalike stage, the device should return to its Access Point state whereby the setup step can be retried? > > Since hostapd and WiFi scanning was verified by you earlier in the mail, > > the WiFi device driver has the proper capabilities to perform both of > > the requested tasks at the same timne. It is thus wpa_supplicant that is > > the roadblock here. It apparently does not have the capabilities of > > scanning while in AP mode. > I'm not sure I follow 100%. wpa_supplicant is invoked/implemented via > gsupplicant, correct? gsupplicant is an internal abstraction that tries to make the use of wpa_supplicant easier. gsupplicant doesn't do any processing on the wifi handling itself. > Anyway, scanning using iw dev wlan0 scan when hostapd is running fails > actually, so it looks like the hardware cannot do it anyway? I guess > openwrt does it by stopping AP mode, scan and restart AP mode quickly > enough so that the client doesn't disconnect. I was actually wrong on this one. There are these two lines in plugins/wifi.c: if (wifi->tethering) return 0; So scanning via wpa_supplicant is not even attempted, thus I was a bit quick saying that wpa_supplicant isn't supporting scanning while being an access point. But as you noticed scanning failed in the end even with hostapd. So no matter what wpa_supplicant does or does not do in this case is irrelevant for the outcome. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Using connman to 'monitor' while tethering
On 18-09-14 11:59, Patrik Flykt wrote: Hi, On Thu, 2014-09-18 at 09:27 +0200, Olliver Schinagl wrote: One thing I have not been able to figure out yet however, if connman is able to do a wifi scan while it is also running as accesspoint. This depends basically on wpa_supplicant and/or the WiFi device driver. If both of them are capable of scanning while doing their AP duties, scan results will be received. Then again I'm not in the clear which use case would demand such behavior as WiFi tethering should be run as long as the user in the other end of the D-Bus connection wants to do that. So suddenly switching tethering off in favor of connecting to a WiFi network is perhaps not the best possible use case here. If this is wanted, the proper way is to disable tethering and then (auto)connect. Well our specific use-case is, that a device is in 'listening' mode as an Accesspoint, a device connects to it (first use wizard like thing) to setup the local network. The the app then via dbus tells connman to stop tethering and be a regular wifi device. To do this however, a result of the available networks is required. So yes, tethering is 'abused' to have an accesspoint. But as mentioned below, irrelevant. We did run some tests using hostapd and it seemed to work just fine, as hostapd created a monitor device in addition to the regular wlan device. I do see connman create a monitoring device, mon.wlan0, so scanning the wifi while being an accesspoint shouldn't be a problem? It may very well be a problem, as wpa_supplicant is used also for tethering. Although coming from the same code base, wpa_supplicant implements a subset of the functionality provided by hostapd, so I'm not surprised that scanning works differently in both. And running both hostapd and wpa_supplicant is a no go, as both of them want to control the very same hardware. In addition, having ConnMan to enable/disable them at run time is not something that can be done, as ConnMan can be started with only enough permissions to get its stuff done without any capabilities or even knowledge of how to stop/start other services in the device in question. Bringing up an accesspoint via tether works well enough. connmanctl enable wifi connmanctl tether wifi on testssid testpassphrase Here the tether bridge, mon.wlan0 are all brought up. I suspect the mon.wlan0 device is related to the monitor command? Anyway, doing a scan wifi, the scan seems to wait for a bit, and then returns with the following: connmanctl scan wifi Error /net/connman/technology/wifi: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Running connmand in the foreground with debugging yields the following when starting the scan: connmand[245]: src/technology.c:scan() technology 0x1cadba0 request from :1.7 connmand[245]: plugins/wifi.c:wifi_scan() device 0x1caa1c0 wifi 0x1cac998 hidden ssid (null) Is this a driver bug for the wifi device? (ath9k_htc) or a bug/limitation of connman? We're using the git version of connman at this moment. Since hostapd and WiFi scanning was verified by you earlier in the mail, the WiFi device driver has the proper capabilities to perform both of the requested tasks at the same timne. It is thus wpa_supplicant that is the roadblock here. It apparently does not have the capabilities of scanning while in AP mode. I'm not sure I follow 100%. wpa_supplicant is invoked/implemented via gsupplicant, correct? Anyway, scanning using iw dev wlan0 scan when hostapd is running fails actually, so it looks like the hardware cannot do it anyway? I guess openwrt does it by stopping AP mode, scan and restart AP mode quickly enough so that the client doesn't disconnect. Thanks for your time and help for now! Olliver Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman -- Met vriendelijke groeten, Kind regards, 与亲切的问候 Olliver Schinagl Research & Development Ultimaker B.V. http://www.ultimaker.com ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Using connman to 'monitor' while tethering
Hi, On Thu, 2014-09-18 at 09:27 +0200, Olliver Schinagl wrote: > One thing I have not been able to figure out yet however, if connman is > able to do a wifi scan while it is also running as accesspoint. This depends basically on wpa_supplicant and/or the WiFi device driver. If both of them are capable of scanning while doing their AP duties, scan results will be received. Then again I'm not in the clear which use case would demand such behavior as WiFi tethering should be run as long as the user in the other end of the D-Bus connection wants to do that. So suddenly switching tethering off in favor of connecting to a WiFi network is perhaps not the best possible use case here. If this is wanted, the proper way is to disable tethering and then (auto)connect. > We did run some tests using hostapd and it seemed to work just fine, as > hostapd created a monitor device in addition to the regular wlan device. > I do see connman create a monitoring device, mon.wlan0, so scanning the > wifi while being an accesspoint shouldn't be a problem? It may very well be a problem, as wpa_supplicant is used also for tethering. Although coming from the same code base, wpa_supplicant implements a subset of the functionality provided by hostapd, so I'm not surprised that scanning works differently in both. And running both hostapd and wpa_supplicant is a no go, as both of them want to control the very same hardware. In addition, having ConnMan to enable/disable them at run time is not something that can be done, as ConnMan can be started with only enough permissions to get its stuff done without any capabilities or even knowledge of how to stop/start other services in the device in question. > Bringing up an accesspoint via tether works well enough. > connmanctl enable wifi > connmanctl tether wifi on testssid testpassphrase > > Here the tether bridge, mon.wlan0 are all brought up. > I suspect the mon.wlan0 device is related to the monitor command? > > Anyway, doing a scan wifi, the scan seems to wait for a bit, and then > returns with the following: > connmanctl scan wifi > Error /net/connman/technology/wifi: Did not receive a reply. Possible > causes include: the remote application did not send a reply, the message > bus security policy blocked the reply, the reply timeout expired, or the > network connection was broken. > > Running connmand in the foreground with debugging yields the following > when starting the scan: > connmand[245]: src/technology.c:scan() technology 0x1cadba0 request from > :1.7 > connmand[245]: plugins/wifi.c:wifi_scan() device 0x1caa1c0 wifi > 0x1cac998 hidden ssid (null) > > Is this a driver bug for the wifi device? (ath9k_htc) or a > bug/limitation of connman? We're using the git version of connman at > this moment. Since hostapd and WiFi scanning was verified by you earlier in the mail, the WiFi device driver has the proper capabilities to perform both of the requested tasks at the same timne. It is thus wpa_supplicant that is the roadblock here. It apparently does not have the capabilities of scanning while in AP mode. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Connman behavior with marginally stabe wifi
Hello all, We have a an embedded linux device that contains wpa_supplicant 2.2 and connman 1.25 to handle ethernet and wifi connections. This device is typically setup once and then gets very little attention and is often even hard to reach. We however have problems with the wifi connection, especially when it is installed such that the wifi connection is marginally stable (and there is no ethernet connection) What we see is that when the connection is dropped (due to bad reception for example), connman tries to reconnect which can fail, in which case connman goes into the "failure" state with one of 2 errors: "connect-failed" or "invalid-key". My first question is if this is known behaviour that it can fail with both of these errors? I would only expect "connect-failed" when the passphrase is correct. What we also see is that connman does not try to reconnect, once it is in the failure state. I would say that this is not the behaviour you would want from an embedded device, as connman would need some "attention" to come out of the failure state and retry. When I look at my (android) phone, it retries to connect to my home WIFI for example, even when I am at the edge of the router range. I certainly never have to go into the WIFI menu because it is in some failure state. What is the reasoning behind this "failure" behaviour of connman and can it perhaps be adjusted via the configuration? Or is this typically solved in the controlling application on embedded devices and if this is the case, does anyone have some pointers and what and what not to do to get it going again without user interaction? Thanks in advance. Regards, Thiemo van Engelen ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Using connman to 'monitor' while tethering
Hey list, We are trying to use connan as our network manager on an embedded platform. So far we are quite happy and can control it via dbus rather well. One thing I have not been able to figure out yet however, if connman is able to do a wifi scan while it is also running as accesspoint. We did run some tests using hostapd and it seemed to work just fine, as hostapd created a monitor device in addition to the regular wlan device. I do see connman create a monitoring device, mon.wlan0, so scanning the wifi while being an accesspoint shouldn't be a problem? Bringing up an accesspoint via tether works well enough. connmanctl enable wifi connmanctl tether wifi on testssid testpassphrase Here the tether bridge, mon.wlan0 are all brought up. I suspect the mon.wlan0 device is related to the monitor command? Anyway, doing a scan wifi, the scan seems to wait for a bit, and then returns with the following: connmanctl scan wifi Error /net/connman/technology/wifi: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Running connmand in the foreground with debugging yields the following when starting the scan: connmand[245]: src/technology.c:scan() technology 0x1cadba0 request from :1.7 connmand[245]: plugins/wifi.c:wifi_scan() device 0x1caa1c0 wifi 0x1cac998 hidden ssid (null) Is this a driver bug for the wifi device? (ath9k_htc) or a bug/limitation of connman? We're using the git version of connman at this moment. One of the reasons this is an issue, is that connman 'forgets' all available services when run in tethering mode and also does not keep it up to date. Any thoughts and pointers are welcome, Olliver -- Met vriendelijke groeten, Kind regards, 与亲切的问候 Olliver Schinagl Research & Development Ultimaker B.V. http://www.ultimaker.com ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] gweb: Don't close socket descriptor handed over to GIOChannel
Otherwise the channel will close it again when being deallocated.
---
gweb/gweb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gweb/gweb.c b/gweb/gweb.c
index f6828cf..dcb0549 100644
--- a/gweb/gweb.c
+++ b/gweb/gweb.c
@@ -1075,7 +1075,8 @@ static int connect_session_transport(struct web_session
*session)
session->addr->ai_addrlen) < 0) {
if (errno != EINPROGRESS) {
debug(session->web, "connect() %s", strerror(errno));
- close(sk);
+ g_io_channel_unref(session->transport_channel);
+ session->transport_channel = NULL;
return -EIO;
}
}
--
1.8.3.2
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
