Comment 57 for bug 1752411
Revision history for this message
| Laban Sköllermark (laban-skoller) wrote Re: [Bug 1752411] Re: bind9-host, avahi-daemon-check-dns.sh hang forever causes network connections to get stuck | #57 |
Hi Liam!
I also uninstalled avahi-daemon some months ago but I verified that the
problem came back when I installed it again, so I think you should still be
able to verify the fix if you want to.
Best regards
Laban
On Fri, Aug 31, 2018, 11:21 Liam <email address hidden> wrote:
> I tried the numerous suggested fixes and the all worked for me including
> uninstalling "avahi-daemon". That last one resolved my problem so I
> can't test the latest fix.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> bind9-host, avahi-daemon-
> connections to get stuck
>
> Status in avahi package in Ubuntu:
> Fix Released
> Status in bind9 package in Ubuntu:
> Confirmed
> Status in openconnect package in Ubuntu:
> Invalid
> Status in strongswan package in Ubuntu:
> Invalid
> Status in avahi source package in Bionic:
> Fix Committed
> Status in bind9 source package in Bionic:
> Confirmed
> Status in avahi source package in Cosmic:
> Fix Released
> Status in bind9 source package in Cosmic:
> Confirmed
> Status in avahi package in Debian:
> New
>
> Bug description:
> [Impact]
>
> * Network connections for some users fail (in some cases a direct
> interface, in others when connecting a VPN) because the 'host' command
> to check for .local in DNS called by /usr/lib/
> check-dns.sh never times out like it should - leaving the script
> hanging indefinitely blocking interface up and start-up. This appears
> to be a bug in host caused in some circumstances however we implement
> a workaround to call it under 'timeout' as the issue with 'host' has
> not easily been identified, and in any case acts as a fall-back.
>
> [Test Case]
>
> * Multiple people have been unable to create a reproducer on a
> generic machine (e.g. it does not occur in a VM), I have a specific
> machine I can reproduce it on (a Skull Canyon NUC with Intel I219-LM)
> by simply "ifdown br0; ifup br0" and there are clearly 10s of other
> users affected in varying circumstances that all involve the same
> symptoms but no clear test case exists. Best I can suggest is that I
> test the patch on my system to ensure it works as expected, and the
> change is only 1 line which is fairly easily auditible and
> understandable.
>
> [Regression Potential]
>
> * The change is a single line change to the shell script to call host
> with "timeout". When tested on working and non-working system this appears
> to function as expected. I believe the regression potential for this is
> subsequently low.
> * In attempt to anticipate possible issues, I checked that the timeout
> command is in the same path (/usr/bin) as the host command that is already
> called without a path, and the coreutils package (which contains timeout)
> is an Essential package. I also checked that timeout is not a built-in in
> bash, for those that have changed /bin/sh to bash (just in case).
>
> [Other Info]
>
> * N/A
>
> [Original Bug Description]
>
> On 18.04 Openconnect connects successfully to any of multiple VPN
> concentrators but network traffic does not flow across the VPN tunnel
> connection. When testing on 16.04 this works flawlessly. This also
> worked on this system when it was on 17.10.
>
> I have tried reducing the mtu of the tun0 network device but this has
> not resulted in me being able to successfully ping the IP address.
>
> Example showing ping attempt to the IP of DNS server:
>
> ~$ cat /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
> # 127.0.0.53 is the systemd-resolved stub resolver.
> # run "systemd-resolve --status" to see details about the actual
> nameservers.
>
> nameserver 172.29.88.11
> nameserver 127.0.0.53
>
> liam@liam-lat:~$ netstat -nr
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt
> Iface
> 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0
> wlp2s0
> 105.27.198.106 192.168.1.1 255.255.255.255 UGH 0 0 0
> wlp2s0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0
> docker0
> 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0
> docker0
> 172.29.0.0 0.0.0.0 255.255.0.0 U 0 0 0
> tun0
> 172.29.88.11 0.0.0.0 255.255.255.255 UH 0 0 0
> tun0
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
> wlp2s0
> liam@liam-lat:~$ ping 172.29.88.11
> PING 172.29.88.11 (172.29.88.11) 56(84) bytes of data.
> ^C
> --- 172.29.88.11 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 3054ms
>
> ProblemType: Bug
> DistroRelease: Ubuntu 18.04
> Package: openconnect 7.08-3
> ProcVersionSign
> Uname: Linux 4.15.0-10-generic x86_64
> ApportVersion: 2.20.8-0ubuntu10
> Architecture: amd64
> CurrentDesktop: ubuntu:GNOME
> Date: Wed Feb 28 22:11:33 2018
> InstallationDate: Installed on 2017-06-15 (258 days ago)
> InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64
> (20160719)
> SourcePackage: openconnect
> UpgradeStatus: Upgraded to bionic on 2018-02-22 (6 days ago)
>
> To manage notifications about this bug go to:
> https:/
>