Yes, I guess you are right :) I never relied on the what the filter count
was anyway - prior to your question I had no idea it was so
"non-determinstic"...
On Wed, Sep 3, 2014 at 5:29 PM, Scott Granados <sc...@granados-llc.net>
wrote:
> So this actually helped, thank you for the pointers and more detail on the
> man page. Honestly, when I read the man page I couldn’t figure out what
> was being said at all. The filter is a filter unless it’s not a filter and
> depending on your OS it might or might not be a filter but only if the moon
> phases are in alignment and it’s the second wednesday of the month? :)
>
> That helped, I followed each step of the path and found a misconfigured
> port which did the trick.
>
> Thank you
>
> On Sep 3, 2014, at 2:16 AM, Adrian Popa <adrian.popa...@gmail.com> wrote:
>
> From tcpdump's man page:
>
> When *tcpdump* finishes capturing packets, it will report counts of:
>
> packets ``captured'' (this is the number of packets that *tcpdump* has
> received and processed);
> packets ``received by filter'' (the meaning of this depends on the OS on
> which you're running *tcpdump*, and possibly on the way the OS was
> configured - if a filter was specified on the command line, on some OSes it
> counts packets regardless of whether they were matched by the filter
> expression and, even if they were matched by the filter expression,
> regardless of whether *tcpdump* has read and processed them yet, on other
> OSes it counts only packets that were matched by the filter expression
> regardless of whether *tcpdump* has read and processed them yet, and on
> other OSes it counts only packets that were matched by the filter
> expression and were processed by *tcpdump*);
> packets ``dropped by kernel'' (this is the number of packets that were
> dropped, due to a lack of buffer space, by the packet capture mechanism in
> the OS on which *tcpdump* is running, if the OS reports that information
> to applications; if not, it will be reported as 0).
>
> So, it's complicated :)
>
> But if it doesn't show additional data, then you most likely aren't
> receiving traffic (according to your filter). Check that the packets leave
> the router and if they do, check that you don't lose them in between...
>
>
>
> On Tue, Sep 2, 2014 at 6:41 PM, Scott Granados <sc...@granados-llc.net>
> wrote:
>
>> Hi,
>> I have been running nfsen for a month or so and had good luck setting up
>> sources but I’m having a strange problem now. I’m sending data from an
>> MX104 to a flow collector. I used the standard config from the Juniper KB
>> article and not receiving flow data. When I run tcpdump this is what I get.
>>
>> [root@flow01d ~]# tcpdump udp port 9901
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>> listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
>>
>> ^C
>> 0 packets captured
>> 24 packets received by filter
>> 0 packets dropped by kernel
>>
>> I do not see the packets being output, I see something about packets
>> being caught by filter and none dropped. Any idea how I troubleshoot this
>> further? I don’t understand how I’m receiving packets but they don’t
>> display and if I issue the same command on a working port I get tons of
>> output. Any pointers would be most appreciated.
>>
>>
>> Thanks
>> Scott
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds. Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Nfsen-discuss mailing list
>> Nfsen-discuss@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/nfsen-discuss
>>
>>
>
>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Nfsen-discuss mailing list
Nfsen-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfsen-discuss
