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. [RFC] ConnMan Session API extensions: Additional policy hooks
and firewalling (Achtzehn Andreas (CM/ENA4))
----------------------------------------------------------------------
Message: 1
Date: Fri, 10 Feb 2017 12:23:54 +0000
From: "Achtzehn Andreas (CM/ENA4)" <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Daniel Wagner <[email protected]>, "EXTERNAL Thorwirth Bjoern
(Brunel, CM-CI1/ERN5-E)" <[email protected]>,
"Nakamura, Yusuke (ADITJ/SWG)" <[email protected]>
Subject: [RFC] ConnMan Session API extensions: Additional policy hooks
and firewalling
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
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).
***** 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.
***** 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).
***** 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.
***** 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.
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).
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).
Andreas
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 16, Issue 15
***************************************
