[openbeosnetteam] Re: Dial-Up task (fwd)
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Mon, 30 Jun 2003 20:47:51 +0200 CEST
"Philippe Houdoin" <philippe.houdoin@xxxxxxx> wrote:
> [Forwarded here, has it may interest the whole team - I really hope
> it
> will!!! ;-)]
Sure :)
> #1 Being able to connect and transfer data (30% done, very big task)
>
> libkppp.a (60% done (maybe more), big task)
> It contains the api and the C++ client ppp interface implementation.
> As soon as we get dynamic libs for drivers/modules it will be changed
> to compile as such.
Although I doubt that this will happen in the R1 time frame!
But nice progress anyway :-)
> ppp_interface_manager (10% done, small-medium task)
> This is the interface module for our netstack.
> ppp_interface_manager wraps our network API to the C++ PPP API calls
> and
> manages all interfaces (so that you get a ppp0/ppp1/etc. with
> ifconfig)
> and destroys unneeded interfaces
> The C++ interface communicates with this manager.
Sounds good.
> pppctl (0% done, small task)
> This driver is an interface for userland applications. It allows to
> control and query all interfaces and their add-on modules.
>
> pppdial (0% done, small task)
> This is the userland dialing application.
> The user must create a file that conforms to the driver_settings
> syntax.
> pppdial parses this file and tells pppctl to create a new interface
> object
> and add it (if needed) to the ppp_interface_manager (which then adds
> a
> new ppp interface ifnet structure to the netstack).
Do we really need two different apps for this? I would rather build
this functionality into pppctl itself. Parsing driver_settings is a one
liner anyway.
And the dialing itself should be triggered by setting the network
interface to "up", right? So it could (theoretically) be done with
ifconfig (if it would have set the config before).
> pppoe (0% done, small task)
> PPPoE protocol implementation.
Maybe Nathan can help out here.
> serial_ppp (0% done, small-medium task)
> Allow to connect with serial modems.
That's very much needed :-)
> #2 GUI preflet (0% done, medium task)
> The GUI preflet is add-on based and generates/parses a connection
> structure (in driver_settings syntax).
> It also uses the ppp_interface_manager and PPPInterface (the ppp
> implementation) query API to be notified when a connection is going
> up/
> down
> and (depending on the settings) shows a user-request dialog or an
> information dialog that it is auto-dialing or nothing.
We also need a deskbar tray icon that displays the current state -
should this be part of pppctl? I don't think it should make a
difference if you dial up from GUI or the shell, at least.
But there should be a setting (display the icon or not) anyway.
> #3 PPP server implementation (0% done, small-medium task (as it is
> only
> a modification of the client implementation))
> Allows to use server interfaces that wait for an incoming connection.
But that's also not really needed for R1, right?
> #4 Additional protocols/modules (0% done, very very big task ;)
> If I can get the devices:
> * USB modem support
> * others?
> Add protocols like:
> * additional authentication protocols (MS CHAP, etc.)
> * MP - The Multilink Protocol allows to combine the bandwidth of many
> devices for your internet connection.
> * compression protocols
> * encryption protocols
> * others?
That sounds very nice, at least :-)
> Maybe I will just port from existing implementations...
That is often the best approach.
Adios...
Axel.
Other related posts:
