Re: [PATCH v2] openvpn: Add MTU related options
On 2015-10-21 12:30, Daniel Wagner wrote: > On 10/21/2015 12:25 PM, Patrik Flykt wrote: >> On Wed, 2015-10-21 at 12:12 +0200, Daniel Wagner wrote: >> >>> The use of the different MTU options depend on you server and link >>> configuration. I don't think you can derive it. OpenVPN seems to offer >>> an option to learn the MTU size by doing some measurements but that >>> takes around 3 minutes according documentation. I recommend to just >>> expose those options and let the user decide what he needs. >> >> Well, now the problem is that I have no idea what to add as MTU values >> if I need to... Sven's "documented" problem and solution was to use >> --tun-mtu, if that is the max sized packet that can go through >> unfragmented it looks like the only option one should specify. And >> --fragment seems to be needed always in addition to any of the MTUs? >> Unless it's the default behavior? > > I don't know if there is a sane MTU configuration setting for OpenVPN. I > reread the documentation several times and it seems you need to pick the > options according your configuration. Yeah. Those values are left alone for the large majority of deployments and I've only seen them used to deal with wonky carriers in WWAN deployments. Personally, I'd be fine with using the OpenVPN.ConfigFile parameter for the few cases I end up needing it. (And I'm not even sure whether we're going to migrate to 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: [PATCH v2] openvpn: Add MTU related options
On 2015-10-21 12:52, Daniel Wagner wrote: > On 10/21/2015 12:45 PM, Sven Schwedas wrote: >> On 2015-10-21 12:30, Daniel Wagner wrote: >>> On 10/21/2015 12:25 PM, Patrik Flykt wrote: >>>> On Wed, 2015-10-21 at 12:12 +0200, Daniel Wagner wrote: >>>> >>>>> The use of the different MTU options depend on you server and link >>>>> configuration. I don't think you can derive it. OpenVPN seems to offer >>>>> an option to learn the MTU size by doing some measurements but that >>>>> takes around 3 minutes according documentation. I recommend to just >>>>> expose those options and let the user decide what he needs. >>>> >>>> Well, now the problem is that I have no idea what to add as MTU values >>>> if I need to... Sven's "documented" problem and solution was to use >>>> --tun-mtu, if that is the max sized packet that can go through >>>> unfragmented it looks like the only option one should specify. And >>>> --fragment seems to be needed always in addition to any of the MTUs? >>>> Unless it's the default behavior? >>> >>> I don't know if there is a sane MTU configuration setting for OpenVPN. I >>> reread the documentation several times and it seems you need to pick the >>> options according your configuration. >> >> Yeah. Those values are left alone for the large majority of deployments >> and I've only seen them used to deal with wonky carriers in WWAN >> deployments. >> >> Personally, I'd be fine with using the OpenVPN.ConfigFile parameter for >> the few cases I end up needing it. (And I'm not even sure whether we're >> going to migrate to connman.) > > Good point. I completely forgot about ConfigFile. So > > OpenVPN.MTU > > should map to > > --tun-mtu --fragment > > ? I'll admit I don't understand OpenVPN enough to answer that. I know that we're not specifying it, I was under the impression that the Kernel network stack fragments itself with tun-mtu set, and that --fragment was to bypass that for… reasons. IMO one more reason to leave it out of the connman plugin and defer that to the config file, lest people start tinkering with it without needing to. -- 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 ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH v2] openvpn: Add MTU related options
On 2015-10-20 14:04, Patrik Flykt wrote: > Are any of these necessary for any use cases? If they are needed for > something, could the currently specified OpenVPN.MTU be used to derive > proper MTUs for the devices involved? They are necessary for some mobile carriers. We're fixing the tun MTU to 576 so OpenVPN doesn't die on (I think) Vodafone Germany's networks. (Though not yet with Connman, it's legacy deployments with NetworkManager/manual OpenVPN, and some special industrial modems from Vodafone. I can't say just how widespread the issue is otherwise.) -- 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: [PATCH v2] openvpn: Add MTU related options
Hi, On 2015-10-20 14:45, Patrik Flykt wrote: > > Hi, > > On Tue, 2015-10-20 at 14:26 +0200, Sven Schwedas wrote: >> On 2015-10-20 14:04, Patrik Flykt wrote: >>> Are any of these necessary for any use cases? If they are needed for >>> something, could the currently specified OpenVPN.MTU be used to derive >>> proper MTUs for the devices involved? >> >> They are necessary for some mobile carriers. We're fixing the tun MTU to >> 576 so OpenVPN doesn't die on (I think) Vodafone Germany's networks. > > Which of the mtu, fragment and/or mssfix options do you end up using and > with what value? We only change the tun-mtu value, none of the others. It seems to be recommended to change the others too, but it fixed the problems for us, and I didn't want to experiment more at the time. Presumably connman would need to support all? > >> (Though not yet with Connman, it's legacy deployments with >> NetworkManager/manual OpenVPN, and some special industrial modems from >> Vodafone. I can't say just how widespread the issue is otherwise.) > > Cheers, > > Patrik > > ___ > 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: Why do we really need Agent in ConnmanCtl ?
On 2015-09-08 13:33, Peter Meerwald wrote: > Hello Abhijit, > >> Just wanted some information on, why there is a need to have agent in >> between connmanctl and connman. >> For prompting input for user, but why can't we feed the connman directly >> with inputs like "passphrase" etc. ? > > the concept is called provisioning in connman's terms, see > doc/config-format.txt: you can pre-configure a passphrase for a given SSID > for example Is there a reason why "agent on" is not enabled by default in connmanctl, though? I can see why other front-ends will need their own agents, but -ctl is only used standalone, is it not? -- 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: DHCP timers
On 2015-06-22 14:46, Patrik Flykt wrote: On Fri, 2015-06-19 at 19:22 -0700, Naveen Singh wrote: I realized that timers used in dhcp plugin use monotonic timers which does not progress during suspend duration of device. Because of this the devices which are sleepy in nature never get to renew IP address and causes lot of communication failures. This affects all timers set by ConnMan, so a generic fix would be of interest. Hasn't this been implemented in some version of glib already? GLib's monotonic timer is documented as It may or may not continue to tick during times where the machine is suspended. On Linux and BSDs it uses bare clock_gettime(CLOCK_MONOTONIC), which isn't suspend aware in Linux (CLOCK_BOOTTIME is supposed to be used as drop-in replacement for such cases), but seems to be on at least OpenBSD. I have an implementation which in stead of using CLOCK_MONOTONIC uses CLOCK_BOOTTIME_ALARM. This implementation is based on creating a timer fd and hooking that fd to a GSource which in turn is attached to GMainLoop. Is community open in accepting a patch for this? If yes I could send the patch for review? I'd definitely want this kind of thing being fixed in glib. How ugly/intrusive is your patch? Cheers, Patrik ___ 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: 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: 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: [PATCH 1/3] Do not assume the gateway is also a NTP server
Do you really want to special-case every single broken network setup under the sun? (And does any networking client apart from connman support this? I think the usual suspects in corporate networks – namely Windows and maybe RHEL with NetworkManager – don't.) On 2015-03-24 04:38, Marcel Holtmann wrote: Hi Tore, But if the gateway does is unable to provide you internet connectivity, the chances of it being able to provide a usable NTP service is pretty much next to nil anyway. not in a corporate environment where you might have a central DHCP, but you might to use the NTP server closest to you. Note that my patches does not preclude the DHCP server from advertising the gateway (or any other node) as an NTP server. If it does, then the FallbackTimeservers doesn't come into play, the advertised NTP server(s) will be what connman ends up using no matter what. Falling back to the gateway as NTP server is when the DHCP server does not provide any NTP servers. As stated above, there are corporate enterprise networks where this make total sense. Hi Marcel, Okay, I admit it is possible to intentionally build a corporate network where it would be beneficial to treat DHCP option 3 essentially as an additional option 42 (I was thinking mostly about broken residental gateways when writing my previous issue). That said, I am really at a loss as to why someone would actually want to do so... First: Why exactly wouldn't the administrator of the DHCP server in question use option 42 to advertise the NTP server address to the clients (which of course could be the exactly same address as the default router address he advertises in option 3)? that is pretty simple. The DHCP server are centrally managed. However they do not want NTP going through the whole network. So it should terminate at the gateway. I have seen this kind of networks. So they exist and we have used ConnMan in these networks. Second: If you're an administrator of a corporate DHCP server and want your clients to use the default gateway as the NTP server, there's no way around using option 42 anyway - because, to the best of my knowledge, connman is the only connection manager / OS to blindly assume that any default router will also provide NTP service. Forgot what an administrator might thing. This is a reality and so get on board with it. Third: If you're an administrator of a corporate DHCP server and you *do* use option 42 to make your client use some other NTP server (i.e., not the default router), you certainly do *not* want connman to second-guess that and blindly add the router as an NTP server anyway. This is what I noticed happening in my network, and what prompted me to submit an issues/send patches. This one sounds like a bug in ConnMan. Worth while fixing. I could of course improve this third issue by making connman not add the default router as an NTP server if option 42 was received. However IMHO that would only make the behaviour less wrong, it would certainly not be right. The bottom line is that the NTP service and default router addresses are two completely independent things that should not be confused, just like you shouldn't confuse the addresses of the DNS service, DHCP service, or any of the other 100+ different things it is possible to advertise in DHCP. If the DHCP provides you an option 42, then second guessing that is wrong. In that case only the FallbackTimeservers should be allowed to do an overwrite. While it is certainly possible to build networks where multiple services are provided by the same node (and there's nothing wrong with doing so), you cannot assume that this is going to be true in the general case or even in a majority of cases. We can argue this for a long time. However I am not breaking existing behavior. As I said before, you can have a main.conf option to just disable it in your installations. Regards Marcel ___ 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
How does connman handle scan_ssid?
Cf. http://blog.viraptor.info/post/your-wifi-shows-me-where-you-live-work-and-travel How does connman handle this? There don't seem to be configuration options for it. -- 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: How does connman handle scan_ssid?
On 2015-03-17 12:09, Tomasz Bursztyka wrote: Hi Sven, ConnMan does a known networks scan, so indeed it leaks the known SSIDs. We could easily add a main.conf parameter to prevent that. Sounds good. What would be the trade-offs? More time needed to authenticate? Tomasz Cf. http://blog.viraptor.info/post/your-wifi-shows-me-where-you-live-work-and-travel How does connman handle this? There don't seem to be configuration options for it. ___ 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: How does connman handle scan_ssid?
On 2015-03-17 16:47, Pasi Sjöholm wrote: On 17.03.2015 14:04, Tomasz Bursztyka wrote: There is an issue however: the hidden SSIDs. These ones, to autoconnect, definitely need an active scan. We could run it if only a hidden service is created for instance. But that means we could still leak some SSIDs - the hidden ones - if we are not located where these could be found. This is exactly what we (Jolla) been doing in the Sailfish OS with ConnMan since July 2014 per customer request. No huge or minor issues experienced. Can this patch be mainlined? Or is it too specific? Br, Pasi ___ 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: Online status
On 2015-02-10 20:40, Marcel Holtmann wrote: Hi Tom, When a service transitions from ready to online status, connman makes an http request to ipv[4,6].connman.net/online/status.html. I have been asked if this is a requirement or is there a way to prevent this from happening? how else would you do it? You need to ensure that you are in fact connected to a working Internet connection. If you do not do it, then you will stay in ready stage. If that is good enough for you, then that is good enough. However things like NTP for example can not work in ready stage. We need to the confirmation that we actually do have a working Internet connection. Otherwise you are just link-local. So ready represented local network connectivity and online represent global network / Internet connectivity. Please note that this is similar on how OS X and also iOS are doing it these days. When it comes to WISPr support, then this HTTP request is actually mandatory. Is the URL configurable? Regards Marcel ___ 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: Issue found in service connman ordering
On 2015-01-29 13:24, Priyaranjan Singh wrote: We are using Connman version: 1.23 1.27 is the last release, and the git master branch has a lot of additional fixes. You should re-test with either (and appropriately recent versions of wpa_supplicant et. al.) and report any still existing issues in a more readable format. -- 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
