[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
Frédéric, Thank you. This is clear to me now. As it's a driver issue, I'm reassigning to the kernel package. The kernel team will probably need more information about your (virtual) hardware and will want you to test the latest upstream kernel version or similar. ** Summary changed: - IPV6 resolving fails via udp (not tcp) from other server + Hyper-V NIC cannot pass IPv6 UDP packets by default until protocol offload is disabled ** Package changed: bind9 (Ubuntu) => linux (Ubuntu) ** Changed in: linux (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: Hyper-V NIC cannot pass IPv6 UDP packets by default until protocol offload is disabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
Hi Robie, Thanks for your reply. I'll do my best to be as clear as possible First, I must say that I found how to resolve the problem in this thread: http://ubuntuforums.org/showthread.php?t=1940190 That way, you'll have a better on where to search. Before answering your request, remember that I also have 2 windows 2012R2 servers on the same environment (HyperV, ipv4/v6 subnet, vlan) and they do not need to have rx/tx checksum disabled to query/answer each other or Ubuntu servers. SO problems appear to be un ubuntu network drivers. So, your request: Setup: I have an HyperV failover cluster made of 5 2012R2 servers. On each server (Dell with Broadcom cards), 2 network cards are teamed using 2012-R2 functionality for LAN access. Virtual machines: 5 Ubuntu 16.06 servers. Some upgraded from 13.X setup, some completely new. Each has dual stack ipv4/v6. Among them, 3 are nameservers running latest bin. From previous reply, I added 2 new machines from scratch: Ubuntu 15.10 and 16.04. I also have 3 virtual windows servers 2012R2 on this subnet (2 are domain controllers so also name servers). All Ubuntu are at the latest version, no more updates proposed/ Here is lshw setup for network *-network description: Ethernet interface physical id: 1 logical name: eth0 serial: 00:15:fd:fd:fd:10 capabilities: ethernet physical configuration: broadcast=yes driver=hv_netvsc firmware=N/A ip=xxx.xx.128.235 link=yes multicast=yes state (intend: with rx/tx enabled on ubuntu machines): - Any server can dig with any bind server on ipv4 udp - Any server can dig with any bind server on ipv4 tcp - NO server can dig with any bind server on ipv6 udp (No server: understand bind or not bind ones) - Any server can dig with any bind server on ipv6 tcp - each bind server can query himself on ipv6 udp using ::1 or its real ipv6 address Tests : - changing any HyperV network card setup does change nothing (there are network protection, router or DHCP protection). I revert to basic setup - live migrating the VMs I'm using to a single HyperV server to get rid of any network use was useless - Disabling rt/tx on HyperV Teamed NIC driver was useless - Disabling rt/tx on HyperV real network card broadcom driver was useless - Disabling rt/tx on my virtual Windows servers was useless : they can query/get queried without problem with leads me to think it's really an Ubuntu problem with hv_netvsc driver. - Disabling "light network protection" in HyperV on the virtual switch is useless) - No physical machine was on this network Resolution: - install ethtool (one machine needed it) - run :$ ethtool --offload eth0 rx off tx off Now, I'll do what you ask: - create 2 VMs (Generation 1) with basically default options. On the same HV server. I didn't add the VM to the failover cluster to prevent migration. One named UbuntuServer, the other Ubuntu Client - install ubuntu 16.04 server (I default to english/unitedstates (i'm french on others)). No DHCP, network manually configured in IPV6 directly. Server ends with ::2000, client ends with ::1000. On the nameserver question, I've added the server ::2000 ipv6 on both. Of course, no updates. Simply selected "Standard system utilities" and "OpenSSH Server" in the list on software and of course "DNS server" on the server ::2000 - listen some good music - Damn... mount the cdrom and install the missing - connect your workstation to this network (I did on my mac). Check ping and ssh on the machines. ==> all OK - Start listening with tcpdump and already notice some 'bad udp cksum' On the server : root@Server:/# tcpdump host 2001:660:660c:120::1000 -v tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 03:27:36.808391 IP6 (flowlabel 0x3c343, hlim 64, next-header UDP (17) payload length: 40) 2001:660:660c:120::1000.50596 > Server.TestUbuntu.domain: [bad udp cksum 0x3809 -> 0x541a!] 1217+ ? ntp.ubuntu.com. (32) 03:27:41.812431 IP6 (flowlabel 0x3c343, hlim 64, next-header UDP (17) payload length: 40) 2001:660:660c:120::1000.50596 > Server.TestUbuntu.domain: [bad udp cksum 0x3809 -> 0x541a!] 1217+ ? ntp.ubuntu.com. (32) On the client: root@Client:/# tcpdump -v host 2001:660:660c:120::2000 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 03:27:36.789368 IP6 (flowlabel 0x3c343, hlim 64, next-header UDP (17) payload length: 40) Client.TestUbuntu.50596 > 2001:660:660c:120::2000.domain: [bad udp cksum 0x4b54 -> 0x541a!] 1217+ ? ntp.ubuntu.com. (32) 03:27:41.793449 IP6 (flowlabel 0x3c343, hlim 64, next-header UDP (17) payload length: 40) Client.TestUbuntu.50596 > 2001:660:660c:120::2000.domain: [bad udp cksum 0x4b54 -> 0x541a!] 1217+ ? ntp.ubuntu.com. (32) On each machine , edit /etc/systemd/timesyncd.conf to avoid ntp resolution noise [Time] NTP=2001:660:660c:120::4000
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
My previous message without trace wrapping ** Attachment added: "Previous message without trace wrap.txt" https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+attachment/4671163/+files/Previous%20message%20without%20trace%20wrap.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: IPV6 resolving fails via udp (not tcp) from other server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
Please provide a single minimal set of steps to reproduce. Requiring two 16.04 VMs connected to each other would be ideal, with one server running bind and one server running dig that queries the server running bind over IPv6. Assuming that the two machines can communicate with each other over IPv6, tell me exactly what commands to type on each machine to install and set up bind and query using dig. Before you post the instructions, please check that they reproduce the problem in your environment and confirm that you did this in your comment. Also, it might be worth trying to reproduce without Hyper-V? Bad UDP checksums may be normal (it's a common optimisation) but may also be the problem. If it does affect Hyper-V only it still may be a bug in Ubuntu (for example in the kernel that handles the Hyper-V virtual NICs) but it would be useful to know, because I don't have Hyper-V here so will not be able to reproduce a Hyper-V-specific problem. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: IPV6 resolving fails via udp (not tcp) from other server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
== TcpDump = from the client root@14Ext-NS:~# tcpdump host 14Ext-Code.dr14.cnrs.fr -v tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 18:27:46.837544 IP6 (flowlabel 0x9a4b5, hlim 64, next-header UDP (17) payload length: 50) 14Ext-Code.dr14.cnrs.fr.46138 > 14Ext-NS.dr14.cnrs.fr.domain: [bad udp cksum 0xe623 -> 0x2df7!] 50905+ [1au] A? www.google.fr. (42) 18:27:49.195988 IP6 (flowlabel 0x4b7e2, hlim 64, next-header UDP (17) payload length: 212) 14Ext-NS.dr14.cnrs.fr.domain > 14Ext-Code.dr14.cnrs.fr.46138: [bad udp cksum 0x203e -> 0xa01b!] 50905 1/4/5 www.google.fr. A 216.58.210.227 (204) 18:27:49.196277 IP6 (flowlabel 0x4b7e2, hlim 64, next-header UDP (17) payload length: 212) 14Ext-NS.dr14.cnrs.fr.domain > 14Ext-Code.dr14.cnrs.fr.46138: [bad udp cksum 0x203e -> 0x301c!] 50905 1/4/5 www.google.fr. A 216.58.210.227 (204) 18:27:51.837791 IP6 (flowlabel 0x9a4b5, hlim 64, next-header UDP (17) payload length: 50) 14Ext-Code.dr14.cnrs.fr.46138 > 14Ext-NS.dr14.cnrs.fr.domain: [bad udp cksum 0xe623 -> 0x2df7!] 50905+ [1au] A? www.google.fr. (42) 18:27:51.838131 IP6 (flowlabel 0x4b7e2, hlim 64, next-header UDP (17) payload length: 212) 14Ext-NS.dr14.cnrs.fr.domain > 14Ext-Code.dr14.cnrs.fr.46138: [bad udp cksum 0x203e -> 0x421c!] 50905 1/4/5 www.google.fr. A 216.58.210.227 (204) 18:27:54.208962 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::215:fdff:fefd:fd10 > 14Ext-Code.dr14.cnrs.fr: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 14Ext-Code.dr14.cnrs.fr source link-address option (1), length 8 (1): 00:15:fd:fd:fd:10 18:27:54.209228 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) 14Ext-Code.dr14.cnrs.fr > fe80::215:fdff:fefd:fd10: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is 14Ext-Code.dr14.cnrs.fr, Flags [solicited] ^C 7 packets captured -- from the nameserver root@14Ext-Code:~# tcpdump host 14Ext-NS.dr14.cnrs.fr -v tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 18:27:41.607983 IP6 (flowlabel 0x9a4b5, hlim 64, next-header UDP (17) payload length: 50) 14Ext-Code.dr14.cnrs.fr.46138 > 14Ext-NS.dr14.cnrs.fr.domain: [bad udp cksum 0x1f9c -> 0x2df7!] 50905+ [1au] A? www.google.fr. (42) 18:27:46.607895 IP6 (flowlabel 0x9a4b5, hlim 64, next-header UDP (17) payload length: 50) 14Ext-Code.dr14.cnrs.fr.46138 > 14Ext-NS.dr14.cnrs.fr.domain: [bad udp cksum 0x1f9c -> 0x2df7!] 50905+ [1au] A? www.google.fr. (42) 18:27:46.620713 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::215:5dff:fe01:140e > 14Ext-NS.dr14.cnrs.fr: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 14Ext-NS.dr14.cnrs.fr source link-address option (1), length 8 (1): 00:15:5d:01:14:0e 18:27:46.621042 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) 14Ext-NS.dr14.cnrs.fr > fe80::215:5dff:fe01:140e: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is 14Ext-NS.dr14.cnrs.fr, Flags [solicited] 18:27:48.966683 IP6 (flowlabel 0x4b7e2, hlim 64, next-header UDP (17) payload length: 212) 14Ext-NS.dr14.cnrs.fr.domain > 14Ext-Code.dr14.cnrs.fr.46138: [bad udp cksum 0x5848 -> 0xa01b!] 50905 1/4/5 www.google.fr. A 216.58.210.227 (204) 18:27:48.966974 IP6 (flowlabel 0x4b7e2, hlim 64, next-header UDP (17) payload length: 212) 14Ext-NS.dr14.cnrs.fr.domain > 14Ext-Code.dr14.cnrs.fr.46138: [bad udp cksum 0xe848 -> 0x301c!] 50905 1/4/5 www.google.fr. A 216.58.210.227 (204) 18:27:51.608023 IP6 (flowlabel 0x9a4b5, hlim 64, next-header UDP (17) payload length: 50) 14Ext-Code.dr14.cnrs.fr.46138 > 14Ext-NS.dr14.cnrs.fr.domain: [bad udp cksum 0x1f9c -> 0x2df7!] 50905+ [1au] A? www.google.fr. (42) 18:27:51.608773 IP6 (flowlabel 0x4b7e2, hlim 64, next-header UDP (17) payload length: 212) 14Ext-NS.dr14.cnrs.fr.domain > 14Ext-Code.dr14.cnrs.fr.46138: [bad udp cksum 0xfa48 -> 0x421c!] 50905 1/4/5 www.google.fr. A 216.58.210.227 (204) ^C 8 packets captured I'm noticing this bad udp cksum. I'll make some searches -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: IPV6 resolving fails via udp (not tcp) from other server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
Hi back. I (really) quickly set up 2 virtual machines on my HyperV cluster. Each With ubuntu OOB iso image, one in 15.10, one in 16.04. No extra setup, only ipv6 adresses. I attached the result. I'll post some tcpdump in a few minutes ** Attachment added: "Screen capture of both servers" https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+attachment/4670255/+files/Capture%20d%E2%80%99%C3%A9cran%202016-05-25%20%C3%A0%2017.42.20.png -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: IPV6 resolving fails via udp (not tcp) from other server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
Hi, thanks for reading. You are right, this is not a bind issue. It appears with ntp also. I spoke about resolv.conf because it masked me the problem: it contains my 3 nameservers But As I mentioned, when one server tries resolving using itself, if works. That's why I noticed lately the problem when adding a non-nameserver ubuntu. Of course, I made my best to find any network issues, there a no firewall and all takes place in a HyperV network. So, I asked a more general and simple question here : https://answers.launchpad.net/ubuntu/+question/294135 When I switch to ipv4 (resolving, ntp) with the same host, all is fine. TO help reproduce, I'll add 2 more servers, strictly ipv6, one in Ubuntu 16.04 and one in 15.10 and check. I'll tell later Fred -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: IPV6 resolving fails via udp (not tcp) from other server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
PS : If you can reaffect this bug report to the right package, thanks for that. I haven't found how to get more generic ... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: IPV6 resolving fails via udp (not tcp) from other server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
Thank you for taking the time to report this bug and helping to make Ubuntu better. I'm sorry, I don't understand your report. You've reported the bug against bind9, so are you saying that the problem is with bind9 serving as a forwarder? But in that case, I don't understand why you're instructing me to change resolv.conf in your reproduction steps, since bind doesn't use that. You're also instructing me to use dig @XXX for a failure case, which also doesn't use resolv.conf but uses the nameserver specified directly. I have just tested and confirmed that dig works correctly with IPv6 on Xenial against one of my ISPs IPv6 resolvers. I tried changing resolv.conf temporarily to point to an IPv6 nameserver only, and it still works: $ dig www.google.com @2001:8b0::2020 ; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.google.com @2001:8b0::2020 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57112 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.google.com.IN A ;; ANSWER SECTION: www.google.com. 202 IN A 216.58.198.100 ;; Query time: 20 msec ;; SERVER: 2001:8b0::2020#53(2001:8b0::2020) ;; WHEN: Wed May 25 14:59:56 BST 2016 ;; MSG SIZE rcvd: 59 Are you sure you don't have a simple firewall issue? Since I cannot understand your report, I regret that this will not make any progress without further information. Please could you provide a simple set of steps to reproduce that uses a single minimal set of DNS tooling, rather than all the tools? For example, if it is a problem with resolv.conf and nss, then your instructions should involve changing resolv.conf and using "getent hosts" or similar only. Using "dig @..." makes no sense since this bypasses resolv.conf and nss. Concurrent commentary using tcpdump said are appreciated and useful; my point is that the failure should be able reproduce using minimal tooling. Once done, please change the bug status back to New. ** Changed in: bind9 (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: IPV6 resolving fails via udp (not tcp) from other server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
The same with ntp: @client:~# ntpdate aaa.bbb.ccc.188 24 May 12:56:09 ntpdate[26846]: adjust time server aaa.bbb.ccc.188 offset 0.083226 sec @client:~# ntpdate :::188 24 May 12:56:38 ntpdate[27174]: no server suitable for synchronization found -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: IPV6 resolving fails via udp (not tcp) from other server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
Just to add a point about how I noticed the bug. It as one important information. I have 3 nameservers, all ipv6/4. No particular problem. Problem occurred when I added a 4th Ubuntu server. This one installs fine as I set ip IPv4 first with the 3 nameservers ipv4 address. But, when I added the ipv6 interface, and all 3 nameservers with their ipv6 address, it failed. I spent a lot of time checking network, Ipv6, reinstalling Ubuntu till I end up notifying that as a real bug. In fact, adding 3 ipv6 nameservers address changes the resolv.conf and the 3 nameservers stack is filled with ipv6 adresses. So, it leads to a non responding resolution. I made some tests on my nameservers and noticed that they are in the same setup but, and thats the important discovery, they get a response with ipv6 when then request themselves. Server1 doesn't get a response from server2 et 3, but it does with server1. That's one I didn't noticed the bug because each nameserver has it's own address in the resolv.conf so requests end with responding To Bypass the bug, each interface has only ipv4 nameserver addresses except on each nameserver where I left it's own ipv6 address in the interface setup -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: IPV6 resolving fails via udp (not tcp) from other server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
Sorry, i'm tired, here is the link: https://bugs.launchpad.net/ubuntu/+source/linux-lts-trusty/+bug/1527902 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1584042 Title: IPV6 resolving fails via udp (not tcp) from other server To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1584042] Re: IPV6 resolving fails via udp (not tcp) from other server
One colleague, linux expert, pointed me to this : #1527902
he did some strace and find :
60735 gettimeofday({1463755505, 995830}, NULL) = 0
60735 sendmsg(20, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(53),
inet_pton(AF_INET6, "2001:660:660c:120::226", _addr), sin6_flowinfo=0,
sin6_scope_id=0}, msg_iov(1)=[{"\236\207\1 \
0\1\0\0\0\0\0\1\3www\6google\2fr\0\0\1\0\1\0"..., 42}], msg_controllen=0,
msg_flags=0}, 0) = 42
60735 futex(0x7f7ab325d0a4, FUTEX_WAIT_PRIVATE, 3, NULL
60737 <... epoll_wait resumed> [{EPOLLIN, {u32=3, u64=3}}], 64, -1) = 1
60737 read(3, "\24\0\0\0\375\377\377\377", 8) = 8
60737 epoll_ctl(5, EPOLL_CTL_ADD, 20, {EPOLLIN, {u32=20, u64=20}}) = 0
60737 read(3, 0x7f7aac706e40, 8)= -1 EAGAIN (Resource temporarily
unavailable)
60737 epoll_wait(5,
60736 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1584042
Title:
IPV6 resolving fails via udp (not tcp) from other server
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1584042/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
