expression rejects all packets

[Jon Dugan]

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[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
-- 
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