Build failure on older toolchains due to missing <linux/ppp-ioctl.h>

[logu05]

When building PPP 2.5.2 against older toolchains below 4, the build fails in sys-linux.c because <linux/ppp-ioctl.h> is not provided by those kernel headers. The header was introduced in later kernel versions, so toolchains with older headers cannot compile PPP without patching.

CC pppd-tls.o
sys-linux.c:133:29: fatal error: linux/ppp-ioctl.h: No such file or directory
#include <linux/ppp-ioctl.h>
^
compilation terminated.
Makefile:1334: recipe for target 'pppd-sys-linux.o' failed

My environment
Board: TI DM3730 (armv7l)
Kernel headers: 3.0
GCC: 4.9.4
libc: glibc 2.20

[Neustradamus]

@paulusmack, @enaess, @jkroonza: Have you seen this ticket?

[jkroonza]

What is meant with "older toolchains below 4"?

gcc version 4?

Perhaps this is more likely a linux headers version issue than a gcc toolchain version issue. On my system at least linux/ppp-ioctl.h is provided by linux-headers, not the toolchain, nor glibc.

Do you have linux-headers (matching the kernel you're running) installed?

[jkroonza]

I dislike it when an itch that doesn't need scratching for myself starts itching ...

From pppd/eap-tls.c

  43 #include <openssl/conf.h>
  44 #ifndef OPENSSL_NO_ENGINE
  45 #include <openssl/engine.h>
  46 #endif

A "simple" hack may simply be to #define OPENSSL_NO_ENGINE in the case of openssl>=3.0?

Eg, just before line 44 we add:

#include <openssl/opensslv.h> /* this is already included indirectly by conf.h but that may not be intentional */
#if OPENSSL_VERSION_MAJOR >= 3
#define OPENSSL_NO_ENGINE
#endif

This feels particularly nasty.

Another option is to simply remove all of the code that relies on ENGINE.

Given that EAP-TLS is used during authentication (as far as I understand), how much do we really gain from using engines here? It does look like there are ways to explicitly configure pppd to use an engine (by having the cert file for of format engine:id), so I'm guessing we can't simply drop this entirely? I'm assuming this means this is for cases where say the private key is stored in some hardware module such as a TPM?

https://blog.hansenpartnership.com/converting-engines-to-openssl-3-providers/ has some info.

I've got no way to test any of this other than the ability to compile it.

I suspect that there are sufficient differences between providers and engines that we should implement a provider: option rather, and deprecate engine: use, warning about that and that it's been deprecated in openssl and will go away, and live with the warnings (or silence them somehow) in the meantime.

[paulusmack]

@jkroonza was your last comment meant for #568 ?

[paulusmack]

It turns out that in Linux versions prior to v3.3, the stuff that is now in <linux/ppp-ioctl.h> was then in <linux/if_ppp.h>. So you could probably fix the build with your ancient kernel headers by changing ppp-ioctl to if_ppp, or by copying your kernel's if_ppp.h to include/linux/ppp-ioctl.h in your ppp source tree. I say "ancient" because 3.3 was released in March 2012, which is more than 13 years ago.

[jkroonza]

@jkroonza was your last comment meant for #568 ?

Yes :(.