Commit Graph

5 Commits

Author SHA1 Message Date
keihan 6979203302 s/netbsd.org/NetBSD.org/g 2003-11-28 08:56:48 +00:00
oki 6873b338d6 Add support in-kernel PPPoE server.
This may work with one PPPoE session.
If you want to use it, #define PPPOE_SERVER in somewhere,
or add options PPPOE_SERVER in kernel config file.

This is experimental code, and good start point for future development.
2003-06-18 08:12:51 +00:00
martin e4998611e9 Fix copyright notice. 2002-04-14 12:24:26 +00:00
martin 99772f59c4 Move net/if_sppp.h to net/if_spppvar.h, create a new net/if_sppp.h
containing the userland visible thinks (i.e. ioctl definitions).

Remove all (both) old ioctls, as they had a brain dead API and made keeping
binary compatibility more or less impossible.

Replace by several new ioctls. While there, remove any arbitrary limits
(resulting from the old, broken ioctls) and allow any length of names
and passwords.
2002-01-04 12:21:24 +00:00
martin b5b75a7d19 Add an in-kernel PPPoE (ppp over ethernet, RFC 2516) implementation,
based on the existing net/if_spppsubr.c stuff.

While there are completely userland (bpf based) implementations available,
those have a vastly larger per packet overhead thus causing major CPU
overhead and higher latency. On an i386 base router, running a 486DX at 50MHz
my line (768kBit/s downstream) was limited to something (varying) between 10
and 20 kByte/s effective download rate. With this implementation I get full
bandwidth (~85kByte/s).

This is client side only. Arguably the right way to add full PPPoE support
(including server side) would be a variation of the ppp line discipline and
appropriate modifications to pppd. I promise every help I can give to anyone
doing that - but I needed this realy fast. Besids, on low memory NAT boxes
with typically a single PPPoE connection, this implementation is more
lightweight than a pppd based one, which nicely fits my needs.
2001-04-29 09:50:36 +00:00