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

Intermittent 10s Delay in Connection Setup Despite Full Bandwidth #3570

Open
hubix2000 opened this issue Oct 4, 2024 · 13 comments
Open

Intermittent 10s Delay in Connection Setup Despite Full Bandwidth #3570

hubix2000 opened this issue Oct 4, 2024 · 13 comments

Comments

@hubix2000
Copy link

Expected Behavior

We expect connections to establish quickly without any delay, even when there are many simultaneous sessions. The connection setup time should be near-instantaneous and reliable.

Current Behavior

Sometimes, the connection setup takes exactly 10 seconds, and occasionally, no session is established at all. This delay seems to happen more often when there are many simultaneous sessions. Despite this, speed tests consistently show full bandwidth. We have checked the logs in Status -> System log but couldn't find a clear explanation for the behavior.

Specifications

  • OpenMPTCProuter version: 0.61rc2-6.6
  • OpenMPTCProuter VPS version: 0.1031-test 6.6.36-x64v4-xanmod1
  • OpenMPTCProuter VPS provider: Azure
  • OpenMPTCProuter platform: x86_64
@Ysurac
Copy link
Owner

Ysurac commented Oct 4, 2024

Did you check if it's a DNS issue or same when using IP ?
Can you give me the result of uci show unbound.ub_main and uci -q get openmptcprouter.settings.disable_ipv6 ?

@hubix2000
Copy link
Author

Hi Ysurac.
It's not an dns issue. The 10s delay is always before dns resolution.

It's happening time by time. But the result is, that it feels very slow.
We have a lot of users using the connection.

root@OpenMPTCProuter:~# uci show unbound.ub_main
unbound.ub_main=unbound
unbound.ub_main.dhcp_link='dnsmasq'
unbound.ub_main.dns64='0'
unbound.ub_main.domain='lan'
unbound.ub_main.edns_size='1232'
unbound.ub_main.extended_stats='0'
unbound.ub_main.hide_binddata='1'
unbound.ub_main.interface_auto='0'
unbound.ub_main.listen_port='5353'
unbound.ub_main.localservice='1'
unbound.ub_main.manual_conf='0'
unbound.ub_main.num_threads='1'
unbound.ub_main.protocol='ip4_only'
unbound.ub_main.rate_limit='0'
unbound.ub_main.rebind_localhost='0'
unbound.ub_main.rebind_protection='1'
unbound.ub_main.recursion='aggressive'
unbound.ub_main.resource='default'
unbound.ub_main.root_age='9'
unbound.ub_main.ttl_min='120'
unbound.ub_main.ttl_neg_max='1000'
unbound.ub_main.unbound_control='0'
unbound.ub_main.validator='1'
unbound.ub_main.validator_ntp='1'
unbound.ub_main.verbosity='1'
unbound.ub_main.iface_trig='lan' 'wan'
unbound.ub_main.enabled='1'
unbound.ub_main.interface='loopback'

root@OpenMPTCProuter:~# uci -q get openmptcprouter.settings.disable_ipv6
1

@hubix2000
Copy link
Author

Screenshot 2024-10-04 110010

Attached you'll find a screenshot with typically timings after some time. Just a restart helps. :-(

@Ysurac
Copy link
Owner

Ysurac commented Oct 4, 2024

In status->overview, how many Active Connections do you have ?
What is the proxy used ? (default is now Shadowsocks-Rust)

@hubix2000
Copy link
Author

We use Shadowsocks-Rust. We have 9090 / 131072 (6%) active connections.

@Ysurac
Copy link
Owner

Ysurac commented Oct 4, 2024

When you have an issue, can you check on the VPS via journalctl -u shadowsocks-go what is the log for the website IP you want to reach ?

@hubix2000
Copy link
Author

I just attached the log file.
vpsadmin@CoreVision-VPS02 ~.txt

@hubix2000
Copy link
Author

Hi Ysurac,
did you forget to check my logs?

@Ysurac
Copy link
Owner

Ysurac commented Oct 7, 2024

There is many "Failed to complete handshake with client".
What are the connections type ? FTTH, mobile, sat,... ?
What is the result of ss --summary on the VPS ?

@hubix2000
Copy link
Author

it's dsl + starlink.

@Ysurac
Copy link
Owner

Ysurac commented Oct 7, 2024

What is the connection set as master ? In your case this should be DSL I think.

@hubix2000
Copy link
Author

It is.

@hubix2000
Copy link
Author

Hi. Somehow the issue can be related to shadowsocks-rust timeout handling. This 10s can be related to SYN.
I added the keap_alive option to the shadowsocks-rust config and the behavior changed a bit. Ist's not fixed yet, but better.

Any idea?

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

No branches or pull requests

2 participants