there must be a bug. I get a lot of RSTs when browsing in a netns with a TUN driven by it #10
Closed
planetoryd
started this conversation in
General
Replies: 24 comments 6 replies
-
|
check_pkt_type seems buggy. The last packet should be ACKing the FIN but it's invalidated |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I did a workaround. planetoryd@2dc5516 |
Beta Was this translation helpful? Give feedback.
0 replies
-
I hope the problem is limited only to check_pkt_type because it would be easy to fix. Could you please provide a pcap file and mention the OS that you use? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
heres the cap of with dbg!s https://github.com/planetoryd/misc/blob/master/ipstack_logs.md the workarounded version https://github.com/planetoryd/misc/blob/master/ipstack_workaround.pcapng has RST+ACKs, which should be RSTing the connection and immediate restablishment (i guess) . on planetoryd@2dc5516 If you see large captures it's me using it as some kind of daily driver. therefore just ask if you want any data, or testing. and I use geph.io 's proxy as upstream, which is a tor-bridge like proxy service (better than tor bridge in fact) It looks quite terrifying to have that much unverified logic. perhaps you can try https://github.com/verus-lang/verus but idk how long it will take to become usable. some nice formal verification (unlikely) |
Beta Was this translation helpful? Give feedback.
0 replies
-
Fortunately, the logic is almost correct. There is only one minor issue that should not affect the communications, but it is indeed a bug! The IP stack deallocates the TCP stream after receiving the last FIN/ACK, so the final ACK goes unrecognized, which results in a RST being returned. In the correct implementation, it should handle the last ACK as well. However, in both cases—whether it returns an RST (the faulty behavior) or accepts the ACK without returning an RST — the connection will be closed. Thanks for the report, I'll fix it soon. Did you see any other unexpected rst except the last ack for the first one? I still did not checked your modifications on planetoryd@2dc5516 . |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@planetoryd: Could you please verify that if #7 fixes the issue? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
It's not fixed. @SajjadPourali You can test |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Yeah, the following RST got removed, when I did the curl again. I open my browser, mozilla connects something. It constantly times out, RSTs the connections and reconnect immediately. https://github.com/planetoryd/misc/blob/master/timeout.pcapng |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Beta Was this translation helpful? Give feedback.
0 replies
-
The timeout issue is manageable because I have hard-coded a 5-second timeout (which I intend to make configurable #4). Firefox keeps the connections open for reuse, and in some cases, this can result in them remaining open for more than 30 seconds. 
|
Beta Was this translation helpful? Give feedback.
0 replies
-
I'll set up a Linux machine over the weekend to test tun2socks5. In the meantime, if you could attach a .pcap file, I would be able to check it manually beforehand. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I just changed the API to use a custom timeout and increased the TCP and UDP timeouts to 60 and 30, respectively, in the main branch. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I used iperf3 on my personal machine through narrowlink's tunnel, which utilizes ipstack. 
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
This time the apps actively tried to RST the connection (quite frequently). I was running Perhaps there is some issue with protocol compliance ? |
Beta Was this translation helpful? Give feedback.
0 replies
-
I can't guarantee that the Ipstack is fully compliant, but I am doing my best to implement it at least based on RFC 793. However, RFC 793 is missing some features (for example, it lacks TCP keep-alive functionality) and has some weaknesses. Therefore, the newer version of TCP is based on RFC 9293, which is more comprehensive and addresses the shortcomings of RFC 793. TCP keep-alive has not been implemented yet #8 (it is also not defined in RFC 793). The screenshot you mentioned shows an attempt to send a TCP keep-alive packet, and since it does not receive an ACK after several attempts, it resets the connection. Are you sure that the tool you're using to forward connections from the Ipstack is functioning properly? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
(image shows direct connection to socks5 proxy) It should be the keep-alive problem |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Well, it looks we are close to fix the fundamental issues. |
Beta Was this translation helpful? Give feedback.
0 replies
-
And from my experience the feel is indeed worse that direct browser connection to socks5. |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
maybe we should add a pcap context dump feature. |
Beta Was this translation helpful? Give feedback.
-
|
It is expected to have a relatively poor experience when comparing Tun to Socks; however, the difference should not be too much. There are at least two main reasons why you might feel that Socks is faster:
Here is a shallow comparison that I did using narrowlink: TUN Socks Please note that narrowlink also works in China ;-) |
Beta Was this translation helpful? Give feedback.
-
|
This is my test result. From the test data, we can see that the general test is no problem, even 8 parallel tests are no problem. But if you perform reverse testing, a single test is no problem, but if you perform 8 parallel tests, something will go wrong in the middle. Please look carefully at my test data.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Another testing data. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
And here: |
Beta Was this translation helpful? Give feedback.
-
|
My internet is not stable, however I can not reproduce the all zero case. Could you please run |
Beta Was this translation helpful? Give feedback.
1 reply
-
I observed some undesired-looking behavior in Linux, but not as severe as in your case. I need to investigate. 
Could you also provide a pcap file to compare what I received to your result? |
Beta Was this translation helpful? Give feedback.
-
|
Here I find another test tool |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Beta Was this translation helpful? Give feedback.
2 replies
-
|
Beta Was this translation helpful? Give feedback.
-
localhost for control |
Beta Was this translation helpful? Give feedback.
-
|
@ssrlive: The pcap file that you sent is fine, and I cannot find any protocol issues! I also tried to run rperf by myself and noticed that it does not succeed in any case, even when I use a direct connection without a tunnel. Results without ipstack/tun interface! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm trying to solve it. A whole TCP stack written by hand. Wcgw.
Beta Was this translation helpful? Give feedback.
All reactions