Fake packets loss at multiple parallel requests
Opened this issue · 11 comments
Environment: Windows 7 SP1. ByeDPI v0.13.1+ at least.
Reproduce Steps:
- Run proxy with
ciadpi.exe -i 127.0.0.1 -H ":youtube.com ytimg.com ggpht.com" -s 4 -f -8 --fake-offset 4 -t <your_dpi_ttl>; - Start network capture, e.g. in Wireshark;
- Open YouTube main page: https://www.youtube.com;
- Inspect the capture.
Expected Result: Fake packets are always sent.
Actual Result:
Fake packets are lost at multiple parallel requests and connections are closed:
but according to log they were sent:
new event: fd: 220, evt: EV_ACCEPT, mod_iter: 0
accept: fd=308
accept: fd=304
accept: fd=312
accept: fd=316
new event: fd: 316, evt: EV_REQUEST, mod_iter: 267
new conn: fd=320, addr=64.233.163.198:443
new event: fd: 312, evt: EV_REQUEST, mod_iter: 267
new conn: fd=324, addr=64.233.163.198:443
new event: fd: 304, evt: EV_REQUEST, mod_iter: 267
new conn: fd=328, addr=64.233.163.198:443
new event: fd: 308, evt: EV_REQUEST, mod_iter: 267
new conn: fd=332, addr=64.233.163.198:443
new event: fd: 220, evt: EV_ACCEPT, mod_iter: 0
accept: fd=336
new event: fd: 336, evt: EV_REQUEST, mod_iter: 269
new conn: fd=340, addr=64.233.163.198:443
new event: fd: 320, evt: EV_CONNECT, mod_iter: 268
new event: fd: 316, evt: EV_DESYNC, mod_iter: 267
desync params index: 0
host: yt3.ggpht.com (127)
split: pos=0-4 (4), m: DESYNC_SPLIT
temp file: C:\Users\}!{enR\AppData\Local\Temp\t8397.tmp
split: pos=4-509 (505), m: DESYNC_FAKE
send: pos=509-517
new event: fd: 332, evt: EV_CONNECT, mod_iter: 268
new event: fd: 328, evt: EV_CONNECT, mod_iter: 268
new event: fd: 324, evt: EV_CONNECT, mod_iter: 268
new event: fd: 340, evt: EV_CONNECT, mod_iter: 270
new event: fd: 304, evt: EV_DESYNC, mod_iter: 267
desync params index: 0
host: yt3.ggpht.com (127)
split: pos=0-4 (4), m: DESYNC_SPLIT
temp file: C:\Users\}!{enR\AppData\Local\Temp\t83B7.tmp
split: pos=4-509 (505), m: DESYNC_FAKE
send: pos=509-517
new event: fd: 308, evt: EV_DESYNC, mod_iter: 267
desync params index: 0
host: yt3.ggpht.com (127)
split: pos=0-4 (4), m: DESYNC_SPLIT
temp file: C:\Users\}!{enR\AppData\Local\Temp\t83C7.tmp
split: pos=4-509 (505), m: DESYNC_FAKE
send: pos=509-517
new event: fd: 336, evt: EV_DESYNC, mod_iter: 269
desync params index: 0
host: yt3.ggpht.com (127)
split: pos=0-4 (4), m: DESYNC_SPLIT
temp file: C:\Users\}!{enR\AppData\Local\Temp\t83D8.tmp
split: pos=4-509 (505), m: DESYNC_FAKE
send: pos=509-517
new event: fd: 312, evt: EV_DESYNC, mod_iter: 267
desync params index: 0
host: yt3.ggpht.com (127)
split: pos=0-4 (4), m: DESYNC_SPLIT
temp file: C:\Users\}!{enR\AppData\Local\Temp\t83E9.tmp
split: pos=4-509 (505), m: DESYNC_FAKE
send: pos=509-517
new event: fd: 300, evt: EV_PRE_TUNNEL, mod_iter: 203
new event: fd: 296, evt: EV_TUNNEL, mod_iter: 201
new event: fd: 336, evt: EV_DESYNC, mod_iter: 269
close: fds=336,340, recv: 517,0, rounds: 1,0
new event: fd: 316, evt: EV_DESYNC, mod_iter: 267
close: fds=316,320, recv: 517,0, rounds: 1,0
new event: fd: 312, evt: EV_DESYNC, mod_iter: 267
close: fds=312,324, recv: 517,0, rounds: 1,0
new event: fd: 304, evt: EV_DESYNC, mod_iter: 267
close: fds=304,328, recv: 517,0, rounds: 1,0
new event: fd: 308, evt: EV_DESYNC, mod_iter: 267
close: fds=308,332, recv: 517,0, rounds: 1,0
On YouTube this error doesn't result in any broken images (probably, it retries), but on other sites it does.
Can someone have a look at this, please? Still happens on v0.15. Does this happen for anyone else?
Apart from broken images, this also slows down video preloading.
Ahh
this is because microsoft limits TransmitFile function
only 2 is allowed to run at the same time, others must wait.
https://learn.microsoft.com/zh-cn/windows/win32/api/mswsock/nf-mswsock-transmitfile
you can set registry to fix it.
but... if you have administration, why not use raw socket and change the seq number to use fake and some other more useful desync method?
Can you test the fixes?
Are you sure that the limit is the cause? It says:您确定限制是原因吗？它说：
the third request will wait until one of the previous requests is completed第三个请求将等待，直到前面的请求之一完成
but it's not like fakes are delayed and sent out of order, they are just not sent at all.但这并不是假货被延迟或乱序发送，而是根本没有发送。 Unfortunately, the registry value only works on servers anyway.不幸的是，无论如何，注册表值仅适用于服务器。
though the fake is fake, it is a packet. system will wait when there are 2 transmit.
so, when system is spare, the fake may have been changed to the real.
I do need a way to check whether the fake is sent. in china, the gfw may sban the ip for a while after it rst. so, i prefer not connecting then not sending fake.
If you have admin, you may use raw to modify TCP directly (for example the seq number)
@hufrea Could you make a test build, please?
Now there are two cases:
- original part is sent instead of fake, then [FIN] + [RST] after all parts;
- only first split is sent, then [FIN] + [RST].
0588ecc should fix this. There is still no full guarantee of sending a fake, as in Linux, but it works much more stable. This will also fix the cancellation of sending a fake.
On v0.16.1 it looks like the fakes are always sent, but parallel connections are still getting closed:
