This problem appeared after updating Fedora 42 to Fedora 43. When connecting to a FortiGate SSL VPN that requires 2FA/OTP authentication, the connection process correctly triggers the OTP email, but the nm-fortisslvpn-auth-dialog crashes immediately when the OTP input dialog appears. Steps to Reproduce: Configure a Fortinet SSLVPN connection in System Settings → Network → Connections Set gateway (with custom port, e.g., server.example.com:10443) Enter username and password, check "Store password for this user only" Attempt to connect OTP email is successfully triggered and received OTP input dialog appears briefly then crashes Actual Results: The nm-fortisslvpn-auth-dialog process crashes systemd-coredump reports: "Process nm-fortisslvpn- terminated abnormally without generating a coredump" NetworkManager logs show: ERROR: Failed to get PIN: GDBus.Error:org.freedesktop.NetworkManager.Settings.Connection.Failed: Secret 'username__server.example.com_2fa' is not supported ERROR: No token specified ERROR: Could not authenticate to gateway Expected Results: The OTP dialog should remain open, accept the OTP code, and complete the VPN connection. Additional Information: KDE Plasma Version: 6.5.3 Qt Version: 6.8 NetworkManager Version: 1.50.0 plasma-nm-fortisslvpn: 6.5.3-1.fc43 NetworkManager-fortisslvpn: 1.4.1-10.20231021gite201da5.fc43 Workaround: Using openfortivpn CLI directly works correctly with OTP: bashsudo openfortivpn server.example.com:10443 --username=user The bug appears to be in the plasma-nm plugin's handling of the 2FA secret format. The error message suggests it's trying to use an unsupported secret name format for the 2FA token.
Thanks for the crash report. If something crashed, we need a backtrace of it so we can figure out what's going on. Can you please attach a backtrace of the crash using the coredumpctl command-line program, as detailed in https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl ? Thanks.
Unfortunately, coredumpctl is not generating actual core files for nm-fortisslvpn-service (Storage: none), even though other programs on my system generate coredumps correctly. PID: 66242 (nm-fortisslvpn-) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Tue 2025-11-25 10:26:29 +07 (6min ago) Command Line: /usr/libexec/nm-fortisslvpn-service --bus-name org.freedesktop.NetworkManager.fortisslvpn.Connection_12 Executable: /usr/libexec/nm-fortisslvpn-service Control Group: /system.slice/NetworkManager.service Unit: NetworkManager.service Slice: system.slice Boot ID: c98592d3047c4484a43213977ca62033 Machine ID: d07c2a110e5e4df38408331f855df301 Hostname: laptopnicow Storage: none Message: Process 66242 (nm-fortisslvpn-) of user 0 terminated abnormally without generating a coredump. I did a live capture with gdb, I'm hope it is useful, here is the output: [New LWP 68362] [New LWP 68361] [New LWP 68360] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007f4bb9098982 in __syscall_cancel_arch () from target:/lib64/libc.so.6 Thread 1 "nm-fortisslvpn-" received signal SIGSEGV, Segmentation fault. g_type_check_instance_is_a (type_instance=type_instance@entry=0x56324adfd460, iface_type=94774004446032) at ../gobject/gtype.c:3905 3905 check = node && node->is_instantiatable && iface && type_node_conforms_to_U (node, iface, TRUE, FALSE); #0 g_type_check_instance_is_a (type_instance=type_instance@entry=0x56324adfd460, iface_type=94774004446032) at ../gobject/gtype.c:3905 #1 0x00007f4bb94ec40d in g_dbus_method_invocation_return_error_literal (invocation=0x56324adfd460, domain=54, code=0, message=0x563217d035ea "Disconnected") at ../gio/gdbusmethodinvocation.c:723 #2 0x0000563217cfd186 in cleanup_plugin (plugin=<optimized out>) at src/nm-fortisslvpn-service.c:128 #3 0x0000563217cfd32d in real_disconnect (plugin=<optimized out>, err=<optimized out>) at src/nm-fortisslvpn-service.c:518 #4 0x00007f4bb960fb41 in nm_vpn_service_plugin_disconnect () from target:/lib64/libnm.so.0 #5 0x00007f4bb928558d in g_child_watch_dispatch (source=0x7f4b9c0055f0, callback=0x563217cfd340 <openfortivpn_watch_cb>, user_data=0x56324addb590) at ../glib/gmain.c:6171 #6 0x00007f4bb927f2a3 in g_main_dispatch (context=0x56324ade1a90) at ../glib/gmain.c:3565 #7 g_main_context_dispatch_unlocked (context=0x56324ade1a90) at ../glib/gmain.c:4425 #8 0x00007f4bb92881f8 in g_main_context_iterate_unlocked (context=0x56324ade1a90, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4490 #9 0x00007f4bb928849f in g_main_loop_run (loop=0x56324adeed30) at ../glib/gmain.c:4695 #10 0x0000563217cfc979 in main (argc=<optimized out>, argv=<optimized out>) at src/nm-fortisslvpn-service.c:794 A debugging session is active. Inferior 1 [process 68359] will be detached. Quit anyway? (y or n) [answered Y; input not from terminal] [Inferior 1 (process 68359) detached] Thanks in advance
Thanks for the backtrace. Those more familiar with this will have to look further into it.
#1 0x00007f4bb94ec40d in g_dbus_method_invocation_return_error_literal (invocation=0x56324adfd460, domain=54, code=0, message=0x563217d035ea "Disconnected") at ../gio/gdbusmethodinvocation.c:723 This paints a picture of the software failing to handle an unexpected disconnection from the plugin.