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

"Waldemar Kornewald" <Waldemar.Kornewald@xxxxxx> wrote:
> > > 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. ;)

Well, we'll see :-)
BTW our current naming scheme is a bit more wordy, I would rather like 
libkernel_ppp.a - if that's no problem for you :)

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

Can't promise, I am also not at all familiar with the net stack - but 
we can try.

> > > pppctl (0% done, small task)
> > > pppdial (0% done, small task)
> > 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.

Damn, now I understand what you mean! Although I would prefer to have 
it go through the net stack itself, that looks good. 
But again, I am a unsure about the naming - pppctl is supposed to be a 
userland application in "other" environments, and almost has the exact 
same job as your pppdial.
If you really want to have an extra driver for this, why don't call it 
just "ppp" and the application configuring or controlling it "pppctl" 
(or even pppconfig, like BONE does)?

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

No matter what we do and how we decide to look at it, we all have a 
long and stony road ahead of us - it's like life, only that we're used 
to be happy when it (hopefully) takes a long time ;-P
But seriously, I doubt it will be you delaying R1 :)

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

You could just create a file "ppp is up" somewhere to have that 
functionality ;-)
I guess we can use the extended notification mechanism in the kernel to 
do this - but just a warning, that thing isn't already implemented 
completely, only the standard node monitoring part is (minus the actual 
message delivery).

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

See? That's what I meant with the long and stony road - it doesn't even 
end with R1 ;-)

Adios...
   Axel.

Other related posts: