[openbeosnetteam] Re: general or PPP ideas

> > AAAAAAH! Outlook Express crashed two times when I tried to reply to
> > this mail. :(
>
> Maybe because my previous mail was in bad english shape?!?
> Sorry for that, I should never try to answer late, in an hurry or both.

Oh, it is not your fault. :)
It is a bug in Outlook Express. If I select a line and press enter two times
(very quickly) it results in a crash sometimes.
And it crashed again. But this time I copied the text into the clipboard
regularly. ;)
I should reinstall it...or use BeOS.

> > So, here is a short answer:
> > You must tell the IP module which ip address it should use, so you need
> > some kind of settings!
> > I do not want to use _files_. I want to use the structures. Just the
> > Nathan's attributes idea and adapt it to settings for modules. IP would
> > use the structure to save nameservers and the ip-address and the
netmask.
> > I do not want to use settings to save protocol ids!
>
> Okay, I think I understand better now:
> A generic way to exchange "settings", or attributs, between all network
modules.
> By attaching them to a net packet or a protocols "stack" connection,
completed
> and used by each modules who require it.

Yes and no. Net packets do not get attributes because this is too
inefficient (IMHO). Only the interface and protocol modules get settings
(attributes). This way it is very easy to set the IP programmatically. You
just set the IP attribute of your stack connection instead of making an
IOCTL. The nameservers are managed the same way.
Maybe we can implement this for all our modules?

Why is it not possible to talk to the interface modules through the core
module? I would like to pass my settings to the PPP module, but that is not
possible because the module interface has only two functions (init and
stop).
This means I must write a small driver that loads the ppp module and talks
to it (to add a ppp connection).

> > The PPP module will know which authentication method to use
> > and which protocols to support.
>
> Can't it be made automaticly discovered?
> I'm not a PPP expert, even far from it even, but can't you discover what
> kind of authentification protocols (CHAP or PAP, is that them?) to use or
are
> supported by PPP server? Trying first CHAP, and fall to PAP if it doesn't
work?

This is possible only if you are a client. I want to add support for PPP
servers. A PPP server should be able to ask a RADIUS or LDAP server for all
users.
I would have to hard-code PAP and CHAP into the PPP module. There are many
other authentication methods (e.g., MS CHAP) and if someone wants add them
it is very hard to read the source and find the right places where to put
the extensions.
Do you think this is too much modularity?
At least for PPP servers the user-DB source should be a module.

> On the "which protocol to support" point, why not all? I mean, PPP could
> support IP, IPX, etc, no? I don't see why we should specified for a DialUp
> connection only IP or IPX or both packets should be allowed to pass thru
the
> PPP link. If an application send IPX (SPX packet) data and the dialup
> connection is the link on the road, or PPP module know how to encapsulate
IPX
> packets and he do it, or he don't and drop it.
> Is it a wrong idea?

I thought about this, but I came to the conclusion that as an ISP you do not
want to support IPX. What if some protocol is not secure and you want to
close it? Anyway, Appletalk or IPX would not be useful for an ISP and a
waist of resources.
And there is the problem that you must specify some settings anyway. The IP
module must know its IP address which can be a statically assigned address
(set by the user).

Another problem is that the user might want to use some IP compression to
increase the connection speed. How does IP know that?

And if you have a PPP server you must tell the IP module which dynamic IPs
it can assign to clients. This is only possible with settings.

> But, for a start, let's focus on IP in PPP support.
>
> BTW, sorry if I sounds too newbie on PPP... ;-)
> Does someone around have a better PPP technical documentation than just
RFCs?
> URLs? PDF(s)?

I did not really intend to support anything else than IPv4 and IPv6. To make
it easy for someone to extend the PPP implementation I want to create an API
so that he/she does not hack into the PPP module.

> > Maybe you want to use IPX for one of your connections, so you must
> > edit the settings file (the format in which Dial-Up saves connections,
> > like bone.conf or any other connection representation).
> > The preflet does not know how to handle IPX because it does not know
> > the needed settings like IPX ID (or something similar to an IP address).
>
> This is another point: Network modules (protocols, interfaces, etc)
> GUI settings panels. Currently, we don't have anyone.
>
> What I've in mind once was that each protocol who need or support
> user-settable settings should *publish*, via a separate add-on or thru a
simple
> exported funcion (NetConfigView * instanciate_config_view() or like) in
the
> stack module itself, the way to display and edit these user-settings.
> The way they're then *set* (live, obvioulsy!) could be proprietary or,
better,
> using a generic way, like a standardized ioctl() op-code and argument...

I think that the only possibility is using a seperate add-on. This is
useful, but it is more work because we need an extra add-on for each
protocol. ;)
PPP should also support some extra add-ons like compression/encryption
protocols or selecting the authentication method(s).

> > I do not have any code at the moment because I want to design all
> > add-on APIs on paper first. They must work together correctly.
>
> Indeed. Always better to put things first on paper...

Yes, and I am currently designing the API on paper and when it is finished I
will post the headers. Maybe you have some better ideas than me. ;)

> > Do you think I should split up the authenticators in authenticator
> > protocols and user-password-DBs?
> > I do not want to hard-code things like using
> > the users DB for authentication. Or is this okay for you? It would be
> > difficult to add support for LDAP, for example.
>
> Keep it simple: consider that PPP authentification protocols
> (CHAP and PAP, no?) are given the user/password to use. They're not the
place
> were LDAP credential or whatever should take place, even if such LDAP
support
> will get to life on OpenBeOS one day!

For (big) PPP servers it is not convenient to just specify the user/password
combination. If you have many thousands of entries it is better to have an
external DB.
Maybe these authenticators should support user-level apps for authentication
source?

> > I will soon be ready with the general concept. Then I will start to make
> > the API and after that I will start coding the real PPP module.
>
> Feel free to share the general concept and API when you'll have them
ready.

Thank you, I will do so. :)

Waldemar

Other related posts: