Writing to files stops after 3.7GB #150

Open
igvk opened this Issue Oct 28, 2015 · 6 comments

Comments

Projects
None yet
3 participants
@igvk

igvk commented Oct 28, 2015

I use latest netsniff-ng under Linux (kernel 4.2.3, 64-bit).
The following command line is used:
netsniff-ng -i bond0 -s -S 16GiB -o ~/sniff -F 500MiB -f 'host 1.2.3.4'

Writing to file stops after about 3.7GB, and here is the statistics after exiting:
7141894 packets incoming (72008616 unread on exit)
14314860 packets passed filter
64835650 packets failed filter (out of space)
81.9144% packet droprate
10937 sec, 831974 usec in total

This looks lke some kind of bug that prevents writing to file after some size, and then all the packets are considered dropped.

@tklauser

This comment has been minimized.

Show comment
Hide comment
@tklauser

tklauser Oct 28, 2015

Contributor

Thanks for your report. This looks very similar to #128.

Does the bug still occur if you use a ring size smaller than 5GiB?

Contributor

tklauser commented Oct 28, 2015

Thanks for your report. This looks very similar to #128.

Does the bug still occur if you use a ring size smaller than 5GiB?

@tklauser tklauser added the bug label Oct 28, 2015

@igvk

This comment has been minimized.

Show comment
Hide comment
@igvk

igvk Oct 28, 2015

I checked with ring size 4GiB, and the problem does not exist.

igvk commented Oct 28, 2015

I checked with ring size 4GiB, and the problem does not exist.

@tklauser

This comment has been minimized.

Show comment
Hide comment
@tklauser

tklauser Oct 29, 2015

Contributor

Did the original bug occur on a 32bit or a 64bit system?

On 32bit it might be related to an integer overflow in the ring size (which I'm about to fix).

Contributor

tklauser commented Oct 29, 2015

Did the original bug occur on a 32bit or a 64bit system?

On 32bit it might be related to an integer overflow in the ring size (which I'm about to fix).

@tklauser

This comment has been minimized.

Show comment
Hide comment
@tklauser

tklauser Oct 29, 2015

Contributor

Never mind. Sorry, didn't read your message careful enough.

Contributor

tklauser commented Oct 29, 2015

Never mind. Sorry, didn't read your message careful enough.

@borkmann

This comment has been minimized.

Show comment
Hide comment
@borkmann

borkmann Oct 29, 2015

Contributor

Thanks for the report, @igvk! Is this always happening at about 3.7GB or rather randomly after a certain amount of time? In other words, how deterministically reproducible is this bug when using -S 16GiB?

Contributor

borkmann commented Oct 29, 2015

Thanks for the report, @igvk! Is this always happening at about 3.7GB or rather randomly after a certain amount of time? In other words, how deterministically reproducible is this bug when using -S 16GiB?

@igvk

This comment has been minimized.

Show comment
Hide comment
@igvk

igvk Oct 29, 2015

For me, it happened all 3 or 4 times that I tried at almost the same sum of generated file sizes.
It doesn't seem to depend on time, because the traffic was different.
I ran strace on netsniff-ng, and it showed nothing, and all the files were closed.
If you are unable to reproduce it, I may try to do some more testing - please tell me what to check or what to debug.

igvk commented Oct 29, 2015

For me, it happened all 3 or 4 times that I tried at almost the same sum of generated file sizes.
It doesn't seem to depend on time, because the traffic was different.
I ran strace on netsniff-ng, and it showed nothing, and all the files were closed.
If you are unable to reproduce it, I may try to do some more testing - please tell me what to check or what to debug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment