Re: Moving ppp-manager into ModemManager

[Dan Williams <dcbw redhat com>]

On Mon, 2009-05-11 at 14:20 -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.
> 
> 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.

The PPP settings are oh-so-much more though.  Look through the settings
for PPP some time.  Many of them are not required, many of them are
actually used.  I'm not saying this is a show-stopper, I'm just saying
that you should understand the scope of PPP configuration.  There are a
lot of shitty, shitty PPP servers out there, which isn't a surprise,
because PPP is such a generic protocol it gets used just about
everywhere.

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

Yeah.

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

Yeah, PPP code is icky.  But just like dhclient, it doesn't need
rewriting.  There are certainly more worthwhile things to spend time on.
It's got a responsive upstream who accepts patches, why not fix the
specific issues you have and upstream the patches.

Dan