https://github.com/dfskoll/rp-pppoe/blob/master/src/configure.ac#L136

these modprobe statements in the configure.ac are redundant - the package still needs to be built for containers that can't modprobe, or for local user without elevation, and when it can modprobe, the unexpected modules loaded leads to a breach of security policy in my environment.
Theres got to be a better way, we are locking configure scripts down.

-Thanks

The latest version of rp-pppoe: 2023-01-04
ppp version number: 2.4.8-2020-10-03
Error compiling openwrt-21-02 x86 firmware!

I tested the openwrt-21.02 compiled file rp-pppoe
https://github.com/openwrtdiy/packages/blob/pppoe-21.02/net/rp-pppoe/Makefile

https://github.com/openwrtdiy/rp-pppoe/tree/20230104

Could you please add the ability to trigger a PADT if PADO/PADI times out?
My ISP uses a Cisco access concentrator that will become very quiet for 30 or more minutes after too many PADI/PADO failures happen until/unless a PADT is sent. I'm using RP-PPPoE from the OpenWRT project, current stable as of this post.

Currently pppoe-server always allocates an IP address, it would be beneficial to enable delegation of IP addresses to the pppd process itself since that would allow various mechanisms for IP allocation including radius addressing (eg, using Framed-Pool or even Framed-IP-Address for clients with static IPs).

I believe it may currently be possible for pppd to override the IPs assigned from pppoe-server, however, if both pppoe-server and pppd are allocating IPs it just seems like a recipe for trouble.

It may, in future, also make pure IPv6 deployments possible, once something like 464-xlat is in place to enable clients that really do need IPv4 and won't have it on the ppp itself.

At least the ability to get static IPs assigned from radius, without taking IPs out of the normally used pool, is relatively important for us in the short term.

Delegation would also mean that if there is a client that keeps failing authentication that we don't bounce IPs on those clients since IP allocation would then only happen once LCP has been established as part of IPCP. Since there shouldn't be a great number of these clients this shouldn't be a problem, but if you have a disgruntled customer ... they can in theory flood the L2 with numerous pppoe establishments resulting in a possible denial of service to legitimate customers.

I compiled rp-pppoe version 4 against pppd version 2.5.0 and I'm encountering issues with the client connection. The log output is not clear about the exact problem. Here's an example:

pppoe-server[107684]: Session 33 created for client bc:24:11:04:cf:a9 (100.103.0.36) on ens18 using Service-Name ''
pppd[107684]: Plugin /etc/ppp/plugins/rp-pppoe.so loaded.
pppd[107684]: RP-PPPoE plugin version 4.0 compiled against pppd 2.5.0
pppd[107684]: Plugin /usr/local/lib/pppd/2.5.0/radius.so loaded.
pppd[107684]: RADIUS plugin initialized.
pppd[107684]: Plugin /usr/local/lib/pppd/2.5.0/radattr.so loaded.
pppd[107684]: RADATTR plugin initialized.
pppd[107684]: pppd 2.5.0 started by root, uid 0
pppd[107684]: Connected to bc:24:11:04:cf:a9 via interface ens18
pppd[107684]: using channel 128
pppd[107684]: Using interface ppp0
pppd[107684]: Connect: ppp0 <--> ens18
pppd[107684]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x74c2651a>]
pppd[107684]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x74c2651a>]
pppd[107684]: rcvd [LCP ConfReq id=0x1 <mru 1492> <magic 0xa2569440>]
pppd[107684]: sent [LCP ConfAck id=0x1 <mru 1492> <magic 0xa2569440>]
pppd[107684]: sent [LCP EchoReq id=0x0 magic=0x74c2651a]
pppd[107684]: rcvd [LCP EchoReq id=0x0 magic=0xa2569440]
pppd[107684]: sent [LCP EchoRep id=0x0 magic=0x74c2651a]
pppd[107684]: rcvd [PAP AuthReq id=0x1 user="0511774" password=]
pppd[107684]: sent [PAP AuthNak id=0x1 "RADIUS: Can't read config file /etc/radcli/radiusclient.conf"]
pppd[107684]: PAP peer authentication failed for 0511774
pppd[107684]: sent [LCP TermReq id=0x2 "Authentication failed"]
pppd[107684]: rcvd [LCP EchoRep id=0x0 magic=0xa2569440]
pppd[107684]: rcvd [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
pppd[107684]: sent [LCP TermAck id=0x2]
pppd[107684]: rcvd [LCP TermAck id=0x2]
pppd[107684]: Connection terminated.
pppd[107684]: Fatal signal 11
pppoe-server[23464]: Session 33 closed for client bc:24:11:04:cf:a9 (100.103.0.36) on ens18
pppoe-server[23464]: Sent PADT

Especially in this section:

pppd[107684]: sent [PAP AuthNak id=0x1 "RADIUS: Can't read config file /etc/radcli/radiusclient.conf"]

I believe it might be related to a dictionary attribute, but it's not reporting as previous versions did.

The pppd package is not clearly indicating where the error is occurring, making it difficult to diagnose the issue.

Hello, brother

OS: Docker Centos7

cd rp-pppoe-master/src
./configure --enable-plugin
make

Here are the errors encountered

gcc 4.8.5
control_socket.c: In function 'control_socket_handle_command': control_socket.c:58:2: error: parameter name omitted void* _subs, void*) ^ control_socket.c:67:2: error: 'for' loop initial declarations are only allowed in C99 mode for (ControlCommand *i = subs; i->command; ++i) { ^ control_socket.c:67:2: note: use option -std=c99 or -std=gnu99 to compile your code control_socket.c:89:2: error: 'for' loop initial declarations are only allowed in C99 mode for (int i = 0; i < argi; ++i) { ^ control_socket.c:96:5: error: 'for' loop initial declarations are only allowed in C99 mode for (ControlCommand *i = subs; i->command; ++i) { ^ control_socket.c: In function 'control_socket_cleanup_client': control_socket.c:109:5: error: 'for' loop initial declarations are only allowed in C99 mode for (int i = client->ctxi; i >= 0; --i) { ^ control_socket.c: In function 'control_socket_push_context': control_socket.c:121:5: warning: implicit declaration of function 'reallocarray' [-Wimplicit-function-declaration] ClientContext *t = reallocarray(client->context, client->ctxi + 2, sizeof(*client->context)); ^ control_socket.c:121:24: warning: initialization makes pointer from integer without a cast [enabled by default] ClientContext *t = reallocarray(client->context, client->ctxi + 2, sizeof(*client->context)); ^ make: *** [control_socket.o] Error 1

gcc 9.3.1

cc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes '-DPPPOE_PATH="/usr/sbin/pppoe"' '-DPPPD_PATH="/usr/local/sbin/pppd"' '-DPLUGIN_PATH="/etc/ppp/plugins/rp-pppoe.so"' '-DPPPOE_SERVER_OPTIONS="/etc/ppp/pppoe-server-options"' -Ilibevent -c -o control_socket.o control_socket.c control_socket.c: In function 'control_socket_handle_command': control_socket.c:58:15: error: parameter name omitted 58 | void* _subs, void*) | ^~~~~ control_socket.c: In function 'control_socket_push_context': control_socket.c:121:24: warning: implicit declaration of function 'reallocarray' [-Wimplicit-function-declaration] 121 | ClientContext *t = reallocarray(client->context, client->ctxi + 2, sizeof(*client->context)); | ^~~~~~~~~~~~ control_socket.c:121:24: warning: initialization of 'ClientContext *' {aka 'struct ClientContext *'} from 'int' makes pointer from integer without a cast [-Wint-conversion] make: *** [control_socket.o] Error 1

Another crazy idea, that may or may not be viable.

Given a restart signal, somehow encode data required to reconstruct state prior to an execve, such that the replacing process (which may be a newer version of pppoe-server) can reconstruct internal state, and continue on keeping existing sessions and interfaces.

For now just let this rest here to think about, this would be non-trivial to say the least and I don't see that upgrades to pppoe-server itself is something that would happen frequently.

Hi,
Trying to upgrade to the latest rp-pppoe (from the 3.12 release!). Using userspace pppoe with the latest pppd. pppoe is invoked by pppd as pppoe -I eth2 -m 1412, nothing fancy, the interface exists, etc.

pppoe busyloops around the select() call: strace shows the following line endlessly repeated:

select(5, [0 3 4], NULL, NULL, NULL)    = 1 (in [4])

Looking at the code, it appears that the culprit is the session() function. fd 4 is conn→discoverySocket, which triggers... but there is no handling for FD_ISSET(conn→discoverySocket, &readable)! So the function loops with an event on the discovery socket that is never read or handled.

By comparison, rp-pppoe 3.12 has the following code snippet to handle that case:

#ifndef USE_BPF
        /* BSD uses a single socket, see *syncReadFromEth() */
        /* for calls to sessionDiscoveryPacket() */
        if (conn->discoverySocket >= 0) {
            if (FD_ISSET(conn->discoverySocket, &readable)) {
                sessionDiscoveryPacket(conn);
            }
        }
#endif

(and I'm not sure what's supposed to happen if USE_BPF is defined, but I don't use BPF so it works for me.)

So, is there anything I'm supposed to do with that discovery socket with the current rp-pppoe git? Or is the code just missing the event handling?

Thanks!

The pppoe-status script will fail when pppd is using the option ifname xxx to set the ppp devicename to something other than pppX.

The logic in https://github.com/dfskoll/rp-pppoe/blob/master/scripts/pppoe-status#L66-L81 assumes, that the ppp-device.pid file contains just the process id of the pppd process.

When the parameter linkname is used however, the pid file contains two lines. The first line is the PID, the second line is the interface name. The corresponding pppd code is at https://github.com/ppp-project/ppp/blob/c2881a6b71a36d28a89166e82820dc5e711fd775/pppd/main.c#L826-L844 with the code adding the second line being at https://github.com/ppp-project/ppp/blob/c2881a6b71a36d28a89166e82820dc5e711fd775/pppd/main.c#L837-L838.

A quick fix that adds support for the two line pid file and allows pppoe-status to work again could look like this:

for i in /etc/ppp/ppp*.pid /var/run/ppp*.pid ; do
    if [ -r $i ] ; then
        if [ "$(wc -l $i | cut -c 1)" = 2 ]; then
            PID=`cat $i | head -n 1`
        else
            PID=`cat $i`
        fi
        if [ "$PID" = "$PPPD_PID" ] ; then
            if [ "$(wc -l $i | cut -c 1)" = 2 ]; then
                IF=`cat $i | tail -n 1`
            else
                IF=`basename $i .pid`
            fi
            $IP route | grep "dev ${IF}\s" > /dev/null
            if [ "$?" != "0" ] ; then
                echo "pppoe-status: Link is attached to $IF, but $IF is down"
                exit 1
            fi
            echo "pppoe-status: Link is up and running on interface $IF"
            $IP addr show $IF
            exit 0
        fi
    fi
done

But I am sure there's a nicer way...

I have no idea on how to do this, but some form of compile test on code submissions at least would be an excellent step forward.

In order to load balance between multiple nodes, and to improve balancing, it may be beneficial to delay responses to PADI frames in some way.

For example, we currently have fail-overs to Mikrotik nodes where we have an option on the pppoe-servers to have a PADO delay, specifically, as an example:

[admin@somewhere] /interface pppoe-server> export
...
add disabled=no interface=xxxx max-mru=1500 max-mtu=1500 \
    one-session-per-host=yes pado-delay=10 service-name=foobob

(Note the PADO delay option.)

What I'm suggesting is a "base delay" combined with a linear increment as the number of active session increase over a certain count, eg:

base delay: 500ms
increment: 10ms
delay sessions: 250

So the moment we hit 250 active sessions, then we start delaying PADO transmission by 500ms, when we reach 300 active session we delay 500ms + (300 - 250) * 10ms/ = 1000ms, in this way less loaded pppoe-servers should be preferred by new clients.

This can also be used to have more of an active-standby approach. Primary server never delays, backup always delays by some amount.

The one challenge here would be that we'd need a transmission queue and integrate this into an event loop somewhere to tx at the right time (or close enough to the right time).

This is extremely low priority currently, but another of those ideas I'd prefer to not lose track off.

Hi @dfskoll

I note you updated a few things in preperation for the 3.16 release, so I went off to try and get that packaged for Gentoo to start my own testing ... just to find it's not actually released yet - or am I missing something?

What's the plan?

(Not looking to apply pressure, just looking to understand your timelines and thought patterns here.)

Kind Regards,
Jaco

After installed PPPoE Server in Ubntu https://src.fedoraproject.org/repo/pkgs/rp-pppoe/rp-pppoe-4.0.tar.gz/ while running PPPOE Server getting error like "pppoe: ioctl(SIOCGIFHWADDR): No such device" Any one help me on this issue.

Apr 25 19:08:55 rnd-test systemd[1]: Stopped =PPPoE-Server.
Apr 25 19:08:55 rnd-test systemd[1]: Started =PPPoE-Server.
Apr 25 19:08:55 rnd-test pppoe-server[13517]: pppoe: ioctl(SIOCGIFHWADDR): No such device
Apr 25 19:08:55 rnd-test pppoe-server[13517]: ioctl(SIOCGIFHWADDR): No such device
Apr 25 19:08:55 rnd-test systemd[1]: pppoe.service: Main process exited, code=exited, status=1/FAILURE
Apr 25 19:08:55 rnd-test systemd[1]: pppoe.service: Failed with result 'exit-code'.
Apr 25 19:08:55 rnd-test systemd[1]: pppoe.service: Scheduled restart job, restart counter is at 5.
Apr 25 19:08:55 rnd-test systemd[1]: Stopped =PPPoE-Server.
Apr 25 19:08:55 rnd-test systemd[1]: pppoe.service: Start request repeated too quickly.
Apr 25 19:08:55 rnd-test systemd[1]: pppoe.service: Failed with result 'exit-code'.
Apr 25 19:08:55 rnd-test systemd[1]: Failed to start =PPPoE-Server.
Apr 25 19:08:56 rnd-test geoclue[1330]: Failed to query location: Error resolving “location.services.mozilla.com”: Temporary failure in name resolution
Apr 25 19:09:00 rnd-test systemd[1]: Starting Clean php session files...
Apr 25 19:09:00 rnd-test systemd[1]: phpsessionclean.service: Deactivated successfully.
Apr 25 19:09:00 rnd-test systemd[1]: Finished Clean php session files.
Apr 25 19:09:01 rnd-test CRON[13589]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)

sudo systemctl restart pppoe.service
rnd-test@rnd-test:/etc/systemd/system$ sudo systemctl status pppoe.service
× pppoe.service - =PPPoE-Server
Loaded: loaded (/etc/systemd/system/pppoe.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2024-04-25 19:15:37 IST; 4s ago
Process: 14303 ExecStart=/usr/sbin/pppoe-server (code=exited, status=1/FAILURE)
Main PID: 14303 (code=exited, status=1/FAILURE)
CPU: 3ms

Apr 25 19:15:37 rnd-test systemd[1]: pppoe.service: Scheduled restart job, restart counter is at 5.
Apr 25 19:15:37 rnd-test systemd[1]: Stopped =PPPoE-Server.
Apr 25 19:15:37 rnd-test systemd[1]: pppoe.service: Start request repeated too quickly.
Apr 25 19:15:37 rnd-test systemd[1]: pppoe.service: Failed with result 'exit-code'.
Apr 25 19:15:37 rnd-test systemd[1]: Failed to start =PPPoE-Server.

Hello, I woild like to report a weird regression/bug (hopefully github is the right place, I saw more activity here than on the debian repo) with recent versions of pppoe in userspace:

For example for my isp connection I have this config:

pty '/usr/sbin/pppoe -s -I enp3s0.835' sync
noauth
# rest of the file

that will produce this result:

$ sudo pppd call myisp
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
CHAP authentication succeeded
CHAP authentication succeeded
local  IP address -
remote IP address -
primary   DNS address -
secondary DNS address -
pppoe: read (syncReadFromPPP): Session 58587: Value too large for defined data type
Modem hangup
Connect time 0.1 minutes.
Sent 5110 bytes, received 1780 bytes.
Connection terminated.
Using interface ppp0
Connect: ppp0 <--> /dev/pts/3
^CTerminating on signal 2
Modem hangup
Connection terminated.

This seems indipendent from my ISP being stupid or some problem specific of routing through a vlan, as other users have reported the same problem: https://bbs.archlinux.org/viewtopic.php?pid=2155419#p2155419

Incidentally if I switch to the kernel module by doing:

plugin /usr/lib/rp-pppoe/rp-pppoe.so nic-enp3s0.835
noauth
# rest of the file

everything seems to work fine and indeed I get a nice stable connection:

$ sudo pppd call myisp
Plugin /usr/lib/rp-pppoe/rp-pppoe.so loaded.
RP-PPPoE plugin version 4.0 compiled against pppd 2.5.0
Connected to -snip- via interface enp3s0.835
Using interface ppp0
Connect: ppp0 <--> enp3s0.835
CHAP authentication succeeded
CHAP authentication succeeded
peer from calling number -snip- authorized
local  IP address -
remote IP address -
primary   DNS address -
secondary DNS address -
local  LL address -
remote LL address -
[everything fine from here on]

I tried having a look through the code and the error seems unequivocally generated from here and since it's picking up a syscall error over type sizes, perhaps it is some weird interaction with more recent Linux kernels, or possibly a miscompilation on the part of arch maintainers?

Hi

1. How to prevent duplicated sessions ?
2. It is possible to force client MTU ?

:)

Currently the list of PPPoE interfaces is specified on the CLI with -I.

I suggest implementing an option whereby a file with a list of interfaces can be given, one per line (ideally with an option for comments, or a space separated comment (We currently have around 70 interfaces).

Currently one could run an instance per interface, but this requires an IP Pool per instance (without #8 - which would still allow a combined pool).

The downside of instance per interface (or group of interfaces) even with #8 is higher memory use, although, I suspect this is overall fairly negligible.

Type 'make install' as root to install the software.
mkdir -p /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/sbin
/usr/bin/install -c -m 755 pppoe /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/sbin
/usr/bin/install -c -m 755 pppoe-server /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/sbin
if test -x pppoe-relay ; then /usr/bin/install -c -m 755 pppoe-relay /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/sbin; fi
if test -x pppoe-sniff; then /usr/bin/install -c -m 755 pppoe-sniff /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/sbin; fi
/usr/bin/install -c -m 755 ../scripts/pppoe-connect /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/sbin
/usr/bin/install -c -m 755 ../scripts/pppoe-start /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/sbin
/usr/bin/install -c -m 755 ../scripts/pppoe-status /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/sbin
/usr/bin/install -c -m 755 ../scripts/pppoe-stop /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/sbin
/usr/bin/install -c -m 755 ../scripts/pppoe-setup /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/sbin
mkdir -p /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/share/doc/rp-pppoe-3.15
/usr/bin/install -c -m 644 ../doc/CHANGES /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/share/doc/rp-pppoe-3.15
/usr/bin/install -c -m 644 ../doc/KERNEL-MODE-PPPOE /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/share/doc/rp-pppoe-3.15
/usr/bin/install -c -m 644 ../doc/HOW-TO-CONNECT /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/share/doc/rp-pppoe-3.15
/usr/bin/install -c -m 644 ../doc/LICENSE /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/share/doc/rp-pppoe-3.15
/usr/bin/install -c -m 644 ../README /home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/ipkg-install/usr/share/doc/rp-pppoe-3.15
/usr/bin/install: cannot stat '../README': No such file or directory
Makefile:151: recipe for target 'install' failed
make[4]: *** [install] Error 1
make[4]: Leaving directory '/home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/src'
Makefile:148: recipe for target '/home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/.built' failed
make[3]: *** [/home/kokang/openwrtdiy/build_dir/target-x86_64_musl/rp-pppoe-2022.04.24/.built] Error 2
make[3]: Leaving directory '/home/kokang/openwrtdiy/feeds/packages/net/rp-pppoe'
time: package/feeds/packages/rp-pppoe/compile#3.71#1.63#6.74
package/Makefile:111: recipe for target 'package/feeds/packages/rp-pppoe/compile' failed
make[2]: *** [package/feeds/packages/rp-pppoe/compile] Error 2
make[2]: Leaving directory '/home/kokang/openwrtdiy'
package/Makefile:107: recipe for target '/home/kokang/openwrtdiy/staging_dir/target-x86_64_musl/stamp/.package_compile' failed
make[1]: *** [/home/kokang/openwrtdiy/staging_dir/target-x86_64_musl/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/kokang/openwrtdiy'
/home/kokang/openwrtdiy/include/toplevel.mk:225: recipe for target 'world' failed
make: *** [world] Error 2

Currently the -p argument takes a file, which gets loaded once-off during startup, there are two possible strategies that can be followed for dynamic reload:

1. explicit signal for reload (which then has the potential to reload more than simply the pool).
2. Automatically whenever the file changes (stat, mtime newer than last load).

Both strategies to me seems sensible the former is probably a safer option as it requires explicit action from the administrator to make things effective.

Just looking at the code, it looks like:

1. It's possible that during a reload, NumSessionsSlots may increase or decrease, with potentially catastrophic consequences, especially for increase.
2. The IP addresses may be in a different ordering, and an active session will on ppp side at least retain the OLD IP, thus duplicate IP addresses are suddenly possible unless care is taken.
3. The address count in the pool file overrides -N (which is probably by design).

Given the above, it may just be simpler to implement ip address delegation (#8), and rely on an ip pool daemon / radius rather than implement this.

@dfskoll: Thanks, rp-pppoe is now on GitHub!

Request history:

• https://dianne.skoll.ca/pipermail/rp-pppoe/2021q3/000623.html
• https://dianne.skoll.ca/pipermail/rp-pppoe/2021q3/000624.html
• https://dianne.skoll.ca/pipermail/rp-pppoe/2021q4/000626.html
• https://dianne.skoll.ca/pipermail/rp-pppoe/2021q4/000627.html
• https://dianne.skoll.ca/pipermail/rp-pppoe/2021q4/000628.html
• https://dianne.skoll.ca/pipermail/rp-pppoe/2021q4/000629.html

cc: @jkroonza.