Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: iptables - ignoring the entries from other processes
(Daniel Wagner)
2. Re: [PATCH v1 0/3] Use /dev/random instead of /dev/urandom
(Daniel Wagner)
3. Re: Connman to control OpenVPN connection (Daniel Wagner)
4. Re: [RFC] ConnMan Session API extensions: Additional policy
hooks and firewalling (Daniel Wagner)
5. Re: [PATCH v1 3/3] README: Add GnuTLS seciont on
GNUTLS_NO_EXPLICIT_INIT (Daniel Wagner)
6. Re: Connman to control OpenVPN connection (Florent Le Saout)
----------------------------------------------------------------------
Message: 1
Date: Mon, 13 Feb 2017 08:28:34 +0100
From: Daniel Wagner <[email protected]>
To: "Puustinen, Ismo" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: iptables - ignoring the entries from other processes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Ismo,
On 02/08/2017 11:39 AM, Puustinen, Ismo wrote:
> On Mon, 2017-02-06 at 22:57 +0100, Usman S wrote:
>> not be disturbed. Also I think we should also include the important
>> xtables_lock before read and release after committing so that it is
>> clean like iptables does. Yeah, the drawback could that if someone
>> else is holding and has not released, Connman would be blocked as
>> well
>> but this seems to me a generic problem. Please let me know your
>> comments.
>
> I did a rough patch for the xtables lock some time ago:
>
> https://github.com/ostroproject/ostro-os/pull/204/commits/4024bbe7ca708
> e92e986f3e3622a9fc25dc26b34
You would need to add some retry mechanism to make it really usable at
least for __connman_firewall_init(). The other call sides are handled by
upper layers. Thought the result would be operation failed for
EWOULDBLOCK. Obviously, not the nicest thing to do. I think you would
need to handled the retry logic as well at higher level in this case.
Thanks,
Daniel
------------------------------
Message: 2
Date: Mon, 13 Feb 2017 08:30:35 +0100
From: Daniel Wagner <[email protected]>
To: Denis Kenzior <[email protected]>, [email protected]
Subject: Re: [PATCH v1 0/3] Use /dev/random instead of /dev/urandom
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Denis,
On 02/07/2017 08:03 PM, Denis Kenzior wrote:
> Hi Daniel,
>
> On 02/07/2017 12:41 PM, Daniel Wagner wrote:
>> Hi Slava,
>>
>> On 02/07/2017 10:16 AM, Slava Monich wrote:
>>> I'm a bit confused. I read that web page again and again - it claims
>>> that it's /dev/urandom which should be used because it never blocks and
>>> it's /dev/random which DOES block. But your comments imply the opposite
>>> - that /dev/urandom blocks and /dev/random doesn't.
>>
>> Me too. I wasn't really awake as it seems. You are absolutely right, the
>> code is fine. Documentation was missing...
>>
>
> Or better yet, do as ell does and use getrandom().
Good idea. Will give it a shot.
Thanks,
Daniel
------------------------------
Message: 3
Date: Mon, 13 Feb 2017 08:38:12 +0100
From: Daniel Wagner <[email protected]>
To: Florent Le Saout <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: Connman to control OpenVPN connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Florent,
FWIW, I have tested the current HEAD with my OpenVPN server. Pretty
standard configuration:
dev tun0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/xxx.crt
key /etc/openvpn/keys/xxx.key
dh /etc/openvpn/keys/dh2048.pem
server 10.1.0.0 255.255.255.0
auth SHA512
cipher AES-256-CBC
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
and on the client side:
[provider_openvpn]
Type = OpenVPN
Name = xxx
Host = xxx
Domain = xxx
OpenVPN.CACert = /var/lib/connman-vpn/ca.crt
OpenVPN.Cert = /var/lib/connman-vpn/xxx.crt
OpenVPN.Key = /var/lib/connman-vpn/xxx.key
OpenVPN.Cipher = AES-256-CBC
OpenVPN.Auth = SHA512
OpenVPN.NSCertType = server
and I haven't observed any problems. Let's see if it happens if I use it
more regularly.
Thanks,
Daniel
------------------------------
Message: 4
Date: Mon, 13 Feb 2017 09:36:31 +0100
From: Daniel Wagner <[email protected]>
To: "Achtzehn Andreas (CM/ENA4)" <[email protected]>,
"[email protected]" <[email protected]>
Cc: "EXTERNAL Thorwirth Bjoern (Brunel, CM-CI1/ERN5-E)"
<[email protected]>
Subject: Re: [RFC] ConnMan Session API extensions: Additional policy
hooks and firewalling
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Andreas,
On 02/10/2017 01:23 PM, Achtzehn Andreas (CM/ENA4) wrote:
> Hello Daniel,
>
> Thank you for your feedback regarding our RFC on the planned
> extensions to ConnMan. As you noted, some of the proposed
> functionalities may interfere with the ConnMan concept. As you suggested
> we have therefore looked into how to build a functional separation that
> will maintain the default ConnMan behavior while enabling more complex
> policy scenarios.
>
> We found that it would be necessary for the more complex policy
> scenarios to add new hooks to the policy callback function
> infrastructure of the Session API. The hooks would be backward
> compatible with the default policy plugin and the ongoing Session API
> development.
>
>
> Hooks
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> We'd consider the following callback functions to be particularly
> relevant for our currently envisioned use cases.
>
> ***** void (*parse_create_session)(DBusMessage *msg,struct connman_session
> *session)
>
> This callback function would extend the __connman_session_create
> function. It would allow a session API user to provide additional
> configuration parameters specific to the running policy plugin during
> the CreateSession DBus call to the API. The default behavior of ConnMan
> should be changed so that it ignores unknown parameters (making it
> compatible with future plugins and unknown parameters).
This is about assigning the Session an ID, so that the application
doesn't have to add logic to handling different sessions?
I really would like to see the D-Bus API as stable stable as possible.
So I rather prefer the Session ID approach than this. Or are there
more API changes or extension you need?
> ***** struct connman_service* (*get_service_for_session)(struct
> connman_session* session, GSList* services);
>
> This callback function would extend the session_activate
> functionality. It would return from a GSList* services (a list of
> services) a pointer to the service that should be used for the session
> based on the custom policy. The GSList* should contain all currently
> useable services (i.e. that evaluate to true in is_session_connected).
> It returns NULL if none of the services is useable. This functionality
> is an extension of the existing policy->allowed hook, but makes the list
> of services and the choice which service should be used into the plugin.
The allowed() function is there to tell the session core which service
can be used for the session. The core ask whenever the plugin whenever
new Service appears if the Service is acceptable.
Can you please elaborate why get_service_for_session() is necessary? If
I understood you correctly, you want to maintain the list of Service
always in the plugin and over steer the session Service picking algorithm.
> ***** void (*update_session_state)(struct connman_session* session, enum
> connman_session_state state)
>
> This callback function would extend the update_session
> functionality. It would be called when the state of the session changes (from
> CONNMAN_SESSION_STATE_DISCONNECTED to CONNMAN_SESSION_STATE_CONNECTED,
> etc.) and allow the plugin to act accordingly. For this to work, the
> enum connman_session_state would need to be exposed. This shouldn't
> result in a conceptual change as, e.g., session-test.c already uses the
> information from the state (but currently defines the enum anew locally).
Okay, though I would like to have a better argument as 'allow the plugin
to act accordingly' for the change.
> ***** bool (*has_notifiable_changes)(struct connman_session* session);
> void (*append_notify)(DBusMessageIter *dict, struct
> connman_session *session);
>
> This pair of callback functions would be used alongside the Update
> message generation. has_notifiable_changes returns true if the plugin
> has some changes to report (e.g. a change in the applied policy) for the
> user. The append_notify function would then add the relevant fields to
> the Update message. Both functions would be embedded with the
> append_notify function.
As I understand this goes along parse_create_session().
> ***** bool (*change_session_settings)(DBusMessage *msg, struct
> connman_session* session);
>
> This function would be called when a user sends a Change messages,
> which acts on none of the basic Session API parameters. The function
> would return true if the sent configuration change request was handled
> by the plugin, otherwise false.
and this one as well.
> Firewalling
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Additionally, we would like to enable plugins to have their own
> firewall rules within the scope of the session. For this, a set of functions
>
> int connman_session_firewall_add_rule(struct connman_session *session,
> const char *table,
> const char *chain,
> const char *rule_fmt, ...);
> int connman_session_firewall_remove_rule(struct connman_session *session, int
> id);
> int connman_session_firewall_enable_rule(struct connman_session *session, int
> id);
> int connman_session_firewall_disable_rule(struct connman_session *session,
> int id);
>
> would be required. They equal to their internal __connman_fw_*
> definitions, but the context always comes from the current session.
> Since firewall rules with the same fwmark'ing mechanism may be of
> interest, the auxiliary function
>
> int connman_session_firewall_get_fwmark(struct connman_session *session);
>
> should return the session mark (without needing to expose the
> complete struct connman_session).
Making the internal firewall API accessible is okay. Just check the
current HEAD. It has gain support for nftables and that's why we dropped
the low level iptables API details as table or table anymore.
> Service search by identifier
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Not specific to the Session API, but we found that a function
>
> struct connman_service *connman_service_lookup_from_identifier(char*
> identifier)
>
> similar to connman_service_lookup_from_network would help to lookup
> a service by its char service name (e.g., ethernet_XXXX_cable).
Okay.
Thanks,
Daniel
------------------------------
Message: 5
Date: Mon, 13 Feb 2017 09:38:43 +0100
From: Daniel Wagner <[email protected]>
To: [email protected]
Subject: Re: [PATCH v1 3/3] README: Add GnuTLS seciont on
GNUTLS_NO_EXPLICIT_INIT
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
I applied the doc patch. The other two patches are obviously bogus.
------------------------------
Message: 6
Date: Mon, 13 Feb 2017 09:53:55 +0100
From: Florent Le Saout <[email protected]>
To: Daniel Wagner <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: Connman to control OpenVPN connection
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Daniel,
Thanks for spending some time trying reproducing that. :)
I'm actually on 2.3.14 on both side, compiled for ARM for the client and
x86_64 for the server.
I could not migrate so far on 2.4
* _Regarding routes :_
What I observe is that most of the times routes are properly set and
connman is listing services in the right order :
root # connmanctl services
* R VPN vpn_192_168_4_201_test
*AO Wired ethernet_7076ff010e20_cable
# ip route
default dev vpn0
10.8.0.1 dev vpn0
192.168.4.0/23 dev eth0 src 192.168.4.119
192.168.4.4 dev eth0
192.168.4.201 via 192.168.4.4 dev eth0
But once in a while, it's not correct.
How can we make sure that VPN will always be on top of the others, which
is the default expected behavior from my perspectives ?
I will also try to reproduce it on my side and try to provide you with
as much details as I can.
* _Regarding Autoconnect :_
When you say :
The VPN Service itself has an AutoConnect property which tells
ConnMan to start it automatically.
Do you mean that this is set automatically by default for this type of
service, or do I need to set it manually bu setting an option, because
if this is the case I haven't found it ?
See below the actual details of my connexion :
/net/connman/service/vpn_192_168_4_201_test
Type = vpn
Security = [ ]
State = ready
Favorite = True
Immutable = False
AutoConnect = False
Thanks,
Florent.
On 13/02/2017 08:38, Daniel Wagner wrote:
> Hi Florent,
>
> FWIW, I have tested the current HEAD with my OpenVPN server. Pretty
> standard configuration:
>
> dev tun0
> ca /etc/openvpn/keys/ca.crt
> cert /etc/openvpn/keys/xxx.crt
> key /etc/openvpn/keys/xxx.key
> dh /etc/openvpn/keys/dh2048.pem
> server 10.1.0.0 255.255.255.0
> auth SHA512
> cipher AES-256-CBC
> push "redirect-gateway def1 bypass-dhcp"
> push "dhcp-option DNS 8.8.8.8"
>
> and on the client side:
>
> [provider_openvpn]
> Type = OpenVPN
> Name = xxx
> Host = xxx
> Domain = xxx
> OpenVPN.CACert = /var/lib/connman-vpn/ca.crt
> OpenVPN.Cert = /var/lib/connman-vpn/xxx.crt
> OpenVPN.Key = /var/lib/connman-vpn/xxx.key
> OpenVPN.Cipher = AES-256-CBC
> OpenVPN.Auth = SHA512
> OpenVPN.NSCertType = server
>
> and I haven't observed any problems. Let's see if it happens if I use
> it more regularly.
>
> Thanks,
> Daniel
--
*Florent LE SAOUT*
R&D department
Embedded Software Developer
AUSY contractor for KERLINK
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20170213/354eb3fc/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 16
***************************************
