problem upgrading from 1.20.5 to 1.21.0 on Debian Sid

[peutch]

Hi,

On a Debian Sid system, I am using NetworkManager to activate a VPN configuration and it works with 1.20.5 and not with 1.21.0. The command line generated by NetworkManager is:
/usr/bin/openfortivpn -c /var/lib/NetworkManager-fortisslvpn/4d48a71a-ce3f-4cae-a421-ce0f17a0369d.config --no-routes --no-dns --pppd-use-peerdns=1 <HIDDEN> --trusted-cert 718d0201f19e60a0822abbe210a705d0a76d8e7fc38ad51d9a1aeb68ffddb2e0 --pinentry /usr/libexec/nm-fortisslvpn-pinentry --pppd-plugin /usr/lib/pppd/2.4.9/nm-fortisslvpn-pppd-plugin.so

Any idea?

Thanks.

ps: that follows https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056235

[peutch]

But forgot to say that it works using a simple command line like: sudo openfortivpn <HIDDEN> -u <USER> -p <PASSWORD> --trusted-cert 718d0201f19e60a0822abbe210a705d0a76d8e7fc38ad51d9a1aeb68ffddb2e0.

[DimitriPapadopoulos]

That's because openfortivpn 1.21 expects pppd ≥ 2.5.0 by default, but your version of Debian ships pppd 2.4.9 < 2.5.0. It shouldn't work from the command line either, unless you pass openfortivpn 1.21 the run-time option --pppd-accept-remote=0.

You need to build openfortivpn ≥ 1.21 with ./configure --enable-legacy-pppd for targets platforms with pppd < 2.5.0.

If you are using a Debian package, can you please point the maintainer to this post, so that the Debian packages can be fixed?

[peutch]

That's because openfortivpn 1.21 expects pppd ≥ 2.5.0 by default, but your version of Debian ships pppd 2.4.9 < 2.5.0. It shouldn't work from the command line either, unless you pass openfortivpn 1.21 the run-time option --pppd-accept-remote=0.

Regarding your comment, this is still strange that the command line worked for me. Could then the option --pppd-accept-remote=0 be somehow default?

You need to build openfortivpn ≥ 1.21 with ./configure --enable-legacy-pppd for targets platforms with pppd < 2.5.0.

If you are using a Debian package, can you please point the maintainer to this post, so that the Debian packages can be fixed?

Maintainer was informed and very reactive: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056235#27

Both thanks!

[peutch]

Could the output running the command line with the option -v of openfortivpn (1.21.0-1, build without --enable-legacy-pppd) and ppp (2.4.9-1+1.1+b1) be interesting?

[DimitriPapadopoulos]

@peutch Thank you so much for spending the time (you and the maintainer) ironing things out on Debian. I must admit I am not happy with this breaking change I had to introduce, but I had no other alternative (such as runtime detection of the version of pppd) with the little time I can dedicate to openfortivpn.

Could the output running the command line with the option -v of openfortivpn (1.21.0-1, build without --enable-legacy-pppd) and ppp (2.4.9-1+1.1+b1) be interesting?

Do you mean openfortivpn should be modified, so that the output of -v gives a brief glimpse of build-time options?

[DimitriPapadopoulos]

Regarding your comment, this is still strange that the command line worked for me. Could then the option --pppd-accept-remote=0 be somehow default?

Do you perhaps have 2 versions of openfortivpn on your machine? In any case, to find which of --pppd-accept-remote=0 and --pppd-accept-remote=1 is the default, compare either of these options to the absence of --pppd-accept-remote. The option =0 or =1 that behaves the same as no --pppd-accept-remote option is the default one.

[peutch]

Regarding your comment, this is still strange that the command line worked for me. Could then the option --pppd-accept-remote=0 be somehow default?

Do you perhaps have 2 versions of openfortivpn on your machine? In any case, to find which of --pppd-accept-remote=0 and --pppd-accept-remote=1 is the default, compare either of these options to the absence of --pppd-accept-remote. The option =0 or =1 that behaves the same as no --pppd-accept-remote option is the default one.

No I have only one openfortivpn version which is the one provided by the Debian package installed. I have currently the build 1.21.0-1 which works using direct command line but not through NetworkManager (whatever CLI, TUI or GNOME). I did not tried yet the new build 1.21.0-2.
Could its build log useful to explain this duality? (https://buildd.debian.org/status/fetch.php?pkg=openfortivpn&arch=amd64&ver=1.21.0-1&stamp=1700366564&raw=1)

[DimitriPapadopoulos]

I understand openfortivpn without --pppd-accept-remote works fine. However, does it also work fine with both --pppd-accept-remote=0 and --pppd-accept-remote=1?

In the build log you refer to openfortivpn is configured without --enable-legacy-pppd:

./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-pppd=/usr/sbin/pppd --enable-resolvconf --with-resolvconf=/sbin/resolvconf

Configururing openfortivpn without --enable-legacy-pppd makes --pppd-accept-remote=1 the default. This is supposed to work with pppd ≥ 2.5.0 but is supposed to fail with pppd < 2.5.0. Now your version of 2.4.9-1+1.1+b1 of pppd appears to be slightly patched, as a result I don't know if it behaves like vanilla 2.4.9, like 2.5.0, or something different.

[epsilon77]

Hello!!

I am openfortivpn maintainer on Debian! I uploaded the new revision with the flag --enable-legacy-pppd, I hope it works fine with NetworkManager-fortisslvpn.

btw, It was strange for me too. Before upload the new version 1.21.0 I made many tests from command line, and its work fine. ( I don't use networkmanager-fortisslvpn.)

Please let me know if is necessary any more changes.

Regards!

[peutch]

I understand openfortivpn without --pppd-accept-remote works fine. However, does it also work fine with both --pppd-accept-remote=0 and --pppd-accept-remote=1?

Surprisingly, it works in both cases.

[DimitriPapadopoulos]

@epsilon77 Thank you for looking into this issue. One thing you may help with, is remind me whether NetworkManager-fortisslvpn handles routing internally, or delegates routing to pppd, like DNS. I don't think pppd can handle that, but I haven't looked at routing issues for quite a long time.

@peutch If it works in both cases, so be it. That's different from what I have heard so far from users on other distributions. It may just mean that pppd 2.4.9-1+1.1+b1 on Debian is different from, and possibly better than pppd 2.4.9 or pppd 2.5.0 on other distributions. I really don't have the time to get to the bottom of this specific question right now. The only relevant difference I can see between openfortivpn 1.20.5 and 1.21.0 is the ipcp-accept-remote thing. The only possible issue I can imagine is that pppd itself behaves differently with option ipcp-accept-remote than without. Either this different behaviour is incorrect, or maybe it is correct but unexpected by NetworkManager-fortisslvpn. In the latter case, we might need to adapt NetworkManager-fortisslvpn. But we're not there yet, because I don't even know how pppd behaves differently with/without ipcp-accept-remote. It would be interesting to compare pppd logs with/without ipcp-accept-remote.

[peutch]

@epsilon77 Thanks for the new build 2.21.0-2, it works fine.
@DimitriPapadopoulos, Many thanks for your help and patience.