This may not be the right group, but I have a few BPF questions that I
hope you can answer:
* What is the maximum size of a BPF expression that can be passed to
tcpdump and pcap_compile()? Some of the BPF expressions I've observed
are over 1024 characters and I wonder what the limt is (if any
BPF for non-nested vlans...
BPF for non-nested vlans...
BPF for non-nested vlans...
User-Agent: Unison/2.1.5
What is the correct BPF for packets that have a vlan tag of either 100
or 200? A BPF like "vlan 100 or vlan 200" would not work (as the
manpage clearly explains).
Thanks much.
-
T
I've been running performance tests against pcap_next_ex() and
pcap_dump(). I've placed micro-second timers around both functions and
sent millions of packets to my test programs.
Both functions performed admirably over a short period of time (up to 8
Gbits/sec) but, as time progressed, both
On 2015-08-22 23:21:55 +, Guy Harris said:
I've been running performance tests against pcap_next_ex() and
pcap_dump(). I've placed micro-second timers around both functions
So those are presumably real-time timers rather than CPU timers.
Using the Boost timer functions. I could be wron
On 2015-08-23 01:42:30 +, Guy Harris said:
So probably real-time.
That means that, *if* there are other processes on the machine, some of
the time *could* be due to other processes having all the cores, but,
with 8 cores, that's unlikely unless your test programs are lighting up
all 8 co
On 2015-08-23 03:13:50 +, Guy Harris said:
It has puzzled me too. Keep in mind that I am making millions of these
pcap calls; only one of them could be taking 2 seconds.
Then the average might be more interesting than the maximum.
Yes, but the average was only about 20 times higher, whi
On 2015-08-23 09:39:19 +, Ander Juaristi said:
Have you completely discarded algorithmical issues?
This looks like something is being constantly doubled. Probably in
logarithmic time.
The timers are wrapped around the pcap functions:
timer before_dump;
pcap_dump();
timer after_
