expression rejects all packets
jdugan at ncsa.uiuc.edu
Thu Sep 6 17:54:30 PDT 2001
On Thu, Sep 06, 2001 at 05:23:46PM -0700, Vern Paxson wrote:
> > #./bro -i sk0 -i sk1 mt ncsa
> > listening on sk0
> > ./bro: problem with interface sk1 - pcap_compile((vlan) and (((((((((ip[6:2] &
> > 0x3fff != 0) and tcp) or (tcp & 0x7 != 0)) or (port finger)) or (tcp port
> > 113)) or (port ftp)) or (port telnet or tcp port 513)) or (port 111)) or (udp
> > port 123))): expression rejects all packets
> > the contents of ncsa.bro are:
> > redef restrict_filter = "vlan";
> > it's weird it looks like the pcap expression compiles for one interface but
> > not the second.
> First thing to try is feeding the expression manually to tcpdump for each
> of the interfaces, to see whether you get the same message.
Ok. I did that and it worked on each interface.
> I suspect the problem is that "vlan" expands into something equates with
> "not ip", and so the conjunction is always false, since all of the other
> expressions require "ip" to be true. I'm not sure how to fix this, as
> my version of tcpdump/libpcap doesn't know about "vlan".
It's in the version of libpcap available from tcpdump.org. I think it may
have been merged into the version that ships with FreeBSD 4.4-RELEASE.
Actually it just moves the beginning of packet pointer to the right 4 bytes
-- it assumes that a frames on the wire are tagged.
Here's the relevant paragraph from the tcpdump manpage:
True if the packet is an IEEE 802.1Q VLAN
packet. If [vlan_id] is specified, only
true is the packet has the specified
vlan_id. Note that the first vlan keyword
encountered in expression changes the decod-
ing offsets for the remainder of expression
on the assumption that the packet is a VLAN
> > for my
> > purposes i don't need to look at the native VLAN since there is no traffic
> > on it.)
> Then wouldn't your filter be "not vlan" rather than "vlan"?
No, the vlan with no arguments simply moves the pointer to skip the tags.
> > in order to get this far i had to rearrange the order of capture_f and
> > restrict_f in main.cc, i put restrict on the left and capture on the left.
> > without doing that the expression wouldn't compile the pcap expression for
> > the first interface.
> That doesn't sound good - they're just a conjunction together, so pcap
> should compile them in either order. I wonder if "vlan" is implemented
> inside pcap as some sort of hack ...
That's what I was thinking.
I've been working on patches to improve the way VLANs are supported in
libpcap -- however the additional BPF logic i added to the statements that
libpcap generates seems to confuse the optimizer in libpcap.
Jon Dugan | Senior Network Engineer, NCSA Network Development
jdugan at ncsa.uiuc.edu | 269 CAB, 605 E Springfield, Champaign, IL 61820
217-244-7715 | http://www.ncsa.uiuc.edu/people/jdugan
More information about the Bro