11:57 p.m.
Build Update for libvirt/libvirt
-------------------------------------
Build: #1186
Status: Errored
Duration: 11 mins and 34 secs
Commit: aa68d0d (v3.7-maint)
Author: Laine Stump
Message: nwfilter: increase pcap buffer size to be compatible with TPACKET_V3
When an nwfilter rule sets the parameter CTRL_IP_LEARNING to "dhcp",
this turns on the "dhcpsnoop" thread, which uses libpcap to monitor
traffic on the domain's tap device and extract the IP address from the
DHCP response.
If libpcap on the host is built with HAVE_TPACKET3 defined (to enable
support for TPACKET_V3), the dhcpsnoop code's initialization of the
libpcap socket would fail with the following error:
virNWFilterSnoopDHCPOpen:1134 : internal error: pcap_setfilter: can't remove kernel
filter: Bad file descriptor
It turns out that this was because TPACKET_V3 requires a larger buffer
size than libvirt was setting (we were setting it to 128k). Changing
the buffer size to 256k eliminates the error, and the dhcpsnoop thread
once again works properly.
A fuller explanation of why TPACKET_V3 requires such a large buffer,
for future git spelunkers:
libpcap calls setsockopt(... SOL_PACKET, PACKET_RX_RING...) to setup a
ring buffer for receiving packets; two of the attributes sent to this
API are called tp_frame_size, and tp_frame_nr. If libpcap was built
with HAVE_TPACKET3 defined, tp_trame_size is set to MAXIMUM_SNAPLEN
(defined in libpcap sources as 262144) and tp_frame_nr is set to:
[the buffer size we set, i.e. PCAP_BUFFERSIZE i.e. 262144] / tp_frame_size.
So if PCAP_BUFFERSIZE < MAXIMUM_SNAPLEN, then tp_frame_nr (the number
of frames in the ring buffer) is 0, which is nonsensical. This same
value is later used as a multiplier to determine the size for a call
to malloc() (which would also fail).
(NB: if HAVE_TPACKET3 is *not* defined, then tp_frame_size is set to
the snaplen set by the user (in our case 576) plus a small amount to
account for ethernet headers, so 256k is far more than adequate)
Since the TPACKET_V3 code in libpcap actually reads multiple packets
into each frame, it's not a problem to have only a single frame
(especially when we are monitoring such infrequent traffic), so it's
okay to set this relatively small buffer size (in comparison to the
default, which is 2MB), which is important since every guest using
dhcp snooping in a nwfilter rule will hold 2 of these buffers for the
entire life of the guest.
Thanks to Christian Ehrhardt for discovering that buffer size was the
problem (this was not at all obvious from the error that was logged!)
Resolves: https://bugzilla.redhat.com/1547237
Fixes: https://bugs.launchpad.net/libvirt/+bug/1758037
Signed-off-by: Laine Stump <laine(a)laine.org>
Reviewed-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com> (V1)
Reviewed-by: John Ferlan <jferlan(a)redhat.com>
Tested-by: Christian Ehrhardt <christian.ehrhardt(a)canonical.com>
(cherry picked from commit ce5aebeacd10a1c15cb3ee46a59c8b5ff235589e)
View the changeset:
https://github.com/libvirt/libvirt/compare/5a81acc80fc7...aa68d0db2cc7
View the full build log and details:
https://travis-ci.org/libvirt/libvirt/builds/372235674?utm_source=email&a...
--
You can configure recipients for build notifications in your .travis.yml file. See
https://docs.travis-ci.com/user/notifications
This email was sent to libvirt-ci(a)redhat.com (mailto:libvirt-ci@redhat.com)
unsubscribe from this list
(http://clicks.travis-ci.com/track/unsub.php?u=14313403&id=51db8e427fd...)