xl2tpd "Can not find tunnel" in jammy

[gregrwm]

[Impact]

Users cannot connect to L2TP VPNs at all, such as through network-manager-l2tp-gnome.

[Development Fix]

Addition to lto-disabled-list and a rebuild of xl2tpd in Kinetic. The upload to lto-disabled-list is in Unapproved, pending Kinetic opening. I've added a task for lto-disabled-list to this bug, so that I'll know to upload the rebuild of xl2tpd when that is built and published. Since the version of the Jammy upload is 1.3.16-1ubuntu0.1, the Kinetic upload will end up "lower" at 1.3.16-1build1, but that shouldn't be a problem because this issue will be fixed in both packages, and then any subsequent uploads to Kinetic will continue "higher" as normal. Alternatively 1.3.16-1ubuntu0.1 could just be copied forward to Kinetic after this SRU lands, but it would be better to avoid the delta in Kinetic so that the package will autosync in the future.

[Stable Fix]

Disabling of LTO in debian/rules. This is a more minimal fix that would not require coordination between two packages in a situation where xl2tpd needs to be rebuilt in Jammy anyway.

[Fix method not adopted]

It would be better to fix upstream so that LTO actually works. Upstream issues are https://github.com/xelerance/xl2tpd/issues/230 and https://github.com/xelerance/xl2tpd/issues/232 and this is tracked in bug 1970740. However these aren't fixed upstream and the change in the area of code suggested may not be the only necessary fix, so it seems safer for both the stable and development releases in Ubuntu to revert what regressed the package for now, until a proper fix confirmed to cover all cases by upstream.

[Test Plan]

Requirements : An L2TP VPN server (Windows Server)

- Install Ubuntu 22.04
- Install network-manager-l2tp-gnome (and requirements)
- Configure a new L2TP VPN connection for your server
  (in my case, not sure if this detail is required)
  - Configure gateway address
  - Configure password auth
  - In the IPsec Options, enable IPsec tunnelling
  - Configure the PSK from your server
  - In the PPP Options, enable MSPPE, and disable MSCHAP (leaving MSCHAPv2 the only auth option)

With thanks to Adrian Wilkins, who will also do the SRU verification for us, since it requires a configured Windows Server at the other end.

In addition, racb will check the build log to ensure that LTO was actually disabled during the build.

[Where problems could occur]

There might be some other unreported users from whom LTO actually fixes something and we will regress them by disabling it. However this bug seems more important to fix since it is reported with 35 reported to be affected users already.

LTO doesn't actually get disabled, and by some other non-determinism the problem is accidentally fixed and regresses again later. Mitigation: check the build log.

[Original Description]

My connection works in 20.04 and fails in 22.04. Perhaps something i've been using is now depricated? Or perhaps jammy xl2tpd is...still working on it?

see my attached syslog extracts at comments #6 thru #11. the er-x extracts were simple, the ubuntu extracts were thus:

egrep -i "l2tp|swan|ipsec|charon|XFRM|layer 2|\<ike" /var/log/syslog|egrep -v "INFORMATIONAL_V1|packet: from"

what seems to stand out is:

These lines show up in syslog only in 20.04:
Nov 22 06:22:04 e540 ipsec[782]: 12[KNL] 3.i.p.4 appeared on ppp0
Nov 22 06:22:04 e540 ipsec[782]: 14[KNL] 3.i.p.4 disappeared from ppp0
Nov 22 06:22:04 e540 ipsec[782]: 09[KNL] 3.i.p.4 appeared on ppp0
Nov 22 06:22:04 e540 ipsec[782]: 05[KNL] interface ppp0 activated

These lines show up in syslog only in jammy:
Nov 24 20:11:45 e540 xl2tpd[983]: Can not find tunnel 105 (refhim=0)
Nov 24 20:11:45 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 105 Dumping.
Nov 24 20:11:46 e540 xl2tpd[983]: Can not find tunnel 12 (refhim=0)
Nov 24 20:11:46 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 12 Dumping.
Nov 24 20:11:46 e540 xl2tpd[983]: Can not find tunnel 105 (refhim=0)
Nov 24 20:11:46 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 105 Dumping.
Nov 24 20:11:48 e540 xl2tpd[983]: Can not find tunnel 12 (refhim=0)
Nov 24 20:11:48 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 12 Dumping.
Nov 24 20:11:48 e540 xl2tpd[983]: Can not find tunnel 105 (refhim=0)
Nov 24 20:11:48 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 105 Dumping.
Nov 24 20:11:52 e540 xl2tpd[983]: Can not find tunnel 12 (refhim=0)
Nov 24 20:11:52 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 12 Dumping.
Nov 24 20:11:52 e540 xl2tpd[983]: Can not find tunnel 105 (refhim=0)
Nov 24 20:11:52 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 105 Dumping.
Nov 24 20:12:00 e540 xl2tpd[983]: Can not find tunnel 12 (refhim=0)
Nov 24 20:12:00 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 12 Dumping.
Nov 24 20:12:00 e540 xl2tpd[983]: Can not find tunnel 105 (refhim=0)
Nov 24 20:12:00 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 105 Dumping.
Nov 24 20:12:16 e540 xl2tpd[983]: Maximum retries exceeded for tunnel 39202. Closing.
Nov 24 20:12:16 e540 xl2tpd[983]: Connection 0 closed to 2.i.p.7, port 1701 (Timeout)
Nov 24 20:12:16 e540 xl2tpd[983]: Can not find tunnel 45 (refhim=0)
Nov 24 20:12:16 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 45 Dumping.
Nov 24 20:12:17 e540 xl2tpd[983]: Can not find tunnel 45 (refhim=0)
Nov 24 20:12:17 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 45 Dumping.
Nov 24 20:12:19 e540 xl2tpd[983]: Can not find tunnel 45 (refhim=0)
Nov 24 20:12:19 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 45 Dumping.
Nov 24 20:12:23 e540 xl2tpd[983]: Can not find tunnel 45 (refhim=0)
Nov 24 20:12:23 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 45 Dumping.
Nov 24 20:12:31 e540 xl2tpd[983]: Can not find tunnel 45 (refhim=0)
Nov 24 20:12:31 e540 xl2tpd[983]: network_thread: unable to find call or tunnel to handle packet. call = 39202, tunnel = 45 Dumping.
Nov 24 20:12:47 e540 xl2tpd[983]: Unable to deliver closing message for tunnel 39202. Destroying anyway.

my /etc/ipsec.conf:
config setup

conn %default
  ikelifetime=60m
  keylife=20m
  rekeymargin=3m
  keyingtries=1
  keyexchange=ikev1
  authby=secret
  ike=aes256-sha1-modp2048!
  esp=aes-sha1!

conn myvp7
  right=2.i.p.7
  rightprotoport=17/1701
  leftprotoport=17/1701
  left=%defaultroute
  keyexchange=ikev1
  type=transport
  authby=secret
  auto=add

my /etc/ipsec.secrets:
: PSK ...

my /etc/xl2tpd/xl2tpd.conf:
[lac myvp7]
lns = 2.i.p.7
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes

my /etc/ppp/options.l2tpd.client:
ipcp-accept-local
ipcp-accept-remote
refuse-eap
require-chap
noccp
noauth
mtu 1280
mru 1280
noipdefault
defaultroute
usepeerdns
connect-delay 5000

name ...
password ...

my startup commands:
ipsec up myvp7&&
echo>/var/run/xl2tpd/l2tp-control c myvp7&&
while i=$(ip route) j=${i#*3.i.p.}
   [[ $j = "$i" ]]
do echo -n .;sleep .3
done
i="ip route add 3.i.p.0/21 via 3.i.p.${j%% *}"
echo $i;$i

er-x /etc/ipsec.conf:
config setup

conn %default
        keyexchange=ikev1

conn remote-access
  authby=secret
  type=transport
  keyexchange=ikev1
  left=2.i.p.7

  leftprotoport=17/1701
  right=%any
  rightprotoport=17/%any
  auto=add
  dpddelay=15
  dpdtimeout=45
  dpdaction=clear
  rekey=no
  ikelifetime=3600
  keylife=3600

er-x /etc/ipsec.secrets:
2.i.p.7 %any : PSK ...

er-x /etc/xl2tpd/xl2tpd.conf:
[global]
listen-addr = 2.i.p.7

[lns default]
ip range = 3.i.p.4-3.i.p.9
local ip = 10.255.255.0
refuse pap = yes
require authentication = yes
name = VyattaL2TPServer
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

er-x /etc/ppp/options.xl2tpd:
name xl2tpd
linkname l2tp
ipcp-accept-local
ipcp-accept-remote
ms-dns 8.8.8.8
ms-dns 8.8.4.4
noccp
auth
nodefaultroute
debug
proxyarp
connect-delay 5000
idle 1800

[Lucas Kanashiro (lucaskanashiro)]

Thanks for taking the time to report this bug and trying to make Ubuntu better.

AFAIU both, your systems running Focal and Jammy, are connection to a VPN that you already have set up, am I right? If yes, could you please share the config you used to set it up? In this way, we could try to reproduce the issue locally. I checked the upstream changelog and I did not notice any deprecated config option or something similar that might be impacting your setup.

I am setting the status of this bug to Incomplete but once you add any information on how to reproduce your full setup please set it back to New and we will take a look again.

[gregrwm (gregrwm)]

yes. focal on HD, vs a jammy iso, connecting to the same colo ("right"). i'm less familiar with the details at the colo, other than the focal config i have on my end works for it. with some difficulty i could likely get more details about the colo config.

sorry the description above didn't show the following section in my ipsec.conf:
conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    keyexchange=ikev1
    authby=secret
    ike=...
    esp=...
if you want to see any of the "..." let's find a way less public.

the extent of my configuration is ipsec.conf, ipsec.secrets, xl2tpd.conf, options.l2tpd.client, and issuing a couple commands to open the connection. as it's the first stage that fails, i presume only the ipsec.conf, ipsec.secrets, and the command "ipsec up myvp7" are relevant.

[Simon Déziel (sdeziel)]

For some reason, strongswan can't find the PSK to use for the connection as hinted in:

no shared key found for '1.i.p.2'[1.i.p.2] - '2.i.p.7'[2.i.p.7]
no shared key found for 1.i.p.2 - 2.i.p.7

Can you share the strongswan-starter logs? Maybe it will explain what's wrong with the ipsec.secrets.

If you could also share obfuscated ipsec.conf and ipsec.secrets that'd be useful to reproduce the issue.

[Update]: looking at the bug subject you already knew about the missing shared key.

[gregrwm (gregrwm)]

i've gained access to the "ER-X" which receives my connection at the colo, if you want info from it just ask.

[Sergio Durigan Junior (sergiodj)]

Thanks for the heads up, gregrwm. As Lucas and Simon said, it would be great if you could provide:

- The configuration files for both sides (client and server), with proper obfuscation in place. ipsec.conf and ipsec.secrets are a good start.

- The log files for both sides, with obfuscation in place where needed.

The first step for us here is to be able to reproduce the bug you're seeing in your environment. If you could provide a step-by-step guide to trigger the problem, that would be ideal. Otherwise, we will need as much information about your setup as you can provide.

Thank you in advance.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chaostya (chaostya)]

Same "Cannot find tunnel" in syslog.
Had a working VPN connection in 21.10 with IPSEC/L2TP (PSK + username password) setup from Settings using GUI.
Did an upgrade to 22.04 and it stopped working.
Will attach an extract from my syslog.

[gregrwm (gregrwm)]

i made the jump to manjaro. rolling release, yay! and ipsec/xl2tpd just works.

[Chaostya (chaostya)]

Works fine if I downgrade xl2tpd to 1.13.12.

Attaching a file with 2 log extracts.
It looks like newer xl2tpd messes up parsing tunnel which is echoed by the server in SCCRP message.

[Chaostya (chaostya)]

If I build 1.13.16 from source it resolves the issue.
Package from the repository still does not work.

[Jakub Klos (9v-ka2ub-3y)]

I can also confirm the bug, building 1.13.17 works as well.

[Раиф Габдуллин (r-r-gabdullin)]

I can also confirm the bug. VPN connection worked in 21.10 with IPSEC/L2TP (Configuration using GUI). After an upgrade to 22.04 it stopped working. Syslog extract in attach (real address replaced with x.x.x.x)

[Adam Keglovits (keglo)]

I can also confirm the bug. Same issue.

[Nick Kondratiev (nickkon)]

Can also confirm this bug.
Downgraded to 1.3.12 from 21.10. Works fine on 22.04

[Adam Keglovits (keglo)]

Downgraded to 1.3.12, works fine on 22.04

[emsan (emsan)]

I can confirm the bug in 22.04. How can I downgrade to a previous version of the package?

[Adam Keglovits (keglo)]

@emsan, I have just removed the installed xl2tpd version and installed the 1.3.12 from github:

https://github.com/xelerance/xl2tpd/releases

[Nick Kondratiev (nickkon)]

@emsan

I downloaded it from
https://ubuntu.pkgs.org/20.04/ubuntu-universe-amd64/xl2tpd_1.3.12-1.1_amd64.deb.html

[emsan (emsan)]

thank you @nickkon and @keglo. I tried compiling 1.3.17 from sources and can also confirm that it works perfectly well on 22.04

[NecLimDul (neclimdul)]

Cross linking with source repo issue discussing link time optimization as the cause of this as well.

https://github.com/xelerance/xl2tpd/issues/230

[msaxl (saxl)]

There seems to be a duplicate:
https://bugs.launchpad.net/ubuntu/+source/xl2tpd/+bug/1968336

[msaxl (saxl)]

Now I've replaced xl2tpd in my ppa with a working lto-enabled 1.3.16 version.

This is the patch I used to create a working version

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "lto-fix-bug-1968336.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Douglas Kosovic (dkosovic)]

For those using network-manager-l2tp, another workaround is to use Katalix go-l2tp which is from the authors of the L2TP kernel modules (which xl2tpd also happens to use).

With Networkmanager-l2tp >= 1.20.0, it has switched to kl2tpd as the default L2TP daemon and falls back to xl2tpd if it can't find it. kl2tpd can readily be installed with :

sudo apt install golang-go

go install "github.com/katalix/go-l2tp/...@latest"
sudo mkdir /usr/local/sbin
sudo cp go/bin/kl2tpd /usr/local/sbin

[Robie Basak (racb)]

Looks like this needs someone familiar with Ubuntu process to arrange either disabling link time optimisation or to use msaxl's patch in comment 30. I don't know which would be correct and would want to consult with others on the LTO thing.

https://wiki.ubuntu.com/StableReleaseUpdates#Procedure documents the required process if there are any volunteers.

[Robie Basak (racb)]

More info: https://wiki.ubuntu.com/ToolChain/LTO

[Adrian Wilkins (adrian-wilkins)]

More of a meta comment :

If Ubuntu wishes to be taken seriously as a professional workstation OS (as I'm sure it will do, with an impending IPO next year), issues blocking VPN connectivity - especially to the Usual Suspect endpoints like L2TP (which will cover anyone using e.g. Azure for their corporate VPN) - need to be considered far more important.

This issue was reported four months ago and will block Azure VPN connections from 22.04 until it's fixed (in the absence of workarounds), which means that many users would be unable to do their job, but has yet to be marked with an importance other than "Undecided".

As an engineer who believes strongly that Linux has a place among his co-workers, it gets increasingly hard to justify this to operations when their compliance requirements (like connecting to VPNs) cannot be met out of the box.

L2TP is, yes, a Microsoft thing. But that doesn't mean you shouldn't be taking it seriously - quite the opposite, as that means it forms a substantial minority of VPN endpoints out there.

Hackarounds like manually installing old package versions or alternative VPN clients [1] do not inspire confidence.

I know that the maintainers are absolutely doing their best within the constraints they are operating in, this comment is more directed at Canonical, in the hope that they can understand this is a part of the distro that needs to be tested and supported more rigorously.

[1] https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1457078/comments/19

[msaxl (saxl)]

I agree with adrian-wilkins. Even though xl2tpd is in "universe", not "main", this should have been noticed since contrary to other software this does 100% not work

Hope it gets better until the first point release is out since if a ubuntu user gets updated to 22.04 he/she will not only notice this issue (for example remote desktop over gateway is currently also broken)
if I had to choose I would try making 22.10 a lts release and revert 22.04's lts state. There is simply too much trouble with openssl3 and lto enablement

[Robie Basak (racb)]

Users affected on 22.04: please test the fix from ppa:racb/fixes (https://launchpad.net/~racb/+archive/ubuntu/fixes?field.series_filter=jammy). This is the minimal change to disable LTO, and is the fix I intend to propose for 22.04 if it is reported to work.

If this does work, then I'll need:

1) Reports that the package in my PPA actually fixes the problem for affected users, so that I know to proceed with this specific fix.

2) Step-by-step instructions that allow someone not familiar with the package to reproduce the issue on a fresh Ubuntu system. I appreciate that this assumes availability of a VPN endpoint somewhere else, so it won't be perfect, but as best as you can manage to explain the configuration on the Ubuntu end at least, please.

3) Further testing of the final proposed update packages for 22.04 after they're made available.

If someone can commit to helping with these, please - especially step 3 - then I can proceed.

Thanks

[Leonardo Barroso da Silva (leo-barroso-silva)]

I can confirm ppa:racb/fixes fixed my VPN connection that stopped working after ubuntu 21.10 to 22.04 upgrade.

What I did:

apt remove xl2tpd
add-apt-repository ppa:racb/fixes
apt install xl2tpd network-manager-l2tp-gnome

Thanks Robie!

[iJay (mustangxu)]

ppa:racb/fixes works for me, thanks Robie!

to #38, 'apt remove xl2tpd' is not necessary, apt will upgrade xl2tpd package after adding ppa

[pgallent (pgallent-i)]

Fix is working for me too in ubuntu 22.04.

Thanks!

[Felix T (crvn)]

The fix is working for me as well on 22.04. I only did:

add-apt-repository ppa:racb/fixes
apt install xl2tpd

Thank you.

[Adrian Wilkins (adrian-wilkins)]

Can confirm that Robie's fix works.

2) Step by step repro instructions

Requirements : An L2TP VPN server (Windows Server)

- Install Ubuntu 22.04
- Install network-manager-l2tp-gnome (and requirements)
- Configure a new L2TP VPN connection for your server
  (in my case, not sure if this detail is required)
  - Configure gateway address
  - Configure password auth
  - In the IPsec Options, enable IPsec tunnelling
  - Configure the PSK from your server
  - In the PPP Options, enable MSPPE, and disable MSCHAP (leaving MSCHAPv2 the only auth option)

Open a window with `journalctl -ef` running to watch the logs.
Initiate the connection from nm-applet.

3) As someone definitely affected, and with a suitable corporate VPN endpoint available, I'll be happy to test the proposed updates.

[Hardik Ghadshi (hardikone)]

I have downgraded it to 1.3.12, works fine on 22.04.
Attached 1.3.12 deb file.

[Nick Kondratiev (nickkon)]

Thanks, @racb.
Fix works for me too.

[Robie Basak (racb)]

Thank you for testing the fix! I've now uploaded the fix for inclusion in an update to 22.04. This is now awaiting SRU team review (I shouldn't do that myself as I prepared it). Once the fix is accepted, we will ask for testing again of the final package binary before it is published to updates.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package lto-disabled-list - 25

---------------
lto-disabled-list (25) kinetic; urgency=medium

  * Add xl2tpd (LP: #1951832).

 -- Robie Basak <email address hidden> Thu, 28 Apr 2022 11:30:54 +0000

[Robie Basak (racb)]

I uploaded a rebuild of xl2tpd to fix this in Kinetic, but it is still pending SRU review for Jammy (22.04).

[Launchpad Janitor (janitor)]

This bug was fixed in the package xl2tpd - 1.3.16-1build1

---------------
xl2tpd (1.3.16-1build1) kinetic; urgency=medium

  * No change rebuild with lto-disabled-list updated to rebuild without
    LTO. This fixes this otherwise broken build. LP: #1951832.

 -- Robie Basak <email address hidden> Thu, 28 Apr 2022 22:20:29 +0100

[Lorant Nemeth (loci)]

Can confirm, that the changes from the ppa fixed the issue.

[Łukasz Zemczak (sil2100)]

Hello gregrwm, or anyone else affected,

Accepted xl2tpd into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/xl2tpd/1.3.16-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Łukasz Zemczak (sil2100)]

Note of things to remember: hopefully there will be a new version before kinetic is released and we will simply sync it to solve the problem, but if not - we need to make sure that someone bumps the xl2tpd package with an ubuntuX no-change rebuild.

[msaxl (saxl)]

i can confirm that the package in -proposed (1.3.16-1ubuntu0.1) does work like expected

[Adrian Wilkins (adrian-wilkins)]

Likewise confirm that the proposed package is working.

[Adrian Wilkins (adrian-wilkins)]

Testing performed :

- Using a config verified to be working on 20.04
- Enabled -proposed
- Updated and verified that component is now version 1.3.16-1ubuntu0.1
- Connected to my corporate VPN successfully where previously I could not
- (this config also worked for the PPA version published above by @racb)

[Robie Basak (racb)]

Thank you msaxl and Adrian for performing the verification!

I've also verified in the build log that lto optimisation is now missing. For example:

cc -DDEBUG_PPPD -DTRUST_PPPD_TO_DIE -O2 -fno-builtin -Wall -DSANITY -DLINUX -I/include/ -DIP_ALLOCATION -DUSE_KERNEL -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DDEBUG_PPPD -DTRUST_PPPD_TO_DIE -O2 -fno-builtin -Wall -DSANITY -DLINUX -I/include/ -DIP_ALLOCATION -Wdate-time -D_FORTIFY_SOURCE=2 -c -o xl2tpd.o xl2tpd.c

became

cc -DDEBUG_PPPD -DTRUST_PPPD_TO_DIE -O2 -fno-builtin -Wall -DSANITY -DLINUX -I/include/ -DIP_ALLOCATION -DUSE_KERNEL -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -DDEBUG_PPPD -DTRUST_PPPD_TO_DIE -O2 -fno-builtin -Wall -DSANITY -DLINUX -I/include/ -DIP_ALLOCATION -Wdate-time -D_FORTIFY_SOURCE=2 -c -o xl2tpd.o xl2tpd.c

[Adam Keglovits (keglo)]

Sorry, I have changed it from Fix Commited to Fix Released by mistake but I cannot change it back. Sorry!

[Łukasz Zemczak (sil2100)]

As agreed, releasing this before the aging period.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xl2tpd - 1.3.16-1ubuntu0.1

---------------
xl2tpd (1.3.16-1ubuntu0.1) jammy; urgency=medium

  * Disable LTO to make the package work again (LP: #1951832).

 -- Robie Basak <email address hidden> Thu, 28 Apr 2022 12:01:14 +0000