[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

I don't think remmina will be updated to 1.27 (1.26 would be enough).
Usually the version of the package remain the same, only some patches
get applied when needed. Browsers are exempt from that rule.

Ubuntu maintainers might cherry pick this:
https://gitlab.com/Remmina/Remmina/-/merge_requests/2402/diffs?commit_id=ecfa4fe4a93f99fd8991eb18fc1442c01b642a07

but they must be convinced this is a issue for enough people to do that.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Incomplete
Status in freerdp2 source package in Jammy:
  Incomplete

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

@t2t-exe some questions:
is the error message exactly the one mentioned here?
what version is the target rdp server (Windows7, Windows 10, Windows Server 
2019, ..)?
since you use a new remmina version, what is the tls security level set to?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Incomplete
Status in freerdp2 source package in Jammy:
  Incomplete

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

I can confirm that 1.6.1+dfsg1-3ubuntu2 fixes the gateway issue

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

remmina will probably have a tls security level switch in the future.

https://gitlab.com/Remmina/Remmina/-/commit/cf4d8f99ac258248b8e3f3a5314ae047a210a3e9

imo it would be cleaner to backport this instead of lowering the default 
security for everyone.
In the next ubuntu version I think the will be an updated remmina, so if we 
decide to lower the default level in 22.04 with a sru, we must not forget to 
drop that in kosmic.
The only other applications that uses libfreerdp directly I know of are 
libguac-client-rdp0 and krdc, but I think they will also adopt as soon as it 
will be obvious that such a setting is needed for a successful connection to 
older OSes

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

@omriasta are you sure you did not use /sec:rdp? 2.6.1+dfsg1-3ubuntu1 does not 
contain the upstream patch and will 100% work over gateway if linked to 
openssl3 and using a tls based transport over rdp gateway (nla/ext/tls), but as 
said /sec:rdp always worked if the remote end allowed it
The version in my ppa is 2.6.1+dfsg1-3ubuntu1.2~gwfix, if you meant that one

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

I have built a version that includes my mentioned security level
workaround.

It's in ppa:saxl/freerdp2

With that this bug report should be addressed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

@blaze status 403 is quite strange, but afaik openssl1.1 is not in
jammy. If you still have it this is because it probably does not get
removed when updating.

I will try to make a package that fixes both rdp gateway and windows < 8.
It would be very useful if you (and probably others) would be able to test this

note however that the gateway part is now this bug report:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1970655

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1970655] Re: ubuntu 22.04 fails connecting to a rdp server through a rdp gateway

[msaxl]

I've build a package that includes the fix mentioned above in
ppa:saxl/freerdp

if someone can test if it works

note however that a 2008r2 gateway probably fails with
ERRCONNECT_TLS_CONNECT_FAILED since openssl3.0 is not compatible with
2008r2 on tls seclevel 1 anymore (#1954970).

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1970655

Title:
  ubuntu 22.04 fails connecting to a rdp server through a rdp gateway

Status in freerdp2 package in Ubuntu:
  New

Bug description:
  There is a regression in freerdp if linked/compiled against openssl 3

  This has been fixed upstream with

  
https://github.com/FreeRDP/FreeRDP/commit/9d7c20ce8fe50bd6de54e7480b5096761a510daf.patch

  The upstream bug report was
  https://github.com/FreeRDP/FreeRDP/issues/7797

  This bug is a split of
  https://bugs.launchpad.net/bugs/1954970
  as actually it showed that the issues discussed there are distinct.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1970655/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1970068] Re: L2TP+IPSec not working after upgrade to 22.04 LTS

[msaxl]

*** This bug is a duplicate of bug 1951832 ***
https://bugs.launchpad.net/bugs/1951832

this is probably not a duplicate but this
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/961

#1951832 does talk about a issue with xl2tpd, looking at this log
output, the ppp session is established but is terminated afer 1.5
minutes. A lot of bytes where sent, but none was received. looks like
the ppp packet was routed inside the ppp tunnel (this is, according to
Douglas Kosovic, a regression in network manager)

** Bug watch added: 
gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues #961
   https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/961

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1970068

Title:
  L2TP+IPSec not working after upgrade to 22.04 LTS

Status in network-manager package in Ubuntu:
  New
Status in network-manager-l2tp package in Ubuntu:
  New
Status in ppp package in Ubuntu:
  New
Status in xl2tpd package in Ubuntu:
  New

Bug description:
  In 20.04LTS i was able to connect to my work over the L2TP tunel. Now
  it seems like this in journald:

  kwi 24 01:00:37 nm-l2tp-service[11368]: xl2tpd started with pid 11433
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Not looking for kernel 
SAref support.
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Using l2tp kernel 
support.
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: xl2tpd version 
xl2tpd-1.3.16 started on crushXnitro PID:11433
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Written by Mark 
Spencer, Copyright (C) 1998, Adtran, Inc.
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Forked by Scott Balmos 
and David Stipp, (C) 2001
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Inherited by Jeff 
McAdams, (C) 2002
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Forked again by 
Xelerance (www.xelerance.com) (C) 2006-2016
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Listening on IP address 
0.0.0.0, port 49636
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Connecting to host 
X.X.X.X, port 1701
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Connection established 
to X.X.X.X, 1701.  Local: 19994, Remote: 201 (ref=0/0).
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Calling on tunnel 19994
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Call established with 
X.X.X.X, Local: 65441, Remote: 142, Serial: 1 (ref=0/0)
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: start_pppd: I'm running:
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "/usr/sbin/pppd"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "plugin"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "pppol2tp.so"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "pppol2tp"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "7"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "passive"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "nodetach"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: ":"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "file"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: 
"/run/nm-l2tp-bd8ac49b-a2e9-4094-91dc-17a13ce61ec8/ppp-options"
  kwi 24 01:00:37 pppd[11434]: Plugin pppol2tp.so loaded.
  kwi 24 01:00:37 pppd[11434]: Plugin 
/usr/lib/pppd/2.4.9/nm-l2tp-pppd-plugin.so loaded.
  kwi 24 01:00:37 pppd[11434]: pppd 2.4.9 started by root, uid 0
  kwi 24 01:00:37 pppd[11434]: Using interface ppp0
  kwi 24 01:00:37 pppd[11434]: Connect: ppp0 <-->
  kwi 24 01:00:37 pppd[11434]: Overriding mtu 1500 to 1400
  kwi 24 01:00:37 pppd[11434]: Overriding mru 1500 to mtu value 1400
  kwi 24 01:00:37 NetworkManager[1017]:   [1650754837.9839] manager: 
(ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/6)
  kwi 24 01:00:38 pppd[11434]: CHAP authentication succeeded
  kwi 24 01:00:38 charon[11397]: 10[KNL] interface ppp0 activated
  kwi 24 01:00:38 charon[11397]: 13[KNL] fe80::81ee:6717:6637:2084 appeared on 
ppp0
  kwi 24 01:00:38 charon[11397]: 14[KNL] flags changed for 
fe80::81ee:6717:6637:2084 on ppp0
  kwi 24 01:00:38 pppd[11434]: local  LL address fe80::81ee:6717:6637:2084
  kwi 24 01:00:38 pppd[11434]: remote LL address fe80::::00f0:0c0e
  kwi 24 01:00:38 charon[11397]: 16[KNL] 192.168.57.181 appeared on ppp0
  kwi 24 01:00:38 NetworkManager[1017]:   [1650754838.0741] device 
(ppp0): state change: unmanaged -> unavailable (reason 'connection-assumed', 
sys-iface-state: 'external')
  kwi 24 01:00:38 charon[11397]: 08[KNL] 192.168.57.181 disappeared from ppp0
  kwi 24 01:00:38 charon[11397]: 10[KNL] 192.168.57.181 appeared on ppp0
  kwi 24 01:00:38 NetworkManager[1017]:   [1650754838.0751] device 
(ppp0): state change: unavailable -> disconnected (reason 'none', 
sys-iface-state: 'external')
  kwi 24 

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

ok, I created a bug report dedicated for the rdp gateway issue
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1970655

regarding the windows 6.1 tls issue (Windows 7 and Windows Server 2008
R2, probably also Vista and Server 2008) there is now an upstream report
here

https://github.com/FreeRDP/FreeRDP/issues/7839

but I think this one needs to be decided downstream if we want to
support Windows 7/2008R2 out of the box or, like in other places where
old tls versions where disabled, we want to drop support for that.

A possible workaround for the average user in that case (or also right
now) might be disabling nla on the windows 7 machine and using rdp
security instead of tls or nla.


** Bug watch added: freerdp-issues #7839
   https://github.com/FreeRDP/FreeRDP/issues/7839

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1970655] [NEW] ubuntu 22.04 fails connecting to a rdp server through a rdp gateway

[msaxl]

Public bug reported:

There is a regression in freerdp if linked/compiled against openssl 3

This has been fixed upstream with

https://github.com/FreeRDP/FreeRDP/commit/9d7c20ce8fe50bd6de54e7480b5096761a510daf.patch

The upstream bug report was
https://github.com/FreeRDP/FreeRDP/issues/7797

This bug is a split of
https://bugs.launchpad.net/bugs/1954970
as actually it showed that the issues discussed there are distinct.

** Affects: freerdp2 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1970655

Title:
  ubuntu 22.04 fails connecting to a rdp server through a rdp gateway

Status in freerdp2 package in Ubuntu:
  New

Bug description:
  There is a regression in freerdp if linked/compiled against openssl 3

  This has been fixed upstream with

  
https://github.com/FreeRDP/FreeRDP/commit/9d7c20ce8fe50bd6de54e7480b5096761a510daf.patch

  The upstream bug report was
  https://github.com/FreeRDP/FreeRDP/issues/7797

  This bug is a split of
  https://bugs.launchpad.net/bugs/1954970
  as actually it showed that the issues discussed there are distinct.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1970655/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

reading the first message actually it would be better splitting out the
gateway fix since this bug really talks about windows 2008r2. If you
agree I will make a new report about the backport of the gateway fix

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

The relevant change is SHA1 in openssl3
https://github.com/openssl/openssl/commit/aba03ae571ea677fc484daef00a21ca8f7e82708
SHA1 is, contrary to what someone would expect given that the documentation 
says:

Level 4

Security level set to 192 bits of security. As a result RSA, DSA and
DH keys shorter than 7680 bits and ECC keys shorter than 384 bits are
prohibited.  Cipher suites using SHA1 for the MAC are prohibited. TLS
versions below 1.2 are not permitted.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

I just discovered that a direct tls connection to a windows 7 (=2008r2) rdp 
server indeed fails with 
ERRCONNECT_TLS_CONNECT_FAILED

the error is that there is no cipher match (this probably happens also
with a 2008r2 based rdp gateway server, but that someone would need to
check)

this however can be workarounded by /tls-seclevel:0

If this resolves your issue I would suggest making this the default for
freerdp. If someone from the Ubuntu team is willing to integrate such a
thing I would make a downstream patch for that too..

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

again: a debug log output would be very useful.
With a gateway there are actually two TLS handshakes. It would be useful what 
handshake fails.

What version of RD Gateway are you using? If it is a 2008/2008R2 based
one, is that even openssl3 compatible? (I checked that TLS1.0 is enabled
on the https tls handshake, but I don't know if a required cipher match
is there since I don't have a such old server available)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

> I've been testing this patch and it didn't help in my case

what would probably be useful in this thread if someone would post the
output of ex.

xfreerdp /v:  /log-level:debug

I know we are talk about remmina here, but it would be very strange if
xfreerdp works and remmina doesn't.

For me before applying this patch the relevant last lines where

[DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_HYBRID
[ERROR][com.freerdp.core] - rdg_process_close_packet:freerdp_set_last_error_ex 
E_PROXY_INTERNALERROR [0x800759D8]
[com.freerdp.core.nego] - Failed to connect with NLA security

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

https://github.com/FreeRDP/FreeRDP/pull/7822 addresses a gateway issue
only, so if you don't use a gateway this will not fix anything for you.

I just compiled the latest ubuntu 2.6.1 version with this patch applied
and for me now gateway connections work

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1954970] Re: remmina "Cannot connect to the RDP server ... via TLS. Check that the client and server support a common TLS version"

[msaxl]

it is now fixed upstream and in stable-2.0
https://github.com/FreeRDP/FreeRDP/pull/7823
https://github.com/FreeRDP/FreeRDP/pull/7822

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp2 in Ubuntu.
https://bugs.launchpad.net/bugs/1954970

Title:
  remmina "Cannot connect to the RDP server ... via TLS. Check that the
  client and server support a common TLS version"

Status in freerdp2 package in Ubuntu:
  Confirmed
Status in freerdp2 source package in Jammy:
  Confirmed

Bug description:
  Xubuntu Jammy (21.04)
  after upgrade
 libfreerdp-client2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
 libfreerdp2-2 (2.3.0+dfsg1-2ubuntu2 => 2.4.1+dfsg1-1)
  Remmina can't connect to any RDP server (Win2008 R2) with error:
  "Cannot connect to the RDP server ... via TLS. Check that the client and 
server support a common TLS version"

  Rollback to Impish version of libs
 libfreerdp-client2-2 2.3.0+dfsg1-2ubuntu2
 libfreerdp2-2 2.3.0+dfsg1-2ubuntu2
  makes it work normal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp2/+bug/1954970/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1968195] Re: websocket transport is never enabled

[msaxl]

closed in tandem with #1968577. This was also backported to stable-2.0
branch

** Changed in: freerdp (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp in Ubuntu.
https://bugs.launchpad.net/bugs/1968195

Title:
  websocket transport is never enabled

Status in freerdp package in Ubuntu:
  Fix Released

Bug description:
  freerdp supports an rdp gateway with websocket transport since 2.3.0.

  There was however a backport bug that never enabled this feature since
  the introduction to disable this feature (by /gt:auto,no-websockets)

  the relevant stable push is
  https://github.com/FreeRDP/FreeRDP/pull/7786

  Note that the upstream master branch had never this problem, so that
  feature should be tested by many people.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp/+bug/1968195/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1968195] [NEW] websocket transport is never enabled

[msaxl]

Public bug reported:

freerdp supports an rdp gateway with websocket transport since 2.3.0.

There was however a backport bug that never enabled this feature since
the introduction to disable this feature (by /gt:auto,no-websockets)

the relevant stable push is https://github.com/FreeRDP/FreeRDP/pull/7786

Note that the upstream master branch had never this problem, so that
feature should be tested by many people.

** Affects: freerdp (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to freerdp in Ubuntu.
https://bugs.launchpad.net/bugs/1968195

Title:
  websocket transport is never enabled

Status in freerdp package in Ubuntu:
  New

Bug description:
  freerdp supports an rdp gateway with websocket transport since 2.3.0.

  There was however a backport bug that never enabled this feature since
  the introduction to disable this feature (by /gt:auto,no-websockets)

  the relevant stable push is
  https://github.com/FreeRDP/FreeRDP/pull/7786

  Note that the upstream master branch had never this problem, so that
  feature should be tested by many people.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp/+bug/1968195/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1752670] [NEW] ppp 2.4.7-2+1ubuntu1 bionic mschap broken

[msaxl]

Public bug reported:

pppd 2.4.7-2+1ubuntu1 breaks vpn connections to Windows and Mikrotik Servers.
It seams only mschap is broken.
manually compiling https://github.com/paulusmack/ppp/ fixes it, so the problem
seams to be downstream.

Removing replace-vendored-hash-functions.patch seams to fix the problem

** Affects: ppp (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ppp in Ubuntu.
https://bugs.launchpad.net/bugs/1752670

Title:
  ppp 2.4.7-2+1ubuntu1 bionic mschap broken

Status in ppp package in Ubuntu:
  New

Bug description:
  pppd 2.4.7-2+1ubuntu1 breaks vpn connections to Windows and Mikrotik Servers.
  It seams only mschap is broken.
  manually compiling https://github.com/paulusmack/ppp/ fixes it, so the problem
  seams to be downstream.

  Removing replace-vendored-hash-functions.patch seams to fix the
  problem

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/1752670/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1713226] Re: systemd-networkd messes up networking

[msaxl]

The example 2 in my first posting is not an bug since the package
contains /lib/systemd/network/80-container-host0.network. As I wrote
this only affects systemd-nspawn containers

the unexpected "thing" is that when you upgrade you do not expect a
system wide configuration that is active in parallel to the "old"
ifupdown configuration. To keep your old configuration someone can for
example touch /etc/systemd/network/80-container-host0.network

I have no idea how to deal with that "problem", but I think that not
many have such configurations and less do a container upgrade instead of
a clean update. With luck the rest will be directed here by google ;)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1713226

Title:
  systemd-networkd messes up networking

Status in ifupdown package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Since systemd-234-2ubuntu8 systemd-networkd is enabled by default.

  This causes problems existing configurations
  ex1: if the network has ipv6 enables (the host recieves a router 
advertisement), networkmanager does not configure the network anymore so you 
get only ipv6 and no ipv4 connections (since systemd-networkd seems to bring 
only the link up)

  ex2: if you use systemd-nspawn and configured static ip addresses in
  /etc/network/interfaces, systemd-networkd adds a dhcp obtained address
  on the host0 adapter and a 169.254 address

  For the average user both is not expected, so my solution was
  systemctl disable systemd-networkd, but since you seem to insist
  having this enabled, it must be made sure systemd-networkd does not
  touch existing configurations.

  My suggestion is:
  1) if /etc/network/interfaces contains anything other than lo -> do not 
enable systemd-networkd
  2) if network-manager is enabled, systemd-networkd must be disabled and vice 
versa

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1713226/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1713226] Re: systemd-networkd messes up networking

[msaxl]

Here are the files of the networkmanager systemd-networkd conflict (I
already removed ifupdown, the problem is the same, so we say for sure
networkmanager or systemd-networkd causes the problem)

the output of ip a is the following:

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth1:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 00:1d:7d:c3:a3:a1 brd ff:ff:ff:ff:ff:ff
inet6 fd12:2017:8387:0:8d6:b5ff:bf63:6389/64 scope global mngtmpaddr 
noprefixroute dynamic 
   valid_lft 86396sec preferred_lft 14396sec
inet6 fd12:2017:8387:0:21d:7dff:fec3:a3a1/64 scope global mngtmpaddr 
noprefixroute dynamic 
   valid_lft 86304sec preferred_lft 14304sec
inet6 fe80::21d:7dff:fec3:a3a1/64 scope link

   
   valid_lft forever preferred_lft forever

the profile that should come up has addr-gen-mode=stable-privacy, so
somehow it adds another ipv6 address, but it totally ignores ipv4...

** Attachment added: "files.tar.xz"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1713226/+attachment/4941430/+files/files.tar.xz

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1713226

Title:
  systemd-networkd messes up networking

Status in ifupdown package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Since systemd-234-2ubuntu8 systemd-networkd is enabled by default.

  This causes problems existing configurations
  ex1: if the network has ipv6 enables (the host recieves a router 
advertisement), networkmanager does not configure the network anymore so you 
get only ipv6 and no ipv4 connections (since systemd-networkd seems to bring 
only the link up)

  ex2: if you use systemd-nspawn and configured static ip addresses in
  /etc/network/interfaces, systemd-networkd adds a dhcp obtained address
  on the host0 adapter and a 169.254 address

  For the average user both is not expected, so my solution was
  systemctl disable systemd-networkd, but since you seem to insist
  having this enabled, it must be made sure systemd-networkd does not
  touch existing configurations.

  My suggestion is:
  1) if /etc/network/interfaces contains anything other than lo -> do not 
enable systemd-networkd
  2) if network-manager is enabled, systemd-networkd must be disabled and vice 
versa

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1713226/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1713226] Re: systemd-networkd messes up networking

[msaxl]

this was a upgrade so the ifupdown problem should not happen with clean 
installs.
How is the migration planned?

If for example one will do a upgrade from 16.04 to the next 18.04 such
problems are a clear show stopper since breaking the network for most
servers will mean needing physical access.

On my system there is nothing that puts the interface to state up, so I blame 
systemd-networkd being it (normal desktop system, so /etc/network/interfaces 
contains only a lo entry).
But after all I consider having two systems that configure the same set of 
network interfaces will never work reliable.
I think the best would be systemd-networkd.service conflicts 
network-manager.service

What is the pro of enabling systemd-networkd on desktop systems? I see
advantages on server systems over ifupdown, but afaik neither gnome nor
plasma has systemd-networkd integration.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1713226

Title:
  systemd-networkd messes up networking

Status in network-manager package in Ubuntu:
  New
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Since systemd-234-2ubuntu8 systemd-networkd is enabled by default.

  This causes problems existing configurations
  ex1: if the network has ipv6 enables (the host recieves a router 
advertisement), networkmanager does not configure the network anymore so you 
get only ipv6 and no ipv4 connections (since systemd-networkd seems to bring 
only the link up)

  ex2: if you use systemd-nspawn and configured static ip addresses in
  /etc/network/interfaces, systemd-networkd adds a dhcp obtained address
  on the host0 adapter and a 169.254 address

  For the average user both is not expected, so my solution was
  systemctl disable systemd-networkd, but since you seem to insist
  having this enabled, it must be made sure systemd-networkd does not
  touch existing configurations.

  My suggestion is:
  1) if /etc/network/interfaces contains anything other than lo -> do not 
enable systemd-networkd
  2) if network-manager is enabled, systemd-networkd must be disabled and vice 
versa

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1713226/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp