Date: Tue, 09 Mar 1999 13:34:05 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: "Fadi Nasser" <fnasser@usa.alcatel.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: PPPoE server or client Unix implementation? Message-ID: <199903091834.NAA75886@whizzo.transsys.com> In-Reply-To: Your message of "Tue, 09 Mar 1999 09:53:40 PST." <36E56024.F9053624@usa.alcatel.com> References: <36E56024.F9053624@usa.alcatel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I read somewhere that somebody has posted the source code to a > PPP-over- Ethernet server (or client) to a FreeBSD newsgroup. I have > not had much luck finding the source code (or anything remotely > related to PPPoE) yet in any of the BSD groups. Would those of you > who are aware of such implementations please set me on the right > track. Your help is much appreciated. You might have seen a reference to a comment that I made. One of the Whistle folks had recently added (or was planning to?) netgraph support to if_ether.c, and I had commented that this now made it possible to do an efficient kernel-level implemention of PPP-over-Ethernet (PPPoE). At my "day job" at UUNET, we did a user-space implemention of PPPoE of both the "ciient" and "server" ends based upon the pppd code to implement the PPP state machine, etc. The TTY-specific code was replaced with code that used BPF to get ethernet frames on and off the network interface. This implementation was done as a proof-of-concept and testing vehicle during the development of the protocol spec (which was just recently published as an Informational RFC, RFC 2516, by the IETF). We wanted to be able to verify the protocol, and test against some vendor implementions, including in the Redback Networks access router and with the RouterWare client for Windows. Since this was a user-space implementation, built for comfort and not speed, we never intended it for real production use and thus haven't released it. Since with netgraph you can do the re-encapsulation in the kernel without context switches, you could get reasonable performance. This seems like a very promising implementation approach if you wanted to support megabit-per-second sorts of performance on a PPP session. We (UUNET) haven't pursued doing this implementation. Given a working netgraph-based kernel implementation of PPP with the control machinary to configure and operate it, the additional work required to do the PPPoE tunneling encapsulation should be pretty simple. As a quick aside: I'm sure there are those of you wondering why on earth you'd want to run PPP over Ethernet frames? Imagine that you have an Ethernet LAN at home or small business. You're using private IP addresses and doing whatever on that network. You'd like to get high-speed Internet connectivity, or perhaps telecommuting access using ADSL. You'd like to do this without breaking your existing network (renumbering, etc.) So, you get your ADSL CPE device, which is an ethernet bridge. You can now establish one or more PPP sessions by bridging encapsulated PPP frames (using their own Ethernet type, different than IP) to the thing at the other end of the ADSL wire. Each PPP session might have vastly different characteristics (performance, public Internet vs. corporate connectivity, etc.) You can think of it as very lightweight L2TP, but where the tunnel endpoints are not addressed using IP. See the RFC for more details if interested. louie (aka louie@UU.NET) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903091834.NAA75886>