-
Notifications
You must be signed in to change notification settings - Fork 258
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
Feature request in nfqws : add delay option, and multiple copy of rst packet #49
Comments
|
Indeed, naive sleeping is not acceptable. In terms of user experience, I can feel a significant slowdown when retransmission is enabled, perhapse 0.2 second is too long for each packet, especially when every packet in the stream will go through the queue. In contrast, delay of 2ms is enough for the injected packets to go ahead of the original one. I'm not in Russia, and the peak packet drop rate here is crazy even for domestic traffic, so multiple copy of rst will be quite helpful. |
No, not every packet is processed by desync. Only http requests (can be multiple) or TLS clienthello (only single per connection). It adds some delays but not too long. Its not hard to add fake packet retransmission. if you want I'll do it. At the end of desync.c find this code :
and copy-paste it as many times as you want, then recompile |
I made three copies of rstack, and the success rate goes from 90% to 100% on 20 trial. |
OK, i added --dpi-desync-repeats option. It resends every packet generated by nfqws N times |
When I am looking at the tcpdump of the final packets, I noticed that not only the fake packet is send multiple times, but also the original packet. Isn't it very strange? The original packet should be verdict as accept, how come it is also duplicated? FYI, I'm testing on openwrt using POSTROUTING, curl from both openwrt itself or PC, the result of tcpdump looks the same. |
Yes, its my mistake, i already fixed it in last commit |
Thanks for the clarification! |
I dont know how it works. But it has always worked. With AF_INET queue receives both 4 and 6. From docs : This could explanation. But I tested this on centos 6 with 2.6 kernel and it also worked. Dont know why |
I rechecked and confirm it really does not work on older kernels. |
An alternative command line design would be allow multiple modes like this:
Then nfqws sends the corresponding packets according to the order specified. This not only allow for duplicated fake packets, but also a combination of approaches in case a single desync method is not robust enough. What do you think? |
Not all actions are compatible with each other. |
Hi, thanks a lot for this project, it is quite helpful. I have some feature suggestion for nfqws:
Would you mind adding these feature?
The text was updated successfully, but these errors were encountered: