Use ipv4 and ipv6 to connect to speedtest servers

[MEschenbacher]

Hey,

is there a way to use both ipv4 and ipv6 to connect to the speedtest servers?

[juev]

@MEschenbacher

Hello, what's the point of this change?

[MEschenbacher]

Currently, speedtest-go uses any (but only one of the two) protocol (v6 or v4) to establish a connection to the speedtest server and there is no option or flag to use a specific internet protocol when performing the actual speedtest.
For dual stack internet connections, a distinction between both might be relevant to explicitly test either v6 or v4.

[juev]

• SpeedTest, as I understand do not provided api for selecting servers on ipv6 or ipv4.
• net/http package use for http requests. It not provided interface for tcp protocol.
• http it's high level protocol on tcp. It not necessery whats protocol you use on low level

Maybe I wrong?

[MEschenbacher]

* SpeedTest, as I understand do not provided api for selecting servers on ipv6 or ipv4.

Too bad :/ As I understand it, the speedtest api returns a list of hostnames. These hostnames could resolve to v4 and/or v6.

* [net/http](https://pkg.go.dev/net/http) package use for http requests. It not provided interface for tcp protocol.

http.Client may be passed a http.Transport which in turn may be passed a DialerContext and ultimately a Dialer which controls the network via https://pkg.go.dev/net#Dial.

* http it's high level protocol on tcp. It not necessery whats protocol you use on low level

I understand that I really don't have to care about the underlying protocol, but in the case of performing speed tests to explicitly v4 targets and explicitly v6 targets to see, if there is any difference in speed when using different protocols.

[juev]

Ok, we can filter server list by ipv4 or ipv6 adressess. We can change Transport. But what point for this changes?

[MEschenbacher]

Measuring speed of v4 and v6 individually

[juev]

It doesn't matter in my opinion.

ipv6 and ipv4 difference only on server names. You can change server name, or his address. But this not change network speed to this server.

[MEschenbacher]

When performing a speed test, you are not only measuring the performance of the server endpoint (speedtest server) itself but also (and I believe more importantly) the components involved during the whole path which your tcp stream's packets take, namely

• Your local endpoint (operating system, network stack and network card)
• Your local network (wifi or cable, switches)
• Your local NAT translation (+ possible stateful firewalling)
• The network hardware and software of your ISP
• The transit networks
• Firewalling in transit and at the destination

Since IPv4 and IPv6 are two different layer3 protocols, the routing may differ significantly and every single on of those stations may handle them differently and cause a different outcome.

[crbertoldo]

Not sure if relevant, but maybe the following can teach us something:

With options single-request-reopen in /etc/resolv.conf:

Ookla speedtest CLI: ~3.5 ms
speedtest-go:  0, 1, or 5000 ms (the last one more frequently).

Without options single-request-reopen in /etc/resolv.conf:

 Ookla speedtest CLI: ~3.5 ms
 speedtest-go: latency: ~2506 ms

We came across single-request-reopen via https://aarvik.dk/disable-ipv6/ due to an issue related to the internal name resolution by tools like wget and curl. OS: #71~20.04.1-Ubuntu.

Tested with 1.1.5, 1.3.0, and 1.3.1.

[crbertoldo]

@showwin @r3inbowari

[r3inbowari]

Not sure if relevant, but maybe the following can teach us something:

With options single-request-reopen in /etc/resolv.conf:

Ookla speedtest CLI: ~3.5 ms
speedtest-go:  0, 1, or 5000 ms (the last one more frequently).

Without options single-request-reopen in /etc/resolv.conf:

 Ookla speedtest CLI: ~3.5 ms
 speedtest-go: latency: ~2506 ms

We came across single-request-reopen via https://aarvik.dk/disable-ipv6/ due to an issue related to the internal name resolution by tools like wget and curl. OS: #71~20.04.1-Ubuntu.

Tested with 1.1.5, 1.3.0, and 1.3.1.

@crbertoldo Yes, I think it's related, maybe using a custom DNS resolver can solve this problem. like this

[BillAnt1]

While I was looking for a way to test IPv4 and IPv6 separately, I came across an interesting url parameter in the Ookla speed test server (in addition to speedtest.net, they also run the speedtestcustom.com server)

To test IPv4 exclusively using the "ipv4-only" parameter in the middle of the url:
http://ookla.ipv4-only.speedtestcustom.com

To test IPv6 if it's available on the connection using the "dualstack" parameter in the middle of the url:
http://ookla.dualstack.speedtestcustom.com

Interestingly, when testing it on a mobile phone with some carriers like Tmobile, the two test url's will sometimes display different geographic locations/states on the same connection due to different servers, therefore the ping times may vary depending on IPv4 or IPv6 tests.

[r3inbowari]

I have dualstack network, but there seems to be no difference on my computer.
http://ookla.dualstack.speedtestcustom.com/api/js/servers?engine=js&limit=10
http://ookla.ipv4-only.speedtestcustom.com/api/js/servers?engine=js&limit=10

[BillAnt1]

I have dualstack network, but there seems to be no difference on my computer. http://ookla.dualstack.speedtestcustom.com/api/js/servers?engine=js&limit=10 http://ookla.ipv4-only.speedtestcustom.com/api/js/servers?engine=js&limit=10

As I mentioned, it pulls up different servers on some mobile carriers, but not all.
When I connect my Windows laptop to my Tmobile hotspot, on IPv4 it pull servers from the DC/VA area, while on IPv6 pulls from KS area.
One way to check if your internet provider connects to different geographic servers depending on IPv4 and v6, is by disabling the IPv6 interface in Networking > Adapter > WAN or WiFi you're using > Properties > uncheck the IPv6
Run your test and take note of the servers, then re-enable the IPv6 adapter and disable the IPv4 adapter, and run the test again. Compare the two lists to see if you're getting connected to different servers. Make sure to re-enable both adapter after done with testing, ;)

Does the line below in /etc/resolv.conf help with IPv4v6 DNS conflicts?
options single-request-reopen

Here's a puzzler....
I have connected an iPhone (also tried an Android) to my Windows7 and 10 laptops, turned on the hotspot and tried to modify the TTL to bypass the hotspot limit via the following cmd lines.

netsh int ipv4 set interface iPhone currenthoplimit=65
netsh int ipv6 set interface iPhone currenthoplimit=65

The IPv4 TTL=65 sticks fine even between reboots, but the IPv6 TTL reverts back to 255 within about a minute for some reason even without rebooting. So I tried the following persistent commands too, but no dice, IPv6 reverts back to 255.

netsh int ipv4 set interface iPhone currenthoplimit=65 store=persistent
netsh int ipv6 set interface iPhone currenthoplimit=65 store=persistent

Any idea why, and any tips I should try?

[r3inbowari]

I try to turn off ipv4 in the adapter. and then visit http://ookla.dualstack.speedtestcustom.com/api/js/servers?engine=js&limit=10
It successfully got a list of servers, but unfortunately, many of the servers in this list do not support ipv6, because I can't get their ipv6 addresses from the DNS server. We can draw a conclusion from it: dualstack api can't filter ipv6 server.

In addition, speedtest.com already supports ipv6. Because the traffic of speedtest.net is proxied by cloudflare (even supports quic).

[r3inbowari]

but the IPv6 TTL reverts back to 255 within about a minute for some reason even without rebooting.

Maybe your ipv6 can't connect, the system automatically set ttl to 255, in order to sends it at a longer distance.

[r3inbowari]

Currently, speedtest-go can test speed through ipv6, but the server must have an ipv6 address.
Take the USA Frontier Server(ISP) as an example.
check losangeles.ca.speedtest.frontier.com dns lookup here.
We enter this command on a dualstack computer:

.\speedtest-go.exe --source=[your ipv6 interface] --force-http-ping --custom-url=http://losangeles.ca.speedtest.frontier.com:8080/upload.php

Result:

It can be found that the data is sent through ipv6.

The problem that is still unsolved is to determine whether a specific server supports ipv6.

[BillAnt1]

The problem that is still unsolved is to determine whether a specific server supports ipv6.

According to some docs, the "dualstack" ookla server reverts to IPv6 if your connection supports it, otherwise falls back to IPv4... well, at least that's their intent. heh
Based on your examples IPv6 servers are problematic..... it's a dual stack clusterfuq till all servers are fully transitioned to IPv6 only. lol

but the IPv6 TTL reverts back to 255 within about a minute for some reason even without rebooting.
Maybe your ipv6 can't connect, the system automatically set ttl to 255, in order to sends it at a longer distance.

When I set the IPv4 TTL to 65 it sticks fine even between reboots.
But when I set IPv6 TTL to 65 (or any other value) it reverts back to 255 within about a minute.
You have suggested that perhaps it's due to Windows setting it back high for long distance hops, but it reverts back even if I disconnect ethernet and WiFi before settings the TTL value and don't reconnect to the web..... I'm just puzzled. Interestingly when I check the "Persistent" settings it's still showing 65 , but the "Active" one reverts back. Thinking that perhaps it's just a tethered phone, I tried setting it on my ethernet interface but same thing,

netsh int ipv6 show interface IPhone store=active - shows 255
netsh int ipv6 show interface IPhone store=persistent - shows 65

While I use TTL to bypassing mobile hotspot limits, I've noticed that setting it to lower than 40 can improve ping times probably due to servers being forced to find shorter routes on lower TTL values. ymmv

[r3inbowari]

According to some docs, the "dualstack" ookla server reverts to IPv6 if your connection supports it, otherwise falls back to IPv4... well, at least that's their intent. heh

haha, I got it

[r3inbowari]

You have suggested that perhaps it's due to Windows setting it high for long distance, but it reverts back even if I disconnect ethernet and WiFi before settings the TTL value and don't reconnect to the web..... I'm just puzzled. Interestingly when I check the "Persistent" settings it's still showing 65 , but the "Active" one reverts back. Thinking that perhaps it's just a tethered phone, I tried setting it on my ethernet interface but same thing,

@BillAnt1 Thank you. Did you turn off auto metric?

[BillAnt1]

You have suggested that perhaps it's due to Windows setting it high for long distance, but it reverts back even if I disconnect ethernet and WiFi before settings the TTL value and don't reconnect to the web..... I'm just puzzled. Interestingly when I check the "Persistent" settings it's still showing 65 , but the "Active" one reverts back. Thinking that perhaps it's just a tethered phone, I tried setting it on my ethernet interface but same thing,

@BillAnt1 Thank you. Did you turn off auto metric?

I will give that a try later on tonight and report back to you.
I can do it in the GUI interface > Properties > Advanced > Automatic Metric > uncheck the box but I need to enter a value
What value should I try (1-99)? Do you know a command line instead of GUI (not that it matters much)?
Not sure how that would prevent the IPv6 TTL from reverting back to 255, but we'll see.
This issue is really bugging me, I need to find a solution. heh

[BillAnt1]

You have suggested that perhaps it's due to Windows setting it high for long distance, but it reverts back even if I disconnect ethernet and WiFi before settings the TTL value and don't reconnect to the web..... I'm just puzzled. Interestingly when I check the "Persistent" settings it's still showing 65 , but the "Active" one reverts back. Thinking that perhaps it's just a tethered phone, I tried setting it on my ethernet interface but same thing,

@BillAnt1 Thank you. Did you turn off auto metric?

I have turned off Metrics on both IPv4 and v6 protocols in the interface, entered the value 10 for v4, 20 for v6, set the TTL to 65 for both, but after a few minutes v6 reverted back to first 0 then 255, v4 seems to be persistent on 65. Then If flipped the Metrics around 10/20 to 20/10 for v4/v6 set the TTL to 65 for both, but v6 keeps reverting back. :( Any other suggestions?

netsh int ipv6 show interface IPhone store=active - shows 0 then 255 after a few minutes of setting the TTL to 65
netsh int ipv6 show interface IPhone store=persistent - shows 65 which stays persistent but it's not active

But the IPv4 TTL value stick just fine.
netsh int ipv4 show interface IPhone store=active - shows 65
netsh int ipv4 show interface IPhone store=persistent - shows 65

[r3inbowari]

Hi, @BillAnt1, I checked Microsoft's documentation. Changing TTL values is typically done for network probes or when multicasting.

It seems that on Neighbor Discovery the TTL will set to 255.

I think you can try turning off Neighbor Discovery.

[BillAnt1]

Thanks for the find, I will have to investigate that. :)
In my OpenWRT Linux router the following firewall/routing-table commands sets the IPv6 TTL via "HL --hl-set" persistently unlike in Windows.

ip6tables -t mangle -I PREROUTING -i iPhone0 -j HL --hl-set 65
ip6tables -t mangle -I POSTROUTING -o iPhone0 -j HL --hl-set 65

And the IPv4 TTL is set via "TTL --ttl-set"
iptables -t mangle -I PREROUTING -i iPhone0 -j TTL --ttl-set 65
iptables -t mangle -I POSTROUTING -o iPhone0 -j TTL --ttl-set 65

You could play around with lower TTL values than 40 to try to force less hops during speed tests. It's best to disable the IPv6 interface in Windows since now we know setting it is not persistent till a solution is found.
On some speed test servers I was able to go as low as 15, but lower than that tends to cause a hop failure somewhere along the path.

[x2q]

I suggest a command line switch with -4 for IPv4 only and -6 for IPv6 only like iproute2

[void-fm]

% host speedtest02a.web.zen.net.uk
speedtest02a.web.zen.net.uk has address 51.148.82.21
speedtest02a.web.zen.net.uk has IPv6 address 2a02:8010:9:1::2

% speedtest-go --custom-url=http://2a02\:8010\:9\:1\:\:2:8080/speedtest/upload.php

speedtest-go v1.7.9 (git-dev) @showwin

⠋ Retrieving User Information
✓ Skip: Using Custom Server

✓ Test Server: [Custom] 2a02:8010:9:1::2:8080
✓ Latency: 7.268992ms Jitter: 130.26µs Min: 7.071937ms Max: 7.456399ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 183.54 Mbps (Used: 231.71MB) (Latency: 18ms Jitter: 16ms Min: 6ms Max: 66ms)
✓ Upload: 105.04 Mbps (Used: 136.51MB) (Latency: 380ms Jitter: 557ms Min: 5ms Max: 1507ms)
✓ Packet Loss: N/A

% speedtest-go --custom-url=http://51.148.82.21:8080/speedtest/upload.php

speedtest-go v1.7.9 (git-dev) @showwin

⠋ Retrieving User Information
✓ Skip: Using Custom Server

✓ Test Server: [Custom] 51.148.82.21:8080
✓ Latency: 7.21547ms Jitter: 461.644µs Min: 6.330698ms Max: 7.959385ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 895.12 Mbps (Used: 1134.89MB) (Latency: 156ms Jitter: 166ms Min: 29ms Max: 620ms)
✓ Upload: 105.36 Mbps (Used: 140.76MB) (Latency: 727ms Jitter: 1028ms Min: 6ms Max: 2496ms)
✓ Packet Loss: 29.82% (Sent: 233/Dup: 0/Max: 331)

[bobobo1618]

Using @void-fm's method, I'm seeing a substantial difference in IPv6 vs. IPv4. Both these Speedtest servers are hosted on my ISPs network and in both cases, IPv6 outperforms IPv4. My router in this case is a 1U rackmount server running VPP to handle NAT and routing.

Server 1, IPv4:

✓ Latency: 1.737886ms Jitter: 433.596µs Min: 1.371202ms Max: 2.944868ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 21218.83 Mbps (Used: 26700.15MB) (Latency: 4ms Jitter: 2ms Min: 2ms Max: 9ms)
✓ Upload: 17217.55 Mbps (Used: 21429.29MB) (Latency: 3ms Jitter: 2ms Min: 1ms Max: 10ms)
✓ Packet Loss: 0.00% (Sent: 268/Dup: 0/Max: 267)

Server 1, IPv6:

✓ Latency: 1.526358ms Jitter: 93.091µs Min: 1.426023ms Max: 1.702024ms
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 21731.62 Mbps (Used: 26890.73MB) (Latency: 6ms Jitter: 4ms Min: 3ms Max: 18ms)
✓ Upload: 18819.12 Mbps (Used: 23691.81MB) (Latency: 3ms Jitter: 1ms Min: 1ms Max: 6ms)
✓ Packet Loss: 0.37% (Sent: 267/Dup: 0/Max: 267)

Server 2, IPv4:

✓ Latency: 524.778µs Jitter: 35.478µs Min: 463.225µs Max: 578.075µs
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 21536.53 Mbps (Used: 27527.30MB) (Latency: 3ms Jitter: 1ms Min: 1ms Max: 5ms)
✓ Upload: 20265.01 Mbps (Used: 25095.53MB) (Latency: 5ms Jitter: 5ms Min: 1ms Max: 19ms)
✓ Packet Loss: 0.75% (Sent: 266/Dup: 0/Max: 267)

Server 2, IPv6:

✓ Latency: 539.872µs Jitter: 51.496µs Min: 463.851µs Max: 617.466µs
✓ Packet Loss Analyzer: Running in background (<= 30 Secs)
✓ Download: 22465.26 Mbps (Used: 28129.11MB) (Latency: 4ms Jitter: 4ms Min: 1ms Max: 17ms)
✓ Upload: 20432.65 Mbps (Used: 26440.96MB) (Latency: 3ms Jitter: 3ms Min: 0ms Max: 13ms)
✓ Packet Loss: 0.37% (Sent: 267/Dup: 0/Max: 267)

[r3inbowari]

I suggest a command line switch with -4 for IPv4 only and -6 for IPv6 only like iproute2

What should we do if the target server unsupported IPV6?

[online-stuff]

What should we do if the target server unsupported IPV6?

Fail and display an error about unable to connect, doesn't exist, anything really.