Re: Cannot connect to EAP (ieee8021x) without a .config file
Hi Filipe, But in this case, since there is no need of certificate, shouldn't connman be able to try to connect without it? I'm just saying it because when I try to connect to this network with an iPhone it connects without any certificate (it just ask if you want to accept a certificate) and with an Android it just connect without even asking to accept a certificate. It is true that Android (and iPhone) asks you these questions when you click on an 802.1x EAP network. Unfortunately they have to ask the use up front before proceeding with the connection attempt, since the WiFi network information from the Access Point does not contain any information about the used EAP protocol. Thus they are as lost as ConnMan what the EAP method of connecting to the network actually is. Asking the user happens before anything starts connecting. Android does that but not iPhone. iPhone just asks for the user/password, tries to connect and shows a certificate that the user needs to accept. Do you guess what they do? The main problem is that, as we know, users doesn't care about this certificates, eap protocols and so on. And if on iOS they are not asked those informations, they expect the same in other devices. Btw, what is this certificate for and why with connman and Android the user don't need to accept it? that last I have been told is that iOS on purpose does not check these certificates against the global trusted certificates. Simple because non of them are authorized for WiFi usage anyway. The only get trusted if you provide your own CA via device management. Also iOS is kinda stupid. They always show the username/password question for the 802.1x networks. Even if that would not work. There are networks that completely authorize by just using certificates. Since there is no certificate the user expects to connect directly. IMO it's ugly to some Agent (or external program) to write a .config file just so connman can recognize the service. Whether any certificates exist or not needs a user decision as much as the EAP method itself. Thus any UI trying to connect to an 802.1x EAP network must prompt the user, give the information to ConnMan and then connect. The current implementation in ConnMan is such that an EAP network needs to be described as a .config file. Maybe it's less implementation friendly to write a file with the needed information, but it shouldn't be a too big obstacle since the UI has already received all the needed (known) information from the user. Some times the Agent will not have rights to write in /var/lib/connman or whatever where connman is reading those files. The agent should never have access to /var/lib/connman ever. If you do that, then your security model is broken. But I agree that knowing this information is not a problem to write a .config file. Another point is the fact that the Agent doesn't know when it should ask those informations to the user. Perhaps by checking the service's security property is ieee8021x? I remember that there was a discussion here and Marcel Holtmann said that Agents shouldn't ask this kind of information to the user, that's why there is no API for that. But as we are discussing now we still need to ask that in case of EAP. So there is clearly an inconsistency here. I am totally fine if we ask username and password for 802.1x from the user, but nothing more. To do that, we need to first know if username and password would actually work in that case. Regards Marcel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: Cannot connect to EAP (ieee8021x) without a .config file
Hi, On Thu, 2012-11-22 at 12:37 -0800, Felipe Tonello wrote: Android does that but not iPhone. iPhone just asks for the user/password, tries to connect and shows a certificate that the user needs to accept. Do you guess what they do? The main problem is that, as we know, users doesn't care about this certificates, eap protocols and so on. And if on iOS they are not asked those informations, they expect the same in other devices. Btw, what is this certificate for and why with connman and Android the user don't need to accept it? I don't have an iPhone so I can't verify what it does. The user certificate is very often optional and the server certificates may be silently accepted in the background. If there is no possibility of selecting a client certificate, some of the EAP PEAP/TLS/TTLS/etc. WiFi networks will not be accessible. Since there is no certificate the user expects to connect directly. IMO it's ugly to some Agent (or external program) to write a .config file just so connman can recognize the service. Whether any certificates exist or not needs a user decision as much as the EAP method itself. Thus any UI trying to connect to an 802.1x EAP network must prompt the user, give the information to ConnMan and then connect. The current implementation in ConnMan is such that an EAP network needs to be described as a .config file. Maybe it's less implementation friendly to write a file with the needed information, but it shouldn't be a too big obstacle since the UI has already received all the needed (known) information from the user. Some times the Agent will not have rights to write in /var/lib/connman or whatever where connman is reading those files. But I agree that knowing this information is not a problem to write a .config file. Another point is the fact that the Agent doesn't know when it should ask those informations to the user. Perhaps by checking the service's security property is ieee8021x? That's exactly the point here. The WiFi security property only specifies EAP, not the authentication method used. The authentication method can be TLS, TTLS, PEAP, plain MSCHAP, PEAP with MSCHAP, GTC, password, etc. - not all of them implemented by ConnMan btw. The EAP method needs to be chosen by the user, at least on Android phones even more method specific options can or need to be filled in by the user depending on the WiFi network. Already the first question about the EAP method used needs to be asked from the user. iOS probably makes a shortcut here, tries by default with something and only then asks some further information (or not) if the initial guess failed. I remember that there was a discussion here and Marcel Holtmann said that Agents shouldn't ask this kind of information to the user, that's why there is no API for that. But as we are discussing now we still need to ask that in case of EAP. So there is clearly an inconsistency here. Interactively asking all this becomes very complex very fast, which is a reason why not to implement it via Agent API. As the user anyway needs to be asked up front for the EAP security method, the user can fill in the remaining bits an pieces at the same time, if there is such a UI component. Except that the user will have a really hard time answering any of the EAP related questions correctly, especially the ones with subtle usage of client certificates and other mysterious bits. Thus its _much_ better that the information comes provisioned as a .config file, especially when said client certs are needed - they can not be generated on the fly. What we're talking about here really goes way beyond the expectations of an Agent UI. All of this should belong to a provisioning component with or without a UI of some kind. Cheers, Patrik ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH v5 00/42] VPN re-design/factoring
On Mon, 2012-11-12 at 14:07 +0200, Jukka Rissanen wrote: Hi, This is v5 of the vpn refactoring patchset. This version fixes the routing issues found out by Patrik. v5: - The VPN tunnel endpoint address (peer) was not passed from vpnd to connmand. This affected patches 1 and 12 - The vpn server specific routes were not parsed and set. This affected patch 14 All patches applied, many thanks! Patrik ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH] ipconfig: Do not check device if interface name is not set
On Thu, 2012-11-22 at 15:02 +0200, Jukka Rissanen wrote: If the interface name is not set, then it is no use checking if the interface would be ignored. The interface name is not set if the interface is being taken down and we get NEWLINK message with NULL interface. Fixes BMC#25865 Applied, thanks! Patrik ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
[PATCH 2/2] openvpn-script: Removed extra empty line
---
scripts/openvpn-script.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/scripts/openvpn-script.c b/scripts/openvpn-script.c
index e359c31..f37eab2 100644
--- a/scripts/openvpn-script.c
+++ b/scripts/openvpn-script.c
@@ -43,7 +43,6 @@ static void print(const char *format, ...)
va_end(ap);
}
-
static void append(DBusMessageIter *dict, const char *pattern)
{
DBusMessageIter entry;
--
1.7.11.4
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
[PATCH 1/2] doc: Clarify UserRoutes and ServerRoutes documentation
As the UserRoutes is to be set by the user, then tell that
in the documentation.
Clarify also what the ServerRoutes mean.
---
Hi,
here are two patches for comments that Wagi had about
the vpnd.
Cheers,
Jukka
doc/vpn-connection-api.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/vpn-connection-api.txt b/doc/vpn-connection-api.txt
index 5fe39d3..9faed8a 100644
--- a/doc/vpn-connection-api.txt
+++ b/doc/vpn-connection-api.txt
@@ -116,7 +116,7 @@ Properties string State [readonly]
The list of nameservers set by VPN.
- array{dict} UserRoutes
+ array{dict} UserRoutes [readwrite]
int ProtocolFamily
@@ -157,7 +157,8 @@ Properties string State [readonly]
Gateway address of the route.
- The VPN server activated route.
+ The VPN server activated route. These routes
+ are pushed to connman by VPN server.
There can be other properties also but as the VPN
technologies are so different, they have different
--
1.7.11.4
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
[PATCH] provider: Set the state properly when removing provider
We need to set the provider into idle state when removing, otherwise the default route will not be set properly after provider removal. Fixes BMC#25658 --- src/provider.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/provider.c b/src/provider.c index fe7eb88..fa3bc48 100644 --- a/src/provider.c +++ b/src/provider.c @@ -197,6 +197,9 @@ int __connman_provider_remove(const char *path) provider_remove(provider); + connman_provider_set_state(provider, + CONNMAN_PROVIDER_STATE_IDLE); + g_hash_table_remove(provider_hash, provider-identifier); return 0; -- 1.7.11.4 ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
[PATCH 1/2] vpn: Remove unused variable
From: Daniel Wagner daniel.wag...@bmw-carit.de
---
plugins/vpn.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/plugins/vpn.c b/plugins/vpn.c
index b29dcc0..c7f59a9 100644
--- a/plugins/vpn.c
+++ b/plugins/vpn.c
@@ -454,7 +454,6 @@ static void connect_reply(DBusPendingCall *call, void
*user_data)
{
DBusMessage *reply;
DBusError error;
- struct connection_data *data;
struct config_create_data *cb_data = user_data;
if (dbus_pending_call_get_completed(call) == FALSE)
@@ -478,7 +477,6 @@ static void connect_reply(DBusPendingCall *call, void
*user_data)
ECONNREFUSED, NULL);
free_config_cb_data(cb_data);
}
- data-cb_data = NULL;
goto done;
}
dbus_error_free(error);
--
1.8.0.rc0
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
[PATCH 2/2] device: Include stdlib.h
From: Daniel Wagner daniel.wag...@bmw-carit.de gcc complains about missing definition for malloc. --- src/device.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/device.c b/src/device.c index 5325ed5..072646c 100644 --- a/src/device.c +++ b/src/device.c @@ -27,6 +27,7 @@ #include string.h #include unistd.h #include stdio.h +#include stdlib.h #include sys/ioctl.h #include net/ethernet.h #include net/if.h -- 1.8.0.rc0 ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH 2/2] device: Include stdlib.h
both patches pushed for the record, this was on f16 gcc 4.6.3 with --disable-optimization ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH 0/3] OpenVPN option enhancement
Hi Jukka, On 22.11.2012 13:05, Jukka Rissanen wrote: Hi, This patchset is related to this enhancement request: https://bugs.meego.com/show_bug.cgi?id=25866 The patchset is against connman-vpnd patchset that I sent earlier. Patch 1 removes obsolete --tls-client option that is automatically set by the --client option. There was discussion in the IRC channel that we could perhaps also remove the --nobind and --persist-key options as they might not be really needed. Removing them now might cause some regressions to the users if they rely those options be there by default, so I did not remove these two ones. If user has a OpenVPN config file, then that file and options in it are taken into use in patch 2. If the config file is used, then some optional default options are not set as they might conflict the settings in the config file. If the user needs these options, he can set them in config file. This is done in patch 3. Applied, thanks! daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH 2/2] openvpn-script: Removed extra empty line
both patches pushed. ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH] provider: Set the state properly when removing provider
On 23.11.2012 12:41, Jukka Rissanen wrote: We need to set the provider into idle state when removing, otherwise the default route will not be set properly after provider removal. Fixes BMC#25658 Applied and markes as fixed in bugzilla. thanks, daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH v4 00/18] Policy IVI Plugin (part 2)
Finally, I pushed this series. ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [PATCH 1/3] TODO: systemd no longer log twice to syslog
On 31.10.2012 10:05, Jukka Rissanen wrote: Fixed by 295cc8b57ce12257a9e90ea2e15e0d610e072e0a --- TODO | 10 -- 1 file changed, 10 deletions(-) TODO update pushed thanks, daniel ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
[PATCH] vpn: Do not access invalid hash table pointer
From: Daniel Wagner daniel.wag...@bmw-carit.de
The vpn deamon went down before create_configuration() was called.
connmand[20065]: src/provider.c:provider_destruct() provider 0x6b9fe0
connmand[20065]: plugins/vpn.c:remove_connection() path
/net/connman/vpn/connection/monom_org_monom_org
connmand[20065]: plugins/vpn.c:connection_destroy() data 0x6bc9d0
connmand[20065]: plugins/vpn.c:remove_connection_reply()
connmand[20065]: plugins/vpn.c:vpnd_removed() connection 0x6aa9e0
[...]
connmand[20065]: src/manager.c:connect_provider() conn 0x6aa9e0
connmand[20065]: src/provider.c:__connman_provider_create_and_connect() msg
0x6ad4b0
connmand[20065]: plugins/vpn.c:create_configuration() OpenVPN.Cert
/home/wagi/.config/openvpn/monom/cesium.crt
connmand[20065]: plugins/vpn.c:create_configuration() OpenVPN.Key
/home/wagi/.config/openvpn/monom/cesium.key
connmand[20065]: plugins/vpn.c:create_configuration() Host monom.org
connmand[20065]: plugins/vpn.c:create_configuration() Name MonoM VPN
connmand[20065]: plugins/vpn.c:create_configuration() OpenVPN.CACert
/home/wagi/.config/openvpn/monom/ca.crt
connmand[20065]: plugins/vpn.c:create_configuration() VPN.Domain monom.org
connmand[20065]: plugins/vpn.c:create_configuration() OpenVPN.RemoteCertTls
server
connmand[20065]: plugins/vpn.c:create_configuration() Type openvpn
connmand[20065]: plugins/vpn.c:create_configuration() OpenVPN.TLSRemote
/C=DE/ST=Bayern/L=Munich/O=monom/CN=cesium/emailAddress=r...@monom.org
connmand[20065]: plugins/vpn.c:create_configuration() VPN type openvpn name
MonoM VPN host monom.org domain monom.org networks (nil)
connmand[20065]: plugins/vpn.c:create_configuration() ident monom_org_monom_org
(gdb) bt
#0 0x003903e4eaa0 in g_log () from /lib64/libglib-2.0.so.0
#1 0x003903e37f29 in g_hash_table_lookup () from /lib64/libglib-2.0.so.0
#2 0x0043125d in create_configuration (msg=0x6ad4b0, callback=0x44a970
connection_ready) at plugins/vpn.c:1233
#3 0x0043c211 in connect_provider (conn=optimized out, msg=0x6ad4b0,
data=optimized out) at src/manager.c:237
#4 0x00410841 in process_message (connection=0x6aa9e0,
message=optimized out, iface_user_data=optimized out,
method=optimized out, method=optimized out) at gdbus/object.c:197
#5 0x00397161da45 in ?? () from /lib64/libdbus-1.so.3
#6 0x00397160fa83 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#7 0x0040ef08 in message_dispatch (data=0x6aa9e0) at
gdbus/mainloop.c:76
#8 0x003903e483bb in ?? () from /lib64/libglib-2.0.so.0
#9 0x003903e47825 in g_main_context_dispatch () from
/lib64/libglib-2.0.so.0
#10 0x003903e47b58 in ?? () from /lib64/libglib-2.0.so.0
#11 0x003903e47f52 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#12 0x0040e9f2 in main (argc=1, argv=0x7fffe568) at src/main.c:604
---
plugins/vpn.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/plugins/vpn.c b/plugins/vpn.c
index c7f59a9..c4733ed 100644
--- a/plugins/vpn.c
+++ b/plugins/vpn.c
@@ -1230,7 +1230,11 @@ static int create_configuration(DBusMessage *msg,
connection_ready_cb callback)
DBG(ident %s, ident);
- data = g_hash_table_lookup(vpn_connections, ident);
+ if (vpn_connections != NULL)
+ data = g_hash_table_lookup(vpn_connections, ident);
+ else
+ data = NULL;
+
if (data != NULL) {
if (data-call != NULL) {
connman_error(Dbus call already pending);
--
1.7.11.7
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
