# expression rejects all packets

**URL:** <https://community.zeek.org/t/expression-rejects-all-packets/181>\
**Category:** Zeek\
**Created:** [September 7, 2001, 12:54am UTC](https://community.zeek.org/t/expression-rejects-all-packets/181 "2001-09-07T00:54:30Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jon\_Dugan](https://avatars.discourse-cdn.com/v4/letter/j/779978/32.png) [@Jon\_Dugan](https://community.zeek.org/u/Jon_Dugan)\
**Post date:** [September 7, 2001, 12:54am UTC](https://community.zeek.org/t/expression-rejects-all-packets/181/1 "2001-09-07T00:54:30Z")

</div>

> \> #./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.

&nbsp;&nbsp;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".

&nbsp;&nbsp;It's in the version of libpcap available from tcpdump.org. I think it may  
&nbsp;&nbsp;have been merged into the version that ships with FreeBSD 4.4-RELEASE.

&nbsp;&nbsp;Actually it just moves the beginning of packet pointer to the right 4 bytes  
&nbsp;&nbsp;-- it assumes that a frames on the wire are tagged.

&nbsp;&nbsp;Here's the relevant paragraph from the tcpdump manpage:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;vlan [vlan\_id]  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;True if the packet is an IEEE 802.1Q VLAN  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;packet. If [vlan\_id] is specified, only  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;true is the packet has the specified  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;vlan\_id. Note that the first vlan keyword  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;encountered in expression changes the decod-  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ing offsets for the remainder of expression  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;on the assumption that the packet is a VLAN  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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"?

&nbsp;&nbsp;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 ...

&nbsp;&nbsp;That's what I was thinking.

&nbsp;&nbsp;I've been working on patches to improve the way VLANs are supported in  
&nbsp;&nbsp;libpcap -- however the additional BPF logic i added to the statements that  
&nbsp;&nbsp;libpcap generates seems to confuse the optimizer in libpcap.

Jon

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\
**Post date:** [May 6, 2022, 3:36pm UTC](https://community.zeek.org/t/expression-rejects-all-packets/181/2 "2022-05-06T15:36:22Z")

</div>