[openbeosnetteam] Re: general or PPP ideas

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

Why not just provide them as add-ons? After all, they are protocols in 
their own rights, especially CHAP, which requires renewal of 
authentication at various points in the connection. You could turn them 
off or on in the settings panel, and specify negotiation preference in 
however you configure the ppp server.

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

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.

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

Of course we need settings. The issue is how much need be set.

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

IMHO, This should be a standard, and not PPP specific, API.
-Nathan

Other related posts: