Re: [PATCH v2.1] agent-connman: Properly read SSID as byte array
On Thu, 2015-07-09 at 12:59 +0300, Patrik Flykt wrote: > On Thu, 2015-07-09 at 11:57 +0300, Patrik Flykt wrote: > > From: Adam Moore > > > > Properly access Agent provided SSID as an array of bytes and recurse > > where needed. > > > > [Patrik: Fixed patch] Applied. Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] connman.service: Fix systemd startup ordering
On Thu, 2015-07-09 at 09:26 +0300, Patrik Flykt wrote: > Start ConnMan after systemd dbus.service and network-pre.target, if > one exists. Reqeust network.target to be enabled by adding a Wants= > directive and ensure ConnMan is started before this target is reached. > > Reported by Simon Byrnard/OSMC. Fixes CM-683. Applied. Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2] agent-connman: read SSID as byte array
Apologies, Patrik - thanks for cleaning it up. The format-patch output I sent to git send-email didn¹t have those characters. I¹ll track down what went wrong before I send another patch. Revised patch looks good to me. Thanks! -Adam On 7/9/15, 1:46 AM, "connman on behalf of Patrik Flykt" wrote: >On Thu, 2015-07-09 at 10:29 +0300, Patrik Flykt wrote: >> On Tue, 2015-07-07 at 02:38 -0700, Adam Moore wrote: >> > Read Agent provided SSID as an array of bytes and recurse where needed >> >> Doesn't apply upstream, please rebase. > >Every line ends with a ^M... > >Cheers, > > Patrik > >___ >connman mailing list >connman@connman.net >https://lists.connman.net/mailman/listinfo/connman Statement of Confidentiality The contents of this e-mail message and any attachments are confidential and are intended solely for the addressee. The information may also be legally privileged. This transmission is sent in trust, and the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or at 508.683.2500 and delete this message and its attachments, if any. ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
On Thu, 2015-07-09 at 14:14 +0300, Jussi Kukkonen wrote: > those unhappy about the current situation always have the option to > patch. And presumably also read the source code to find out what exactly is happening in the first place. Usually the online check fails because pacrunner is not installed and therefore proxies cannot be used to reach the Internet. In that case nothing is transmitted. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] service: Add __connman_service_ipconfig_indicate_states function
On Thu, 2015-07-09 at 16:37 +0300, Slava Monich wrote: > Calling __connman_service_ipconfig_indicate_state for both IPv4 and IPv6 is > a fairly common pattern on connman. It makes sense to combine these two calls > into one function. NACK. Since __connman_service_ipconfig_indicate_state() is still needed it does not really help anybody to now have two exported functions that do the same. The other point is that it should be made obvious that IPv4 and IPv6 do work independently of each other and connectivity can be provided with either. Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH] service: Add __connman_service_ipconfig_indicate_states function
Calling __connman_service_ipconfig_indicate_state for both IPv4 and IPv6 is a fairly common pattern on connman. It makes sense to combine these two calls into one function. --- src/connman.h | 2 ++ src/network.c | 17 - src/service.c | 34 +++--- 3 files changed, 21 insertions(+), 32 deletions(-) diff --git a/src/connman.h b/src/connman.h index aac6a0b..c5a94c9 100644 --- a/src/connman.h +++ b/src/connman.h @@ -703,6 +703,8 @@ int __connman_service_online_check_failed(struct connman_service *service, int __connman_service_ipconfig_indicate_state(struct connman_service *service, enum connman_service_state new_state, enum connman_ipconfig_type type); +void __connman_service_ipconfig_indicate_states(struct connman_service *service, + enum connman_service_state new_state); enum connman_service_state __connman_service_ipconfig_get_state( struct connman_service *service, enum connman_ipconfig_type type); diff --git a/src/network.c b/src/network.c index badb770..cd66c4e 100644 --- a/src/network.c +++ b/src/network.c @@ -697,13 +697,8 @@ static void set_disconnected(struct connman_network *network) } } - __connman_service_ipconfig_indicate_state(service, - CONNMAN_SERVICE_STATE_IDLE, - CONNMAN_IPCONFIG_TYPE_IPV4); - - __connman_service_ipconfig_indicate_state(service, - CONNMAN_SERVICE_STATE_IDLE, - CONNMAN_IPCONFIG_TYPE_IPV6); + __connman_service_ipconfig_indicate_states(service, + CONNMAN_SERVICE_STATE_IDLE); network->connecting = false; network->connected = false; @@ -1214,12 +1209,8 @@ int connman_network_set_associating(struct connman_network *network, struct connman_service *service; service = connman_service_lookup_from_network(network); - __connman_service_ipconfig_indicate_state(service, - CONNMAN_SERVICE_STATE_ASSOCIATION, - CONNMAN_IPCONFIG_TYPE_IPV4); - __connman_service_ipconfig_indicate_state(service, - CONNMAN_SERVICE_STATE_ASSOCIATION, - CONNMAN_IPCONFIG_TYPE_IPV6); + __connman_service_ipconfig_indicate_states(service, + CONNMAN_SERVICE_STATE_ASSOCIATION); } return 0; diff --git a/src/service.c b/src/service.c index 2d8245e..00385ac 100644 --- a/src/service.c +++ b/src/service.c @@ -3927,12 +3927,8 @@ static gboolean connect_timeout(gpointer user_data) } else autoconnect = true; - __connman_service_ipconfig_indicate_state(service, - CONNMAN_SERVICE_STATE_FAILURE, - CONNMAN_IPCONFIG_TYPE_IPV4); - __connman_service_ipconfig_indicate_state(service, - CONNMAN_SERVICE_STATE_FAILURE, - CONNMAN_IPCONFIG_TYPE_IPV6); + __connman_service_ipconfig_indicate_states(service, + CONNMAN_SERVICE_STATE_FAILURE); if (autoconnect && service->connect_reason != @@ -5452,12 +5448,8 @@ int __connman_service_indicate_error(struct connman_service *service, set_error(service, error); - __connman_service_ipconfig_indicate_state(service, - CONNMAN_SERVICE_STATE_FAILURE, - CONNMAN_IPCONFIG_TYPE_IPV4); - __connman_service_ipconfig_indicate_state(service, - CONNMAN_SERVICE_STATE_FAILURE, - CONNMAN_IPCONFIG_TYPE_IPV6); + __connman_service_ipconfig_indicate_states(service, + CONNMAN_SERVICE_STATE_FAILURE); return 0; } @@ -5478,13 +5470,8 @@ int __connman_service_clear_error(struct connman_service *service) provider_pending = service->provider_pending; service->provider_pending = NULL; - __connman_service_ipconfig_indicate_state(service, - CONNMAN_SERVICE_STATE_IDLE, - CONNMAN_IPCONFIG_TYPE_IPV6); - - __connman_service_ipconfig_indicate_state(service, - CONNMAN_SERVICE_STATE_IDLE, -
Re: connman online test
On 9 July 2015 at 12:15, Marcel Holtmann wrote: > Hi Jussi, > Now that we're talking about the online check... I've talked to people who considered this behaviour "calling home" and thought it unreasonable that a) it's not possible to prevent the online check from happening via configuration and >>> >>> >>> Why would you prevent it to happen? This check is something extra anyway, >>> being "ready" means you are connected. In a way, people should not care too >>> much not seeing there service being set to "online", since such check can't >>> be bullet-proof. >> >> It's not about connman functionality at all. It's (as an example) >> about people building a super secret embedded product demo on top of >> Yocto suddenly realizing that their device is connecting to a web >> server they don't control or even know about (aka "who is this Marcel >> Holtmann why is our IOT Fridge fetching web pages from him?") > > if this super secret fridge is connected to the Internet and can actually > reach it, then it is no longer super secret. If you would be really worried, > then you would have it locked up in a lab with no access to anything. > > And even if it would be calling the ConnMan servers, nobody in the world > could tell super secret fridge apart from someone sitting next to it using > ConnMan on Yocto on a Minnowboard or its laptop. > > I can not repeat this enough. This whole think is designed with full > anonymity in mind. We are building our own HTTP request for exactly that > reason. No headers can sneak in. No unwanted meta data can leak. ConnMan > ships its own HTTP client for a reason. This is a good point, thanks. I don't expect everyone to be persuaded but I think adding a notice about the online check to Yocto documentation (mostly that it exists and that it is as anonymous as possible) should be good enough -- those unhappy about the current situation always have the option to patch. - Jussi > Think about this for a second. You can leak more information by using a > distro libcurl by accident that includes some meta headers. If ConnMan's > online check is your concern, then you do not understand privacy at all. > >> FWIW, I totally understand the point Patrik makes in the previous discussion: >>> If the URL is configurable, upstream >>> does not have the means to fix online related bug reports as we'd be >>> unable to confirm the online checking service to work properly in the >>> first place. In the worst case even the URL accessed is not known, not >>> even to the person submitting the bug report. >> >> This is a compelling argument as well -- I'm not in favor of making >> this too easy. I do think there are legitimate use cases where people >> do not want to rely on Marcel (or Intel) handling their online checks. >> >> Since the required patches are not big (as shown by Pasi, thanks!) >> just adding clear documentation to Yocto about the online check >> Connman makes and instructions on how to modify it may be a sufficient >> alternative. > > If someone wants to add documentation on what ConnMan is doing, then I am all > for it. More documentation is always good. I am in favor of full transparency. for what it's worth, I think the connman documentation on this is fine:I started the subthread because I've had several discussions where people were negatively surprised that this online check happened by default -- I think adding transparency within Yocto here is the key. > I am however not in favor of giving such an option. If someone wants to shoot > themselves into the foot, then they can pick up the gun by themselves. I do > not see a good reason why would make this easy. > > And honestly I prefer them carrying an extra patch changing the defines in > the source code. That means they have to carry that extra patch. So every > time it breaks, they get a nice reminder that something might have changed. > So they have a change in catching it. The config file is to easy to forget. > > Regards > > Marcel > > ___ > 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] service: Reset state to idle when disassociating service from the network.
On 09/07/15 13:03, Tomasz Bursztyka wrote: > Hi Slava, > >> It only does the job for the networks that have been connected: >> >> if (network->connected) >> set_disconnected(network); > > Why not adding there a test on > network->associating/network->connecting as well? > Because __connman_service_remove_from_network() is invoked from two places. Besides, most of what set_disconnected() is doing is irrelevant in case if the network hasn't been connected. Regards, -Slava > > Tomasz > ___ > 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] service: Reset state to idle when disassociating service from the network.
On Thu, 2015-07-09 at 12:37 +0300, Slava Monich wrote: > if (network->connected) > set_disconnected(network); > > This patch prevents services that are BEING connected from getting > stuck in the that state forever. I'd guess there is an obvious oneliner patch for the above line should that be the source of all evil. The testing of that one is the part taking time. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] service: Reset state to idle when disassociating service from the network.
Hi Slava, It only does the job for the networks that have been connected: if (network->connected) set_disconnected(network); Why not adding there a test on network->associating/network->connecting as well? Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2.1] agent-connman: Properly read SSID as byte array
On Thu, 2015-07-09 at 11:57 +0300, Patrik Flykt wrote: > From: Adam Moore > > Properly access Agent provided SSID as an array of bytes and recurse > where needed. > > [Patrik: Fixed patch] The point for mopping up this was to reduce the round trip time. An extra pair of eyes to verify that this patch is now as intended would not do any harm... Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
On to, 2015-07-09 at 11:15 +0200, Marcel Holtmann wrote: > Hi Jussi, > > >>> Now that we're talking about the online check... I've talked to people > >>> who considered this behaviour "calling home" and thought it > >>> unreasonable that > >>> a) it's not possible to prevent the online check from happening via > >>> configuration and > >> > >> > >> Why would you prevent it to happen? This check is something extra anyway, > >> being "ready" means you are connected. In a way, people should not care too > >> much not seeing there service being set to "online", since such check > >> can't > >> be bullet-proof. > > > > It's not about connman functionality at all. It's (as an example) > > about people building a super secret embedded product demo on top of > > Yocto suddenly realizing that their device is connecting to a web > > server they don't control or even know about (aka "who is this Marcel > > Holtmann why is our IOT Fridge fetching web pages from him?") > > if this super secret fridge is connected to the Internet and can actually > reach it, then it is no longer super secret. If you would be really worried, > then you would have it locked up in a lab with no access to anything. > > And even if it would be calling the ConnMan servers, nobody in the world > could tell super secret fridge apart from someone sitting next to it using > ConnMan on Yocto on a Minnowboard or its laptop. > > I can not repeat this enough. This whole think is designed with full > anonymity in mind. We are building our own HTTP request for exactly that > reason. No headers can sneak in. No unwanted meta data can leak. ConnMan > ships its own HTTP client for a reason. > > Think about this for a second. You can leak more information by using a > distro libcurl by accident that includes some meta headers. If ConnMan's > online check is your concern, then you do not understand privacy at all. > > > FWIW, I totally understand the point Patrik makes in the previous > > discussion: > >> If the URL is configurable, upstream > >> does not have the means to fix online related bug reports as we'd be > >> unable to confirm the online checking service to work properly in the > >> first place. In the worst case even the URL accessed is not known, not > >> even to the person submitting the bug report. > > > > This is a compelling argument as well -- I'm not in favor of making > > this too easy. I do think there are legitimate use cases where people > > do not want to rely on Marcel (or Intel) handling their online checks. > > > > Since the required patches are not big (as shown by Pasi, thanks!) > > just adding clear documentation to Yocto about the online check > > Connman makes and instructions on how to modify it may be a sufficient > > alternative. > > If someone wants to add documentation on what ConnMan is doing, then I am all > for it. More documentation is always good. I am in favor of full transparency. There is already documentation about online check in ConnMan README file. If that is not enough, then patches are welcome. > > I am however not in favor of giving such an option. If someone wants to shoot > themselves into the foot, then they can pick up the gun by themselves. I do > not see a good reason why would make this easy. > > And honestly I prefer them carrying an extra patch changing the defines in > the source code. That means they have to carry that extra patch. So every > time it breaks, they get a nice reminder that something might have changed. > So they have a change in catching it. The config file is to easy to forget. > > Regards > > Marcel Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] service: Reset state to idle when disassociating service from the network.
On 09/07/15 11:14, Patrik Flykt wrote: > On Wed, 2015-07-08 at 17:05 +0300, Slava Monich wrote: >> Otherwise, service may get stuck in the ASSOCIATION state forever and >> update_from_network() won't do anything because is_connecting() keeps >> returning true, making recovery impossible. > This is not the place to handle a stuck association. Calling > __connman_service_remove_from_network() is always due to a group > removal, causes no change to connectivity status except that the gateway > is removed. It's the set_disconnected() earlier in src/network.c, > network_remove() that is supposed to do the job. It only does the job for the networks that have been connected: if (network->connected) set_disconnected(network); This patch prevents services that are BEING connected from getting stuck in the that state forever. -Slava > Cheers, > > Patrik > >> --- >> src/service.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/src/service.c b/src/service.c >> index 2d8245e..bd150aa 100644 >> --- a/src/service.c >> +++ b/src/service.c >> @@ -6858,6 +6858,12 @@ void __connman_service_remove_from_network(struct >> connman_network *network) >> __connman_connection_gateway_remove(service, >> CONNMAN_IPCONFIG_TYPE_ALL); >> >> +__connman_service_ipconfig_indicate_state(service, >> +CONNMAN_SERVICE_STATE_IDLE, >> +CONNMAN_IPCONFIG_TYPE_IPV4); >> +__connman_service_ipconfig_indicate_state(service, >> +CONNMAN_SERVICE_STATE_IDLE, >> +CONNMAN_IPCONFIG_TYPE_IPV6); >> connman_service_unref(service); >> } >> > > ___ > 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: connman online test
Hi Jussi, >>> Now that we're talking about the online check... I've talked to people >>> who considered this behaviour "calling home" and thought it >>> unreasonable that >>> a) it's not possible to prevent the online check from happening via >>> configuration and >> >> >> Why would you prevent it to happen? This check is something extra anyway, >> being "ready" means you are connected. In a way, people should not care too >> much not seeing there service being set to "online", since such check can't >> be bullet-proof. > > It's not about connman functionality at all. It's (as an example) > about people building a super secret embedded product demo on top of > Yocto suddenly realizing that their device is connecting to a web > server they don't control or even know about (aka "who is this Marcel > Holtmann why is our IOT Fridge fetching web pages from him?") if this super secret fridge is connected to the Internet and can actually reach it, then it is no longer super secret. If you would be really worried, then you would have it locked up in a lab with no access to anything. And even if it would be calling the ConnMan servers, nobody in the world could tell super secret fridge apart from someone sitting next to it using ConnMan on Yocto on a Minnowboard or its laptop. I can not repeat this enough. This whole think is designed with full anonymity in mind. We are building our own HTTP request for exactly that reason. No headers can sneak in. No unwanted meta data can leak. ConnMan ships its own HTTP client for a reason. Think about this for a second. You can leak more information by using a distro libcurl by accident that includes some meta headers. If ConnMan's online check is your concern, then you do not understand privacy at all. > FWIW, I totally understand the point Patrik makes in the previous discussion: >> If the URL is configurable, upstream >> does not have the means to fix online related bug reports as we'd be >> unable to confirm the online checking service to work properly in the >> first place. In the worst case even the URL accessed is not known, not >> even to the person submitting the bug report. > > This is a compelling argument as well -- I'm not in favor of making > this too easy. I do think there are legitimate use cases where people > do not want to rely on Marcel (or Intel) handling their online checks. > > Since the required patches are not big (as shown by Pasi, thanks!) > just adding clear documentation to Yocto about the online check > Connman makes and instructions on how to modify it may be a sufficient > alternative. If someone wants to add documentation on what ConnMan is doing, then I am all for it. More documentation is always good. I am in favor of full transparency. I am however not in favor of giving such an option. If someone wants to shoot themselves into the foot, then they can pick up the gun by themselves. I do not see a good reason why would make this easy. And honestly I prefer them carrying an extra patch changing the defines in the source code. That means they have to carry that extra patch. So every time it breaks, they get a nice reminder that something might have changed. So they have a change in catching it. The config file is to easy to forget. Regards Marcel ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
Hi Jussi, > Now that we're talking about the online check... I've talked to people > who considered this behaviour "calling home" and thought it > unreasonable that > a) it's not possible to prevent the online check from happening via > configuration and an actual HTTP request is needed no matter what. That is how WISPr is specified. So that check happens and it needs to be in a way that we can tell if we are on a portal or not. If you actually have a better technical solution than calling a server that is specifically set up to do just that, let me know. Let me put it this way, there is actual software that really calls home and transmits tons of private data that nobody knows about. What do you think Android or iOS are doing for example. Or you Facebook or pick your favorite service that sends you notifications if you log in from a new machine or change the country. I think that kernel.org knows more about my location than the ConnMan servers. So everybody labeling this as "calling home" should really think hard about what they are talking about. The code we are using is open source. You can look into exactly what we are sending. The only extra meta information we are sending is the ConnMan version number. Nothing else. There is no machine id or any kind of information to associate this HTTP request with another one from the same source IP. And honestly the ConnMan version number gets only included so that in case of a broken brown-paper-bag release, we can stop that version from breaking the server. That is about it. The whole thing is designed to be as anonymous as possible. We put a lot of thought into this since the HTTP request for the online check is technically required. > b) it's not possible to set the checked URL in the configuration I would argue that any user of ConnMan who wants to change the URL is in the business of actually calling home and tracking you. If everybody uses the same service then it is fully anonymous since nobody can tell you apart from the other ConnMan on your network. If we start fragmenting, then this looses its anonymous status where everybody is equal. Also I have no intention to debug faulty online checks from servers that run badly or are not returning the correct HTTP headers to allow us clear identification of the status. Think about what happens if we add a new header on the server that newer versions of ConnMan use. Everybody hacking in a different URL is on their own to deal with that change. > Would you guys be willing to change the above (or at least willing to > take patches)? As outlined above, there are reasons why things the way they are. We have good reasons for it. So unless someone really comes with a good argument, I do not think we need changes here. Regards Marcel ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
[PATCH v2.1] agent-connman: Properly read SSID as byte array
From: Adam Moore
Properly access Agent provided SSID as an array of bytes and recurse
where needed.
[Patrik: Fixed patch]
---
src/agent-connman.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/agent-connman.c b/src/agent-connman.c
index 8440451..2d714b5 100644
--- a/src/agent-connman.c
+++ b/src/agent-connman.c
@@ -140,18 +140,21 @@ static void request_input_passphrase_reply(DBusMessage
*reply, void *user_data)
dbus_message_iter_get_basic(&value, &name);
name_len = strlen(name);
} else if (g_str_equal(key, "SSID")) {
+ DBusMessageIter array_iter;
+
dbus_message_iter_next(&entry);
if (dbus_message_iter_get_arg_type(&entry)
!= DBUS_TYPE_VARIANT)
break;
dbus_message_iter_recurse(&entry, &value);
if (dbus_message_iter_get_arg_type(&value)
- != DBUS_TYPE_VARIANT)
+ != DBUS_TYPE_ARRAY)
break;
- if (dbus_message_iter_get_element_type(&value)
- != DBUS_TYPE_VARIANT)
+ dbus_message_iter_recurse(&value, &array_iter);
+ if (dbus_message_iter_get_arg_type(&array_iter)
+ != DBUS_TYPE_BYTE)
break;
- dbus_message_iter_get_fixed_array(&value, &name,
+ dbus_message_iter_get_fixed_array(&array_iter, &name,
&name_len);
}
dbus_message_iter_next(&dict);
--
2.1.4
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2] agent-connman: read SSID as byte array
On Thu, 2015-07-09 at 10:29 +0300, Patrik Flykt wrote: > On Tue, 2015-07-07 at 02:38 -0700, Adam Moore wrote: > > Read Agent provided SSID as an array of bytes and recurse where needed > > Doesn't apply upstream, please rebase. Every line ends with a ^M... Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
On 9 July 2015 at 11:25, Tomasz Bursztyka wrote: > Hi Jussi, >> >> Hi, >> >> Now that we're talking about the online check... I've talked to people >> who considered this behaviour "calling home" and thought it >> unreasonable that >>a) it's not possible to prevent the online check from happening via >> configuration and > > > Why would you prevent it to happen? This check is something extra anyway, > being "ready" means you are connected. In a way, people should not care too > much not seeing there service being set to "online", since such check can't > be bullet-proof. It's not about connman functionality at all. It's (as an example) about people building a super secret embedded product demo on top of Yocto suddenly realizing that their device is connecting to a web server they don't control or even know about (aka "who is this Marcel Holtmann why is our IOT Fridge fetching web pages from him?") FWIW, I totally understand the point Patrik makes in the previous discussion: > If the URL is configurable, upstream > does not have the means to fix online related bug reports as we'd be > unable to confirm the online checking service to work properly in the > first place. In the worst case even the URL accessed is not known, not > even to the person submitting the bug report. This is a compelling argument as well -- I'm not in favor of making this too easy. I do think there are legitimate use cases where people do not want to rely on Marcel (or Intel) handling their online checks. Since the required patches are not big (as shown by Pasi, thanks!) just adding clear documentation to Yocto about the online check Connman makes and instructions on how to modify it may be a sufficient alternative. - Jussi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
On Thu, 2015-07-09 at 11:17 +0300, Pasi Sjöholm wrote:
> https://lists.connman.net/pipermail/connman/2014-April/017033.html
> https://lists.connman.net/pipermail/connman/2014-April/017034.html
The problem here is that nobody will know how good the connectivity to
any of these user defined server will be. This is especially true for
IPv6.
So what is exactly supposed to happen to bug reports concerning online
state with a user defined server? Ignore them? Use wall-clock time to
figure out that the user indeed changed the service although not
noticing it himself? And this is not just for noticing online, it also
detects captive portals on the way.
With {ipv4,ipv6}.connman.net it's always at least upstream's fault when
it doesn't work and can be fixed.
> > people who considered this behaviour "calling home"
Perhaps even showing the code here doesn't even help.
Cheers,
Patrik
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
Hi Jussi, Hi, Now that we're talking about the online check... I've talked to people who considered this behaviour "calling home" and thought it unreasonable that a) it's not possible to prevent the online check from happening via configuration and Why would you prevent it to happen? This check is something extra anyway, being "ready" means you are connected. In a way, people should not care too much not seeing there service being set to "online", since such check can't be bullet-proof. b) it's not possible to set the checked URL in the configuration Passi from Jolla already sent a patch last year: https://lists.connman.net/pipermail/connman/2014-April/017033.html Cheers, Tomasz ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
Hi, we (Jolla) did something like that earlier: https://lists.connman.net/pipermail/connman/2014-April/017033.html https://lists.connman.net/pipermail/connman/2014-April/017034.html I'm willing to rebase the patch if upstream wants to get it merged. Br, Pasi On 09.07.2015 11:05, Jussi Kukkonen wrote: > Hi, > > Now that we're talking about the online check... I've talked to > people who considered this behaviour "calling home" and thought it > unreasonable that a) it's not possible to prevent the online check > from happening via configuration and b) it's not possible to set > the checked URL in the configuration > > Would you guys be willing to change the above (or at least willing > to take patches)? > > - Jussi ___ 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] service: Reset state to idle when disassociating service from the network.
On Wed, 2015-07-08 at 17:05 +0300, Slava Monich wrote: > Otherwise, service may get stuck in the ASSOCIATION state forever and > update_from_network() won't do anything because is_connecting() keeps > returning true, making recovery impossible. This is not the place to handle a stuck association. Calling __connman_service_remove_from_network() is always due to a group removal, causes no change to connectivity status except that the gateway is removed. It's the set_disconnected() earlier in src/network.c, network_remove() that is supposed to do the job. Cheers, Patrik > --- > src/service.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/src/service.c b/src/service.c > index 2d8245e..bd150aa 100644 > --- a/src/service.c > +++ b/src/service.c > @@ -6858,6 +6858,12 @@ void __connman_service_remove_from_network(struct > connman_network *network) > __connman_connection_gateway_remove(service, > CONNMAN_IPCONFIG_TYPE_ALL); > > + __connman_service_ipconfig_indicate_state(service, > + CONNMAN_SERVICE_STATE_IDLE, > + CONNMAN_IPCONFIG_TYPE_IPV4); > + __connman_service_ipconfig_indicate_state(service, > + CONNMAN_SERVICE_STATE_IDLE, > + CONNMAN_IPCONFIG_TYPE_IPV6); > connman_service_unref(service); > } > ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: connman online test
Hi, Now that we're talking about the online check... I've talked to people who considered this behaviour "calling home" and thought it unreasonable that a) it's not possible to prevent the online check from happening via configuration and b) it's not possible to set the checked URL in the configuration Would you guys be willing to change the above (or at least willing to take patches)? - Jussi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2] agent-connman: read SSID as byte array
On Tue, 2015-07-07 at 02:38 -0700, Adam Moore wrote:
> Read Agent provided SSID as an array of bytes and recurse where needed
Doesn't apply upstream, please rebase.
Cheers,
Patrik
> ---
> src/agent-connman.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/src/agent-connman.c b/src/agent-connman.c
> index 8440451..1b6f8a3 100644
> --- a/src/agent-connman.c
> +++ b/src/agent-connman.c
> @@ -141,17 +141,20 @@ static void request_input_passphrase_reply(DBusMessage
> *reply, void *user_data)
> name_len = strlen(name);
> } else if (g_str_equal(key, "SSID")) {
> dbus_message_iter_next(&entry);
> + DBusMessageIter *array_iter = NULL;
> if (dbus_message_iter_get_arg_type(&entry)
> != DBUS_TYPE_VARIANT)
> break;
> dbus_message_iter_recurse(&entry, &value);
> if (dbus_message_iter_get_arg_type(&value)
> - != DBUS_TYPE_VARIANT)
> + != DBUS_TYPE_ARRAY)
> break;
> - if (dbus_message_iter_get_element_type(&value)
> - != DBUS_TYPE_VARIANT)
> +
> + dbus_message_iter_recurse(&value, &array_iter);
> + if (dbus_message_iter_get_arg_type(&array_iter)
> + != DBUS_TYPE_BYTE)
> break;
> - dbus_message_iter_get_fixed_array(&value, &name,
> + dbus_message_iter_get_fixed_array(&array_iter, &name,
> &name_len);
> }
> dbus_message_iter_next(&dict);
> --
> 1.9.1
>
>
> Statement of Confidentiality
>
> The contents of this e-mail message and any attachments are confidential and
> are intended solely for the addressee. The information may also be legally
> privileged. This transmission is sent in trust, and the sole purpose of
> delivery to the intended recipient. If you have received this transmission in
> error, any use, reproduction or dissemination of this transmission is
> strictly prohibited. If you are not the intended recipient, please
> immediately notify the sender by reply e-mail or at 508.683.2500 and delete
> this message and its attachments, if any.
>
> ___
> 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
