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
