Ubports installer fails to download files on IPv6-enabled internet connection.

Dave

Hi,

running the ubports installer on saturday I had stochastic download errors ("ECONNRESET") that made it impossible to finish installation, until I disabled my IPv6 internet support alltogether.

Right now I can reproduce the problem, a significant percentage of SSL connection attempts die after the TLS client hello due to the server sending a RST packet.

https_proxy= wget https://system-image.ubports.com//20.04/arm64/android9plus/stable/mimameid/version-1.tar.xz.asc
--2023-07-11 09:31:51--  https://system-image.ubports.com//20.04/arm64/android9plus/stable/mimameid/version-1.tar.xz.asc
Resolving system-image.ubports.com (system-image.ubports.com)... 2606:4700:3030::6815:61, 2606:4700:3033::ac43:96d2, 172.67.150.210, ...
Connecting to system-image.ubports.com (system-image.ubports.com)|2606:4700:3030::6815:61|:443... connected.
GnuTLS: Error in the pull function.
Unable to establish SSL connection.

This is the corresponding tcpdump:

$ tcpdump -r brokenip6-2.dump 
reading from file brokenip6-2.dump, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144
09:31:51.904786 IP6 mosquito-public-ip.40400 > 2606:4700:3030::6815:61.https: Flags [S], seq 1137994465, win 64440, options [mss 1432,sackOK,TS val 1525877974 ecr 0,nop,wscale 7], length 0
09:31:51.924352 IP6 2606:4700:3030::6815:61.https > mosquito-public-ip.40400: Flags [S.], seq 346910756, ack 1137994466, win 64704, options [mss 1360,sackOK,TS val 1056910065 ecr 1525877974,nop,wscale 13], length 0
09:31:51.924464 IP6 mosquito-public-ip.40400 > 2606:4700:3030::6815:61.https: Flags [.], ack 1, win 504, options [nop,nop,TS val 1525877994 ecr 1056910065], length 0
09:31:51.925039 IP6 mosquito-public-ip.40400 > 2606:4700:3030::6815:61.https: Flags [P.], seq 1:518, ack 1, win 504, options [nop,nop,TS val 1525877995 ecr 1056910065], length 517
09:31:51.945671 IP6 2606:4700:3030::6815:61.https > mosquito-public-ip.40400: Flags [R], seq 346910757, win 0, length 0

This is running on a Devuan-Linux server connected via DSL directly on a PPPoE modem. So no middle-boxes (NAT etc.) involved (not that I'd expect any NAT to happen on IPv6).

Though this could still be my internet provider doing shenanigans.

Can you collect packet captures on your side, so we can compare where those RST packets are injected?

Note also, that forums.ubports.com is currently broken when running via a IPv6 connection. Maybe your browser's Happy Eyeballs implementation hides the problem from you, but with a HTTPS proxy currently any connection attempts time out for me.

cheers,

Dave

Dave

Just to reiterate, this is a stochastic problem. The majority of SSL connection attempts just work. For reference, here is the wget output and a (truncated) tcpdump for the case where it happens to work:

$ https_proxy= wget https://system-image.ubports.com//20.04/arm64/android9plus/stable/mimameid/version-1.tar.xz.asc
--2023-07-11 09:30:56--  https://system-image.ubports.com//20.04/arm64/android9plus/stable/mimameid/version-1.tar.xz.asc
Resolving system-image.ubports.com (system-image.ubports.com)... 2606:4700:3033::ac43:96d2, 2606:4700:3030::6815:61, 104.21.0.97, ...
Connecting to system-image.ubports.com (system-image.ubports.com)|2606:4700:3033::ac43:96d2|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘version-1.tar.xz.asc.10’

version-1.tar.xz.as     [ <=>                ]     488  --.-KB/s    in 0s      

2023-07-11 09:30:56 (19.1 MB/s) - ‘version-1.tar.xz.asc.10’ saved [488]

 $ tcpdump -r workingip6-2.dump
reading from file workingip6-2.dump, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144
09:30:56.330881 IP6 mosquito-public-ip.33520 > 2606:4700:3033::ac43:96d2.https: Flags [S], seq 2471135345, win 64440, options [mss 1432,sackOK,TS val 4074644192 ecr 0,nop,wscale 7], length 0
09:30:56.353850 IP6 2606:4700:3033::ac43:96d2.https > mosquito-public-ip.33520: Flags [S.], seq 3615166120, ack 2471135346, win 64704, options [mss 1360,sackOK,TS val 1553849798 ecr 4074644192,nop,wscale 13], length 0
09:30:56.354269 IP6 mosquito-public-ip.33520 > 2606:4700:3033::ac43:96d2.https: Flags [.], ack 1, win 504, options [nop,nop,TS val 4074644215 ecr 1553849798], length 0
09:30:56.356973 IP6 mosquito-public-ip.33520 > 2606:4700:3033::ac43:96d2.https: Flags [P.], seq 1:518, ack 1, win 504, options [nop,nop,TS val 4074644216 ecr 1553849798], length 517
09:30:56.380014 IP6 2606:4700:3033::ac43:96d2.https > mosquito-public-ip.33520: Flags [.], ack 518, win 7, options [nop,nop,TS val 1553849824 ecr 4074644216], length 0
09:30:56.382855 IP6 2606:4700:3033::ac43:96d2.https > mosquito-public-ip.33520: Flags [.], seq 1:1349, ack 518, win 8, options [nop,nop,TS val 1553849827 ecr 4074644216], length 1348
[..]

looking at the packet contents in wireshark, I cannot spot any difference in what my host sends out between the cases where it works vs. where it does not work (i.e. I don't think that wget or my firewall is to blame).

Dave

This seems to be a general problem with IPv6 access to cloudflare CDN from my location.

Same things happens e.g. for linux.die.net, too

$ wget -6 https://linux.die.net -O/dev/null
--2023-07-12 11:16:32--  https://linux.die.net/
Resolving linux.die.net (linux.die.net)... 2606:4700:20::ac43:45bb, 2606:4700:20::681a:5e, 2606:4700:20::681a:15e
Connecting to linux.die.net (linux.die.net)|2606:4700:20::ac43:45bb|:443... connected.
GnuTLS: Error in the pull function.
Unable to establish SSL connection.

both system-image.ubports.com and linux.die.net appear to be hosted via cloudflare CDN.