Hi Samuel,
> So I've been thinking about how ConnMan could support the DUN server case.
> I gathered that the ConnMan requirements for that use case are the following:
>
> - Provide a free IP range for oFono's ppp gateway address. The address range
> should be a /24 one, in which oFono can freely pick a couple IPs (for the
> local and peer addresses).
>
> - Enable NAT and IP forwarding between the ppp interface created by oFono and
> our default service one.
>
> Even though we could certainly create some ad-hoc net.connman.Manager methods
> for that, I think the DUN case can easily be seen as a tethering corner case.
> It's basically what we're currently doing with the tethering implementation,
> except that:
> a) We don't want to put the ppp interface on a bridge and
> b) We don't want a DHCP server to be listening on the ppp interface (although
> we could, but that's useless in most cases).
right now we have the fun fact that we are doing IPCP before we have the
ppp0 interface. This means we need to know the IP address before we have
the interface available.
However in theory that could be changed in oFono so that we create the
ppp0 interface before starting IPCP and then just asking ConnMan to set
up IP forwarding and return the IP address + DNS to us.
So I was more thinking in the direction of just having something like
this:
dict RequestForwarding("ppp0", options/flags)
If we take this one step further then oFono does not need to know about
the interface name at all. It does not really care. So we could use fd
passing and keep the TUN/TAP control directly inside ConnMan.
dict{fd, IP + DNS} RequestPrivateNetwork(options)
This way it could happen all in the IPCP phase of PPP and we could
either reject or accept it. Also in case of a failure we could just
reject it.
The only problem really is that we might need some sort of an agent here
actually. Since we do need updates in case of network side disconnect
etc.
Maybe the BlueZ media API is a good example on how should be dong this.
> So what I propose is to define a more generic tethering API for ConnMan,
> starting from the Manager one, and would look like that:
>
> diff --git a/doc/manager-api.txt b/doc/manager-api.txt
> index 743ba18..f8ca93d 100644
> --- a/doc/manager-api.txt
> +++ b/doc/manager-api.txt
> @@ -192,6 +192,52 @@ Methods dict GetProperties()
>
> Possible Errors: [service].Error.InvalidArguments
>
> + object RequestTether(dict settings)
> +
> + This method will request a tethering object.
> +
> + Valid settings for tethering objects are:
> +
> + string Interface [optional]
> +
> + Interface name to be used as the tethering link.
> +
> + string Technology [optional]
> +
> + The technology that should act as the tethering
> + link. This value is only valid when Interface is
> + not specified.
> + If the Technology value is not specified, all
> + technologies supporting tethering will be used
> + as tethering links.
> +
> + string Bridge [optional]
> +
> + The bridge name tethering clients will belong to.
> + This value is only valid when Interface is not
> + specified.
> + If the Bridge value is not specified but the
> + Technology one is, then a default bridge named
> + "tether" will be used.
> +
> + boolean DynamicIP [optional]
> +
> + This value specifies if a DHCP server should run
> + on the tethering bridge or interface. When set
> + to FALSE, a specific IP range will be reserved.
> +
> + When successful this method will return the object
> + path of the corresponding tether.
> +
> + Possible Errors: [service].Error.InvalidArguments
> +
> + void ReleaseTether(object tether)
> +
> + Release a tethering object.
> + The tethering link is brought down if it was still up.
> +
> + Possible Errors: [service].Error.InvalidArguments
> +
> Signals PropertyChanged(string name, variant value)
>
> This signal indicates a changed value of the given
> @@ -249,13 +295,6 @@ Properties string State [readonly]
> the limited usage of WiFi or Bluetooth devices might
> be allowed in some situations.
>
> - boolean Tethering [readwrite]
> -
> - This option allows to enable or disable the support
> - for tethering. When tethering is enabled then the
> - default service is bridged to all client where
> - connection sharing is supported.
> -
So I do wanna keep this. Since it should map one-to-one to a UI piece
enabling Tethering or not.
And more important this does not depend on the life-time of the caller;
which is intentional.
> object ActiveProfile [readwrite]
>
> Object path of the current active profile.
> diff --git a/doc/tether-api.txt b/doc/tether-api.txt
> new file mode 100644
> index 0000000..589d1c4
> --- /dev/null
> +++ b/doc/tether-api.txt
> @@ -0,0 +1,37 @@
> +Tether hierarchy
> +=================
> +
> +Service net.connman
> +Interface net.connman.Tether
> +Object path /
> +
> +Methods dict GetProperties()
> +
> + Returns properties for the tether object. See
> + the properties section for available properties.
> +
> + Possible Errors: [service].Error.InvalidArguments
> +
> + void Start()
> +
> + Possible Errors: [service].Error.InvalidArguments
> +
> + void Stop()
> +
> + Possible Errors: [service].Error.InvalidArguments
We did have these Start/Stop things for Bluetooth profiles in BlueZ and
it never really worked out nicely. So we did remove them in the end. As
mentioned above you do wanna bind it to some lifetime of the caller.
> +Properties dict IPv4 [readonly]
> +
> + string Address [readonly]
> +
> + The current reserved IPv4 address
> + range.
> +
> + uint8 PrefixLength [readonly]
> +
> + The prefix length of the IPv4 address
> + range.
> +
> + array{string} Nameservers [readonly]
> +
> + The IPv4 namesevers array.
>
>
> And the current Manager Tethering property would be replaced by calling
> Start()/Stop on a tether object we'd get from Manager.RequestTether(NULL,
> NULL, NULL, TRUE).
>
> oFono usage of this interface for DUN would look like that:
>
> 1) Manager.RequestTether("ppp0", NULL, NULL, FALSE)
> 2) Tether.GetProperties() would give oFono the IP range it could use for the
> ppp gateway and client addresses, along with the nameservers to pass to the
> client.
> 3) Tether.Start() once the IPCP link is up. That would enable IP forwarding
> and NATing.
We are making then 3 method calls for one simple request. Enable IP
forwarding on ppp0. Not sure if that is the right thing here.
Regards
Marcel
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
