On 02/12/2013 09:59 PM, Jon Schipp wrote:
Daniel, out of curiosity, what was the reason why the signal catch
(SIGUSR1 I think it was) was removed in early versions?

Actually, two reasons (besides the fact that the code at that time was
crappy anyway):

 * The stuff that was printed at that time, was directly printed from
   the signal handler, which is a bad thing / design since in signal handlers
   you should never do more than setting an sig_atomic_t variable.

 * AF_PACKET/RX_RING socket statistics need to be read out via a system
   call, and (even worse) this was done -- when demanded via SIGUSR1 --
   within the signal handler. Thus, it was not only wrong, but also slows
   down the netsniff-ng ``fast-path''.

This is why I actually want to avoid printing too much verbose stuff in
netsniff-ng (when with -s) either. However, if someone suggests or
implements a clean / sound way to do it differently I'm open to that.

On Tue, Feb 12, 2013 at 10:02 AM, Daniel Borkmann
<[email protected]> wrote:
On 02/12/2013 03:33 PM, [email protected] wrote:

On Tuesday, 12 February 2013 13:59:03 UTC, Daniel Borkmann  wrote:

On 02/12/2013 02:08 PM, Felix wrote:

I'm in the process of setting up netsniff to monitor my network traffic.
I'd like to have some indication of how many packets are being dropped (if
possible). Something similar to the summary given by tcpdump on exit.


Something similar as in tcpdump you have here:

[root@fedorabox Desktop]# netsniff-ng

Running! Hang up with ^C!



[...]



              7  packets incoming

              7  packets passed filter

              0  packets failed filter (out of space)   <----- HERE

         0.0000% packet droprate

              5  sec, 278139 usec in total



This line ("packets failed filter (out of space)") is telling you if
there have been any

packet drops during capturing.


Thanks Daniel. That will be a good place to start.

As a bonus: is there a way to get any stats on the running process? The
servers will be running over a long period of time and so it would be useful
to have an idea of any issues during the capture rather than when it
finishes.


Lets assume you record long-term stuff, then you could use -V to show
statistics
after each write, the first number is pkts captured, the second lost, e.g.:

   netsniff-ng --in team0 --out /opt/caps/ --interval 1GiB -V -s

Cheers,

Daniel


--
You received this message because you are subscribed to the Google Groups
"netsniff-ng" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups 
"netsniff-ng" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to