ROG Ally to PC is slow

[Auscobe]

I've allowed in my firewall, I've checked both speeds on speedtest.net (to both systems getting the same speed), I've used other programs that can go at normal speeds (i.e Tailscale, WinSCP), and I can't get ACP to go from Ally to PC as fast as PC to Ally. I don't know what I could provide other than perhaps a dxdiag log for further information?

My PC can send to my Ally at a sustained 116MB/s or so (both over ethernet), but from my Ally to PC, it can't go nearly as fast. I'm talking 30MB/s over wifi, 12MB/s over ethernet not through dock, and <1MB/s over ethernet through dock.

Thanks in advance, this is an awesome tool.

[Contextualist]

Thanks for the report!

If Tailscale works for you, you might want to set it to the first transport strategy for acp in the config.

If you want to dig deeper, the first thing to check is probably running acp with the -debug option to print out the addresses and ports of the connection. Check if the corresponding network interface is what you expect.

[Auscobe]

Tailscale does work both ways, but I strongly prefer acp as it (at least feels faster) and doesn't have the files put into an archive in the background, as my Ally won't have space to deal with that. Otherwise I have to use Taildrop to send 15 files at a time.

Looking at the debug info, it appears it tries tailscale first despite it being second in my strategy config on both devices. Following this, one device will quickly report that the remote host "forcibly closed" the connection, while the other will be left hanging for a while. I'm only almost techie enough to know more beyond that.

It starts with "Listen at tailscale addr [ip] filed: listen tcp: address [ip]
taildrop is available"

[Contextualist]

I see, let's take a closer look at the default strategy then.

it appears it tries tailscale first despite it being second in my strategy config on both devices ... It starts with "Listen at tailscale addr [ip] filed: listen tcp: address [ip] taildrop is available"

This is expected. It is actually doing feature detection for the Tailscale strategy ahead of time, because both ends need a complete list of working strategies before deciding which one to try first. And no connection attempt is made during the feature detection stage.

Following this, one device will quickly report that the remote host "forcibly closed" the connection, while the other will be left hanging for a while.

This looks like that one end is unable to talk to the rendezvous service. Could you provide output with -debug, with sensitive information (chanName and all IP addresses) replaced?

Example

sender:

tailscale IP address is available
taildrop is available
send {"priAddr":"*.*.*.150:57963","chanName":"***","strategy":["tcp_punch","tailscale"],"nPlan":1,"tsAddr":"*.*.*.96:57954","tsCap":3}
waiting for peer...
recv {"peerAddrs":[{"pubAddr":"*.*.*.200:41057","priAddr":"*.*.*.200:41057"}],"peerNPlan":1,"strategy":["tcp_punch","tailscale"],"tsAddr":"*.*.*.22","tsCap":1}
strategy: a=[tcp_punch tailscale], b=[tcp_punch tailscale], consensus=[tcp_punch tailscale]
rendezvous with *.*.*.200:41057
connected *.*.*.150:57963->*.*.*.200:41057
sending...

receiver:

tailscale network interface search failed, found addrs []: <nil>
taildrop is available
send {"priAddr":"*.*.*.200:41057","chanName":"***","strategy":["tcp_punch","tailscale"],"nPlan":1,"tsAddr":"*.*.*.22","tsCap":1}
waiting for peer...
recv {"peerAddrs":[{"pubAddr":"*.*.*.248:58373","priAddr":"*.*.*.150:57963"}],"peerNPlan":1,"strategy":["tcp_punch","tailscale"],"tsAddr":"*.*.*.96:57954","tsCap":3}
strategy: a=[tcp_punch tailscale], b=[tcp_punch tailscale], consensus=[tcp_punch tailscale]
rendezvous with *.*.*.150:57963 | *.*.*.248:58373
accepted *.*.*.200:41057
receiving...

In the mean time, try the following command on the first machine:

curl -sI https://acp.deno.dev/get -w '%{local_ip}\n' 

If succeed (e.g. you see HTTP/2 200), this will print the local IP address you should be using when talking to the rendezvous service, check if it matches one of the IP address you see in the debug output.

[Auscobe]

The curl command provided had the expected result on my PC (alongside other information), but my Ally simply outputted an IPv6 address on its own. Seems to me something on my Ally isn't configured correctly like on my PC? Also, I don't think the program is expecting IPv6 addresses per this log (this was before I physically expanded my CMD to actually get everything to print, it'll say too many colons in address):

acp -debug
listen at tailscale addr * failed: listen tcp: address *
taildrop is available
send {"priAddr":":51789","chanName":"/","strategy":["tcp_punch","tailscale"],"nPlan":1,"tsAddr":"*
waiting for peer...
recv {"peerAddrs":[{"pubAddr":":59114","priAddr":":59114"}],"peerNPlan":1,"strategy":["tcp_punch"
strategy: a=[tcp_punch tailscale], b=[tcp_punch tailscale], consensus=[tcp_punch tailscale]
rendezvous with *:59114 | *:59114
connected :51789->:59114
receiving...
read tcp :51789->:59114: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

I've just tried disabling IPv6 on my Ally's ethernet as it's not enabled on my PC either, but that apparently isn't the problem.

[Contextualist]

receiving...
read tcp :51789->:59114: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Hmm, so acp actually established the connection successfully, but was unable to receive data. After Googling I only had a sense that this is Windows-specific. I'm sorry that I have no idea why this is happening.

listen at tailscale addr * failed: listen tcp: address *

This is another unexpected part. During feature detection for Tailscale, acp was unable to listen at the Tailscale IP it found, and thus couldn't use the Tailnet. Not sure what caused this, but that's why it had to fallback to Taildrop for the Tailscale strategy.

I don't think the program is expecting IPv6 addresses

Right, acp uses IPv4 by default. You can force it to use IPv6 by enabling it in the config on both side. Although I don't think this solves the problem.

Overall, it seems that there exists certain network restrictions for programs running on ROG Ally. Sorry that I don't have access to a similar device that I can debug on. I'll keep this issue open and hope someone or I myself can come across relevant information in the future.🥲

[Auscobe]

No worries. I'll also update if possible.

How do I enable IPv6 in the config? I don't see anything around the repo about it.

[Contextualist]

You can turn on IPv6 by adding "ipv6": true in the config file. The location of config file and the complete list of options can be found in the advanced document.