Re: Security mechanisms in connman
Thank You. I'll read more about it. Best regards Lukasz W dniu 2015-04-28 o 13:26, Sven Schwedas pisze: On 2015-04-28 13:15, Lukasz Wojciechowski wrote: Thank You Sven I did see the dbus conf, but it allows only robust security configuration at the level of interfaces and already defined users. Take a look at dbus-daemon's documentation. It allows member-level configuration, not just interfaces, and can work with groups just as well as users. I would like to have more granularity and that is why I analyzed security plugins. Let me give an example: I would like to allow only some users to configure wifi. Users can be created at runtime of a system. I would have to change connman-dbus.conf every time a user is created, removed or I just want to limit his/her privileges. With polkit working I can change or add rules that can distinguish users and methods not only interfaces. I just wonder if anyone uses it or is interested in maintaining that mechanism or is it just a relict of the past. Best regards Lukasz W dniu 2015-04-28 o 13:02, Sven Schwedas pisze: On 2015-04-28 12:42, Lukasz Wojciechowski wrote: Hi I'm studying connman's code and I'm interested in limiting access to some API. I found that there is a mechanism for defining security plugins, that set GDBusSecurityTable by calling g_dbus_register_security(). There is only one such plugin implemented - polkit plugin. However IMO it seems to be dead. It registers polkit checks for privileges: CONNMAN_PRIVILEGE_MODIFY and CONNMAN_PRIVILEGE_SECRET, but all gdbus methods registered with GDBUS_*_METHOD macros do not set privilege field in GDBusMethodTable structure. Because of that security checks are never run, because method-privilege never equals security-privilege (check_privilege() function in gdbus/object.c). So I have few questions: * What am I missing? How this security works ? * Are there any plans for defining privileges for methods ? Connman uses DBus' bus policies to limit access, cf. http://git.kernel.org/cgit/network/connman/connman.git/tree/src/connman-dbus.conf and the respective file for connman-vpn. Distributions seem to tweak those to limit/grant access. No idea what the other code is for. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH v2] iptables: Keep the current counter values on changes
When new iptables are commited, the counters in the kernel are reset and
the values of the old tables are returned. By keeping track of the original
index of an iptable entry, the new table can be updated with the original
counter values.
When a policy of a builtin chain is changed, its counter value is reset.
When new rules are added, their counter is preset to 0.
---
v2: Fixes warnings when compiling for (64 bit) systems where __u64 is a
different type than uint64_t
src/iptables.c | 73 +++---
1 file changed, 60 insertions(+), 13 deletions(-)
diff --git a/src/iptables.c b/src/iptables.c
index 8d583ea..2602dfd 100644
--- a/src/iptables.c
+++ b/src/iptables.c
@@ -31,6 +31,7 @@
#include sys/errno.h
#include sys/socket.h
#include xtables.h
+#include inttypes.h
#include linux/netfilter_ipv4/ip_tables.h
@@ -154,6 +155,7 @@ struct error_target {
struct connman_iptables_entry {
int offset;
int builtin;
+ int counter_idx;
struct ipt_entry *entry;
};
@@ -251,8 +253,9 @@ static int print_entry(struct ipt_entry *entry, int
builtin, unsigned int hook,
{
iterate_entries_cb_t cb = user_data;
- DBG(entry %p hook %d offset %d size %d, entry, hook,
- offset, entry-next_offset);
+ DBG(entry %p hook %u offset %u size %u packets %PRIu64 bytes
%PRIu64,
+ entry, hook, offset, (unsigned int) entry-next_offset,
+ (uint64_t) entry-counters.pcnt, (uint64_t)
entry-counters.bcnt);
return cb(entry, builtin, hook, size, offset, NULL);
}
@@ -460,7 +463,7 @@ static void update_targets_reference(struct
connman_iptables *table,
static int iptables_add_entry(struct connman_iptables *table,
struct ipt_entry *entry, GList *before,
- int builtin)
+ int builtin, int counter_idx)
{
struct connman_iptables_entry *e, *entry_before;
@@ -473,6 +476,7 @@ static int iptables_add_entry(struct connman_iptables
*table,
e-entry = entry;
e-builtin = builtin;
+ e-counter_idx = counter_idx;
table-entries = g_list_insert_before(table-entries, before, e);
table-num_entries++;
@@ -620,7 +624,7 @@ static int iptables_add_chain(struct connman_iptables
*table,
error-t.u.user.target_size = ALIGN(sizeof(struct error_target));
g_stpcpy(error-error, name);
- if (iptables_add_entry(table, entry_head, last, -1) 0)
+ if (iptables_add_entry(table, entry_head, last, -1, -1) 0)
goto err_head;
/* tail entry */
@@ -638,7 +642,7 @@ static int iptables_add_chain(struct connman_iptables
*table,
ALIGN(sizeof(struct ipt_standard_target));
standard-verdict = XT_RETURN;
- if (iptables_add_entry(table, entry_return, last, -1) 0)
+ if (iptables_add_entry(table, entry_return, last, -1, -1) 0)
goto err;
return 0;
@@ -826,7 +830,7 @@ static int iptables_append_rule(struct connman_iptables
*table,
if (!new_entry)
return -EINVAL;
- ret = iptables_add_entry(table, new_entry, chain_tail-prev, builtin);
+ ret = iptables_add_entry(table, new_entry, chain_tail-prev, builtin,
-1);
if (ret 0)
g_free(new_entry);
@@ -857,7 +861,7 @@ static int iptables_insert_rule(struct connman_iptables
*table,
if (builtin == -1)
chain_head = chain_head-next;
- ret = iptables_add_entry(table, new_entry, chain_head, builtin);
+ ret = iptables_add_entry(table, new_entry, chain_head, builtin, -1);
if (ret 0)
g_free(new_entry);
@@ -1128,6 +1132,8 @@ static int iptables_change_policy(struct connman_iptables
*table,
target = ipt_get_target(entry-entry);
t = (struct xt_standard_target *)target;
+ if (t-verdict != verdict)
+ entry-counter_idx = -1;
t-verdict = verdict;
return 0;
@@ -1405,6 +1411,19 @@ static int iptables_replace(struct connman_iptables
*table,
return 0;
}
+static int iptables_add_counters(struct connman_iptables *table,
+ struct xt_counters_info *c)
+{
+ int err;
+
+ err = setsockopt(table-ipt_sock, IPPROTO_IP, IPT_SO_SET_ADD_COUNTERS,
c,
+ sizeof(*c) + sizeof(struct xt_counters) *
c-num_counters);
+ if (err 0)
+ return -errno;
+
+ return 0;
+}
+
static int add_entry(struct ipt_entry *entry, int builtin, unsigned int hook,
size_t size, unsigned offset, void *user_data)
{
@@ -1417,7 +1436,8 @@ static int add_entry(struct ipt_entry *entry, int
builtin, unsigned int hook,
memcpy(new_entry, entry, entry-next_offset);
- return iptables_add_entry(table, new_entry, NULL, builtin);
+
Re: [PATCH] wifi: disconnect if 4way-handshake fails while roaming.
On Tue, 2015-04-28 at 09:09 +0300, pasi.sjoh...@jolla.com wrote: From: Pasi Sjöholm pasi.sjoh...@jollamobile.com While wifi-state is G_SUPPLICANT_STATE_COMPLETED and gets changed into G_SUPPLICANT_STATE_4WAY_HANDSHAKE the connection is most probably roaming. However if for some reason the wifi-state changes into G_SUPPLICANT_STATE_DISCONNECTED after being G_SUPPLICANT_STATE_4WAY_HANDSHAKE the handle_4way_handshake_failure() is called from interface_state() it is required to check wifi-connected and force disconnect if true. If not the actual disconnection will be skipped unless retries FAVORITE_MAXIMUM_RETRIES and wifi-connected will be set as false. Later on this will cause state-machine deadlock between network.c and wifi.c as network.c will still think that the network is connected and after wifi.c thinks it's not. In short: wifi-state will change into G_SUPPLICANT_STATE_SCANNING- G_SUPPLICANT_STATE_ASSOCIATING and connman_network_set_associating(network, true); gets called. Now the network.c is in both associating and connected. Finally when wifi-state goes through G_SUPPLICANT_STATE_4WAY_HANDSHAKE - G_SUPPLICANT_STATE_COMPLETED the connman_network_set_connected(network, true); will be called but it will never call set_connected as it's already connected and service state will stay as associating until disconnected. And applied, thanks for fixing this corner(?) case. Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Security mechanisms in connman
On 2015-04-28 12:42, Lukasz Wojciechowski wrote: Hi I'm studying connman's code and I'm interested in limiting access to some API. I found that there is a mechanism for defining security plugins, that set GDBusSecurityTable by calling g_dbus_register_security(). There is only one such plugin implemented - polkit plugin. However IMO it seems to be dead. It registers polkit checks for privileges: CONNMAN_PRIVILEGE_MODIFY and CONNMAN_PRIVILEGE_SECRET, but all gdbus methods registered with GDBUS_*_METHOD macros do not set privilege field in GDBusMethodTable structure. Because of that security checks are never run, because method-privilege never equals security-privilege (check_privilege() function in gdbus/object.c). So I have few questions: * What am I missing? How this security works ? * Are there any plans for defining privileges for methods ? Connman uses DBus' bus policies to limit access, cf. http://git.kernel.org/cgit/network/connman/connman.git/tree/src/connman-dbus.conf and the respective file for connman-vpn. Distributions seem to tweak those to limit/grant access. No idea what the other code is for. -- Mit freundlichen Grüßen, / Best Regards, Sven Schwedas Systemadministrator TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167 http://software.tao.at signature.asc Description: OpenPGP digital signature ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
re-connecting to enterprise network
All, I successfully connect to an enterprise AP, then at some point change to a different AP, and finally attempt to switch back to the original enterprise AP. The connection seems to be remembering the identity and passphrase that I originally used to connect, as the agent isn't called to prompt for them. At this point the association phase fails, and the debugging output is clear that it is moving from association to failure. The message error I get back from dbus is GDBus.Error:net.connman.Error.Failed: Input/output error. If, at this time I try yet again to connect to the enterprise AP no previous values are remembered, and the agent again prompts me for the identity and passphrase, and the connection completes. It would seem as if the failed attempt did not send the proper identity and passphrase. Is it possible to tell exactly what is being passed on the association phase? Tom ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Security mechanisms in connman
Thank You Sven I did see the dbus conf, but it allows only robust security configuration at the level of interfaces and already defined users. I would like to have more granularity and that is why I analyzed security plugins. Let me give an example: I would like to allow only some users to configure wifi. Users can be created at runtime of a system. I would have to change connman-dbus.conf every time a user is created, removed or I just want to limit his/her privileges. With polkit working I can change or add rules that can distinguish users and methods not only interfaces. I just wonder if anyone uses it or is interested in maintaining that mechanism or is it just a relict of the past. Best regards Lukasz W dniu 2015-04-28 o 13:02, Sven Schwedas pisze: On 2015-04-28 12:42, Lukasz Wojciechowski wrote: Hi I'm studying connman's code and I'm interested in limiting access to some API. I found that there is a mechanism for defining security plugins, that set GDBusSecurityTable by calling g_dbus_register_security(). There is only one such plugin implemented - polkit plugin. However IMO it seems to be dead. It registers polkit checks for privileges: CONNMAN_PRIVILEGE_MODIFY and CONNMAN_PRIVILEGE_SECRET, but all gdbus methods registered with GDBUS_*_METHOD macros do not set privilege field in GDBusMethodTable structure. Because of that security checks are never run, because method-privilege never equals security-privilege (check_privilege() function in gdbus/object.c). So I have few questions: * What am I missing? How this security works ? * Are there any plans for defining privileges for methods ? Connman uses DBus' bus policies to limit access, cf. http://git.kernel.org/cgit/network/connman/connman.git/tree/src/connman-dbus.conf and the respective file for connman-vpn. Distributions seem to tweak those to limit/grant access. No idea what the other code is for. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] gsupplicant: add a callback after WPS start gets called
On Mon, 2015-04-27 at 11:30 +, Nakamura, Yusuke (ADITJ/SWG) wrote: When WPS is used to connect a network, connect_callback should get called. Before this change connect_callback was called only after non-WPS connection. If WPS is used repeatedly, refcount continues increasing because this callback is not called. This causes that a network is not released properly. Applied, thanks! Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] iptables: Keep the current counter values on changes
Hi, On Tue, 2015-04-21 at 11:30 +0200, Thiemo van Engelen wrote: When new iptables are commited, the counters in the kernel are reset and the values of the old tables are returned. By keeping track of the original index of an iptable entry, the new table can be updated with the original counter values. When a policy of a builtin chain is changed, its counter value is reset. When new rules are added, their counter is preset to 0. Something went a bit wrong in this patch. Compiling I get lots of: CC src/src_connmand-plugin.o In file included from src/connman.h:129:0, from src/iptables.c:38: src/iptables.c: In function ‘print_entry’: ./include/connman/log.h:76:16: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 8 has type ‘__u64’ [-Werror=format=] static struct connman_debug_desc __connman_debug_desc \ ^ src/iptables.c:256:2: note: in expansion of macro ‘DBG’ DBG(entry %p hook %u offset %u size %u packets %PRIu64 bytes %PRIu64, ^ ./include/connman/log.h:76:16: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 9 has type ‘__u64’ [-Werror=format=] static struct connman_debug_desc __connman_debug_desc \ ^ src/iptables.c:256:2: note: in expansion of macro ‘DBG’ DBG(entry %p hook %u offset %u size %u packets %PRIu64 bytes %PRIu64, ^ Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Security mechanisms in connman
On 2015-04-28 13:15, Lukasz Wojciechowski wrote: Thank You Sven I did see the dbus conf, but it allows only robust security configuration at the level of interfaces and already defined users. Take a look at dbus-daemon's documentation. It allows member-level configuration, not just interfaces, and can work with groups just as well as users. I would like to have more granularity and that is why I analyzed security plugins. Let me give an example: I would like to allow only some users to configure wifi. Users can be created at runtime of a system. I would have to change connman-dbus.conf every time a user is created, removed or I just want to limit his/her privileges. With polkit working I can change or add rules that can distinguish users and methods not only interfaces. I just wonder if anyone uses it or is interested in maintaining that mechanism or is it just a relict of the past. Best regards Lukasz W dniu 2015-04-28 o 13:02, Sven Schwedas pisze: On 2015-04-28 12:42, Lukasz Wojciechowski wrote: Hi I'm studying connman's code and I'm interested in limiting access to some API. I found that there is a mechanism for defining security plugins, that set GDBusSecurityTable by calling g_dbus_register_security(). There is only one such plugin implemented - polkit plugin. However IMO it seems to be dead. It registers polkit checks for privileges: CONNMAN_PRIVILEGE_MODIFY and CONNMAN_PRIVILEGE_SECRET, but all gdbus methods registered with GDBUS_*_METHOD macros do not set privilege field in GDBusMethodTable structure. Because of that security checks are never run, because method-privilege never equals security-privilege (check_privilege() function in gdbus/object.c). So I have few questions: * What am I missing? How this security works ? * Are there any plans for defining privileges for methods ? Connman uses DBus' bus policies to limit access, cf. http://git.kernel.org/cgit/network/connman/connman.git/tree/src/connman-dbus.conf and the respective file for connman-vpn. Distributions seem to tweak those to limit/grant access. No idea what the other code is for. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman -- Mit freundlichen Grüßen, / Best Regards, Sven Schwedas Systemadministrator TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167 http://software.tao.at signature.asc Description: OpenPGP digital signature ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: missing patch...
On Fri, 2015-04-24 at 23:47 +, Thomas Green wrote: There was a patch in service.c __connman_service_set_passphrase that would let a provisioned service that was 8021x let the agent prompt for the username and passphrase. Now, in revision 1.28 there is a check in __connman_service_set_identity that seems to restore the old undesired behavior, but this time while checking for the passphrase. There were additional fixes for PSK and 802.1x passphrase handling applied in 1.29, namely commits 346609214f05b3b4eb49a2b1b03844d94e9eb59d and 346609214f05b3b4eb49a2b1b03844d94e9eb59d. They might have been fixing the issue you are seeing. See also _connman_service_set_agent_identity(), it seems to be a mess with service-identity and service-agent_identity at the moment. I do wonder why there are two of these... If I am mis-reading the code, please let me know, but as of now, when I try to connect to an 8021x AP and expect the agent to prompt for the username and password it returns Error /net/connman/service/wifi_5c313e2c3958_70726976617465_managed_ieee8021x: Invalid arguments When I use connmanctl. Does this happen every time with 1.28? Does it work with 1.29? Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: How to Enable VPN support in Connman ?
Hi, On Fri, 2015-04-24 at 07:21 +, Lamsoge, Abhijit wrote: Hi All, I am fairly new to connman. I wanted to know the below two things. 1) How to I enable vpn support in connman from ./configure script ? - Because after compiling I do not see any vpn related binaries or objects and nothing is mentioned in docs currently available. It's built by default and called connman-vpnd in .the vpn/ directory. 2) How do I compile all the plug-ins as shared libs or .so ? - Nothing mentioned in README and HACKING docs. Compiling features as libraries did not make too much sense and was therefore removed as most of the plugins rely on run-time D-Bus discovery. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] inet: Remove unnecessary break statement
On Mon, 2015-04-27 at 16:21 +0530, Saurav Babu wrote: --- src/inet.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) Applied, thanks! Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] Disable 6to4 by default
On Sat, 2015-04-18 at 14:05 +0200, Tore Anderson wrote: The 6to4 protocol as deployed on the public internet has been shown to cause severe connectivity problems. RFC 6343 section 4.1 therefore recommends against host implementations enabling it by default. This patch implements that recommendation by introducing a new Enable6to4 configuration option, which defaults to false. Due to the operational problems described in RFC 6343 section 3, the IETF is about to deprecate the 6to4 protocol completely. This is done in the document draft-ietf-v6ops-6to4-to-historic which is currently in the RFC Editor's queue, pending final pulication as an RFC. Section 4 of this document reinforces and strengthens RFC 6343's current recommendation, mandating that hosts MUST disable 6to4 by default. And applied, thanks! Although it is sad to see 6to4 being retired, it must mean we're going in the right direction with the IPv6 adoption. Now if I only could convince my ISP to give me a prefix for free... Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Security mechanisms in connman
Hi I'm studying connman's code and I'm interested in limiting access to some API. I found that there is a mechanism for defining security plugins, that set GDBusSecurityTable by calling g_dbus_register_security(). There is only one such plugin implemented - polkit plugin. However IMO it seems to be dead. It registers polkit checks for privileges: CONNMAN_PRIVILEGE_MODIFY and CONNMAN_PRIVILEGE_SECRET, but all gdbus methods registered with GDBUS_*_METHOD macros do not set privilege field in GDBusMethodTable structure. Because of that security checks are never run, because method-privilege never equals security-privilege (check_privilege() function in gdbus/object.c). So I have few questions: * What am I missing? How this security works ? * Are there any plans for defining privileges for methods ? Best regards Lukasz Wojciechowski ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2] service: Clean up nameserver and search domain handling
On Sat, 2015-04-25 at 16:25 +0530, Saurav Babu wrote: +return connman_resolver_remove(index, nameserver, NULL); This one should also be changed to connman_resolver_remove(index, NULL, nameserver); After these changes nameservers are properly getting removed both from service structure and resolv.conf. Thanks for the modified patches and sorry for the late reply Thanks for the update on connman_resolver_remove()! Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH 0/4] Nameserver and search domain handling
On Wed, 2015-04-22 at 12:35 +0300, Patrik Flykt wrote: Hi, This patch set attempts to clean up nameserver handling in service.c. Applied all four patches, with v2 + the connman_resolver_remove() issue noticed by Saurav applied as 1/4. Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] wifi: disconnect if 4way-handshake fails while roaming.
From: Pasi Sjöholm pasi.sjoh...@jollamobile.com While wifi-state is G_SUPPLICANT_STATE_COMPLETED and gets changed into G_SUPPLICANT_STATE_4WAY_HANDSHAKE the connection is most probably roaming. However if for some reason the wifi-state changes into G_SUPPLICANT_STATE_DISCONNECTED after being G_SUPPLICANT_STATE_4WAY_HANDSHAKE the handle_4way_handshake_failure() is called from interface_state() it is required to check wifi-connected and force disconnect if true. If not the actual disconnection will be skipped unless retries FAVORITE_MAXIMUM_RETRIES and wifi-connected will be set as false. Later on this will cause state-machine deadlock between network.c and wifi.c as network.c will still think that the network is connected and after wifi.c thinks it's not. In short: wifi-state will change into G_SUPPLICANT_STATE_SCANNING- G_SUPPLICANT_STATE_ASSOCIATING and connman_network_set_associating(network, true); gets called. Now the network.c is in both associating and connected. Finally when wifi-state goes through G_SUPPLICANT_STATE_4WAY_HANDSHAKE - G_SUPPLICANT_STATE_COMPLETED the connman_network_set_connected(network, true); will be called but it will never call set_connected as it's already connected and service state will stay as associating until disconnected. --- plugins/wifi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/plugins/wifi.c b/plugins/wifi.c index 42dd407..2c4c2d6 100644 --- a/plugins/wifi.c +++ b/plugins/wifi.c @@ -2262,6 +2262,9 @@ static bool handle_4way_handshake_failure(GSupplicantInterface *interface, if (wifi-state != G_SUPPLICANT_STATE_4WAY_HANDSHAKE) return false; + if (wifi-connected) + return false; + service = connman_service_lookup_from_network(network); if (!service) return false; -- 2.1.0 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] device: Add configurable DontBringDownAtStartup list
On Mon, 2015-04-27 at 15:40 +0300, Slava Monich wrote: Particular for this patch, which issue was being fixed here? This resolves the conflict between developer mode (handled by usb-moded) and USB tethering (handled by connman) on Jolla phone. When phone boots up with USB connected, usb-moded handles it and turns on the developer mode. connman interferes with that by bringing interface down. If that happens, USB cable has to be physically reconnected to re-enable developer mode, which breaks automated testing and is generally inconvenient. I have really no idea why developer mode is any different from USB tethering. Get an IPv4 address via DHCP on the developer machine, whereafter it is immediately known that ConnMan is to be found on the same subnet as IPv4 address x.x.x.1. If one intends to have ConnMan dynamically ignore interface on the fly via main.conf, ConnMan needs to be restarted for the changes to take effect. This means the existing interface ignore setting can be used to handel developer mode, as a restart is anyway needed. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
