> > 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. > > With add-ons you mean kernel modules, don't you? Assuming it's a kernel-land stack, then yes, just as any other protocol would be added. > 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. > 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. > 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. > > 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. > > 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? -Nathan