expression rejects all packets

Zeek
1

> #./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[13] & 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:

              vlan [vlan_id]
                     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
                     packet.

> 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