Using a time-based interval in netsniff-ng crashes at the end of the first interval

[branchnet...@gmail.com]

I built netsniff-ng 0.5.8-rc2 from git just last night on a 64bit Ubuntu 12.04.2 LTS box.

When I specify a time-based interval, netsniff-ng records for the full interval but then crashes with a "Poll failed!" error before starting a 2nd pcap file.  Like this:

root@server:~# netsniff-ng --in eth1 --out dump -s --interval 30s
Running! Hang up with ^C!

Poll failed!
root@server:~# ll dump
total 152064
drwxr-xr-x  2 root root      4096 Aug 16 10:27 ./
drwx------ 57 root root     12288 Aug 16 10:26 ../
-rw-r--r--  1 root root 155690405 Aug 16 10:27 dump-1376663235.pcap

This does not occur with a traffic volume interval like "--interval 1MiB"

I googled about for "netsniff-ng" and "Poll failed!" but it appears this may have cropped up recently, since nothing turned up in my digging.

Kevin

[Daniel Borkmann]

Thanks for reporting! I've just pushed a fix upstream to the Git repository.

Could you test it on your side?

> Kevin

[Kevin Branch]

Daniel,

I did a fresh git pull of the latest netsniff-ng 0.5.8-rc2 minutes ago and built it on these platforms:

• Ubuntu 12.04.2 LTS with stock 64bit Ubuntu kernel
• CentOS 6.4 with non-stock 3.10.7-1.el6.elrepo.x86_64 kernel
  

Using time-based intervals is working in both cases.

Thanks!
Kevin

[Kevin Branch]

With netsniff-ng 0.5.8-rc2+, when I run the below packet capture
session, the output seems to imply that 64K of memory is being allocated
per frame, which does not look like what I want since my interface MTU
is only 1500. This appears to be severely limiting the number of frames
I can fit into my packet capture ring.

[root@nids-sen ttt]# netsniff-ng --in dmz -s --out dump.cap -S 256MiB -V
RX: 256.00 MiB, 4096 Frames, each 65536 Byte allocated

Running! Hang up with ^C!

Should I do something to explicitly disable jumbo frames support?

Kevin

[Daniel Borkmann]

Nope, the capture-only setting of netsniff-ng uses TPACKET_V3, where there is
no such restriction of static frame slot sizes as in TPACKET_V2 where e.g.
each frame is of max size 4096 usually. Frames are written to the ring buffer in
a continuous way. It uses the same API in netsniff-ng and therefore just prints
the same setting. So, you don't need to do anything explicitly here.

But I agree with you that we should change the verbose output of that line in
this case. Will push a patch in a moment.

[Kevin Branch]

I am hoping to switch my existing traffic recording systems from using
daemonlogger to netsniff-ng. They make hourly capture files that start
at the top of the hour and end and the end of the hour. Daemonlogger's
default behavior for handling time-based intervals is to roll over at
the top of the interval in alignment with the time of day so a "1 hour"
interval would pick up traffic from 8:00-8:59, 9:00-9:59, etc... always
rotating at the exact top of the hour even if that means the first
interval is much shorter because the program is started in the middle of
an hour. Based on my current experimentation, it appears netsniff-ng
aligns its intervals with the exact start time of the program, so if I
start an hourly interval capture at 8:35, all capture files will start
at 35 minutes after the hour. I can't guarantee that my traffic
recording system will always be started at the exact top of the hour, so
could you consider making an option in netsniff-ng to rotate on even
time intervals, perhaps --even-intervals?

Thanks for your consideration. I have only recently discovered
netsniff-ng and really like what I see.

Kevin

[Daniel Borkmann]

Great idea. We could indeed do something about that. We will put this on the list for rc4.

Thanks !