Eivind Næss [Fri, 6 Aug 2021 17:06:17 +0000 (10:06 -0700)]
Changing defines for CHAPMS, MSLANMAN, MPPE to prefix with PPP_WITH_*
To avoid bleeding over to third party projects. They are all
defined and exported by pppdconf.h either way. These projects
will stil have a consistent view of how pppd was compiled.
Eivind Næss [Fri, 6 Aug 2021 16:14:02 +0000 (09:14 -0700)]
Changing INET6 to PPP_WITH_IPV6CP and adding configure option
Based on feedback on PR #296, the option ipv6-support seems inconsistent
with the existing ipxcp option. Futhermore, the #define has been renamed
to avoid bleeding into third party projects.
pppdconf.h is already distributed and will define or undefine the
PPP_WITH_IPV6CP define.
pppd: Add support for registering ppp interface via Linux rtnetlink API
pppd currently creates ppp network interface via PPPIOCNEWUNIT ioctl API.
This API creates a new ppp network interface named "ppp<unit_id>". If user
supply option "ifname" with custom network name then pppd calls SIOCSIFNAME
ioctl to rename "ppp<unit_id>" to custom name immediately after successful
PPPIOCNEWUNIT ioctl call. If custom name is already registered then
SIOCSIFNAME ioctl fails and pppd close current channel (which destroy also
network interface).
This has side effect that in the first few miliseconds interface has
different name as what user supplied.
Tools like systemd, udev or NetworkManager are trying to query
interface attributes based on interface name immediately when new
network interface is created.
But if interface is renamed immediately after creation then these tools
fails. For example when running pppd with option "ifname ppp-wan" following
error is reported by systemd / udev into dmesg log:
[ 35.718732] PPP generic driver version 2.4.2
[ 35.793914] NET: Registered protocol family 24
[ 35.889924] systemd-udevd[1852]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
[ 35.901450] ppp-wan: renamed from ppp0
[ 35.930332] systemd-udevd[1852]: link_config: could not get ethtool features for ppp0
[ 35.939473] systemd-udevd[1852]: Could not set offload features of ppp0: No such device
There is an easy way to fix this issue: Use new rtnetlink API.
Via rtnetlink API it is possible to create ppp network interface with
custom ifname atomically. Just it is not possible to specify custom ppp
unit id.
So use new rtnetlink API when user requested custom ifname without custom
ppp unit id. This will avoid system issues with interface renaming as ppp
interface is directly registered with specified final name.
This has also advantage that if requested interface name already exists
then pppd fail during registering of networking interface and not during
renaming network interface which happens after successful registration.
If user supply custom ppp unit id then it is required to use old ioctl API
as currently it is the only API which allows specifying ppp unit id.
When user does not specify custom ifname stay also with old ioctl API.
There is currently a bug in kernel which cause that when empty interface is
specified in rtnetlink message for creating ppp interface then kernel
creates ppp interface but with pseudo-random name, not derived from ppp
unit id. And therefore it is not possible to retrieve what is the name of
newly created network interface. So when user does not specify interface
name via "ifname" option (which means that want from kernel to choose some
"free" interface name) it is needed to use old ioctl API which do it
correctly for now.
eap-tls.c: In function 'ssl_msg_callback':
eap-tls.c:1284:10: error: 'SSL3_RT_HEADER' undeclared (first use in this function); did you mean 'SSL3_RT_ALERT'?
1284 | case SSL3_RT_HEADER:
| ^~~~~~~~~~~~~~
| SSL3_RT_ALERT
Paul Mackerras [Mon, 4 Jul 2022 07:37:31 +0000 (17:37 +1000)]
pppd: Add dummy noipx option
Add "noipx" as an option that does nothing to avoid breaking
installations that have "noipx" in /etc/ppp/defaults or wherever.
(The IPX-related options were removed by commit c2881a6b71a3 ("pppd:
Drop linux IPX support (#326)", 2022-01-13)).
Jaco Kroon [Tue, 17 May 2022 08:05:27 +0000 (10:05 +0200)]
pppd/auth: Pass ipparam to auth-up and auth-down scripts
ipparam is the only way a system administrator has of passing arbitrary
information from options files to scripts, and this may be useful during
auth-up in particular. (If upstream pppd had support for an auth-fail
script, it could be useful there too.)
Signed-off-by: Jaco Kroon <jaco@uls.co.za> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Need to update the esp->ea_client.ea_namelen variable. A plugin can override the
name of the user, and the variable is passed onto the eap_chap2_response generating
the wrong response length.
Richard Purdie [Thu, 13 Jan 2022 06:48:14 +0000 (06:48 +0000)]
pppd: Drop linux IPX support (#326)
The 5.15 Linux kernel has removed ipx support, along with the userspace
visible header. This support wasn't very well maintained in the kernel
for several years so drop the support from ppp as well since this won't
be usable in future.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Jaco Kroon [Thu, 13 Jan 2022 06:38:04 +0000 (08:38 +0200)]
Expand byte count statistics to 64 bits (#298)
* Add Gigawords to radius packets where applicable.
IMPORTANT NOTE: The ioctl() only supports 32-bit counters. In order t
obtain 64-bit counters, these are now pulled in from sysfs (it's assumed
to be mounted on /sys which I'm assuming is standard).
It is unknown whether sysfs will be available everywhere, as such, keep
the ioctl() method in place, but attempt to detect wrap-overs.
If the sysfs mechanism fails, fail back to the ioctl().
Given maximum data rates, the intervals between calling this needs to be
such that no more than 4GB (2^32) bytes are sent or received in any
given interval. Mostly important for radius plugin where data
accounting may be in effect.
Towards this, a timer interval on 25 seconds is set to force a ioctl()
poll irrespective of the rate of stats update calls. This may be
important for especially radius that needs to provide interim-update
intervals, if the interim updates is too long and the counters could
wrap-over twice in a single interval. At 25 seconds we should detect
all wraps up to an effective data rate of 1.37Gbps, which for my
purposes is adequate.
Possible downsides, 4 files are opened, read and closed every time
statistics is requested. This results in 12 system calls every single
time statistics is required, compared to 1 for the ioctl. Efficiency is
unknown, but as a rule of thumb fewer system calls are better, this is
however not a critical path in my opinion, so should not be a problem.
If required I can run a few benchmarks using gettimeofday() to measure
actual impact.
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
* Use netlink if possible to obtain 64-bit stats.
This uses two system calls per round.
This should be preferred where available. It seems the RTM_GETSTATS was
only added from 2016 some point (4.7.0 as per pali), which is in my
opinion old, but given experience with certain embedded systems does
need to be supported.
Pali Rohár [Tue, 21 Dec 2021 17:10:27 +0000 (18:10 +0100)]
pppoe-discovery: Remove duplicate and unused includes
Some of specified include header files in pppoe-discovery.c are duplicate
and some of them are unused. Remove all these include lines which are not
needed.
ipv6cp: Add support for ipv6cp-use-remotenumber option
This new option cause that pppd would use "remotenumber" option value for
negotiating IPv6 remote interface identifier.
It is expected that "remotenumber" option in this case is set either to MAC
address, IPv4 address, IPv6 address or telephone number (with or without
plus sign) of remote peer system.
This option is useful for PPPoE connections to generate stable and
predicable IPv6 remote interface identifier as "remotenumber" is set by
pppoe.so plugin to MAC address of remote ethernet peer.
Similarly dial-up connections set "remotenumber" to telephone number of the
remote system and VPN-based ppp plugins set "remotenumber" to address of
remote peer (in case VPN connection is based on IPv4 transport protocol
then address is set to IPv4, if based on IPv6 then remotenumber is IPv6
address).
Having stable IPv6 interface identifiers in ipv6cp is really important.
Pali Rohár [Sat, 5 Jun 2021 16:51:52 +0000 (18:51 +0200)]
ipv6cp: Add support for ipv6cp-nosend option
This new option cause that pppd would not send our local IPv6 interface
identifier to peer during IPv6 interface identifier negotiation. Like
nosendip option for IPv4.
Paul Mackerras [Fri, 10 Dec 2021 21:40:57 +0000 (08:40 +1100)]
pppoe: Print packet fields in hex if they contain non-printable characters
This adds logic to pppoe_printpkt to print text fields as hex if the
field contains any non-printable characters. This is so that a
malicious, buggy or hacked access concentrator can't cause us to send
non-printing characters to syslog.
Daniel Barlow [Sat, 20 Nov 2021 04:58:17 +0000 (04:58 +0000)]
pppd: Add ipv6-{up,down}-script options (#321)
These allow a user to specify the paths to the scripts
usually located at /etc/ppp/ipv6-up and /etc/ppp/ipv6-down,
similarly to the existing ip-up-script and ip-down-script
options
Paul Mackerras [Sat, 16 Oct 2021 03:01:46 +0000 (14:01 +1100)]
Merge pull request #297 from mjeveritt/patch-11-test-pr
pppd: Add option to ask peer for WINS address
This adds a 'usepeerwins' option, analogous to the usepeerdns option,
to ask the peer for WINS server addresses. Nothing is done with
the addresses provided other than to pass them to the ip-up
script in environment variables.
With this, if the peer sends an IPCP Configure-NAK containing
WINS addresses, we will request them in the following IPCP
Configure-Request.
Co-authored-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Michael Everitt <gentoo@veremit.xyz> Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> Signed-off-by: Michael Everitt <michael@2e0cer.net>
Eivind Næss [Thu, 24 Jun 2021 23:06:11 +0000 (16:06 -0700)]
Improve the PEAP contribution by Rustam Kovhaev
These changes adds to his contribution by
* Adding options to perform CA/CRL checking and certificate validation
consistent with what is already been done for EAP-TLS
* Certificate validation is now in line with what is already been done
for EAP-TLS. Users can now set "remotename" and "tls-verify-method" to
control these.
* Validation of certificate purpose and extended key usage is controlled
by the option "tls-verify-key-usage".
* Fixing up MPPE key generation to use the new API for handling MPPE keys
* Man page is updated where appropriate for the new options.
* Added unit-tests for the PEAP code in case of crypto or parameters would
change in the future.
* Added the peap feature to configure scripts. Users can now control the
feature by specifying --enable-peap/--disable-peap.
To acheive feature parity with the EAP-TLS change, the EAP-TLS common code was
refactored into tls.c/.h such that it could be re-used in both instances.
Using PEAP/MSCHAPv2 is now supported in PPPD with this change.
pppd: Fix usage of BOTHER ioctl API on Linux (#314)
Linux architectures have different content of struct termios2 and also
different value of BOTHER macro. So do not declare any struct termios2 nor
BOTHER macro. Current definitions in ppp were applicable only for x86.
Correct definitions for current architecture are only in <asm/termbits.h>
and <asm/ioctls.h> header files. But Linux header file <asm/termbits.h> is
in conflict with glibc header file <termios.h> and only one can be included
in one source unit. Moreover both header files contains struct termios but
with different content. So it is not possible to use glibc tc* functions
with <asm/termbits.h> definitions.
For this reason provide a new include header file "termios_linux.h" which
provides custom implementation of all glibc's termios.h functions via Linux
ioctl() interface with definitions from Linux <asm/termbits.h> header file.
Thus this "termios_linux.h" is replacement for <termios.h> with additional
support for BOTHER Linux termios API.
Same "termios_linux.h" is going to be used by U-Boot's kwboot utility for
the same reason to use arbitrary baudrate value via BOTHER ioctl API.
Hopefully one day glibc will provide some API functions for functionality
provided currently by BOTHER Linux API.
CLang detected possible invalid memory access (-Wsizeof-pointer-memaccess)
rc_find_server() resets the secret by setting *secret = 0 instead of what
was likely intended: memset the entire array. In case of error, moved the
memset operation outside of the rc_find_server() function. It's only used
in one place anyway.
radattr: tighten permissions on radattr file to avoid information leakage. (#290)
Depending on the invoking process's umask it's possible that the radattr
file (which in certain cases can contain crytographic keys) be stored
with permissions such that world-read access is possible, resulting in
sensitive information being leaked to local users.
Rustam Kovhaev [Thu, 10 Oct 2019 19:53:36 +0000 (12:53 -0700)]
pppd: add experimental support for PEAP protocol, an extension of EAP
current patch implements client functionality for PEAPv0/EAP-MSCHAPv2,
which is usually the most common setup deployed by companies utilizing
Microsoft RRAS as their VPN solution
Michael Everitt [Sun, 15 Aug 2021 22:16:46 +0000 (23:16 +0100)]
Fix situation where peer may NAK with request for MS_WINS
Previously, if configure-request is sent without MS_WINS[12], a
peer may return a NAK with a request for it. However, code in the
ipcp_nakci didn't handle this case properly. This patch fixes it
to set try.req_wins[12].
Signed-off-by: Michael Everitt <michael@2e0cer.net>
Eivind Næss [Sat, 7 Aug 2021 06:56:43 +0000 (23:56 -0700)]
Fixing up a few inconsistencies in configure.ac (#306)
Options that specify --with-logfile-dir, or --with-plugin-dir, or --with-runtime-dir needs to be specified using AC_ARG_WITH, not AC_ARG_ENABLE.
If you try to specify --without-openssl, then the conditions should be tested against = "xyes". There is a case where the option is either blank or is set to "xno" and the former case wasn't properly handled.
pppd: Remove usage of incorrect constant MAXIFNAMELEN
MAXIFNAMELEN is currently hardcoded to 32, but maximal size of interface
name on Linux is just 15 + nul-term byte. This limit is already provided by
IFNAMSIZ macro defined in net/if.h header file.
So replace MAXIFNAMELEN usage by IFNAMSIZ to not silently truncate
interface name.
pppoe: Remove rp-pppoe.so symlink to not conflict with real rp-pppoe.so plugin (#304)
Backward compatibility symlink is there already for one ppp release. Remove
it for next ppp release to not conflict with real rp-pppoe.so plugin. So
both ppp's pppoe.so and rp's rp-pppoe.so plugins can be installed together.
Now when conversion to automake was done, it is a good time to drop this
problematic symlink from default installation.
radius: interim and stop frames should not depend on successful start. (#299)
It could simply be that the accounting server is temporarily down, and
any good accounting server should be able to recover from missed
start/stop frames. In particular Acct-Session-Time on the first seen
interim update or even stop frame allows for determining start time.
Eivind Næss [Thu, 24 Jun 2021 23:07:26 +0000 (16:07 -0700)]
Use autoconf/automake to configure and make ppp
This change brings in autoconf/automake scripts to configure the ppp project. Current change doesn't eliminate the previous build system, but the new script autogen.sh will overwrite configure, and generate the basic Makefile.in and Makefile files.
Features can now be enabled by command line:
* Microsoft Extensions,
- MSCHAP
- MPPE
- MS LAN Manager support
* IPXCP protocol
* CBCP protocol
* PAM support
* EAP-TLS support
* EAP-SRP support
* Max session lifetime by byte count
* Plugins
* Packet activity filter support
* Multilink
* IPv6 support
Control linkage with
* OpenSSL (-lssl -lcrypto)
* systemd (-lsystemd)
* libatm (-latm)
* libsrp (-lsrp)
* pam (-lpam)
Also, the configure script is made sensitive to features of OpenSSL. Like the presence or absence of DES, SHA, MD4 and MD5 crypto support. In the cases where either of these are missing, the support will be directly compiled into pppd and plugins.
In addition, package maintainers can now control the installation paths with standard --prefix=, or --localstatedir=, or --sysconfdir= to configure. On top of that, they can now control the following directories:
* runtime directory w/--with-runtime-dir
* logfile directory w/--with-logfile-dir
* plugin directory w/--with-plugin-dir
In the case where automake isn't the right solution, namely: SunOS kernel module build, the original Makefile infrastructure is preserved and reused.
Care was taken to only cosmetically touchup the source files in this change. This means:
* Insert HAVE_CONFIG_H and include config.h in all .c files.
* Change HAS_SHADOW to HAVE_SHADOW_H
* Change HAVE_LOGWTMP to HAVE_UTMP_H
* Introduce HAVE_CRYPT_H into the source code where appropriate
* Added ifdef MPPE where appropriate
* USE_SRP required a few changes as it didn't compile
* Touchup some compile warning in pppstats directory on SunOS
Introduced a new pppdconf.h file that exports the appropriate defines to a module that wants to provide a module that pppd can dynamically load. This will define/undef features like MPPE, CHAPMS such that the project doesn't have to guess what features pppd is compiled with.
Paul Mackerras [Mon, 19 Jul 2021 07:41:09 +0000 (17:41 +1000)]
chat: Clean up usage of clean() function
In a couple of places, we were calling clean(), which does environment
variable substitution among other things, but then using the original
string not the "cleaned" string when logging a message about what
we're doing.
Also, this removes a couple of checks that the "cleaned" string is not
longer than the original string, which date back to the first version
of the code checked into CVS. Those checks were appropriate before
environment variable substitution was added in commit eaca954c2d4a
("add -E option to use environment variables, from Andreas Arens") and
dynamic reallocation of the result buffer was added in commit 86dd2eec100d ("clean(): Fix buffer overflow.") but are no longer
necessary.
These changes were prompted by github issue #294 and redhat bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1650539
Adrian [Fri, 16 Jul 2021 09:24:13 +0000 (12:24 +0300)]
plugins/radius: Add RFC8044 dictionary compatibility for IPv4 address (#291)
This patch adds ipv4addr RADIUS data type compatible with RFC8044.
New dictionaries from RADIUS is using ipv4addr instead of old
ipaddr data type. This patch is avoiding modification of RADIUS
dictionaries to be compatible with PPP.