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