FreeLists / openbeosnetteam / [openbeosnetteam] Re: Dial-Up task (fwd)

["Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx>]

I forgot: Philippe, could you please add these milestones (the first two
should be enough ;) to our task list?

> "Philippe Houdoin" <philippe.houdoin@xxxxxxx> wrote:
> > [Forwarded here, has it may interest the whole team - I really hope
> > it
> > will!!! ;-)]
>
> Sure :)

Hopefully. :)

> > #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 :-)

Yes, I hope it will be done before R1. ;)
My biggest problems are the BSD stack which I find very hard to understand.
Would you all please help me? (A help request is in my draft folder and will
follow soon).

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

Why two different apps? pppctl is not an application, but a driver. pppdial
must open pppctl because it cannot load the ppp_interface_manager directly.
This is similar to our current concept. ppp_interface_manager is the core,
pppctl is the stack driver, and pppdial is ifconfig.

> > pppoe (0% done, small task)
> > PPPoE protocol implementation.
>
> Maybe Nathan can help out here.

It is still a long way until I need his help. :(

> > serial_ppp (0% done, small-medium task)
> > Allow to connect with serial modems.
>
> That's very much needed :-)

Yeah, I had to beg someone to not throw away his modem to solve this task.
;)

And I forgot another little task:

IPCP
The IPv4 control protocol. ;)
Again 0% and a small task, I think.

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

No, pppctl should be a tool for Linux fans and for having a simple tool to
test the ppp implementation.
I have thought about that, too. The ppp_interface_manager will allow to use
"live-queries" (hehe) to be automatically informed when an interface goes
up/down. This way, even when using ifconfig you will be notified that some
(possibly unknown) ppp interface went up. :))

> > #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?

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

Oh, well, I cannot promise that this will ever happen...before R3. ;)

Waldemar