[Touch-packages] [Bug 1842320] Re: Can't boot: "error: out of memory." immediately after the grub menu
I am getting this error and cannot even boot Ubuntu 22.04.1 from a live
USB. I am using an HP Elite Dragonfly G2 with 16GB of RAM. I get an
error: out of memory message then a kernel panic. Please fix this, I
would very much like to try running Ubuntu but I have to run Fedora 36
instead due to the fact that I can't even boot Ubuntu because of this
bug.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1842320
Title:
Can't boot: "error: out of memory." immediately after the grub menu
Status in grub:
Unknown
Status in OEM Priority Project:
Triaged
Status in grub2-signed package in Ubuntu:
Confirmed
Status in initramfs-tools package in Ubuntu:
Confirmed
Status in linux package in Ubuntu:
Confirmed
Bug description:
[Impact]
* In some cases, if the users’ initramfs grow bigger, then it’ll
likely not be able to be loaded by grub2.
* Some real cases from OEM projects:
In many built-in 4k monitor laptops with nvidia drivers, the u-d-c
puts the nvidia*.ko to initramfs which grows the initramfs to ~120M.
Also the gfxpayload=auto will remain to use 4K resolution since it’s
what EFI POST passed.
In this case, the grub isn't able to load initramfs because the
grub_memalign() won't be able to get suitable memory for the larger
file:
```
#0 grub_memalign (align=1, size=592214020) at ../../../grub-core/kern/mm.c:376
#1 0x7dd7b074 in grub_malloc (size=592214020) at
../../../grub-core/kern/mm.c:408
#2 0x7dd7a2c8 in grub_verifiers_open (io=0x7bc02d80, type=131076)
at ../../../grub-core/kern/verifiers.c:150
#3 0x7dd801d4 in grub_file_open (name=0x7bc02f00
"/boot/initrd.img-5.17.0-1011-oem",
type=131076) at ../../../grub-core/kern/file.c:121
#4 0x7bcd5a30 in ?? ()
#5 0x7fe21247 in ?? ()
#6 0x7bc030c8 in ?? ()
#7 0x00017fe21238 in ?? ()
#8 0x7bcd5320 in ?? ()
#9 0x7fe21250 in ?? ()
#10 0x in ?? ()
```
Based on grub_mm_dump, we can see the memory fragment (some parts seem
likely be used because of 4K resolution?) and doesn’t have available
contiguous memory for larger file as:
```
grub_real_malloc(...)
...
if (cur->size >= n + extra)
```
Based on UEFI Specification Section 7.2[1] and UEFI driver writers’
guide 4.2.3[2], we can ask 32bits+ on AllocatePages().
As most X86_64 platforms should support 64 bits addressing, we should
extend GRUB_EFI_MAX_USABLE_ADDRESS to 64 bits to get more available
memory.
* When users grown the initramfs, then probably will get initramfs
not found which really annoyed and impact the user experience (system
not able to boot).
[Test Plan]
* detailed instructions how to reproduce the bug:
1. Any method to grow the initramfs, such as install nvidia-driver.
2. If developers would like to reproduce, then could dd if=/dev/random
of=... bs=1M count=500, something like:
```
$ cat /usr/share/initramfs-tools/hooks/zzz-touch-a-file
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
dd if=/dev/random of=${DESTDIR}/test-500M bs=1M count=500
```
And then update-initramfs
* After applying my patches, the issue is gone.
* I did also test my test grubx64.efi in:
1. X86_64 qemu with
1.1. 60M initramfs + 5.15.0-37-generic kernel
1.2. 565M initramfs + 5.17.0-1011-oem kernel
2. Amd64 HP mobile workstation with
2.1. 65M initramfs + 5.15.0-39-generic kernel
2.2. 771M initramfs + 5.17.0-1011-oem kernel
All working well.
[Where problems could occur]
* The changes almost in i386/efi, thus the impact will be in the i386 /
x86_64 EFI system.
The other change is to modify the “grub-core/kern/efi/mm.c” but I use the
original addressing for “arm/arm64/ia64/riscv32/riscv64”.
Thus it should not impact them.
* There is a “#if defined(__x86_64__)” which intent to limit the >
32bits code in i386 system and also
```
#if defined (__code_model_large__)
-#define GRUB_EFI_MAX_USABLE_ADDRESS 0x
+#define GRUB_EFI_MAX_USABLE_ADDRESS __UINTPTR_MAX__
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x7fff
#else
#define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fff
+#define GRUB_EFI_MAX_ALLOCATION_ADDRESS 0x3fff
#endif
```
If everything works as expected, then i386 should working good.
If not lucky, based on “UEFI writers’ guide”[2], the i386 will get >
4GB memory region and never be able to access.
[Other Info]
* Upstream grub2 bug #61058
https://savannah.gnu.org/bugs/index.php?61058
* Test PPA: https://launchpad.net/~os369510/+archive/ubuntu/lp1842320
* Test grubx64.efi:
[Touch-packages] [Bug 1970402] Re: Initrd out of memory error after upgrade to 22.04
*** This bug is a duplicate of bug 1842320 *** https://bugs.launchpad.net/bugs/1842320 I am getting the same error and cannot even boot Ubuntu 22.04.1 from a live USB. I am using an HP Elite Dragonfly G2 with 16GB of RAM. I get an error: out of memory message then a kernel panic. Please fix this, I would very much like to try running Ubuntu but I have to run Fedora 36 instead. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1970402 Title: Initrd out of memory error after upgrade to 22.04 Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Jammy: Confirmed Bug description: After upgrading to 22.04 system is unbootable because of "out of memory" error when loading initial ramdisk. I was able to fix it by editing cat /etc/initramfs-tools/initramfs.conf and changing configuration to: MODULES=dep COMPRESS=xz RUNSIZE=15% Not sure which one helped, but I can test it if needed. System information: Description:Ubuntu 22.04 LTS Release:22.04 initramfs-tools: Installed: 0.140ubuntu13 Candidate: 0.140ubuntu13 Version table: *** 0.140ubuntu13 500 500 http://pl.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 500 http://pl.archive.ubuntu.com/ubuntu jammy/main i386 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970402/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718931] Re: No VPN autoconnect
Well...it has been quite some time and this bug has received absolutely *zero* attention from the Gnome Shell Gitlab here https://gitlab.gnome.org/GNOME/gnome-shell/issues/123 escalated from the Gnome Bugzilla tracker after Gnome shell development moved to Gitlab. The issue is fully present in Ubuntu 18.04 AND in the newer version of the Gnome shell and NetworkManager in Fedora 28. Before v3.26.X, auto- connect worked fine through the NetworkManager in the Gnome environment. I'm afraid to report that months later, absolutely nothing has been done to address what should be a relatively high-priority bug in the Gnome Shell. If anyone has the capabilities to reach out farther than I already have, please do so. This critical bug has been sitting idle with no attention for months, and persists across newer versions of the Gnome shell, namely 3.28.X, seemingly independent of distribution. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1718931 Title: No VPN autoconnect Status in NetworkManager: Incomplete Status in network-manager package in Ubuntu: Triaged Bug description: When setting up VPN to auto connect with wifi (done through nm- connection-editor) the wifi never manages to connect. However if I unselect the auto connect option while it is attempting a reconnection then it manages to connect to both (wifi and VPN). Doing the connection manually also poses no issues ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: network-manager 1.8.2-1ubuntu8 ProcVersionSignature: Ubuntu 4.13.0-11.12-generic 4.13.1 Uname: Linux 4.13.0-11-generic x86_64 ApportVersion: 2.20.7-0ubuntu1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Sep 22 13:15:55 2017 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2017-09-09 (12 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170908) IpRoute: default via 192.168.0.1 dev wlp6s0 proto static metric 600 169.254.0.0/16 dev wlp6s0 scope link metric 1000 192.168.0.0/24 dev wlp6s0 proto kernel scope link src 192.168.0.18 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH wlp6s0 wifi connected /org/freedesktop/NetworkManager/Devices/2 VM5055940 85b8f881-7ed9-477a-9c39-9afb5a40bda9 /org/freedesktop/NetworkManager/ActiveConnection/1 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- ---- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.8.2connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1718931/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718931] Re: No VPN autoconnect
Filed an upstream bug, at long last, in the Gnome bugtracker at https://bugzilla.gnome.org/show_bug.cgi?id=793977 ** Bug watch added: GNOME Bug Tracker #793977 https://bugzilla.gnome.org/show_bug.cgi?id=793977 ** Also affects: network-manager via https://bugzilla.gnome.org/show_bug.cgi?id=793977 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1718931 Title: No VPN autoconnect Status in NetworkManager: Unknown Status in network-manager package in Ubuntu: Confirmed Bug description: When setting up VPN to auto connect with wifi (done through nm- connection-editor) the wifi never manages to connect. However if I unselect the auto connect option while it is attempting a reconnection then it manages to connect to both (wifi and VPN). Doing the connection manually also poses no issues ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: network-manager 1.8.2-1ubuntu8 ProcVersionSignature: Ubuntu 4.13.0-11.12-generic 4.13.1 Uname: Linux 4.13.0-11-generic x86_64 ApportVersion: 2.20.7-0ubuntu1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Sep 22 13:15:55 2017 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2017-09-09 (12 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170908) IpRoute: default via 192.168.0.1 dev wlp6s0 proto static metric 600 169.254.0.0/16 dev wlp6s0 scope link metric 1000 192.168.0.0/24 dev wlp6s0 proto kernel scope link src 192.168.0.18 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH wlp6s0 wifi connected /org/freedesktop/NetworkManager/Devices/2 VM5055940 85b8f881-7ed9-477a-9c39-9afb5a40bda9 /org/freedesktop/NetworkManager/ActiveConnection/1 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- ---- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.8.2connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1718931/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718931] Re: No VPN autoconnect
Okay, so...why isn't this a priority bugfix? I love gnome, don't get me wrong, but when I can't even autoconnect to my VPN like I did countless times in the past few years running Ubuntu on Unity without compromising the security of my system something is wrong. There needs to be an option - and a working one at that - for auto-connecting to a VPN through the Gnome NetworkManager GUI. The KDE folks fixed this ages ago with KWallet, I suspect this involves the Gnome-Keyring. This is a *very* annoying problem. Should I report the bug on the Gnome bugtracker? So frustrating when this is an extremely common problem with nobody actually looking into *why* it's happening or how to fix it. I'm afraid this one is beyond me. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1718931 Title: No VPN autoconnect Status in network-manager package in Ubuntu: Confirmed Bug description: When setting up VPN to auto connect with wifi (done through nm- connection-editor) the wifi never manages to connect. However if I unselect the auto connect option while it is attempting a reconnection then it manages to connect to both (wifi and VPN). Doing the connection manually also poses no issues ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: network-manager 1.8.2-1ubuntu8 ProcVersionSignature: Ubuntu 4.13.0-11.12-generic 4.13.1 Uname: Linux 4.13.0-11-generic x86_64 ApportVersion: 2.20.7-0ubuntu1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Sep 22 13:15:55 2017 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2017-09-09 (12 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170908) IpRoute: default via 192.168.0.1 dev wlp6s0 proto static metric 600 169.254.0.0/16 dev wlp6s0 scope link metric 1000 192.168.0.0/24 dev wlp6s0 proto kernel scope link src 192.168.0.18 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH wlp6s0 wifi connected /org/freedesktop/NetworkManager/Devices/2 VM5055940 85b8f881-7ed9-477a-9c39-9afb5a40bda9 /org/freedesktop/NetworkManager/ActiveConnection/1 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- ---- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.8.2connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1718931/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
@bagl0312 I agree, there really should be some kind of GUI default way to set negative DNS priority when setting up certain VPN connections. The average user shouldn't experience a nasty surprise when DNS leaks happen by default. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in NetworkManager: Unknown Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Zesty: Confirmed Status in network-manager source package in Artful: Fix Released Bug description: [Impact] * NetworkManager incorrectly handles dns-priority of the VPN-like connections, which leads to leaking DNS queries outside of the VPN into the general internet. * Upstream has resolved this issue in master and 1.8 to correctly configure any dns backends with negative dns-priority settings. [Test Case] #FIXME# * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. #FIXME# [Regression Potential] * If this issue is changed DNS resolution will change, for certain queries, to go via VPN rather than general internet. And therefore, one may get new/different results or even loose access to resolve/access certain parts of the interent depending on what the DNS server on VPN chooses to respond to. [Other Info] * Original bug report I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1728145] [NEW] gnome-terminal does not fill screen when window snapping on Wayland in Ubuntu 17.10
Public bug reported: When using a Wayland gnome-session or Wayland ubuntu-session in Ubuntu 17.10, gnome-terminal (v3.24.2 is the version in the 17.10 repositories) does not fill the screen at all when snapping the window to the right or left side. There are large gaps on the right and bottom edges of the terminal window in Wayland. On the same computer, with the same version of gnome-terminal in an Xorg gnome-session or Xorg ubuntu-session, the window fills screen space entirely and there is no problem. I am not using display scaling or hidpi features at all, my display resolution is set at default 1080p. This needs to be fixed or I'm ditching gnome- terminal. Expected behavior: gnome-terminal window should fill right/left of screen when snapped to corner in a Wayland session What happened instead: gnome-terminal window does not fill screen space when snapped to right or left edge of desktop on Wayland session, there are large gaps below and to the right of the snapped window on either side. ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New ** Affects: wayland (Ubuntu) Importance: Undecided Status: New ** Tags: gnome-terminal wayland ** Also affects: wayland (Ubuntu) Importance: Undecided Status: New ** Description changed: - When using a Wayland gnome-session or ubuntu-session in Ubuntu 17.10, - gnome-terminal (v3.24.2 is the version in the 17.10 repositories) does - not fill the screen at all when snapping the window to the right or left - side.There are large gaps on the right and bottom edges of the terminal - window in Wayland. On the same computer, with the same version of gnome- - terminal in an Xorg gnome-session or Xorg ubuntu-session, the window - fills screen space entirely and there is no problem. I am not using - display scaling or hidpi features at all, my display resolution is set - at default 1080p. This needs to be fixed or I'm ditching gnome-terminal. + When using a Wayland gnome-session or Wayland ubuntu-session in Ubuntu + 17.10, gnome-terminal (v3.24.2 is the version in the 17.10 repositories) + does not fill the screen at all when snapping the window to the right or + left side.There are large gaps on the right and bottom edges of the + terminal window in Wayland. On the same computer, with the same version + of gnome-terminal in an Xorg gnome-session or Xorg ubuntu-session, the + window fills screen space entirely and there is no problem. I am not + using display scaling or hidpi features at all, my display resolution is + set at default 1080p. This needs to be fixed or I'm ditching gnome- + terminal. Expected behavior: gnome-terminal window should fill right/left of screen when snapped to corner in a Wayland session What happened instead: gnome-terminal window does not fill screen space when snapped to right or left edge of desktop on Wayland session, there are large gaps below and to the right of the snapped window on either side. ** Description changed: When using a Wayland gnome-session or Wayland ubuntu-session in Ubuntu 17.10, gnome-terminal (v3.24.2 is the version in the 17.10 repositories) does not fill the screen at all when snapping the window to the right or - left side.There are large gaps on the right and bottom edges of the + left side. There are large gaps on the right and bottom edges of the terminal window in Wayland. On the same computer, with the same version of gnome-terminal in an Xorg gnome-session or Xorg ubuntu-session, the window fills screen space entirely and there is no problem. I am not using display scaling or hidpi features at all, my display resolution is set at default 1080p. This needs to be fixed or I'm ditching gnome- terminal. Expected behavior: gnome-terminal window should fill right/left of screen when snapped to corner in a Wayland session What happened instead: gnome-terminal window does not fill screen space when snapped to right or left edge of desktop on Wayland session, there are large gaps below and to the right of the snapped window on either side. ** Summary changed: - gnome-terminal does not fill screen when window snapping on Wayland + gnome-terminal does not fill screen when window snapping on Wayland in Ubuntu 17.10 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1728145 Title: gnome-terminal does not fill screen when window snapping on Wayland in Ubuntu 17.10 Status in gnome-terminal package in Ubuntu: New Status in wayland package in Ubuntu: New Bug description: When using a Wayland gnome-session or Wayland ubuntu-session in Ubuntu 17.10, gnome-terminal (v3.24.2 is the version in the 17.10 repositories) does not fill the screen at all when snapping the window to the right or left side. There are large gaps on the right and bottom edges of the terminal window in Wayland. On
[Touch-packages] [Bug 1728143] [NEW] Screen freezes after waking from suspend with Gnome on Wayland
Public bug reported: It appears that using Xorg instead of Wayland is the only way to fix this problem on Ubuntu 17.10. For some odd reason, whenever I wake my computer from suspend (especially after an extended period of time asleep) using Gnome in a Wayland session (gnome-session and stock ubuntu-session alike), my screen freezes completely on whatever was last there before suspending and I can't get any IO response at all. Nothing, the screen is totally frozen. I am also unable to exit into a recovery shell or kill GDM or gnome-session/ubuntu-session locally. I also can't seem to find any traces or indications for the freeze in the syslog, or maybe I'm just not sure where to look. I believe this is a problem with GDM on Wayland, not kernel related, as it happens on a totally stock install and when I use an upgraded/downgraded kernel. It literally necessitates restarting my computer. This problem is nonexistent when using Xorg instead of Wayland with GDM. Anyone else have this issue on Ubuntu 17.10 or figure out a solution better than simply switching to Xorg? I should clarify that I am not using nvidia drivers, I'm using Intel integrated graphics on a core-i7 5500U. Ubuntu 17.10 uses gnome-session v3.26.1. Expected behavior: When waking computer from suspend, expect GDM lock prompt and log back in. What happened instead: When waking computer from suspend, screen and IO is completely frozen, necessitating a force-shutdown. ** Affects: gdm (Ubuntu) Importance: Undecided Status: New ** Affects: gnome-session (Ubuntu) Importance: Undecided Status: New ** Affects: wayland (Ubuntu) Importance: Undecided Status: New ** Tags: gdm gnome-17.10 gnome-session suspend-resume ** Also affects: gnome-session (Ubuntu) Importance: Undecided Status: New ** Also affects: wayland (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1728143 Title: Screen freezes after waking from suspend with Gnome on Wayland Status in gdm package in Ubuntu: New Status in gnome-session package in Ubuntu: New Status in wayland package in Ubuntu: New Bug description: It appears that using Xorg instead of Wayland is the only way to fix this problem on Ubuntu 17.10. For some odd reason, whenever I wake my computer from suspend (especially after an extended period of time asleep) using Gnome in a Wayland session (gnome-session and stock ubuntu-session alike), my screen freezes completely on whatever was last there before suspending and I can't get any IO response at all. Nothing, the screen is totally frozen. I am also unable to exit into a recovery shell or kill GDM or gnome-session/ubuntu-session locally. I also can't seem to find any traces or indications for the freeze in the syslog, or maybe I'm just not sure where to look. I believe this is a problem with GDM on Wayland, not kernel related, as it happens on a totally stock install and when I use an upgraded/downgraded kernel. It literally necessitates restarting my computer. This problem is nonexistent when using Xorg instead of Wayland with GDM. Anyone else have this issue on Ubuntu 17.10 or figure out a solution better than simply switching to Xorg? I should clarify that I am not using nvidia drivers, I'm using Intel integrated graphics on a core-i7 5500U. Ubuntu 17.10 uses gnome-session v3.26.1. Expected behavior: When waking computer from suspend, expect GDM lock prompt and log back in. What happened instead: When waking computer from suspend, screen and IO is completely frozen, necessitating a force-shutdown. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1728143/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
I'm not sure about split-horizon DNS, frankly I think that is a different bug entirely. However, I have had no problems with DNS leaks over my VPN connections whatsoever on Ubuntu 17.10. The bugfix I personally requested from the NM-devs and backported to Ubuntu 17.04 (running NetworkManager v1.4.x) was effectively just patching the negative dns-priority bug related to systemd-resolved. From 'man nm- settings': "Negative values have the special effect of excluding other configurations with a greater priority value; so in presence of at least a negative priority, only DNS servers from connections with the lowest priority value will be used." This means that DNS servers configured for the non-VPN connection will be 'unseated' and ONLY the VPN-configured DNS servers are used. Ubuntu 17.10 is running NetworkManager v1.8.4, so Thomas Haller's merged bugfix is present and working. You MUST use the command: 'sudo nmcli connection modify ipv4.dns-priority -42' or similar to actually set negative DNS priority for the VPN connection. Restart the network manager with 'sudo service network-manager restart', then connect to the VPN. Examine the output of 'systemd-resolved --status' and use the 'Extended' test on dnsleaktest.com to verify that you are not leaking DNS queries. I use openvpn, but setting negative dns priority should work for preventing DNS leaks over regular VPN connections of all kinds as a kind of 'catch-all'. Auto-connecting to openvpn through the GUI is a little troublesome in 17.10, but this 'fix' worked for me: https://askubuntu.com/questions/967408/how-to-automatically-connect-to-vpn-in-ubuntu-17-10/967415#967415 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in NetworkManager: Unknown Status in network-manager package in Ubuntu: Confirmed Status in network-manager source package in Zesty: Confirmed Status in network-manager source package in Artful: Confirmed Bug description: [Impact] * NetworkManager incorrectly handles dns-priority of the VPN-like connections, which leads to leaking DNS queries outside of the VPN into the general internet. * Upstream has resolved this issue in master and 1.8 to correctly configure any dns backends with negative dns-priority settings. [Test Case] #FIXME# * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. #FIXME# [Regression Potential] * If this issue is changed DNS resolution will change, for certain queries, to go via VPN rather than general internet. And therefore, one may get new/different results or even loose access to resolve/access certain parts of the interent depending on what the DNS server on VPN chooses to respond to. [Other Info] * Original bug report I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718931] Re: No VPN autoconnect
Literally just toggling that one option "Store password for all users" in the VPN settings fixes the problem entirely. Use "sudo service network-manager restart" and it connects flawlessly the first time. To avoid the error loop on bootup specifically, just uncheck the box "Make available to other users" on the primary connection. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1718931 Title: No VPN autoconnect Status in network-manager package in Ubuntu: Confirmed Bug description: When setting up VPN to auto connect with wifi (done through nm- connection-editor) the wifi never manages to connect. However if I unselect the auto connect option while it is attempting a reconnection then it manages to connect to both (wifi and VPN). Doing the connection manually also poses no issues ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: network-manager 1.8.2-1ubuntu8 ProcVersionSignature: Ubuntu 4.13.0-11.12-generic 4.13.1 Uname: Linux 4.13.0-11-generic x86_64 ApportVersion: 2.20.7-0ubuntu1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Sep 22 13:15:55 2017 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2017-09-09 (12 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170908) IpRoute: default via 192.168.0.1 dev wlp6s0 proto static metric 600 169.254.0.0/16 dev wlp6s0 scope link metric 1000 192.168.0.0/24 dev wlp6s0 proto kernel scope link src 192.168.0.18 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH wlp6s0 wifi connected /org/freedesktop/NetworkManager/Devices/2 VM5055940 85b8f881-7ed9-477a-9c39-9afb5a40bda9 /org/freedesktop/NetworkManager/ActiveConnection/1 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- ---- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.8.2connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1718931/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1718931] Re: No VPN autoconnect
Yeah, I keep getting the "vpn-connection[...]: Failed to request VPN secrets #3: No agents were available for this request." error message in my syslog. I found, however, that THIS worked for me: All you have to do is go Dash->VPN->VPN Settings->connection_name_here->Identity->Password->"Store for all users" and bingo problem solved. If nm-connection-editor says that you can't save the connection (the save box is grayed out), then...just forget the network and set up the connection again (worked for me at least). Once you have checked said auto-connect box with nm-connection- editor and ensured that the VPN password is set to "Store for all users," both the primary connection AND the VPN will start successfully at the same time. See my post at https://askubuntu.com/questions/967408 /how-to-automatically-connect-to-vpn-in-ubuntu-17-10/967415#967415 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1718931 Title: No VPN autoconnect Status in network-manager package in Ubuntu: Confirmed Bug description: When setting up VPN to auto connect with wifi (done through nm- connection-editor) the wifi never manages to connect. However if I unselect the auto connect option while it is attempting a reconnection then it manages to connect to both (wifi and VPN). Doing the connection manually also poses no issues ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: network-manager 1.8.2-1ubuntu8 ProcVersionSignature: Ubuntu 4.13.0-11.12-generic 4.13.1 Uname: Linux 4.13.0-11-generic x86_64 ApportVersion: 2.20.7-0ubuntu1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Sep 22 13:15:55 2017 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2017-09-09 (12 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha amd64 (20170908) IpRoute: default via 192.168.0.1 dev wlp6s0 proto static metric 600 169.254.0.0/16 dev wlp6s0 scope link metric 1000 192.168.0.0/24 dev wlp6s0 proto kernel scope link src 192.168.0.18 metric 600 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-dev: DEVICE TYPE STATE DBUS-PATH CONNECTION CON-UUID CON-PATH wlp6s0 wifi connected /org/freedesktop/NetworkManager/Devices/2 VM5055940 85b8f881-7ed9-477a-9c39-9afb5a40bda9 /org/freedesktop/NetworkManager/ActiveConnection/1 lo loopback unmanaged /org/freedesktop/NetworkManager/Devices/1 -- ---- nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.8.2connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1718931/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
@Stephan the Penguin god has not forsaken us, my friend :D So glad it works for you guys, thanks for the nice feedback! This issue bugged me so much I sorta made it my mission haha. It's fantastic I finally got this thing sorted out with some help from the Gnome NM devs :) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in network-manager source package in Artful: Confirmed Status in systemd source package in Artful: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Please test with the new patch or patched .deb and follow the steps to set negative ipv4 dns-priority. I (and lead NM-dev Thomas Haller himself) believe this resolves the bug. Thanks, and I hope this helps you all! :) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in network-manager source package in Artful: Confirmed Status in systemd source package in Artful: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
After setting the ipv4.dns-priority of the VPN connection to a negative number and patching the source or installing the conveniently packaged .deb below, you should not experience DNS leaks over NM-VPN. (Output from extended test at https://dnsleaktest.com ) Test complete Query round Progress... Servers found 1 .. 1 2 .. 1 3 .. 1 4 .. 1 5 .. 1 6 .. 1 IP HostnameISP Country 173.239.226.69 ip-69-226-239-173.east.us.northamericancoax.com LogicWeb Inc United States To install the .deb package, simply use: cd ~/Downloads && sudo dpkg -i network-manager_1.4.4-1ubuntu4_amd64.deb NOTE: make sure apt does not replace the package with: sudo apt-mark hold network-manager Make sure to stop all network services and restart the network manager using: sudo service network-manager stop sudo service networking restart sudo service network-manager start To build the source and apply the patch yourself, use the following steps: sudo apt-get build-dep network-manager cd ~/Downloads && mkdir nm-patch && cd nm-patch apt-get source network-manager cd network-manager-1.4.4 cp ~/Downloads/systemd-resolved-dns-priority-fix.patch . patch -p1 < systemd-resolved-dns-priority-fix.patch rm systemd-resolved-dns-priority-fix.patch dpkg-buildpackage -us -uc -b (wait a while, it will take some time to compile) Then install the generated network-manager_1.4.4-1ubuntu .deb package using: cd ../ && sudo dpkg -i ** Attachment added: "network-manager_1.4.4-1ubuntu4_amd64.deb" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1624317/+attachment/4900613/+files/network-manager_1.4.4-1ubuntu4_amd64.deb -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in network-manager source package in Artful: Confirmed Status in systemd source package in Artful: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
I have successfully backported Thomas Haller's excellent upstream solution as detailed in https://bugzilla.gnome.org/show_bug.cgi?id=783569 This took some time as things have changed quite a bit upstream, but the patch works on the current zesty 17.04 1.4.4-1ubuntu3.1 network-manager! This is a much better fix than the stopgap SetLinkDomains "." bus call based on link type I included in the previous patch. It should be reviewed for current application/submission to the package maintainers as it is basically a direct backport of Haller's fix merged upstream. NOTE: You MUST set the ipv4.dns-priority to a negative number for the network-manager to unseat DNS configurations for other non-VPN interfaces. This patch allows for correct behavior with negative ipv4 .dns-priority: "Negative values have the special effect of excluding other configurations with a greater priority value; so in presence of at least a negative priority, only DNS servers from connections with the lowest priority value will be used." Usage of a negative dns-priority disables DNS configuration for all other interfaces, ensuring there are no DNS leaks over a VPN connection using systemd-resolved. Before Haller's bugfix, this feature did not work with systemd-resolved. To set the ipv4.dns-priority, open the VPN connection profile you have configured through NM like so: sudo nano /etc/NetworkManager/system-connections/ and adding the line (value of -42 recommended by Haller) "dns-priority=-42" so that the file contains something like: [ipv4] dns-priority=-42 dns-search= method=auto Alternatively, use the command sudo nmcli connection modify "" ipv4.dns-priority -42 And you should see that the config file for that connection contains the same line as shown above. After doing so and patching/installing the patched network manager, you should not experience DNS leaks. When I am connected to PIA's servers through network-manager-openvpn using the patched network manager and a negative ipv4.dns-priority set for my VPN connection, the output of systemd-resolved looks like this (notice that the Verizon ISP DNS server was 'unseated' and is absent for the primary wireless link wlo1): Global DNSSEC NTA: 10.in-addr.arpa ...(long list of NTAs omitted)... test Link 4 (tun0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 209.222.18.222 209.222.18.218 Link 2 (wlo1) Current Scopes: LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no If anyone is curious about support for the routing-only domain in NM, see the following bug https://bugzilla.gnome.org/show_bug.cgi?id=746422 which is about adding support for routing-only domains for systemd- resolved (still work in progress). ** Bug watch added: GNOME Bug Tracker #746422 https://bugzilla.gnome.org/show_bug.cgi?id=746422 ** Patch added: "systemd-resolved-dns-priority-fix.patch" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1624317/+attachment/4900587/+files/systemd-resolved-dns-priority-fix.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in network-manager source package in Artful: Confirmed Status in systemd source package in Artful: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Hey all, so it seems like Thomas Haller at the bug thread https://bugzilla.gnome.org/show_bug.cgi?id=783569 may have actually fixed this issue upstream! Not sure how to backport the fix though, I tried and didn't have any luck, so this may be up to the package maintainers. I think this might actually be fixed though! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in network-manager source package in Artful: Confirmed Status in systemd source package in Artful: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Unfortunately my patch is not a good solution for upstream application. I agree with what Beniamino Galvani mentioned, that "it is wrong to assume the connection is a VPN based on the link type, since you can have non-VPN tun/tap/gre/gretap connections as well, and they are affected by this patch." However, it seems that this issue with DNS leaks over NM-VPN connections and broken VPN split-horizon DNS using systemd-resolved still exists upstream and doesn't have a good fix. I think this issue needs some attention and work from the Gnome- NM/systemd/Canonical devs, I've reached my limit here. :( -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in network-manager source package in Artful: Confirmed Status in systemd source package in Artful: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Actually I take that back. The issue is not fixed by the commit referenced on https://bugzilla.gnome.org/show_bug.cgi?id=783569 as it is already present in the current version of the network-manager. So we still have a major problem folks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in network-manager source package in Artful: Confirmed Status in systemd source package in Artful: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
My apologies, it seems like this issue could have already been addressed upstream. See https://bugzilla.gnome.org/show_bug.cgi?id=783569 Anyway, I'll see if I can backport the fix provided there and whether or not it works. Sorry guys :/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
I have upstreamed the patch at https://bugzilla.gnome.org/show_bug.cgi?id=783569 ! Hopefully this can be incorporated into future releases of network-manager :) ** Bug watch added: GNOME Bug Tracker #783569 https://bugzilla.gnome.org/show_bug.cgi?id=783569 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
No, it's not an upstream patch. My patch can be applied directly to the current source on 17.04 obtained using 'apt-get source network-manager', so that would be network-manager 1.4.4-1ubuntu3 from http://us.archive.ubuntu.com/ubuntu zesty/main amd64 Packages -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
** Attachment added: "patched network-manager .deb for easy testing on Ubuntu 17.04" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1624317/+attachment/4891741/+files/network-manager_1.4.4-1ubuntu4_amd64.deb -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
In reference to John Bedford's comment: >bedfojo (commercial-johnbedford) wrote on 2017-06-06: #57 >Nicholas, thank you very much for your work on this patch. >It works correctly for me: no DNS leak detected by either https://ipleak.net >or >https://dnsleaktest.com for me, when both detected leaks in the unpatched >version. >Running Ubuntu-MATE 17.04. >Could we perhaps get this upstreamed into NM? >bedfojo (commercial-johnbedford) wrote on 2017-06-06: #58 >I should add that I'm using network-manager-openvpn and >network-manager-openvpn-gnome. I think it would be great if we could get this patch upstreamed into the network-manager! I've attached a finalized version of the patch with a more informative / verbose syslog message that also accounts for cisco gre/gretap connections not in #49. Please use this patch when building network-manager for Ubuntu 17.04. I will also attach a .deb build of network-manager for easy installation and testing for anyone interested. So far, this is known to solve dns leaks with network-manager-openvpn but could also solve dns leaks for other VPNs that use TUN, TAP, or Cisco GRE network interfaces through the network-manager. You should now see a message in your syslog when connecting that looks like the following: NetworkManager[32636]: [1496880041.6435] systemd-resolved[0x55cc602ce430]: Link #12 type is VPN TUN or TAP, fixing DNS leak... Make sure to stop apt from replacing the patched .deb using: sudo apt-mark hold network-manager To verify that you are using the 'routing-only domain', use the command systemd-resolve --status and look for the line "DNS Domain: ~." under the VPN link number. Alternatively, check that you are not experiencing DNS leaks using the 'extended test' on https://dnsleaktest.com/ Cheers :) ** Patch added: "resolved-vpn-dns-leak-fix.patch" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1624317/+attachment/4891740/+files/resolved-vpn-dns-leak-fix.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
** Patch removed: "patch for network-manager source" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1624317/+attachment/4889747/+files/resolved-vpn-dns-leak-fix.patch ** Patch removed: "possible cisco network-manager-openconnect-fix" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1624317/+attachment/4890352/+files/resolved-vpn-dns-leak-fix.patch ** Attachment removed: "patched network manager .deb for easy fix installation on Ubuntu 17.04" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1624317/+attachment/4889755/+files/network-manager_1.4.4-1ubuntu3_amd64.deb ** Attachment removed: "updated patched .deb packaged network-manager for easy testing" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1624317/+attachment/4890421/+files/network-manager_1.4.4-1ubuntu3_amd64.deb -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Huh, weird, yeah it's quite possible it's a different issue entirely, or a problem related to network-manager-openconnect. Because the routing- only domain is clearly listed as DNS Domain ~. so systemd-resolved should only send queries to the specified dns servers for the interface vpn0. Yeah...not sure sorry. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Huh. No, actually my patch DID work. See the line under vpn0 that says DNS Domain: ~. So the correct bus call was made and all dns queries SHOULD be directed to the link-specified listed DNS servers. Your problem actually appears to be that there are no link-specified dns servers. See the line that says DNS Servers: Please try manually specifying the correct DNS servers in the network-manager-openconnect gui settings. That should fix your problem I believe. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Tim, I have a question for you. When you connect through network-manager-openconnect-gnome, and type systemd-resolve --status, what is your link name called? Something like 'tun0' or 'tap1' or the like? Because I've been looking around at the openconnect wiki at http://www.infradead.org/openconnect/building.html, and it seems like openconnect requires tun/tap drivers. So theoretically, it should have worked with the original patch containing just the conditional expression: if (link_type == NM_LINK_TYPE_TUN || link_type == NM_LINK_TYPE_TAP) As in, this should evaluate to true as the link should be of type tun or tap. It seems like the updated patch containing the conditional expression if (link_type == NM_LINK_TYPE_TUN || link_type == NM_LINK_TYPE_TAP || link_type == NM_LINK_TYPE_GRE || link_type == NM_LINK_TYPE_GRETAP) might, however, help address users of network-manager-vpnc/network-manager-vpnc-gnome. If anyone uses network-manager-vpnc/network-manager-vpnc-gnome, let me know if the newer patch containing the cases for NM_LINK_TYPE_GRE and NM_LINK_TYPE_GRETAP fixes DNS leaks for you on a Cisco PPTP/IPsec VPN. I am unable to test this out as I don't have access to any such Cisco VPN services. Anyway, if the network manager doesn't correctly register the openconnect interface as being link type TUN or TAP, I don't really know how to fix it as that could be a problem on network-manager- openconnect's end or the result of some way it doesn't properly notify the network manager. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Jordi, Sure thing, glad I could help. :) I wonder if somebody can figure out how to help Tim with network-manager-openconnect. I tried adding two more conditions for cisco vpn gre connections but apparently it didn't work or those aren't the kind of links used. Not sure how to address that because the innards of network-manager and how it interacts with plugins is fairly complex, but maybe someone could modify the patch to account for that. For anyone just using network-manager-openvpn, the first patch and .deb uploaded are all that is needed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Sorry to here that, I'm frankly not sure what to do about that then :/ At the very least the original patch fixes stuff for openvpn, which is good. Perhaps someone else could figure out the cisco openconnect thing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Anyone using Cisco PPTP/IPsec/openconnect VPN, please test the network manager with the aforementioned patch or with the updated built .deb provided here. The updated patch should address more types of VPN links. Thanks! ** Attachment added: "updated patched .deb packaged network-manager for easy testing" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317/+attachment/4890421/+files/network-manager_1.4.4-1ubuntu3_amd64.deb -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Tim Shannon, from the comment about network-manager-openconnect-gnome, please use this updated patch to build the network manager. I added conditions for the cisco GRE and GRETAP link types, see https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation and http://www.cisco.com/c/en/us/td/docs/security/security_management/cisco_security_manager/security_manager/4-4/user/guide/CSMUserGuide_wrapper/vpgredm.html#69194 so I think this might fix the issue connecting through network-manager-openconnect-gnome Please build the network-manager with the following patch and see if DNS leaks are fixed over cisco openconnect VPN links. Thanks! ** Patch added: "possible cisco network-manager-openconnect-fix" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317/+attachment/4890352/+files/resolved-vpn-dns-leak-fix.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Yeah, apologies as I'm not sure what link type that openconnect uses / how to identify an openconnect link. It would be a simple matter to add a conditional for that in the file I patched, please try that. For now my patch only addresses openvpn tap or tun links, but I'm sure it could be expanded if possible. Anyone using network-manager-openvpn please test. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
>From the Debian man pages, it seems like this is not in fact a problem of systemd itself, as it allows for domain routing exclusively for dns servers on a single interface using the routing-only domain. My patch effectively just tells the NetworkManager to make a systemd bus call for the routing-only domain when the connection is a vpn tun or tap link. In fact, this feature of systemd, the routing-only domain, is a marked improvement from the glibc API, which has no equivalent concept of dns servers limited to a system link. The SetLinkDomains method of the systemd-resolved API allows for this behavior. >From SYSTEMD.NETWORK(5): "The "routing-only" domain "~." (the tilde indicating definition of a routing domain, the dot referring to the DNS root domain which is the implied suffix of all valid DNS names) has special effect. It causes all DNS traffic which does not match another configured domain routing entry to be routed to DNS servers specified for this interface. This setting is useful to prefer a certain set of DNS servers if a link on which they are connected is available. This setting is read by systemd-resolved.service(8). "Search domains" correspond to the domain and search entries in resolv.conf(5). Domain name routing has no equivalent in the traditional glibc API, which has no concept of domain name servers limited to a specific link." -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
I can confirm this works for multiple vpn connections and after wakeup from system suspend on Ubuntu 17.04. I encourage you to install the patched .deb or follow the instructions to build it from source and see for yourself. I'm honestly so glad this fixes dns leaks for using openvpn through the network manager gui on Ubuntu that I'm switching my primary machine to 17.04. :) Please let me know if this resolves your problems with DNS leaks using a vpn via the network manager. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
The actual patch is attached above and can be applied to the source code which you can build yourself. But for your convenience, I have attached the .deb file below: ** Attachment added: "patched network manager .deb for easy fix installation on Ubuntu 17.04" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317/+attachment/4889755/+files/network-manager_1.4.4-1ubuntu3_amd64.deb -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
Please note that this patch and fix only works for Ubuntu 17.04 which relies on systemd-resolved as a DNS/DNSSEC stub resolver, as well as an LLMNR resolver. You also need to be using a network-manager plugin like network-manager-openvpn-gnome. Install and configure an openvpn connection after going 'sudo apt-get install network-manager- openvpn-gnome', importing a config file, connecting (if possible), and observing the fact that there are DNS leaks (queries WILL be routed to your ISP) with online tools like those at https://dnsleaktest.com. Otherwise, just know that systemd-resolved naturally leaks DNS queries over all configured domains on all interfaces by design unless a specific system bus call is made. In this case, the SetLinkDomains(in i ifindex, in a(sb) domains) method, if passed the interface index followed by an array containing the "routing-only" domain "~." (see https://manpages.debian.org/testing/systemd/systemd.network.5.en.html) and the boolean true. But enough with the technical details, lets move on to the fix! First, make sure you have all necessary packages to build the network manager, install with: sudo apt update sudo apt-get build-dep network-manager cd ~/Documents mkdir nm && cd nm apt-get source network-manager cd network-manager-1.4.4/ Copy the patch file into the network-manager-1.4.4 directory: cp ~/Downloads/resolved-vpn-dns-leak-fix.patch . Apply the patch with: patch -p1 < resolved-vpn-dns-leak-fix.patch Remove patch from source directory before compilation: rm resolved-vpn-dns-leak-fix.patch Compile and build .deb package for installation (this will take a while): dpkg-buildpackage -us -uc -b The compiled .debs should be in the parent directory you created nm: cd ../ First, stop all network services: sudo service network-manager stop sudo service networking stop Install just the patched network manager (the other .debs are not necessary): sudo dpkg -i network-manager_1.4.4-1ubuntu3_amd64.deb Bring network services back up: sudo service networking start sudo service network-manager start Connect to standard openvpn via network-manager-openvpn GUI (or other plugin) Search the syslog for something like: NetworkManager[876]: [1496716774.9849] systemd-resolved[0x55b0132ec2b0]: Link type is VPN TUN or TAP, fixing DNS leak... and verify that the VPN link (for example tun0) includes the descriptor: DNS Domain: ~. using the command: systemd-resolve --status When compiling network manager, several bogus links are created and will show up when you type 'systemd-resolve --status', don't worry they will disappear once you reboot. Then open your browser, navigate to https://dnsleaktest.com and select Extended test You should only see your VPN provider's DNS servers. For example, with PIA you should see something like: Test complete Query round Progress... Servers found 1 .. 1 2 .. 1 3 .. 1 4 .. 1 5 .. 1 6 .. 1 IP HostnameISP Country 173.239.220.5 ip-5-220-239-173.east.us.northamericancoax.com GoLightSpeed United States Now, to prevent Ubuntu apt from replacing your patched, VPN-DNS-leak- free version of network manager that relies on systemd-resolved, use the command: sudo apt-mark hold network-manager Thats all, you're done. Congrats, no DNS leaks on Ubuntu 17.04! I hope that I was able to make your life easier and more secure using openvpn or other vpn services through the built-in GUI for the Gnome NetworkManager on Ubuntu 17.04 :) (Side note: I am a college student and C/C++ dev who loves Ubuntu <3 Also, this took quite a bit of research on the GLib API, systemd-resolved API, and much much tracing using our good friend 'grep -r' for built in functions and enums of the Gnome network manager itself. No additional compiler warnings are generated, the patch conforms to the C90 standard, and the syntax style used throughout the network manager source code was maintained.) I will attach the small text patch generated using 'diff -u' along with the patched generated .deb file for your convenience. Cheers, and I hope this helps you all! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
** Patch added: "patch for network-manager source" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317/+attachment/4889747/+files/resolved-vpn-dns-leak-fix.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1624317] Re: systemd-resolved breaks VPN with split-horizon DNS
** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Changed in: network-manager (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1624317 Title: systemd-resolved breaks VPN with split-horizon DNS Status in systemd: New Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I use a VPN configured with network-manager-openconnect-gnome in which a split-horizon DNS setup assigns different addresses to some names inside the remote network than the addresses seen for those names from outside the remote network. However, systemd-resolved often decides to ignore the VPN’s DNS servers and use the local network’s DNS servers to resolve names (whether in the remote domain or not), breaking the split-horizon DNS. This related bug, reported by Lennart Poettering himself, was closed with the current Fedora release at the time reaching EOL: https://bugzilla.redhat.com/show_bug.cgi?id=1151544 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1624317/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1636395] Re: dnsmasq not working with OpenVPN
Okay so I have found the issue pertaining to dns resolution on Ubuntu 16.04.2! There is a critical bug in the package dnsmasq-base here: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776 The fix hasn't yet been applied to the current version of dnsmasq-base. This time I have all the dependencies on 1.2.6 at their newest version and installing the patched .deb version provided by Harald Rudell fixes DNS name resolution on wakeup/suspend and with restart of the network manager, all while cooperating with openvpn. I hope this helps anyone on 16.04.2 LTS! wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+attachment/4780245/+files /dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb sudo dpkg -i dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb This appears to have actually worked, and is much better than using dnscrypt-proxy (which I have found to be incredibly slow) or holding back a bunch of packages. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1636395 Title: dnsmasq not working with OpenVPN Status in dnsmasq package in Ubuntu: Confirmed Status in openvpn-systemd-resolved package in Ubuntu: Confirmed Bug description: I'm using OpenVPN configured with Network Manager. My VPN have a DNS server configured by OpenVPN and config pushed by it while connecting. This server is not registered by dnsmasq so domain names are not resolved but pinging by IP address works. When I test name resolving by pointing to DNS server (172.16.1.1) from VPN provider it's works. For example: $ host google.com 172.16.1.1 Using domain server: Name: 172.16.1.1 Address: 172.16.1.1#53 Aliases: google.com has address 172.217.0.174 google.com has IPv6 address 2607:f8b0:400b:807::200e google.com mail is handled by 30 alt2.aspmx.l.google.com. google.com mail is handled by 20 alt1.aspmx.l.google.com. google.com mail is handled by 40 alt3.aspmx.l.google.com. google.com mail is handled by 10 aspmx.l.google.com. google.com mail is handled by 50 alt4.aspmx.l.google.com. But if I test without pointing DNS server is not working: $ host google.com ;; connection timed out; no servers could be reached My /etc/resolv.conf: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 To repair this bug I have to kill dnsmasq and it's automatically reloaded. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1636395/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1681295] [NEW] Problem in network-manager-openvpn, openvpn fails during and after downloads.
Public bug reported: So I've been using OpenVPN through the network-manager-openvpn package integrated into the network manager GUI. I experienced an odd problem where consistently, during or after downloading (in this case, I tested by just downloading the kernel tarball from kernel.org repeatedly, which is around 90MB) Every single time, without fail, the openvpn client would fail and my connection would go dead. To reconnect, I would have to manually restart the network manager. Now, I played around with .conf files and the CLI openvpn client and noticed EXACTLY the same behavior happening. I eventually arrived to the conclusion that the flag or option "auth-nocache" would cause a connection reset after or during downloads and streaming. I then got to reading the openvpn man pages and I stumbled across this message (you can easily find it by going 'man openvpn | grep nocache') about the guaranteed failure of key renegotiation if auth-user-pass and auth-nocache were used together: " Further, using --daemon together with --auth-user-pass (entered on console) and --auth-nocache will fail as soon as key renego‐ tiation (and reauthentication) occurs." When I removed auth-user-pass from my .conf files, the problem went away. Then I wondered. Now what if...network-manager-openvpn was actually passing both flags to openvpn? Then I downloaded the source tarball and found that indeed, this exact thing is happening on a SINGLE line. See line 1380 of network-manager-openvpn-1.1.93/src/nm-openvpn-service.c "add_openvpn_arg (args, "--auth-nocache");" So I decided to comment out that single line. I then rebuilt the packages network-manager-openvpn and network-manager-openvpn using 'dpkg-buildpackage -us -uc -nc', installed them, and tested downloading the source kernel repeatedly to see if the connection would hold. It does! Literally commenting out ONE line fixed weeks worth of extreme annoyance repeatedly reconnecting to my vpn. This issue is rather annoying and needs to be fixed so openvpn doesn't keep cutting out. I've attached a patch for the source. ** Affects: network-manager-openvpn (Ubuntu) Importance: Undecided Status: New ** Tags: network-manager network-manager-openvpn openvpn ** Patch added: "The following patch removes the single offending line which causes this issue." https://bugs.launchpad.net/bugs/1681295/+attachment/4859305/+files/nm-openvpn-service-fix.patch ** Also affects: network-manager-openvpn (Ubuntu) Importance: Undecided Status: New ** No longer affects: network-manager (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1681295 Title: Problem in network-manager-openvpn, openvpn fails during and after downloads. Status in network-manager-openvpn package in Ubuntu: New Bug description: So I've been using OpenVPN through the network-manager-openvpn package integrated into the network manager GUI. I experienced an odd problem where consistently, during or after downloading (in this case, I tested by just downloading the kernel tarball from kernel.org repeatedly, which is around 90MB) Every single time, without fail, the openvpn client would fail and my connection would go dead. To reconnect, I would have to manually restart the network manager. Now, I played around with .conf files and the CLI openvpn client and noticed EXACTLY the same behavior happening. I eventually arrived to the conclusion that the flag or option "auth-nocache" would cause a connection reset after or during downloads and streaming. I then got to reading the openvpn man pages and I stumbled across this message (you can easily find it by going 'man openvpn | grep nocache') about the guaranteed failure of key renegotiation if auth-user-pass and auth-nocache were used together: " Further, using --daemon together with --auth-user-pass (entered on console) and --auth-nocache will fail as soon as key renego‐ tiation (and reauthentication) occurs." When I removed auth-user-pass from my .conf files, the problem went away. Then I wondered. Now what if...network-manager-openvpn was actually passing both flags to openvpn? Then I downloaded the source tarball and found that indeed, this exact thing is happening on a SINGLE line. See line 1380 of network-manager-openvpn-1.1.93/src/nm-openvpn-service.c "add_openvpn_arg (args, "--auth-nocache");" So I decided to comment out that single line. I then rebuilt the packages network-manager-openvpn and network-manager-openvpn using 'dpkg-buildpackage -us -uc -nc', installed them, and tested downloading the source kernel repeatedly to see if the connection would hold. It does! Literally commenting out ONE line fixed weeks worth of extreme annoyance repeatedly reconnecting to my vpn. This issue is rather annoying and needs to be fixed so
[Touch-packages] [Bug 1671606] Re: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1
*** This bug is a duplicate of bug 1639776 *** https://bugs.launchpad.net/bugs/1639776 Okay so I have found the issue pertaining to dns resolution on Ubuntu 16.04.2! There is a critical bug in the package dnsmasq-base here: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776 The fix hasn't yet been applied to the current version of dnsmasq-base. This time I have all the dependencies on 1.2.6 at their newest version and installing the patched .deb version provided by Harald Rudell fixes DNS name resolution on wakeup/suspend and with restart of the network manager, all while cooperating with openvpn. I hope this helps anyone on 16.04.2 LTS! wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1639776/+attachment/4780245/+files/dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb sudo dpkg -i dnsmasq-base_2.76-4ubuntu1FIX1639776ubuntu1_amd64.deb This appears to have actually worked, and is much better than using dnscrypt-proxy (which I have found to be incredibly slow) or holding back a bunch of packages. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1671606 Title: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1 Status in network-manager package in Ubuntu: Confirmed Status in resolvconf package in Ubuntu: Invalid Bug description: I use my company's cisco vpn via network-manager in Ubuntu 16.04.2 LTS. After recent upgrade of network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 DNS resolution of VPN's server hostnames does not work. Roll back to version 1.2.2-0ubuntu0.16.04.4 solves the problem. Steps for reproducing: 1. upgrade network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 2. connect to VPN via network-manager applet 3. nslookop servername.internal --> ** server can't find servername.internal: NXDOMAIN 4. disconnect from VPN via network-manager applet 5. roll back network-manager via command: sudo apt-get install network-manager=1.2.2-0ubuntu0.16.04.4 6. restart network-manager via sudo service network-manager restart 7. connect to VPN via network-manager applet 8. nslookop servername.internal --> the server is resolved correctly ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: network-manager 1.2.6-0ubuntu0.16.04.1 ProcVersionSignature: Ubuntu 4.4.0-66.87-generic 4.4.44 Uname: Linux 4.4.0-66-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 9 19:49:55 2017 InstallationDate: Installed on 2015-10-05 (520 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.6connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671606] Re: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1
Well, scratch that hope and consider me mistaken about Goth Queen's workaround. It appears that manually setting a fixed DNS server DOES allow for successful reconnect when the network manager is restarted (whereas before it wouldn't reconnect period), but just like this bug https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1631241 name resolution (not using the dnscrypt-proxy service, just a fixed DNS address) fails after waking up from suspend for some frustrating, arcane reason. I have downgraded the following packages: (credit to Kostadin Stoilov) sudo apt install network-manager=1.2.2-0ubuntu0.16.04.4 sudo apt install libnm-glib-vpn1=1.2.2-0ubuntu0.16.04.4 sudo apt install libnm-glib4=1.2.2-0ubuntu0.16.04.4 sudo apt install libnm0=1.2.2-0ubuntu0.16.04.4 sudo apt install libnm-util2=1.2.2-0ubuntu0.16.04.4 sudo apt install resolvconf=1.78ubuntu2 and held them in place with 'sudo apt-mark hold' for the time being, as there appears to be a critical flaw in the updated versions of network- manager and possibly resolv-conf and dnsmasq. I suppose we just have to wait until something is fixed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1671606 Title: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1 Status in network-manager package in Ubuntu: Confirmed Status in resolvconf package in Ubuntu: Invalid Bug description: I use my company's cisco vpn via network-manager in Ubuntu 16.04.2 LTS. After recent upgrade of network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 DNS resolution of VPN's server hostnames does not work. Roll back to version 1.2.2-0ubuntu0.16.04.4 solves the problem. Steps for reproducing: 1. upgrade network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 2. connect to VPN via network-manager applet 3. nslookop servername.internal --> ** server can't find servername.internal: NXDOMAIN 4. disconnect from VPN via network-manager applet 5. roll back network-manager via command: sudo apt-get install network-manager=1.2.2-0ubuntu0.16.04.4 6. restart network-manager via sudo service network-manager restart 7. connect to VPN via network-manager applet 8. nslookop servername.internal --> the server is resolved correctly ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: network-manager 1.2.6-0ubuntu0.16.04.1 ProcVersionSignature: Ubuntu 4.4.0-66.87-generic 4.4.44 Uname: Linux 4.4.0-66-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 9 19:49:55 2017 InstallationDate: Installed on 2015-10-05 (520 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.6connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1677175] Re: network-manager 1.2.6 won't connect to vpn and displays false connected message
** No longer affects: linux (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1677175 Title: network-manager 1.2.6 won't connect to vpn and displays false connected message Status in network-manager package in Ubuntu: New Bug description: I have been having a rather serious and incredibly annoying problem on the updated version of network-manager v1.2.6 on Ubuntu 16.04.2 LTS. Trying to manually connect to my VPN provider using openvpn through the network manager fails literally any time except bootup. Every godforsaken time. Waking the computer from suspend results in the network manager 'reconnecting' but no actual internet connection. Restarting the network manager using 'sudo service network-manager restart' sometimes doesn't work at all and I actually have to reboot the computer for it to connect to the internet. Despite the icon showing that I'm connected, in actuality I have no internet connection and cannot load any web pages. The critical thing is that this issue isn't present at all on v1.2.2, which I have downgraded to and used 'apt-mark hold' to keep it in place. I'm disappointed that the newer default version is so unstable. Any insight or confirmation of this issue would be appreciated. --- ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity DistroRelease: Ubuntu 16.04 EcryptfsInUse: Yes InstallationDate: Installed on 2017-03-19 (10 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) Package: network-manager 1.2.2-0ubuntu0.16.04.4 PackageArchitecture: amd64 Tags: xenial Uname: Linux 4.9.16 x86_64 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1677175/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671606] Re: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1
Oops, Goth Queen actually provided a solution earlier, it was just difficult for me to understand at the time. Enter whatever fixed DNS server you want and set 'Automatic (DHCP) addresses only' under IPv4 Settings in network-manager for the default network connection. So just manually entering in your VPN's DNS server (for PIA it's 209.222.18.222) or installing dnscrypt-proxy and choosing 127.0.0.2 as the server both work. This seems an adequate workaround for now. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1671606 Title: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1 Status in network-manager package in Ubuntu: Confirmed Status in resolvconf package in Ubuntu: Invalid Bug description: I use my company's cisco vpn via network-manager in Ubuntu 16.04.2 LTS. After recent upgrade of network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 DNS resolution of VPN's server hostnames does not work. Roll back to version 1.2.2-0ubuntu0.16.04.4 solves the problem. Steps for reproducing: 1. upgrade network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 2. connect to VPN via network-manager applet 3. nslookop servername.internal --> ** server can't find servername.internal: NXDOMAIN 4. disconnect from VPN via network-manager applet 5. roll back network-manager via command: sudo apt-get install network-manager=1.2.2-0ubuntu0.16.04.4 6. restart network-manager via sudo service network-manager restart 7. connect to VPN via network-manager applet 8. nslookop servername.internal --> the server is resolved correctly ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: network-manager 1.2.6-0ubuntu0.16.04.1 ProcVersionSignature: Ubuntu 4.4.0-66.87-generic 4.4.44 Uname: Linux 4.4.0-66-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 9 19:49:55 2017 InstallationDate: Installed on 2015-10-05 (520 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.6connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671606] Re: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1
Okay so since resolvconf and dmasq are not cooperating, I have resorted to using dnscrypt-proxy. Credit to QkiZ, the dnscrypt-proxy service works EVERY TIME and ignores the (completely broken) DNS resolution of dnsmasq and resolvconf. Even with the newest version of network-manager (1.2.6) on 16.04 LTS and all its dependencies: network-manager libnm-glib-vpn1 libnm-glib4 libnm0 libnm-util2 No more DNS resolution issues! To apply this workaround (which actually also offers some security benefits against DNS leakage), use: sudo apt install dnscrypt-proxy In the network manager, select "Edit Connections", select the primary (non-VPN) network you use, click on the "IPv4 Settings" tab, change the "Method" tab to "Automatic (DHCP) addresses only", then add 127.0.0.2 to the "DNS servers:" box. Save your changes, then restart the connection by disabling and enabling networking. Now go to https://www.opendns.com/welcome/ and you should see a nice check mark. Now, your network connection and VPN should work (meaning DNS resolution won't break on you) every single time you wake up from suspend or use sudo service network-manager restart And if for some odd reason it's slow just restart the network manager repeatedly by aliasing that to something like alias nm-restart='sudo service network-manager restart' in your ~/.bash_aliases file. I know, annoying but at least DNS resolution actually works and the computer doesn't have to be literally restarted to connect to the internet. This isn't intended to be a fix, just a possible alternative for those of us who experience total DNS resolution failure using a vpn on Ubuntu. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1671606 Title: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1 Status in network-manager package in Ubuntu: Confirmed Status in resolvconf package in Ubuntu: Invalid Bug description: I use my company's cisco vpn via network-manager in Ubuntu 16.04.2 LTS. After recent upgrade of network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 DNS resolution of VPN's server hostnames does not work. Roll back to version 1.2.2-0ubuntu0.16.04.4 solves the problem. Steps for reproducing: 1. upgrade network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 2. connect to VPN via network-manager applet 3. nslookop servername.internal --> ** server can't find servername.internal: NXDOMAIN 4. disconnect from VPN via network-manager applet 5. roll back network-manager via command: sudo apt-get install network-manager=1.2.2-0ubuntu0.16.04.4 6. restart network-manager via sudo service network-manager restart 7. connect to VPN via network-manager applet 8. nslookop servername.internal --> the server is resolved correctly ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: network-manager 1.2.6-0ubuntu0.16.04.1 ProcVersionSignature: Ubuntu 4.4.0-66.87-generic 4.4.44 Uname: Linux 4.4.0-66-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 9 19:49:55 2017 InstallationDate: Installed on 2015-10-05 (520 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.6connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1636395] Re: dnsmasq not working with OpenVPN
Credit to QkiZ, the dnscrypt-proxy service works EVERY TIME and ignores the (completely broken) DNS resolution of dnsmasq and resolvconf. Even with the newest version of network-manager (1.2.6) on 16.04 LTS and all its dependencies: network-manager libnm-glib-vpn1 libnm-glib4 libnm0 libnm-util2 No more DNS resolution issues! To apply this workaround (which actually also offers some security benefits against DNS leakage), use: sudo apt install dnscrypt-proxy In the network manager, select "Edit Connections", select the primary (non-VPN) network you use, click on the "IPv4 Settings" tab, change the "Method" tab to "Automatic (DHCP) addresses only", then add 127.0.0.2 to the "DNS servers:" box. Save your changes, then restart the connection by disabling and enabling networking. Now go to https://www.opendns.com/welcome/ and you should see a nice check mark. Now, your network connection and VPN should work (meaning DNS resolution won't break on you) every single time you wake up from suspend or use sudo service network-manager restart Good stuff! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1636395 Title: dnsmasq not working with OpenVPN Status in dnsmasq package in Ubuntu: Confirmed Status in openvpn-systemd-resolved package in Ubuntu: Confirmed Bug description: I'm using OpenVPN configured with Network Manager. My VPN have a DNS server configured by OpenVPN and config pushed by it while connecting. This server is not registered by dnsmasq so domain names are not resolved but pinging by IP address works. When I test name resolving by pointing to DNS server (172.16.1.1) from VPN provider it's works. For example: $ host google.com 172.16.1.1 Using domain server: Name: 172.16.1.1 Address: 172.16.1.1#53 Aliases: google.com has address 172.217.0.174 google.com has IPv6 address 2607:f8b0:400b:807::200e google.com mail is handled by 30 alt2.aspmx.l.google.com. google.com mail is handled by 20 alt1.aspmx.l.google.com. google.com mail is handled by 40 alt3.aspmx.l.google.com. google.com mail is handled by 10 aspmx.l.google.com. google.com mail is handled by 50 alt4.aspmx.l.google.com. But if I test without pointing DNS server is not working: $ host google.com ;; connection timed out; no servers could be reached My /etc/resolv.conf: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 To repair this bug I have to kill dnsmasq and it's automatically reloaded. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1636395/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1671606] Re: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1
I have downgraded both the network-manager and resolvconf package but I still experience complete DNS resolution failure randomly, where restarting the network manager has no effect and I cannot connect to the internet. The only way to get DNS working again is to completely reboot the computer, which is a massive pain and shouldn't happen. I need openvpn to connect to my university's ssh server at home. LTS was working totally fine for me for months but now I have run into this massively annoying issue. Killing the dnsmasq process has no effect for me. Downgrading the two packages makes it so that my vpn connection *sometimes* works but without fail, I eventually have to force restart my computer to connect to the internet at all. This is intolerable. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to resolvconf in Ubuntu. https://bugs.launchpad.net/bugs/1671606 Title: DNS server from vpn connection is not being used after network-manager upgrade to 1.2.6-0ubuntu0.16.04.1 Status in network-manager package in Ubuntu: Confirmed Status in resolvconf package in Ubuntu: Confirmed Bug description: I use my company's cisco vpn via network-manager in Ubuntu 16.04.2 LTS. After recent upgrade of network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 DNS resolution of VPN's server hostnames does not work. Roll back to version 1.2.2-0ubuntu0.16.04.4 solves the problem. Steps for reproducing: 1. upgrade network-manager:amd64 from version 1.2.2-0ubuntu0.16.04.4 to version 1.2.6-0ubuntu0.16.04.1 2. connect to VPN via network-manager applet 3. nslookop servername.internal --> ** server can't find servername.internal: NXDOMAIN 4. disconnect from VPN via network-manager applet 5. roll back network-manager via command: sudo apt-get install network-manager=1.2.2-0ubuntu0.16.04.4 6. restart network-manager via sudo service network-manager restart 7. connect to VPN via network-manager applet 8. nslookop servername.internal --> the server is resolved correctly ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: network-manager 1.2.6-0ubuntu0.16.04.1 ProcVersionSignature: Ubuntu 4.4.0-66.87-generic 4.4.44 Uname: Linux 4.4.0-66-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity Date: Thu Mar 9 19:49:55 2017 InstallationDate: Installed on 2015-10-05 (520 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-nm: RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW WIFI WWAN-HW WWAN running 1.2.6connected started full enabled enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1671606/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1677175] ProcEnviron.txt
apport information ** Attachment added: "ProcEnviron.txt" https://bugs.launchpad.net/bugs/1677175/+attachment/4850129/+files/ProcEnviron.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1677175 Title: network-manager 1.2.6 won't connect to vpn and displays false connected message Status in linux package in Ubuntu: Incomplete Status in network-manager package in Ubuntu: New Bug description: I have been having a rather serious and incredibly annoying problem on the updated version of network-manager v1.2.6 on Ubuntu 16.04.2 LTS. Trying to manually connect to my VPN provider using openvpn through the network manager fails literally any time except bootup. Every godforsaken time. Waking the computer from suspend results in the network manager 'reconnecting' but no actual internet connection. Restarting the network manager using 'sudo service network-manager restart' sometimes doesn't work at all and I actually have to reboot the computer for it to connect to the internet. Despite the icon showing that I'm connected, in actuality I have no internet connection and cannot load any web pages. The critical thing is that this issue isn't present at all on v1.2.2, which I have downgraded to and used 'apt-mark hold' to keep it in place. I'm disappointed that the newer default version is so unstable. Any insight or confirmation of this issue would be appreciated. --- ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity DistroRelease: Ubuntu 16.04 EcryptfsInUse: Yes InstallationDate: Installed on 2017-03-19 (10 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) Package: network-manager 1.2.2-0ubuntu0.16.04.4 PackageArchitecture: amd64 Tags: xenial Uname: Linux 4.9.16 x86_64 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677175/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1677175] JournalErrors.txt
apport information ** Attachment added: "JournalErrors.txt" https://bugs.launchpad.net/bugs/1677175/+attachment/4850128/+files/JournalErrors.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1677175 Title: network-manager 1.2.6 won't connect to vpn and displays false connected message Status in linux package in Ubuntu: Incomplete Status in network-manager package in Ubuntu: New Bug description: I have been having a rather serious and incredibly annoying problem on the updated version of network-manager v1.2.6 on Ubuntu 16.04.2 LTS. Trying to manually connect to my VPN provider using openvpn through the network manager fails literally any time except bootup. Every godforsaken time. Waking the computer from suspend results in the network manager 'reconnecting' but no actual internet connection. Restarting the network manager using 'sudo service network-manager restart' sometimes doesn't work at all and I actually have to reboot the computer for it to connect to the internet. Despite the icon showing that I'm connected, in actuality I have no internet connection and cannot load any web pages. The critical thing is that this issue isn't present at all on v1.2.2, which I have downgraded to and used 'apt-mark hold' to keep it in place. I'm disappointed that the newer default version is so unstable. Any insight or confirmation of this issue would be appreciated. --- ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity DistroRelease: Ubuntu 16.04 EcryptfsInUse: Yes InstallationDate: Installed on 2017-03-19 (10 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) Package: network-manager 1.2.2-0ubuntu0.16.04.4 PackageArchitecture: amd64 Tags: xenial Uname: Linux 4.9.16 x86_64 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677175/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1677175] Re: network-manager 1.2.6 won't connect to vpn and displays false connected message
apport information ** Tags added: apport-collected xenial ** Description changed: I have been having a rather serious and incredibly annoying problem on the updated version of network-manager v1.2.6 on Ubuntu 16.04.2 LTS. Trying to manually connect to my VPN provider using openvpn through the network manager fails literally any time except bootup. Every godforsaken time. Waking the computer from suspend results in the network manager 'reconnecting' but no actual internet connection. Restarting the network manager using 'sudo service network-manager restart' sometimes doesn't work at all and I actually have to reboot the computer for it to connect to the internet. Despite the icon showing that I'm connected, in actuality I have no internet connection and cannot load any web pages. The critical thing is that this issue isn't present at all on v1.2.2, which I have downgraded to and used 'apt-mark hold' to keep it in place. I'm disappointed that the newer default version is so unstable. Any insight or confirmation of this issue would be appreciated. + --- + ApportVersion: 2.20.1-0ubuntu2.5 + Architecture: amd64 + CurrentDesktop: Unity + DistroRelease: Ubuntu 16.04 + EcryptfsInUse: Yes + InstallationDate: Installed on 2017-03-19 (10 days ago) + InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) + Package: network-manager 1.2.2-0ubuntu0.16.04.4 + PackageArchitecture: amd64 + Tags: xenial + Uname: Linux 4.9.16 x86_64 + UnreportableReason: The running kernel is not an Ubuntu kernel + UpgradeStatus: No upgrade log present (probably fresh install) + UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo + _MarkForUpload: True ** Attachment added: "Dependencies.txt" https://bugs.launchpad.net/bugs/1677175/+attachment/4850127/+files/Dependencies.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1677175 Title: network-manager 1.2.6 won't connect to vpn and displays false connected message Status in linux package in Ubuntu: Incomplete Status in network-manager package in Ubuntu: New Bug description: I have been having a rather serious and incredibly annoying problem on the updated version of network-manager v1.2.6 on Ubuntu 16.04.2 LTS. Trying to manually connect to my VPN provider using openvpn through the network manager fails literally any time except bootup. Every godforsaken time. Waking the computer from suspend results in the network manager 'reconnecting' but no actual internet connection. Restarting the network manager using 'sudo service network-manager restart' sometimes doesn't work at all and I actually have to reboot the computer for it to connect to the internet. Despite the icon showing that I'm connected, in actuality I have no internet connection and cannot load any web pages. The critical thing is that this issue isn't present at all on v1.2.2, which I have downgraded to and used 'apt-mark hold' to keep it in place. I'm disappointed that the newer default version is so unstable. Any insight or confirmation of this issue would be appreciated. --- ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: Unity DistroRelease: Ubuntu 16.04 EcryptfsInUse: Yes InstallationDate: Installed on 2017-03-19 (10 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) Package: network-manager 1.2.2-0ubuntu0.16.04.4 PackageArchitecture: amd64 Tags: xenial Uname: Linux 4.9.16 x86_64 UnreportableReason: The running kernel is not an Ubuntu kernel UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677175/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1677175] [NEW] network-manager 1.2.6 won't connect to vpn and displays false connected message
Public bug reported: I have been having a rather serious and incredibly annoying problem on the updated version of network-manager v1.2.6 on Ubuntu 16.04.2 LTS. Trying to manually connect to my VPN provider using openvpn through the network manager fails literally any time except bootup. Every godforsaken time. Waking the computer from suspend results in the network manager 'reconnecting' but no actual internet connection. Restarting the network manager using 'sudo service network-manager restart' sometimes doesn't work at all and I actually have to reboot the computer for it to connect to the internet. Despite the icon showing that I'm connected, in actuality I have no internet connection and cannot load any web pages. The critical thing is that this issue isn't present at all on v1.2.2, which I have downgraded to and used 'apt-mark hold' to keep it in place. I'm disappointed that the newer default version is so unstable. Any insight or confirmation of this issue would be appreciated. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: network-manager openvpn vpn ** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1677175 Title: network-manager 1.2.6 won't connect to vpn and displays false connected message Status in linux package in Ubuntu: New Status in network-manager package in Ubuntu: New Bug description: I have been having a rather serious and incredibly annoying problem on the updated version of network-manager v1.2.6 on Ubuntu 16.04.2 LTS. Trying to manually connect to my VPN provider using openvpn through the network manager fails literally any time except bootup. Every godforsaken time. Waking the computer from suspend results in the network manager 'reconnecting' but no actual internet connection. Restarting the network manager using 'sudo service network-manager restart' sometimes doesn't work at all and I actually have to reboot the computer for it to connect to the internet. Despite the icon showing that I'm connected, in actuality I have no internet connection and cannot load any web pages. The critical thing is that this issue isn't present at all on v1.2.2, which I have downgraded to and used 'apt-mark hold' to keep it in place. I'm disappointed that the newer default version is so unstable. Any insight or confirmation of this issue would be appreciated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677175/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
