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 _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list