OpenBSD Journal

In kernel PPPoE client

Contributed by mk/reverse on from the less mode switches dept.

Foxy was the first to write us about this:

According to this CVS commit log, the kernel now has a PPPoE client:

In kernel pppoe client, a simple IPv4 only implementation.
Initial porting from NetBSD by David Berghoff.
Modified/simplified to match our sppp implementation.
ok deraadt@

Quite a few people have requested this over the years, so be sure to check this out and give it a thorough testing. Also, be sure to report all problems you might encounter, and try doing some debugging.

(Comments are closed)


  1. By Anonymous Coward () on

    Yes, this might be a dumb question for some, but an un-asked question is even dumber... ;) What's the advantage/dis-advantage of an in-kernel pppoe client vs userland - or even, what's the main difference(s)? TIA!

    1. By James () on

      First google hit: http://www.jraitala.net/comp/articles/2002/pppoe/

    2. By Michael Knudsen () on

      > Yes, this might be a dumb question for some, but an un-asked question
      > is even dumber... ;) What's the advantage/dis-advantage of an in-kernel
      > pppoe client vs userland - or even, what's the main difference(s)? TIA!

      The main advantage is a performance gain which comes from not doing two things:

      • Copying packets between userland and kernel
      • Mode/context switches from kernel to userland (and this is really expensive if it's done once per packet)
      The main disadvantage (at least that I can come up with) is added complexity to the kernel.

  2. By Rodolfo Gouveia () on

    It's www.benzedrine.cx instead of just benzedrine.cx

    1. By Michael Knudsen () on

      Works for me.

      1. By Anonymous Coward () on

        The link provided on-top doesn't work for me either... Linked to http://benzedrine.cx/crashreport.html whereas the parent poster is saying http://www.benzedrine.cx/crashreport.html works, instead.

        1. By Michael Knudsen () on

          Well, it still works for me, but now I've updated the link anyway.

  3. By SeppoE () on

    or does it go into 3.7 or can I get it by cvsup'ing 3.6-src and do I have to rebuild the whole world :?

    1. By Michael Knudsen () on

      Unless serious errors are found in the code, it will go in 3.7. You can update your 3.6 source with ``cvs up -PdA'' or whatever takes you to HEAD with cvsup. If you're on 3.6 or 3.6-stable now, you should rebuild your entire system. If you're on (almost) -current, building the kernel and ifconfig(8) may be enough but I wouldn't bet on it.

    2. By phessler () on

      It only exists in -current. Not in -stable. Upgrade to a very recent snapshot, and that'll get it for you.

    3. By Anonymous Coward () on

      I don't know if this is the same patch, but I was using it since 3.5 and now for 3.6-stable: http://www.openbsd.de/~merith/

  4. By tom () tom@replic8.net on

    many THANKS go to david berghoff for all his porting efforts!

    i did some "performance testing" using halo 2 on a xbox,
    running http://www.teamxlink.co.uk/ to get around the nasty
    microsoft xbox live service.

    the new pppoe-client performs like a champ! true gaming
    experience! no-lag! security-hassle-free-enjoyment! :>

    to sum it up, my gaming experience is improved by far,
    i'm now able to host halo 2 games with up to 16 people
    without any lag :D

    (well, a bit offtopic, but i wanted to point out how
    much FUN OpenBSD can be :)

    1. By x () on

      Does it change something to use pppoe ?

      1. By tom () tom@replic8.net on

        well in terms of halo2 it just lags less than before playing online.
        i haven't measured anything. my impression is subject to subjectivity :)

  5. By Luiz Gustavo () on http://hades.uint8t.org

    Works for me, I just miss the ppp.(linkup|linkdown).
    ifstated(8) here we come...

  6. By Anonymous Coward () on

    I would just like to remind everyone that PPPoE isn't the only option. PPPoE slows down your connection quite a bit for no good reason. You can get much faster speeds over the same connection when not using PPPoE.

    Just about the exclusive realm of PPPoE is DSL, and you'd be better served switching DSL providers to one that doesn't use PPPoE at all.

    1. By Anthony () on

      "Just about the exclusive realm of PPPoE is DSL, and you'd be better served switching DSL providers to one that doesn't use PPPoE at all."

      Yes. Because in today's broadband market, there's always plenty of competition.

    2. By Anonymous Coward () on

      Unfortunately, only PPPoE ADSL services are readily available in my country. Which sucks.

    3. By chort () on http://www.smtps.net/email-sec/

      Being able to choose your DSL provider is a luxury that few have. I live in Silicon Valley, so of course there are plenty of choices. In heavily populated areas you're likely to have more choices, but in rural and/or less technically developed areas, your only choice is likely the telco, and for some reason the telcos love PPPoE (furthering my belief that all telcos are spawned of SATAN).

      Before settling for the sub-standard service that your telco ISP offers, check if you do have the opportunity to choose Speakeasy.net or Sonic.net--I would highly recommend them.

      --
      chort

      1. By Jason Wright () jason@openbsd.org on http://www.thought.net/

        Well, I talked with some of the authors of the PPPoE RFC at USENIX awhile back... ok, so I was ranting about what I thought about the protocol =)

        The response was essentially, "Well, it's not as bad as the alternatives that were floating about at the time." Point taken...

        I'm not disputing the fact that telco's ARE spawned from ${DEVIL}, but they could have done worse. How about ATM over Ethernet... yeah yeah...

        1. By mirabile () on http://mirbsd.de/

          Actually, telcos are usually doing IPv4 over PPP over Ethernet
          (PPPoE) over AAL5 over ATM for ADSL access...

          That's why the optimum MTU is 1454, not 1492, too - refer to
          http://www.mynetwatchman.com/kb/adsl/pppoemtu.htm

  7. By Anonymous Coward () on

    I'm planning on upgrading my firewall to 3.6-CURRENT soon so I will try this for myself, but I am curious:

    If my machine (p166, 254MB RAM) is currently able to handle usermode pppoe on my 1Mbps ADSL connection, will kernelmode pppoe make it any faster?

    For example, will there be reduced lag since the copying of packets from user space to kernel space is eliminated?

    At present, ppp hovers around 10% CPU.

    Thanks.

    1. By Anonymous Coward () on

      I think you mean just -CURRENT.

    2. By Nathan Houghton () nate AT ocalafl dot net on http://www.brainwerk.org

      In kernel PPPoE should help a bit, especially on a lower end box like the one you have... 1mbit is not too heavy, so you may not actually notice a big speed improvement if the box is exclusively used for pppoe/pf/nat/etc. processor usage should go down a bit though, so other tasks should go a bit faster.

      http://www.jraitala.net/comp/articles/2002/pppoe/
      An interesting benchmark regarding the speeds of the different PPPoE implementations. Since the code is based heavily on netbsd I think the performance should be quite good.

      For example in that article openbsd 3.2 used about 99% cpu on a ~2.5mbit connection, on netbsd with kernel mode pppoe it was using 23% on a ~8.5mbit connection.. quite a bit nicer :] The test machine was a 90mhz.

  8. By tobold () on

    Thank you a thousand times! I had some real troubles with the userland pppoe some times, this will now all be gone.

    Thanks!

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]