Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Nov 1999 17:08:03 -0800
From:      Julian Elischer <julian@whistle.com>
To:        spork <spork@super-g.com>
Cc:        "Louis A. Mamakos" <louie@TransSys.COM>, freebsd-net@FreeBSD.ORG
Subject:   Announce: PPPoE for -curent and -stable now standard.
Message-ID:  <3839E8F3.446B9B3D@whistle.com>
References:  <Pine.BSF.4.00.9910031557440.3189-100000@super-g.inch.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Net type people.

As the Header annunces, FreeBSD now has a full implementation of 
PPPoE in -current. -Stable has all the kernel and ppp parts but 
not yet the pppoed that lets it serve pppoe sessions (only needs
MFC-ing)

Thanks go particularly to Brian who got a "deep end 
of the pool" introduction to Netgraph. And who did as much 
to debug my hacky netgraph code as another person could be
expected to put up with.

I chose this (old) message to respond to as it touched on a few things..


spork wrote:
> 
> This is from a company that sells win/mac/linux PPPoE implementations to
> ISP's (I came here after browsing the linux source on Sympatico's
> website).  Seems like a decent list of links:
> 
> http://www.nts.com/library/tlpppoe.html
> 
> There's a bit of info from sympatico at:
> 
> http://www.hse.sympatico.ca/en/community/download.htm
> 
> Charles
> 

Not that these are only partial implementations. I believe FreeBSD
to be a complete implementation of the PPPoE RFC. We can both serve
and request PPPoE sessions.



> > On Fri, 1 Oct 1999, Louis A. Mamakos wrote:
> >

> > > Uh, as one of the folks responsible for driving PPPoE development, I can
> > > assure that the last part of your remark wasn't one of the goals we had.
> > > It was, in fact, time-to-market given the existing bridged-ethernet
> > > capable hardware out there.  It was also to support simultanous connections
> > > to different service providers, and with different levels of service.  Think
> > > low-end, consumer user vs. work-at-home teleworkers.  Why shouldn't they
> > > be able to use the same ADSL pipe to support concurrent access to both
> > > e.g., AOL  for the kids (that you're paying for yourself) AND
> > > higher-performance
> > > access that your employer is paying for.

It turns out that the main ISPs who have implemented it allow only ONE 
MAC address per DSL connection. If you change ethernet cards you 
need to wait for the old one to timeout (apparently a day or so)
before the new one will work.

Or maybe you can call the ISP and get them to flush the MAC cache
entries.
(yeah right.. "duh, sorry sir, I don't understand")

This means that you cannot use the DSL line for > 1 machine 
unless you use the NAT feature of ppp of natd, and a second interface.
(good for us, bad for windows :-) 
This suprises me as you suggested it was a goal of pppoe.



> > >
> > > > Is there anyone actively working on PPPoE for FreeBSD?  I don't like the
> > > > whole concept of wrapping so many frames inside each other, but it would
> > > > be a shame if a bunch of folks with FBSD gateways for their home nets had
> > > > to move to Win98 and its' ICS (Internet Connection Sharing).  Blech.
> > > >
> > > > Could user/kernel ppp be modified?  How does this work anyhow?  Is there
> > > > an ethernet frame type for PPPoE?  How close do you have to get to the
> > > > ethernet driver to send PPPoE frames? Can any existing PPP implementations
> > > > easily handle a few megabits/sec on older hardware?
> > >
> > > We did a proof-of-concept implemention starting with the user-mode PPP
> > > daemon and using BPF to put frames on and off the wire, with no kernel
> > > changes.  This happened to be done on a BSDI system, but that's really
> > > not at all significant.

There is such a userland program available, anyone who wants it 
can contact me as I have a copy. (for those poor NetBSD/OpenBSD/BSDI
guys that
don't have Netgraph :-) It has very poor performance but works.

> > >
> > > I observed once before that the Whistle netgraph stuff is an ideal
> > > sort of solution for this type of problem where you're really concerned
> > > about performance, and don't want to context switch into a user process
> > > for each packet.
> >
> > I hope to start work on a netgraph/PPPoE module in the next day or so..
> > do you have any suggested reading?
> >

Well it took longer than expected as neither Brian nor I was working 
on it full time but I think everyone will be pleased by the result.
(see the netgraph(4), netgraph(3) ng_pppoe(8) ppp(8) and pppoed(8) 
man pages for details).

This will be improved even more when ppp learns to use netgraph to 
to ppp packet processing totally in the kernel. (we already have it 
working under mpd). This will result in NO kernel boundary crossings 
for ppp processing.

Have a look at it and netgraph. Comments are welcome.

Julian


-- 
+------------------------------------+       ______ _  __
|   __--_|\  Julian Elischer         |       \     U \/ / On assignment
|  /       \ julian@Whistle.com      +------>x   USA    \ in a strange
| (   OZ    ) 110 Marsh dr. Foster City, CA  \___   ___ | country !
+- X_.---._/  USA+(650) 577-7063 (wk)            \_/   \\
          v


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?3839E8F3.446B9B3D>