[PATCH] manager: Do not recurse one more level for upnp basic type
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.
---
src/manager.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/manager.c b/src/manager.c
index e97921b..17fd7ee 100644
--- a/src/manager.c
+++ b/src/manager.c
@@ -399,19 +399,20 @@ static int parse_peers_service_specs(DBusMessageIter
*array,
dbus_message_iter_next(&entry);
dbus_message_iter_recurse(&entry, &inter);
- dbus_message_iter_recurse(&inter, &value);
if (!g_strcmp0(key, "BonjourResponse")) {
+ dbus_message_iter_recurse(&inter, &value);
dbus_message_iter_get_fixed_array(&value,
spec, spec_len);
} else if (!g_strcmp0(key, "BonjourQuery")) {
+ dbus_message_iter_recurse(&inter, &value);
dbus_message_iter_get_fixed_array(&value,
query, query_len);
} else if (!g_strcmp0(key, "UpnpService")) {
- dbus_message_iter_get_basic(&value, spec);
+ dbus_message_iter_get_basic(&inter, spec);
*spec_len = strlen((const char *)*spec)+1;
} else if (!g_strcmp0(key, "UpnpVersion")) {
- dbus_message_iter_get_basic(&value, version);
+ dbus_message_iter_get_basic(&inter, version);
} else
return -EINVAL;
--
1.9.1
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
[RFC/PATCH] gsupplicant: Configure p2p device with WPS PBC method only
Thus incoming connection will not try to use WPS PIN method. This
enforces connman to support only WPS PBC on incoming connection.
---
Let's wait for wpa_supplicant's patch:
"[PATCH] dbus: Add a device configuration entry to set the P2P WPS methods"
to be accepted first before applying this one.
gsupplicant/supplicant.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index fd16caf..83d4c1c 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -3203,12 +3203,15 @@ static void p2p_device_config_result(const char *error,
static void p2p_device_config_params(DBusMessageIter *iter, void *user_data)
{
struct supplicant_p2p_dev_config *config = user_data;
+ const char *methods = "push_button";
DBusMessageIter dict;
supplicant_dbus_dict_open(iter, &dict);
supplicant_dbus_dict_append_basic(&dict, "DeviceName",
DBUS_TYPE_STRING, &config->device_name);
+ supplicant_dbus_dict_append_basic(&dict, "ConfigMethods",
+ DBUS_TYPE_STRING, &methods);
supplicant_dbus_dict_close(iter, &dict);
}
--
1.8.5.5
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: timeservers get used up
Hi, On Mon, 2014-09-15 at 17:41 +0200, Peter Meerwald wrote: > Hello Patrik, > > connman builds up available timeservers and keeps them in a list, each > timeservers is tried and used in turn > > if a timeserver fails (not resolvable, not in sync, kiss-of-death), > current timeserver is REMOVED from the list and next one in the list is > used > > is this the intended behaviour? So far yes. Every 2h ConnMan wakes up and compares the existing timeserver list against a freshly created one. If the first element of the current and the fresh timeserver lists differ, the timeserver resolution is restarted using the fresh list. This way more preferred timeservers are retried every once in a while should they have been removed due to connectivity problems. And of course if the connection is changed, the timeserver list is reset. See commit 3b70a3d5a93fb229c2caacf6b2df43dd9ea5b6bd for details. > cycling through the timeserver list is a good idea, but why removing them? > after a temporary network outage, a connection may recover but looses all > its timeservers The problem here is to know when to stop and not keep on cycling through the list banging on timeservers that are not answering. At the same time more preferred ones should be used over the global ones. Perhaps a modification could be made so that if the list gets exhausted, the set of timeservers is retried in something like 5-10 mins? Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: timeservers get used up
Hello Patrik, > > connman builds up available timeservers and keeps them in a list, each > > timeservers is tried and used in turn > > > > if a timeserver fails (not resolvable, not in sync, kiss-of-death), > > current timeserver is REMOVED from the list and next one in the list is > > used > > > > is this the intended behaviour? > > So far yes. Every 2h ConnMan wakes up and compares the existing > timeserver list against a freshly created one. If the first element of > the current and the fresh timeserver lists differ, the timeserver > resolution is restarted using the fresh list. This way more preferred > timeservers are retried every once in a while should they have been > removed due to connectivity problems. And of course if the connection is > changed, the timeserver list is reset. See commit > 3b70a3d5a93fb229c2caacf6b2df43dd9ea5b6bd for details. > > > cycling through the timeserver list is a good idea, but why removing them? > > after a temporary network outage, a connection may recover but looses all > > its timeservers > > The problem here is to know when to stop and not keep on cycling through > the list banging on timeservers that are not answering. At the same time > more preferred ones should be used over the global ones. > > Perhaps a modification could be made so that if the list gets exhausted, > the set of timeservers is retried in something like 5-10 mins? sounds like a good idea; thanks for the explanation! thanks, p. -- Peter Meerwald +43-664-218 (mobile) ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
