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

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

I forgot an additional task in milestone #3 (server):
libppp.so
This will be a library that gives userland apps a C++ interface to query
interfaces and get notified about any state changes.
It will use the pppctl (or ppp) driver to access all functions.
Additionally it will provide GUI controls (I am not sure which are needed,
though).

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

Does this mean I am slow? :)
Yes, I am slow (I only had the weekend to work on ppp).
Now, I have a little bit more time to work. But this will not help much,
either.

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

That is okay. :)

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

I am currently looking at pppd. It is the cleanest of all implementations I
looked at. Why did I not look at it earlier!?
This will help a lot and leave less questions to you.

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

pppctl can be renamed.
pppdial got its name because it must not remind anyone of the other tools.
pppconfig will make people think that it uses the same syntax for its
connection files, which it does not.
pppdial has its own syntax that can be easily transfered to kernel land.

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

I hope so. :)

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

Oh no, that would be far too easy. ;)
Seriously, it is not that simple, because the srever implementation will use
this functionality.
The query interface will not just say "hey, I'm up!", but it will also say
"interface x is entering authentication phase", "interface x has
authenticated". And each time it may be configured to wait until it gets a
response whether to continue or not.
After an interface has authenticated the server can talk to the IPCP module
and tell it the ip address it may assign to the authenticated user.
It may also disable some protocols.

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

Lol. :)
Everyone has dreams. ;)

Waldemar