Re: Moving ppp-manager into ModemManager

[Marcel Holtmann <marcel holtmann org>]

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.

since ModemManager's API already has auth settings like username,
password and also PIN codes, I think it would be fine to have these in
there.

> - 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.

As I said, DHCP is purely for configuration, but one of of PPP's main
purpose encapsulation. Hard to tell which belongs where. I think it
would be beneficial if PPP would be done inside ModemManager and then it
just hands out the IP configuration via D-Bus (which is does for HSO
based devices already).

> 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.

I was reading through the pppd code btw. and figure out a way how we
might be able to split this or reimplement in a more proper way. The
pppd code is kinda ancient and carries a lot of code that is not longer
be used in any modern distro. Need to play with this a little bit more
and figure out which PPP features we are actually need and which ones
are just pointless nowadays.

Regards

Marcel