As the title says, every time I try to connect (via RDP), Remmina only connects once (and it works for that remainder of the session), but any subsequent attempts of connecting to another or even the same PC, fails. I need to restart Remmina, after which it works again. What could be the reason for that?
Starting remmina from console I can see the following output. The first time the connection works, and everything is good. The second time it fails. Only restarting remmina allows me to reconnect again.
StatusNotifier/Appindicator support: not supported by desktop. Remmina will try to fallback to GtkStatusIcon/xembed
(org.remmina.Remmina:11362): Gtk-WARNING **: 12:05:52.660: gtk_menu_attach_to_widget(): menu already attached to GtkMenuItem
(org.remmina.Remmina:11362): Gtk-CRITICAL **: 12:05:56.558: gtk_window_resize: assertion 'width > 0' failed
[12:05:56:021] [11362:11367] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[12:05:56:021] [11362:11367] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[12:05:56:021] [11362:11367] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[12:05:56:021] [11362:11367] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[12:05:57:335] [11362:11367] [ERROR][com.winpr.sspi.Kerberos] - error while getting credentials
[12:05:57:335] [11362:11367] [ERROR][com.winpr.sspi.Kerberos] - Kerberos credentials not found and could not be acquired
[12:05:57:335] [11362:11367] [WARN][com.winpr.negotiate] - No Kerberos credentials. Retry with NTLM
[12:05:57:335] [11362:11367] [WARN][com.winpr.sspi] - InitializeSecurityContextA status SEC_E_NO_CREDENTIALS [0x8009030E]
[12:05:57:844] [11362:11367] [INFO][com.freerdp.gdi] - Local framebuffer format PIXEL_FORMAT_BGRA32
[12:05:57:844] [11362:11367] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_RGB16
[12:05:57:845] [11362:11367] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel disp
[12:05:57:847] [11362:11386] [INFO][com.freerdp.channels.rdpsnd.client] - Loaded pulse backend for rdpsnd
(org.remmina.Remmina:11362): Gtk-CRITICAL **: 12:06:02.825: gtk_window_resize: assertion 'width > 0' failed
[12:06:02:287] [11362:11391] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[12:06:02:287] [11362:11391] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[12:06:02:287] [11362:11391] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[12:06:02:287] [11362:11391] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[12:06:03:434] [11362:11391] [ERROR][com.winpr.sspi] - EncryptMessage status SEC_E_INVALID_TOKEN [0x80090308]
[12:06:03:434] [11362:11391] [ERROR][com.freerdp.core.nla] - EncryptMessage status SEC_E_INVALID_TOKEN [0x80090308]
[12:06:03:434] [11362:11391] [ERROR][com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_NLA - nla_recv_pdu() fail
[12:06:03:434] [11362:11391] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
[12:06:03:434] [11362:11391] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[12:06:03:601] [11362:11391] [ERROR][com.winpr.sspi] - EncryptMessage status SEC_E_INVALID_TOKEN [0x80090308]
[12:06:03:601] [11362:11391] [ERROR][com.freerdp.core.nla] - EncryptMessage status SEC_E_INVALID_TOKEN [0x80090308]
[12:06:03:601] [11362:11391] [ERROR][com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_NLA - nla_recv_pdu() fail
[12:06:03:601] [11362:11391] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
[12:06:03:601] [11362:11391] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[12:06:03:601] [11362:11391] [ERROR][com.freerdp.core] - freerdp_post_connect failed
libfreerdp returned code is 0002000D
I should note that I'm on Arch, with all the latest updates and I'm using Remmina 1.3.4. I've found another person with the same problem, but this is more than a year ago, and the recommended solution (downgrading) seems impractical, since it did work up to a week ago or so.