Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Writing to files stops after 3.7GB #150

Open
igvk opened this issue Oct 28, 2015 · 7 comments
Open

Writing to files stops after 3.7GB #150

igvk opened this issue Oct 28, 2015 · 7 comments
Labels

Comments

@igvk
Copy link

@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
Copy link
Contributor

@tklauser 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
Copy link
Author

@igvk igvk commented Oct 28, 2015

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

@tklauser
Copy link
Contributor

@tklauser 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
Copy link
Contributor

@tklauser tklauser commented Oct 29, 2015

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

@borkmann
Copy link
Contributor

@borkmann 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
Copy link
Author

@igvk 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.

@ValZapod
Copy link

@ValZapod ValZapod commented Mar 29, 2020

Such problems are almost always connected to uint64_t.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.