Launchpad has imported 10 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1547237.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2018-02-20T20:03:52+00:00 Laine wrote: Starting with F27, the Fedora-only patch that disabled TPACKET_V3 support was removed with the comment: Drop TPACKET_V3 patch as it should be fixed in kernel by now This is apparently not the case since, on a host with F27 packages, including libpcap-1.8.1-6 and kernel 4.15.3-300, the previously-functional libvirt code that uses libpcap to watch for DHCP traffic now fails when pcap_setfilter() returns EBADF. Here is the excerpt of libvirt code (from the file src/nwfilter/nwfilter_dhcpsnoop.c): [...] handle = pcap_create(ifname, pcap_errbuf); if (handle == NULL) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("pcap_create failed")); goto cleanup_nohandle; } if (pcap_set_snaplen(handle, PCAP_PBUFSIZE) < 0 || pcap_set_buffer_size(handle, PCAP_BUFFERSIZE) < 0 || pcap_activate(handle) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("setup of pcap handle failed: %s"), pcap_geterr(handle)); goto cleanup; } if (pcap_compile(handle, &fp, ext_filter, 1, PCAP_NETMASK_UNKNOWN) != 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("pcap_compile: %s"), pcap_geterr(handle)); goto cleanup; } if (pcap_setfilter(handle, &fp) != 0) { <=== FAILURE HERE virReportError(VIR_ERR_INTERNAL_ERROR, _("pcap_setfilter: %s"), pcap_geterr(handle)); goto cleanup_freecode; } [...] If I add the patch titled "pcap-linux: don't use TPACKETV3 for memory mmapped capture" back to the F27 build of libpcap (built locally with fedpkg) and install the resulting rpm, the same code magically begins to work. I haven't checked rawhide, but I assume the behavior is the same. I think Fedora needs to re-disable TPACKET_V3 Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037/comments/0 ------------------------------------------------------------------------ On 2018-02-22T13:27:19+00:00 Martin wrote: TPACKET_V3 was enable because it is a vital feature for network packet analyzers. I don't want to disable it again, because it will trigger other bugs (usually it is about packet drops). Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037/comments/1 ------------------------------------------------------------------------ On 2018-02-22T14:24:58+00:00 Laine wrote: Can you recommend how we should modify the libvirt code that uses pcap to avoid this regression in pcap's behavior? (while maintaining compatibility with other/older distros that haven't enabled TPACKET_V3) Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037/comments/2 ------------------------------------------------------------------------ On 2018-02-26T11:33:43+00:00 Michal wrote: Switching the needinfo to the assignee(myself). Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037/comments/3 ------------------------------------------------------------------------ On 2018-03-22T08:36:38+00:00 Martin wrote: Could you please provide us with some steps to reproduce? Something about how to compile/run the code in order to trigger this bug, so that we can properly examine it. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037/comments/4 ------------------------------------------------------------------------ On 2018-03-26T14:09:49+00:00 Laine wrote: If you have a system with libvirt and virt-manager installed, you can just create a virtual machine, then edit its configuration with "virsh edit" to att the following "<filterref>" section to its <interface>, then attempt to start the virtual machine: <interface type='network'> <source network='default'/> <filterref filter='clean-traffic'> <parameter name='CTRL_IP_LEARNING' value='dhcp'/> <parameter name='DHCPSERVER' value='192.168.122.1'/> </filterref> </interface> If you've installed the debuginfo for libvirt, you can set a breakpoint on the function virNWFilterSNoopDHCPOpen() (which is the source of the bit of code I posted above). I can provide more detailed step-by-step instructions if you need it, but didn't want to pollute the BZ with a long treatise on installing virt stuff if you already had it on. If you need any assistance while doing this, you can find me (and several other libvirt developers) on IRC in the #virt channel on irc.oftc.net. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037/comments/9 ------------------------------------------------------------------------ On 2018-03-27T10:27:09+00:00 Martin wrote: Created attachment 1413663 Libpcap patch that logs debug information and bypasses the problem Thanks for the reproducer. Just for the record, it is necessary to install libvirt-daemon-config-nwfilter package before this starts to work. Then you can attach to running libvirtd using gdb, set the breakpoint and try to start the virtual machine. The real name of the function is: virNWFilterSnoopDHCPOpen , it took me a while to notice the capital N in SNoop :) The bug itself is triggered in the function: pcap_setfilter_linux -> pcap_setfilter_linux_common -> reset_kernel_filter where setsockopt is called with handle->fd as an argument, which is -1 in this case. I am not sure yet, where the -1 came from in this file descriptor, but surrounding this function with a condition bypasses the problem and my VM starts just fine. Though I don't know if the libvirt filter works, because I don't know what it is supposed to do. I attach a patch for libpcap, that can be used for debugging. It is not meant as a fix, rather for other maintainers to try it. Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037/comments/10 ------------------------------------------------------------------------ On 2018-03-27T11:09:09+00:00 Laine wrote: (In reply to Martin Sehnoutka from comment #7) > Created attachment 1413663 [details] > Libpcap patch that logs debug information and bypasses the problem > > Thanks for the reproducer. Just for the record, it is necessary to install > libvirt-daemon-config-nwfilter package before this starts to work. Interesting. That should have been installed as a dependency. I'll look into why it's missing. Was your test platform F28, or something else? > > The real name of the function is: virNWFilterSnoopDHCPOpen , it took me a > while to notice the capital N in SNoop :) Oops! Sorry about that - that will teach me to type instead of paste :-) > I attach a > patch for libpcap, that can be used for debugging. It is not meant as a fix, > rather for other maintainers to try it. For the sake of gathering information, I'll build with this patch applied and try it to see if libvirt's functionality is still there (what's supposed to happen is that libvirt will monitor all DHCP traffic, and grab the IP address of the guest out of the DHCP response, then use that IP to build additional iptables rules). Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037/comments/11 ------------------------------------------------------------------------ On 2018-03-27T12:04:41+00:00 Martin wrote: (In reply to Laine Stump from comment #8) > Was your test platform F28, or something else? > Fedora 27 Workstation Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037/comments/12 ------------------------------------------------------------------------ On 2018-04-25T08:06:30+00:00 Christian wrote: Hi, I wanted to let you know that this problem is not only affecting Fedora. I happened to debug [1] leading the same conclusions on the fd being -1 breaking the latter setsockopt. I asked on #virt and fortunately danpb was aware of this bug and pointed me here. Ubuntu and Debian have no disabled TPACKET_V3 (never had) so it seems about all releases I could test are affected by this bug. Glad I found this bug to participate here and to be able to track your further insights as well. [1]: https://bugs.launchpad.net/libvirt/+bug/1758037 Reply at: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1758037/comments/18 ** Changed in: libvirt Status: Unknown => Confirmed ** Changed in: libvirt Importance: Unknown => Undecided -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1758037 Title: LTC Test- Ubuntu18.04: Starting the guest with network filter defined will fail with "cause is unknown". To manage notifications about this bug go to: https://bugs.launchpad.net/libvirt/+bug/1758037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
