Subject: Re: in-kernel PPPoE server (include patch)
To: Masaru OKI <oki@netbsd.org>
From: Martin Husemann <martin@duskware.de>
List: tech-net
Date: 06/12/2003 09:24:15
On Thu, Jun 12, 2003 at 02:55:40PM +0900, Masaru OKI wrote:
> I implement in-kernel PPPoE server code.
Cool!
> comments?
At first look I thaught "uhh, that's not how I would have done it" - but on
second thought it is something we can use now and later easily extend.
When I designed the PPPoE stuff I thought about the server side too, and here
is what I came up with at that time (but neglected to implement, since there
was no real need for me at that time):
- Have a userland daemon listen (via bpf) for the PADI packets and let
it handle the initial steps (completely in userland) until the PPP
authentication finished
- Then create a new pppoe* interface, initialize it's state with the
already negotiated data and make it take over the connection
But this is more (duplicated) work.
Your code is fine if you have exactly one incoming connection.
I would like to extend it (in the future) like this:
- When incoming connections are enabled (you did that with the "passive"
interface by searching all pppoe* interfaces, a sysctl could do it as
well) create a new interface when receiving a PADI request and make it
handle the session establishement and initial PPP negotiation. Mark it
(internally) to need userland authentication.
- When an interface marked to nee userland authentication has LCP open
and receives authentication requests, it fires a kqueue event and queues
the request, but does not answer itself.
- A userland daemon wakes up on the kevent, picks up (via an ioctl) the
waiting authentication requests and makes the interface continue
via another ioctl. This way, a large database of possible users can
be managed in userland (i.e. querying a radius server).
- When userland ACKs the authentication, the interface continues as usual,
but is marked as "auto destory on LCP down". When LCP terminates, the
interface is destroyed.
- When userland NAKs or times out, the interface NAKs the request, maybe
retries, and finaly destroys itself when LCP terminates and the PPPoE
session is finished.
Maybe I left out a few details now, but I bet you get the idea.
Anyway, this is an optional (future) extension, it can easily be integrated
with your current code and can even run in parallel.
Martin