Re: Moving ppp-manager into ModemManager

[Dan Williams <dcbw redhat com>]

On Mon, 2009-05-11 at 12:24 -0700, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > >         what do you guys think about moving the ppp-manager part from
> > > >         NetworkManager into ModemManager?
> > > >         
> > > >         What is the actual reason why ModemManager doesn't handle the
> > > >         PPP part
> > > >         of a data connection?
> > > > 
> > > > Because NetworkManager also happens to support pppoe and friends
> > > 
> > > and with the same argument the support for DSL modems etc. could also be
> > > moved into ModemManager.
> > > 
> > > My problem is that if ModemManager as a standalone can not deal with the
> > > PPP portion of a dialup connection, then it is nothing more than an AT
> > > command parser with D-Bus interface. I am failing to see the point why
> > > this code was ever moved outside NetworkManager to begin with then.
> > 
> > Not all modems are PPP.  The IP layer handling isn't the responsibility
> > of the modem manager, it's the responsibility of the connection manager,
> > since the conneciton manager applies the IP-layer policies and such.
> > 
> > There are a number of different IP configuration methods that modems use
> > these days:  PPP, static IP, and DHCP.  It makes no sense to put PPP
> > into ModemManager without putting the other two in as well.  But putting
> > the other two into MM is clearly expanding the scope of MM way beyond
> > what it should be.
> 
> I am fine with ModemManager not doing IP configuration, but PPP is
> mostly a transport layer. The IP configuration aspects are only on top
> of it. So I would expect ModemManager to do the PPP handling and then
> tell the application the IP details (routing, nameserver etc.) to
> actually set these details.

Ok sure, but this has additional drawbacks:

- complicating the API, since you have to funnel the PPP configuration
down to ModemManager, including auth methods and auth method setup
(potentially including EAP), MPPE, etc.  It does mean a lot of
additional configuration may need to be sent from the connection manager
down to MM.

- if PPP gets stuck into MM, why wouldn't DHCP also go into MM?
Obviously MM wouldn't set the IP details, but DHCP is logically at the
same level here as PPP is, since at the end of either PPP or DHCP, you
get nameservers and IP addresses.  Seems pretty wrong to put DHCP
handling into MM as well.  However, clean APIs are hard to come by since
the realities of the world intrude.

So TBH, I don't really mind putting the PPP bits into MM.  This would
make PPP-driven devices operate identically to 'hso' devices that use
AT_OWANDATA to return IP+DNS information, and MM would simply advertise
that the device used the "static" IP configuration method, and the
connection manager would apply the details provided by MM to the IP
interface provided by MM (in this case ppp0 or whatever).

DHCP-based devices (f3507g for example) would continue to require the
connection manager to perform DHCP.

Dan