Re: [RFC] doc: Extended tethering API
Hi Gustavo,
> I've been thinking a bit on this an here is my proposed API for the DUN Server
> case. As I do not understand all the ConnMan internals yet I might be missing
> something basic here.
>
> Current oFono implementation runs the IPCP negotiation before create the PPP
> interface. That may become a problem if we have to ask the IP + DNS to
> ConnMan, if we want to simplify the API between ConnMan and oFono we might
> want to fix the connection setup order. Or move TUN/TAP to inside ConnMan and
> have it creating the ppp0 interface then NAT/forwarding.
>
> It makes more sense to me move TUN/TAP to ConnMan. It already does that for
> VPN, for example. Looks more like a ConnMan work than an oFono's.
>
> Proposed API wants to move the TUN/TAP to ConnMan, then we will have first the
> LCP negotiation on the oFono side and once LCP is up, oFono will ask ConnMan
> to create the ppp interface a give the IPs and DNS to be used in the IPCP
> negotiation.
>
> Probably something that was already suggested by Marcel:
>
> dict {fd, IP + DNS} RequestPrivateNetwork(options)
lets do it like this:
fd, dict{settings} RequestPrivateNetwork(dict options)
for now. And then include:
ReleasePrivateNetwork(fd)
This might not be the final solution actually, but I think it is a good
start. We can learn form its implementation and what we really do need.
Mark both methods as experimental in the documentation so that it is
clear that we need some more testing here.
Regards
Marcel
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Re: [RFC] doc: Extended tethering API
Hi Marcel,
On Tue, Jan 25, 2011 at 06:17:37PM +0100, Marcel Holtmann wrote:
> 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)
It probably makes sense for ConnMan to create the virtual interface, so
this API looks fine to me.
> 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.
For low level events like a network disconnection, ConnMan could notify
oFono through the fd (as Gustavo pointed out). Are you thinking about
higher level events, like e.g. network settings changes ?
Also, with this API we'd also need a hook for oFono to notify ConnMan
about disconnections from the device side.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Re: [RFC] doc: Extended tethering API
Hi Marcel,
* Marcel Holtmann [2011-01-25 18:17:37 +0100]:
> 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.
>
I've been thinking a bit on this an here is my proposed API for the DUN Server
case. As I do not understand all the ConnMan internals yet I might be missing
something basic here.
Current oFono implementation runs the IPCP negotiation before create the PPP
interface. That may become a problem if we have to ask the IP + DNS to
ConnMan, if we want to simplify the API between ConnMan and oFono we might
want to fix the connection setup order. Or move TUN/TAP to inside ConnMan and
have it creating the ppp0 interface then NAT/forwarding.
It makes more sense to me move TUN/TAP to ConnMan. It already does that for
VPN, for example. Looks more like a ConnMan work than an oFono's.
Proposed API wants to move the TUN/TAP to ConnMan, then we will have first the
LCP negotiation on the oFono side and once LCP is up, oFono will ask ConnMan
to create the ppp interface a give the IPs and DNS to be used in the IPCP
negotiation.
Probably something that was already suggested by Marcel:
dict {fd, IP + DNS} RequestPrivateNetwork(options)
I'm not sure if we need another method in ConnMan API that oFono can call when
IPCP is up. If yes then we will need some sort of Start() method in a
PrivateNetwork API.
Then it also comes that we have to treat the cases where either oFono or
ConnMan give ups of the Connection. If ConnMan disconnect In oFono side
we can just pool on the fd listening for a HUP, which means no need for
an agent here.
If oFono wants to disconnect we can add a ReleasePrivateNetwork() in the
ConnMan's Manager API. This method will remove the tun/tap and undo all the
NAT/forwarding.
Another error case happens if the IPCP negotiation fails, in this case we
could just call ReleasePrivateNetwork() and everything will be ok.
diff --git a/doc/manager-api.txt b/doc/manager-api.txt
index 743ba18..69b0fc7 100644
--- a/doc/manager-api.txt
+++ b/doc/manager-api.txt
@@ -192,6 +192,25 @@ Methodsdict GetProperties()
Possible Errors: [service].Error.InvalidArguments
+ dict {fd, settings} RequestPrivateNetwork(object path, options)
+
+ Request a new Private Network, whick includes the
+ creation of a tun/tap interface, and IP
+ configuration, NAT and IP forwarding on that
+ interface.
+ A file descritor to the interface is returned together
+ with the IP, gateway and DNS settings for the
+ interface.
+
+ Possible Errors: [service].Error.InvalidArguments
+[service].Error.NotSupported
+
+ void ReleasePrivateNetwork(object path)
+
+ Releases a private network.
+
+ Possible Errors:
Re: [RFC] doc: Extended tethering API
Hi, On Tue, 2011-01-25 at 17:59 +0100, ext Samuel Ortiz wrote: > - 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). How do we define this free range? I.e. what do we do if we connect to a (WLAN) network which happens to be giving out the same "free" range as we did for tethering? I see routing and route caching problems with this in the Linux kernel. Cheers, Patrik ___ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
Re: [RFC] doc: Extended tethering API
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.
or coming to think about this a little bit more, we treat this as a
client of the session API. Strictly speaking the Dialup depends on an
active session.
So we could treat oFono Dialup server as session client with the extra
feature that it gets IP + DNS and a separate TUN/TAP with forwarding.
Regards
Marcel
___
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
Re: [RFC] doc: Extended tethering API
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
