[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] Re: pppoe domU: did you test userspace rp-pppoe?



Peter Jakobi wrote:
On Fri, Nov 23, 2007 at 12:03:46AM +1100, kanour-xen wrote:
I just though that the rp-pppoe is loaded:
Nov 22 11:50:20 alsfw01 pppd[1542]: Plugin rp-pppoe.so loaded.
Nov 22 11:50:20 alsfw01 pppd[1542]: Linux kernel does not support PPPoE -- are you running 2.4.x?
Nov 22 11:50:20 alsfw01 pppd[1542]: Exit.

What is the difference between the rp-pppoe.so and the one which you are talking?

ok, here's what I came up with on looking at more recent systems
(but I cannot either remember or find why I avoided the original
kernel space version at around suse 7 or 8 and how that differed
on dial-on-demand; and there's not much to find online dated
more recent than end of '03, which argues for the stability of
the current solution).



looks like kernel and standalone rp pppoe implementations
are still at least somewhat distinct:

kernel:
/lib/modules/2.6.22-14-generic/kernel/drivers/net/pppoe.ko

depending on the kernel pppoe:
/usr/lib/pppd/2.4.4/rp-pppoe.so
        libc.so.6 => /lib/libc.so.6 (0x00002b3e7ed7b000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
loaded with passprompt.so and stuff into a pppd.

so you should have a closer look at the pppd, not just the kernel.


fully userspace:
/usr/sbin/rp-pppoe



some years ago, the pppd could be started with a userspace pppoe like this:

export EIF=eth2 # or similar - your external interface on the firewall
pppd pty "/usr/local/dist/DIR/pppoe/pppoe -m 1412 -I $EIF" noipdefault passive 
hide-password name "ACCOUNTNAME" idle 601 maxconnect 84500

- the  pty script option still exists (at least in the manpage).
- works with both the original code by luke stras (1999)
- and the rp-pppoe in version 1.3 [I think I'm sill using the compiled
  from source version, and I've patched at least the stras one to cope
  with the packet format peculiarities of t-online]
- as far as I've read in the docs and manpages, it should still work
when you install the pppoe/rp-pppoe package. WITHOUT depending on anything in the kernel.
- note that the above way to invoke pppd by script is avoiding
  pretty much all of your distro's configuration, network wrapping,
probably including protection via firewall (excluding of course problems via the default settings of the firewall), and a slew of pppd settings. - There should be options in /etc/ppp to allow running the pppd the standard distro way of the week with either kernel or standalone pppoe, resulting finally in commands similar to
  the above. Upto graphical frontends. But maybe the major
distros have stabilized and do less messing up a working network config files and arch by now.


funny: I've the .so on a recent system (not the old 1.3 I'm actually
using on my (old) firewall) as part of the ppp package. Without the
package pppoe being installed.

Looks like for e.g. ubuntu, rp-pppoe as a standalone [not using the .so]
is placed into the package pppoe, while a library version with less
support files, but depending on kernel pppoe has been folded into
pppd (the .so).

On fedora (e.g. centos 4.3), it's rp-pppoe instead for the standalone
and ppp for pppd with the .so file.



In general, less processes is better, so kernel pppoe module first,
then rp-pppoe standalone. Ease of use winner for me however was
(anno 2000) the rp-pppoe standalone. [I seem to remember the early
kernel pppoe being somewhat differently to use, with arguments to
avoid userspace to gain speed. But that might have been SuSE specific.
Currently it looks like it's always just using pppd for both cases, with
possibly the non-control packages handled only in kernel, and the
.so / pppoe kernel module enabling using an overloaded ethX as a
pty acc. to the docs (to validate ?). A possible speedup might
be to try configuring for "synch." ppp, which might take less cpu
(to validate)].

Using pppd with the standalone rp-pppoe should still work on _any_
kernel, _without_ loading pppoe modules.

Using pppd with the plugin seems to depend on modprobe pppoe
[see /usr/share/doc/ppp/README.pppoe; they might have removed some
of the package handling in the .so]. You should be able to autoload
the kernel module by adding "alias net-pf-24 pppoe" to /etc/modules.conf.

In both cases you still use the pppd as userspace front end,
in the standalone case however, the rp-pppoe program does all the lifting,
whereas with kernel pppoe / .so, some of the processing has been moved from
the early userspace down into the device layer of the kernel
(Documentation/networking/ppp_generic.txt; somewhat dated and still talking
about 2.4). But the more universal pppoe  implementation seems to still be
the userspace one.


Hi Peter. Thank you for this extensive explanation. It is good to know this. However, if read my thread the problem was solved by installing udev. Yes, it was so simple. As soon as I installed udev in domU, the error messages didn't come up and pppd started to work.

Thanks for your efford.

Jiri

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.