FreeLists / openbeosnetteam / [openbeosnetteam] Re: general or PPP ideas

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

> > I want to do that, but how
> > does the server know which users are available and which password
> > they have?
>
> It depends. In the context of a ppp client, they could be attributes of
> the ppp node. For a server, you could have some look-up database whose
> location is defined centrally, perhaps by an attribute.

We need some attribute class for this. Does anybody want to do it or do I
have to implement it? :)
I cannot guarantee that it will be a good implementation. ;)

> > Some methods need the raw password from the authenticator and some
> > can tell
> > the unencrypted password to the authenticator. If you want to
> > authenticate
> > with the OS user DB (like in Unix) it is only possible with PAP
> > because the
> > unencrypted password is needed for the user DB which then encrypts
> > the raw
> > password and compares it with the encrypted password in the user db.
> > Using
> > CHAP is not possible here, for example. Other system could supply the
> > unencrypted password to CHAP which then encrypts it for
> > authentication.
> > I would like to use userland user-DB-add-ons because it puts less
> > code into
> > the kernel.
>
> You could have a kernel-level protocol module talk to some generalized
> password database.

This is what I wanted to do, but this module would have to be developed and
it would reside inside the kernel.

The DB module asks the userland DB process through a port. The userland DB
process loads DB add-ons. I will define some add-on API so everyone who
wants to implement his own DB add-on does not have to write a kernel module,
but only a new userland DB add-on. The DB process loads the add-ons and
creates a thread for each authentication request.
How does the authenticator get the result? Can it just read the thread's
message queue? The userland add-on would get a thread_id and write the
result to it.
All requests would be distributed through threads and all authentications
would work simultaneously.

I hope this was understandable. :)

> > But this removes the possibility to make a PPP connection inside
> > the kernel. And it adds dependency on a userland application or
> > complicated
> > userland API. I would prefer to make it very easy. If the
> > authenticator asks
> > the userland DB it must block until each user is authenticated.
>
> Why? It could be asynchronous.

Is my idea similiar to what you thought of when you wrote "asynchronous"?

> > > This is negotiated by LCP. If you try to bring up a protocol's NCP
> > > that
> > > the ISP doesn't like, it sends back a protocol-reject packet.
> > > Essentially, all you need is an ability to close down specific
> > > protocols. Again, in the case of servers, there should be a way to
> > > specify things, but for the user, little needs to be hardcoded. The
> > > server can just never notify protocols it doesn't like of an open
> > > link.
> >
> > I would like the client and the server to specify their wishes. :)
>
> I think that, by default, everything should be brought up everywhere.
> You could block it, though.

How do you want to bring up IPCP? Should it by default get the IP
dynamically?
Additionally, I would not like it if any protocol other than IP would be
loaded. I always disable NetBIOS in Windows and I hate having to do it!
I do not like systems that load things automatically. They open security
holes. Most users would be thankful if only IP would be negotiated. And what
should PPP do if it had IPv4 and IPv6? Why do we need IPv4 if IPv6 can be
used?
I think the dialer application/preflet should specify some default settings
like IP and nameservers (which can be changed in the preflet, of course) so
that the user does not specify anything other than the ISP phone number or
the PPPoE device and authentication data by default. Advanced users can
specify other protocols either by editing the dial-up file by hand or
through the Dial-Up preflet if it supports this.

> > > Of course we need settings. The issue is how much need be set.
> >
> > Only the basics should be needed, but everything should be possible.
> > NCPs should be specified, for example.
>
> Why would you want to specify NCPs? Why not just the protocol?

The user never sees the NCPs. And the NCP module for IP will be called IP,
not IPCP. But, actually these protocols are NCPs, so the PPP interface will
load NCP modules which are named by their transported protocol name.
I think I do not understand the question. What is the difference?
The NCP is just the translator module that talks to to PPP and IP. It is
clear that we cannot tell PPP to use the IP module itself because PPP does
not know its type number.

Waldemar