Unreachable: https://repo.turris.cz/omnia/lists/base.lua

ebretteville · April 24, 2019, 7:24am

JFYI, in france the provider named “free” is going all ipv6 soon. So maybe, handling this can be good for some french users.

Theo · May 20, 2019, 3:10am

No, this is not a Turris problem. This is an ISP problem. As long as Free.fr and all the transit providers between them and Turris.cz are working properly, going all IPv6 will not be an issue.

Theo · May 20, 2019, 3:28am

In my case, it’s because the AT&T DHCPv6 server distributes an address to the router (IA_NA) from a different address pool than the delegated prefix (IA_PD) for the local network (2001:506:6000::/35 vs 2600:1700::/28). The packets from the IA_NA address are able to reach American servers, but they’re filtered out at AT&T’s interfaces to the rest of the world.

Brian_Feinzimer · May 29, 2019, 5:26pm

When I was experiencing this issue back in April, I fixed it by changing my DNS provider in Turris, however the same problem has come back again. I am on AT&T (Los Angeles, CA) and have tried all 5 DNS forwarding options and the updater fails on all 5 options. Tired disabling DNS forwarding and DNSSEC and updater still fails. Not sure what I can do at this point?

I am at a loss on how to fix this now.

ebretteville · June 3, 2019, 7:49am

Had the same issue here in france with the free isp

mkyral · June 9, 2019, 6:33pm

Hi. Just installed a brand new Omnia. All works, but after I setup ipv6 tunnel from HE, I got this error

root@turris:~# wget https://repo.turris.cz/omnia/lists/base.lua
--2019-06-09 20:21:18--  https://repo.turris.cz/omnia/lists/base.lua
Resolving repo.turris.cz... 2001:1488:ac15:ff80::69, 217.31.192.69
Connecting to repo.turris.cz|2001:1488:ac15:ff80::69|:443... failed: Operation timed out.
Connecting to repo.turris.cz|217.31.192.69|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9237 (9.0K)
Saving to: 'base.lua'

base.lua                                            100%[================================================================================================================>]   9.02K  --.-KB/s    in 0s      

2019-06-09 20:23:25 (118 MB/s) - 'base.lua' saved [9237/9237]

It worked correctly on my old Turris 1.1.

I’ve switched off dns forwarding - no change. Any Idea? Is it my ISP or HE issue?

xba · June 9, 2019, 7:26pm

root@RTCN:~# wget https://repo.turris.cz/omnia/lists/base.lua
…
Resolving repo.turris.cz… 2001:1488:ac15:ff80::69, 217.31.192.69
Connecting to repo.turris.cz|2001:1488:ac15:ff80::69|:443… failed: Operation timed out.
Connecting to repo.turris.cz|217.31.192.69|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 9237 (9.0K)
Saving to: ‘base.lua’

base.lua 100%[==================================================================================>] 9.02K --.-KB/s in 0s

2019-06-09 21:07:26 (111 MB/s) - ‘base.lua’ saved [9237/9237]
root@RTCN:~# pkgupdate
line not found
line not found
line not found
ERROR:
unreachable: https://repo.turris.cz/omnia/lists/base.lua: Operation timed out after 30000 milliseconds with 0 out of 0 bytes received

Without IPV6
root@RTCN:~# pkgupdate
WARN:Requested package luci-i18n-ddns-en that is missing, ignoring as requested.

vcunat · June 9, 2019, 7:48pm

Well, from various posts on the forum over time, I think pkgupdate doesn’t work well when you have IPv6 that appears OK (in some way) but doesn’t really work.

mkyral · June 9, 2019, 9:24pm

Well. One thing is a workaround - switch to ipv4.
Second thing is this ipv6 issue. I’m not expert on network, so I have no idea, how to analyze the problem.

@xba are you using native ipv6 or tunnel?

vcunat · June 10, 2019, 6:15am

Hmm, have you tried the WAN connection test button in Foris? (Though I can not say I’m really good at debugging these.)

Fenevadkan · June 10, 2019, 11:32am

Try “okpg update” beforehand

mkyral · June 12, 2019, 6:51am

Thanks for hint. I’ll test it after my return from business trip. Unfortunately, I’ve some troubles with VPN as well, so can’t test it remotely.

anon50890781 · June 12, 2019, 8:24am

wget https://repo.turris.cz/omnia/lists/base.lua works on this node with native ipv6 via dhcp pd and ipv4 via ds-lite.

Resolving repo.turris.cz… 2001:1488:ac15:ff80::69, 217.31.192.69
Connecting to repo.turris.cz|2001:1488:ac15:ff80::69|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 9237 (9.0K)

However, this one does not work wget https://raw.githubusercontent.com/stangri/openwrt-repo/master/Packages.gz and stops/hangs

Resolving raw.githubusercontent.com… 64:ff9b::9765:2485, 151.101.36.133
Connecting to raw.githubusercontent.com|64:ff9b::9765:2485|:443… failed: Operation timed out.
Connecting to raw.githubusercontent.com|151.101.36.133|:443… connected.
Unable to establish SSL connection.

Turning off ipv6 solves the matter and for my part I am convinced thus being a routing issue with ipv6 somehow, though not clear whether it is caused by the ISP’s ipv6 routing or the TO.

Another indication seems that with ipv6 via dhcp pd and ipv4 via ds-lite enabled android apps that support only ipv4 connectivity fail to connect as well.

It is difficult to debug since the traceoute package is castrate of -T and tcptraceroute not available in the repo.

vcunat · June 12, 2019, 8:35am

Usually routing issues are on IP level already, in which case it shouldn’t be significant which method you use (UDP is default IIRC). Otherwise I was testing such stuff from some other machine behind Omnia, or one could surely use a container on Omnia, too.

anon50890781 · June 12, 2019, 9:40am

I am wondering whether this potentially caused by openssl and/or netifd because the result on the TO differs from one of its client

On the TO

Resolving raw.githubusercontent.com… 64:ff9b::9765:2485, 151.101.36.133
Connecting to raw.githubusercontent.com|64:ff9b::9765:2485|:443… failed: Operation timed out.
Connecting to raw.githubusercontent.com|151.101.36.133|:443… connected.
Unable to establish SSL connection.

Whilst on the TO client

Resolving raw.githubusercontent.com (raw.githubusercontent.com)… 64:ff9b::9765:c85, 151.101.36.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|64:ff9b::9765:c85|:443… failed: Connection timed out.
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.36.133|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 3241 (3.2K) [application/octet-stream]

Maxmilian_Picmaus · June 13, 2019, 8:51pm

So far i did not face this issue at all, this week it occurs twice. After remote-restart, all fine. Aside “backup” service was complaining as well. Updater was complaining also. So from my point of view, just some “network” glitch. Is there something i can “check/change” ?

anon50890781 · June 13, 2019, 8:53pm

coincided with Outage of some of our services ?

Maxmilian_Picmaus · June 13, 2019, 8:56pm

very possibly , yes … thanks for link

anon50890781 · June 16, 2019, 11:12am

I know this will not solve the issue of the OP, respectively the thread’s topic but I thought to share at least my findings.

For my case the culprit is vpn-policy-routing. Having enabled the connectivity issue with raw.githubusercontent.com is present, disabling it the issue is not present.
It seems that that package introduces some NAT64 behaviour by embedding ipv4 addresses into ipv6 addresses.

rufus · June 17, 2019, 6:08am

Since yesterday I have the same issue:

pkgupdate

line not found

ERROR:

unreachable: https://repo.turris.cz/omnia/lists/base.lua: Operation timed out after 30000 milliseconds with 0 out of 0 bytes received

Turris OS Version 3.11.4

Kernelversion 4.4.178-7bc33afbb1b35f5830b2b1b42c9cd8a0-0