With a bit more analysis, this seems to only affect the new -B option. 
Using -b or uni-directional flows, the filters seem to work.  I am using
the latest stable release: 1.6.1.

Thanks again

> I am trying to filter out known, good traffic so I can see traffic that I
> am not expecting or considering.  I have a list of "rules" that match good
> traffic and have converted those to nfdump filters.  My next step was to
> negate them which is not producing what I expected.  Here are a couple of
> the simple filters I have tried:
>
> // this works great and gives the expected result
> nfdump -qBr file 'not dst port 443'
>
> // This works as expected
> nfdump -qBr file 'dst port 443 or dst port 389'
>
> Now for the inverse filters:
>
> // this does not work, it removes 443 traffic, but not 389
> nfdump -qBr file 'not dst port 443 and not dst port 389'
>
> // this also does not work, it removes 443 traffic, but not 389
> nfdump -qBr file 'not ((dst port 443) or (dst port 389))'
>
> Am I doing this incorrectly?
>
> Thank you for your time
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Nfdump-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfdump-discuss
>



------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Nfdump-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfdump-discuss

Reply via email to