Closed lukego closed 9 years ago
G'day, Luke!
Why do you expect either packet to be dropped? pflua's behaviour matches libpcap's; both match each packet with the ip6 and tcp and portrange 32768-65535
clause, since both packets are ipv6 tcp packets, both of which involve port 49671, which is in the specified range.
First packet
% ./pflua-pipelines-match /tmp/bug/f.pcap 'ip6 and tcp and portrange 32768-65535' 1
OK: bpf-lua-unopt libpcap-unopt libpcap-opt pure-lua-unopt pure-lua-opt bpf-lua-opt all matched: all were true
Second packet
% ./pflua-pipelines-match /tmp/bug/f.pcap 'ip6 and tcp and portrange 32768-65535' 2
OK: bpf-lua-unopt libpcap-unopt libpcap-opt pure-lua-unopt pure-lua-opt bpf-lua-opt all matched: all were true
(I'm using tcpdump version 4.5.1 and libpcap version 1.5.3).
Hah!
This is my bad: I should be using dst portrange
instead of simply portrange
for my intended behaviour.
Thanks for the quick feedback!
I wondered... :-) I'm glad you've sorted it out.
I am really impressed with the testing tools you are creating btw! I have heard John Hughes and others give a lot of talks about nice testing techniques but I don't see them so often in the wild.
I'm really happy to be working on a project that has a good design (thanks Andy!) and relatively few dependencies/external bugs, and I have some background in formal verification. And I take http://danluu.com/testing/ and http://danluu.com/everything-is-broken/ and similar seriously, and like to see how software can be done better. I think property-based testing is low-hanging, too-often-ignored fruit, and gave a talk at FOSDEM to that effect, too. :-)
Good day to you fine people!
I have a packet that is passing a filter when I expect it to be dropped. This seems to affect the current master (4c947889).
Here is the filter, which is verbose because autogenerated from OpenStack config:
Here is the trace where I had expected the first packet to be dropped:
Here is that trace again as a base64 encoded pcap file: