Debugging pcap_activate and pcap_create with and without
<parameter name='CTRL_IP_LEARNING' value='dhcp'/>
TL;DR:
- Bad Case: fd stays at -1 on pcap_activate
- Good case: pcap_activate sets a valid fd = 27
They use very different paths.
Bad Case:
1.
pcap_create(ifname, pcap_errbuf);
ifname = "vnet0"
pcap_errbuf is a local char* of [PCAP_ERRBUF_SIZE];
2. pcap_set_snaplen(handle, PCAP_PBUFSIZE)
PCAP_PBUFSIZE = 576 by nwfilter_dhcpsnoop.c:237
3. pcap_set_buffer_size(handle, PCAP_BUFFERSIZE)
PCAP_BUFFERSIZE (128 * 1024) by nwfilter_dhcpsnoop.c:259
4. pcap_activate(handle)
Good Case:
- doesn't even hit virNWFilterSnoopDHCPOpen.
- It reaches the pacp functions via:
#0 pcap_activate (p=p@entry=0x7f3234000bb0) at ./pcap.c:775
#1 0x00007f3290684b4c in pcap_open_live (device=device@entry=0x7f3280017768
"vnet0", snaplen=snaplen@entry=8192, promisc=promisc@entry=0,
to_ms=to_ms@entry=500, errbuf=errbuf@entry=0x7f3284b9fb70 "") at
./pcap.c:840
#2 0x00007f32908cb575 in learnIPAddressThread (arg=0x7f3280017760) at
../../../src/nwfilter/nwfilter_learnipaddr.c:413
#3 0x00007f32adaa9ad2 in virThreadHelper (data=<optimized out>) at
../../../src/util/virthread.c:206
#4 0x00007f32ad1536db in start_thread (arg=0x7f3284ba0700) at
pthread_create.c:463
#5 0x00007f32ace7c88f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Maybe this does something different in between?
It does
1. pcap_create(device, errbuf);
same device string
same size of errbuf
2. pcap_set_snaplen(p, snaplen);
len is BUFSIZ which is stdio.h _IO_BUFSIZ (that is 8192 by
/usr/include/x86_64-linux-gnu/bits/_G_config.h:61:#define _G_BUFSIZ 8192)
3. pcap_set_promisc(p, promisc)
with promisc being 0
4. pcap_set_timeout(p, to_ms)
with timeout being 500
5. pcap_activate(p);
Before that p->oldstyle = 1; gets set.
Following comment for that assignment:
/*
* Mark this as opened with pcap_open_live(), so that, for
* example, we show the full list of DLT_ values, rather
* than just the ones that are compatible with capturing
* when not in monitor mode. That allows existing applications
* to work the way they used to work, but allows new applications
* that know about the new open API to, for example, find out the
* DLT_ values that they can select without changing whether
* the adapter is in monitor mode or not.
*/
Could it be that the libvirt usage just is "oldstyle"?
I'm now trying to recreate that against a local build of master to patch
the differences one by one hopefully finding the weak spot we could fix.
--
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
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
