[Desktop-packages] [Bug 1390623] Re: VPN with IPv6 connectivity but no IPv6 DNS server results in broken DNS config
Affects 15.04 as well. before VPN: Aug 25 21:20:14 challenger dnsmasq[2049]: setting upstream servers from DBus Aug 25 21:20:14 challenger dnsmasq[2049]: using nameserver 2001:db8:b0e2::51#53 Aug 25 21:20:14 challenger dnsmasq[2049]: using nameserver 2001:db8:b0e2::52#53 Aug 25 21:20:14 challenger dnsmasq[2049]: using nameserver 192.168.1.51#53 Aug 25 21:20:14 challenger dnsmasq[2049]: using nameserver 192.168.1.52#53 after VPN: Aug 25 21:20:20 challenger dnsmasq[2049]: using nameserver 192.168.0.6#53 for domain netdirect.ca Aug 25 21:20:20 challenger dnsmasq[2049]: using nameserver 192.168.0.6#53 for domain 31.172.in-addr.arpa Aug 25 21:20:20 challenger dnsmasq[2049]: using nameserver 192.168.0.6#53 for domain 10.in-addr.arpa Aug 25 21:20:20 challenger dnsmasq[2049]: using nameserver 192.168.0.6#53 for domain 0.168.192.in-addr.arpa Aug 25 21:20:20 challenger dnsmasq[2049]: using nameserver 192.168.0.6#53 for domain 235.16.216.in-addr.arpa -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1390623 Title: VPN with IPv6 connectivity but no IPv6 DNS server results in broken DNS config Status in network-manager package in Ubuntu: Confirmed Bug description: When connecting to a VPN that provides both a default route over IPv4 and IPv6, but only DNS servers over IPv4, you can end up with the IPv4 DNS servers set up as "split DNS". When that happens, the user is left without a working DNS configuration. See the attached log file for an example. I think the cause is that the patch for avoiding split DNS on VPNs with default routes[1] stops looking when it finds the first VPN configuration with a default route. If that configuration happens to be the IPv6-side of the VPN connection, then it will still add the IPv4 configuration with split DNS. A workaround is to simply add a IPv6 DNS server to the configuration in addition to the IPv4 DNS servers. In that case, the IPv6 DNS server is added without split DNS. This has been tested with both Ubuntu 14.04 LTS and Xubuntu 14.04. Package versions (on Xubuntu 14.04): network-manager 0.9.8.8-0ubuntu7 network-manager-openvpn 0.9.8.2-1ubuntu4 openvpn 2.3.2-7ubuntu3 [1] http://bazaar.launchpad.net/~network-manager/network- manager/ubuntu/view/head:/debian/patches/dnsmasq-vpn-dns- filtering.patch To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1390623/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1273201] Re: bridge_ignore_without_connections.patch breaks NM created bridge at boot
Is there any way to mark this as affecting the 14.04 LTS? It's status fix-released, but the fix has *not* actually been released. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1273201 Title: bridge_ignore_without_connections.patch breaks NM created bridge at boot Status in “network-manager” package in Ubuntu: Fix Released Bug description: I've created a bridge with network-manager-gnome, the bridge slave physical device is eth0. After a reboot the bridge is brought up, but eth0 isn't attached. First test-case: Created a bridge with network-manager-gnome with the bridge slave physical device is eth0 and remove all other connections. After a reboot the bridge is brought up, but eth0 isn't attached. When I open /etc/NetworkManager/NetworkManager.conf and save it without any modification, eth0 is instantly added to my bridge. Strange! Second test-case: Created a bridge with network-manager-gnome with the bridge slave physical device is eth0. Disable the "autoconnect" of the default wired network. After a reboot the bridge is brought up, but eth0 isn't attached. Instead eth0 is brought up and full configured. After compiling and testing different upstream versions, i could track the problem down to bridge_ignore_without_connections.patch. A network-manager package without this specific patch, brings my bridge up at boot and adds eth0 to the bridge in both test-cases. I've checked the behaviour on my ubuntu 13.10 box with network-manager (0.9.8.0-0ubuntu22) and the trusty version network-manager (0.9.8.8-0ubuntu1) . Till now i couldn't encounter any sideeffects of removing this patch with the bridge created by libvirt. Regards Mathias Kresin To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1273201/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1273201] Re: bridge_ignore_without_connections.patch breaks NM created bridge at boot
I see the fix released for 14.10, ETA for this to be backported to trusty? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1273201 Title: bridge_ignore_without_connections.patch breaks NM created bridge at boot Status in “network-manager” package in Ubuntu: Fix Released Bug description: I've created a bridge with network-manager-gnome, the bridge slave physical device is eth0. After a reboot the bridge is brought up, but eth0 isn't attached. First test-case: Created a bridge with network-manager-gnome with the bridge slave physical device is eth0 and remove all other connections. After a reboot the bridge is brought up, but eth0 isn't attached. When I open /etc/NetworkManager/NetworkManager.conf and save it without any modification, eth0 is instantly added to my bridge. Strange! Second test-case: Created a bridge with network-manager-gnome with the bridge slave physical device is eth0. Disable the "autoconnect" of the default wired network. After a reboot the bridge is brought up, but eth0 isn't attached. Instead eth0 is brought up and full configured. After compiling and testing different upstream versions, i could track the problem down to bridge_ignore_without_connections.patch. A network-manager package without this specific patch, brings my bridge up at boot and adds eth0 to the bridge in both test-cases. I've checked the behaviour on my ubuntu 13.10 box with network-manager (0.9.8.0-0ubuntu22) and the trusty version network-manager (0.9.8.8-0ubuntu1) . Till now i couldn't encounter any sideeffects of removing this patch with the bridge created by libvirt. Regards Mathias Kresin To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1273201/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1273201] Re: bridge_ignore_without_connections.patch breaks NM created bridge at boot
Looks like this also affects my configuration: http://askubuntu.com/q/520051/9083 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1273201 Title: bridge_ignore_without_connections.patch breaks NM created bridge at boot Status in “network-manager” package in Ubuntu: Confirmed Bug description: I've created a bridge with network-manager-gnome, the bridge slave physical device is eth0. After a reboot the bridge is brought up, but eth0 isn't attached. First test-case: Created a bridge with network-manager-gnome with the bridge slave physical device is eth0 and remove all other connections. After a reboot the bridge is brought up, but eth0 isn't attached. When I open /etc/NetworkManager/NetworkManager.conf and save it without any modification, eth0 is instantly added to my bridge. Strange! Second test-case: Created a bridge with network-manager-gnome with the bridge slave physical device is eth0. Disable the "autoconnect" of the default wired network. After a reboot the bridge is brought up, but eth0 isn't attached. Instead eth0 is brought up and full configured. After compiling and testing different upstream versions, i could track the problem down to bridge_ignore_without_connections.patch. A network-manager package without this specific patch, brings my bridge up at boot and adds eth0 to the bridge in both test-cases. I've checked the behaviour on my ubuntu 13.10 box with network-manager (0.9.8.0-0ubuntu22) and the trusty version network-manager (0.9.8.8-0ubuntu1) . Till now i couldn't encounter any sideeffects of removing this patch with the bridge created by libvirt. Regards Mathias Kresin To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1273201/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1326810] [NEW] ping forgets to whom it's talking
Public bug reported: Distro: ubuntu 14.04 x64 Package: iputils-ping 3:20121221-4ubuntu1.1 The ping command accidentally uses the information for the last ICMP UNREACHABLE response instead of the host from which the *actual* response came. See the output below: michael@challenger:~ ○ → ping 10gb-sw1 PING 10gb-sw1.office.netdirect.ca (192.168.0.33) 56(84) bytes of data. >From challenger.netdirect.ca (192.168.0.135) icmp_seq=1 Destination Host >Unreachable >From challenger.netdirect.ca (192.168.0.135) icmp_seq=2 Destination Host >Unreachable … >From challenger.netdirect.ca (192.168.0.135) icmp_seq=82 Destination Host >Unreachable >From challenger.netdirect.ca (192.168.0.135) icmp_seq=86 Destination Host >Unreachable 64 bytes from challenger.netdirect.ca (192.168.0.135): icmp_seq=88 ttl=255 time=3.25 ms 64 bytes from challenger.netdirect.ca (192.168.0.135): icmp_seq=89 ttl=255 time=0.737 ms 64 bytes from challenger.netdirect.ca (192.168.0.135): icmp_seq=90 ttl=255 time=1.68 ms … 64 bytes from challenger.netdirect.ca (192.168.0.135): icmp_seq=96 ttl=255 time=2.83 ms ^C --- 10gb-sw1.office.netdirect.ca ping statistics --- 96 packets transmitted, 9 received, +56 errors, 90% packet loss, time 95015ms rtt min/avg/max/mdev = 0.737/2.427/3.966/1.156 ms, pipe 4 michael@challenger:~ ○ → ping 10gb-sw1 PING 10gb-sw1.office.netdirect.ca (192.168.0.33) 56(84) bytes of data. 64 bytes from 10gb-sw1.netdirect.ca (192.168.0.33): icmp_seq=1 ttl=255 time=4.34 ms 64 bytes from 10gb-sw1.netdirect.ca (192.168.0.33): icmp_seq=2 ttl=255 time=2.97 ms 64 bytes from 10gb-sw1.netdirect.ca (192.168.0.33): icmp_seq=3 ttl=255 time=2.14 ms ^C --- 10gb-sw1.office.netdirect.ca ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 2.146/3.156/4.344/0.907 ms ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: iputils-ping 3:20121221-4ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-27.50-generic 3.13.11 Uname: Linux 3.13.0-27-generic x86_64 NonfreeKernelModules: nvidia zfs zunicode zavl zcommon znvpair ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 CurrentDesktop: XFCE Date: Thu Jun 5 09:50:13 2014 InstallationDate: Installed on 2013-09-09 (268 days ago) InstallationMedia: Ubuntu-Server 13.04 "Raring Ringtail" - Release amd64 (20130423.1) SourcePackage: iputils UpgradeStatus: Upgraded to trusty on 2014-04-18 (48 days ago) ** Affects: iputils (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug trusty -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to iputils in Ubuntu. https://bugs.launchpad.net/bugs/1326810 Title: ping forgets to whom it's talking Status in “iputils” package in Ubuntu: New Bug description: Distro: ubuntu 14.04 x64 Package: iputils-ping 3:20121221-4ubuntu1.1 The ping command accidentally uses the information for the last ICMP UNREACHABLE response instead of the host from which the *actual* response came. See the output below: michael@challenger:~ ○ → ping 10gb-sw1 PING 10gb-sw1.office.netdirect.ca (192.168.0.33) 56(84) bytes of data. From challenger.netdirect.ca (192.168.0.135) icmp_seq=1 Destination Host Unreachable From challenger.netdirect.ca (192.168.0.135) icmp_seq=2 Destination Host Unreachable … From challenger.netdirect.ca (192.168.0.135) icmp_seq=82 Destination Host Unreachable From challenger.netdirect.ca (192.168.0.135) icmp_seq=86 Destination Host Unreachable 64 bytes from challenger.netdirect.ca (192.168.0.135): icmp_seq=88 ttl=255 time=3.25 ms 64 bytes from challenger.netdirect.ca (192.168.0.135): icmp_seq=89 ttl=255 time=0.737 ms 64 bytes from challenger.netdirect.ca (192.168.0.135): icmp_seq=90 ttl=255 time=1.68 ms … 64 bytes from challenger.netdirect.ca (192.168.0.135): icmp_seq=96 ttl=255 time=2.83 ms ^C --- 10gb-sw1.office.netdirect.ca ping statistics --- 96 packets transmitted, 9 received, +56 errors, 90% packet loss, time 95015ms rtt min/avg/max/mdev = 0.737/2.427/3.966/1.156 ms, pipe 4 michael@challenger:~ ○ → ping 10gb-sw1 PING 10gb-sw1.office.netdirect.ca (192.168.0.33) 56(84) bytes of data. 64 bytes from 10gb-sw1.netdirect.ca (192.168.0.33): icmp_seq=1 ttl=255 time=4.34 ms 64 bytes from 10gb-sw1.netdirect.ca (192.168.0.33): icmp_seq=2 ttl=255 time=2.97 ms 64 bytes from 10gb-sw1.netdirect.ca (192.168.0.33): icmp_seq=3 ttl=255 time=2.14 ms ^C --- 10gb-sw1.office.netdirect.ca ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 2.146/3.156/4.344/0.907 ms ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: iputils-ping 3:20121221-4ubuntu1.1 ProcVersionSignature: Ubuntu 3.13.0-27.50-generic 3.13.11 Uname: Linux 3.13.0-27-generic x86_64 NonfreeKernelModules: nvidia zfs zunicode zavl zcommon znvpair ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 CurrentDesktop: XFCE Date: Thu Jun 5 0
