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


#42

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


#43

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.


#44

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.


#45

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.


#46

Had the same issue here in france with the free isp


#47

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

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?


#48

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.

Package list
|nstall |luci-i18n-ddns-ca |2.4.8-1 |1681 |Translation for luci-app-ddns - Català (Catalan)|
|Install |luci-i18n-ddns-cs |2.4.8-1 |1712 |Translation for luci-app-ddns - Čeština (Czech)|
|Install |luci-i18n-ddns-de |2.4.8-1 |8071 |Translation for luci-app-ddns - Deutsch (German)|
|Install |luci-i18n-ddns-el |2.4.8-1 |1831 |Translation for luci-app-ddns - Ελληνικά (Greek)|
|Install |luci-i18n-ddns-es |2.4.8-1 |1684 |Translation for luci-app-ddns - Español (Spanish)|
|Install |luci-i18n-ddns-fr |2.4.8-1 |1663 |Translation for luci-app-ddns - Français (French)|
|Install |luci-i18n-ddns-he |2.4.8-1 |1725 |Translation for luci-app-ddns - עִבְרִית (Hebrew)|
|Install |luci-i18n-ddns-hu |2.4.8-1 |1709 |Translation for luci-app-ddns - Magyar (Hungarian)|


#49

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.


#50

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?


#51

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


#52

Try “okpg update” beforehand


#53

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.


#54

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.


#55

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.


#56

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]


#57

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” ?


#58

coincided with Outage of some of our services ?


#59

very possibly , yes :slight_smile: … thanks for link :smiley:


#60

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 with raw.githubusercontent.com the issue seems to be DNS64 records that being synthesised by unbound's DNS64 module and that the tls libraries appear to have problems with.

The difference to repo.turris.cz, which works on this node, is that raw.githubusercontent.com and its CNAME github.map.fastly.net do not feature AAAA records in their DNS whilst in comparison repo.turris.cz does.

For that reason unbound's DNS64 module correctly synthesis from the A record of raw.githubusercontent.com and produces an IPv4-embedded IPv6 address, which in a packet dump reads:

Destination: 64:ff9b::9765:2485
[Destination Embedded IPv4: 151.101.36.133]

Having then run gnutls-cli -d 4 -V raw.githubusercontent.com

revealed that ipv6 connectivity fails in the first instance and subsequent ipv4 connectivity producing a fatal error

Connecting to ‘64:ff9b::9765:7085:443’…
Connecting to ‘151.101.112.133:443’…
|<4>| HSK[0x14c2750]: CLIENT HELLO was queued [235 bytes]
|<2>| WRITE: -1 returned from 0x4, errno: 104
|<3>| ASSERT: buffers.c[errno_to_gerr]:228
|<3>| ASSERT: buffers.c[_gnutls_io_write_flush]:720
|<3>| ASSERT: handshake.c[handshake_client]:2817
*** Fatal error: Error in the push function. |<2>| WRITE: -1 returned from 0x4, errno: 32
|<3>| ASSERT: buffers.c[errno_to_gerr]:228
|<3>| ASSERT: buffers.c[_gnutls_io_write_flush]:720
|<3>| ASSERT: record.c[_gnutls_send_tlen_int]:554
Could not connect to 151.101.112.133:443: Socket not connected

I cannot be sure but reckon that the cause might be with libgnutls | libopenssl not handling those DNS64 records correctly.

Also noticed that various apps on an Android client facing similar connectivity issues, perhaps utilizing libgnutls | libopenssl in versions that having issues with DNS64 records.


#61

Since yesterday I have the same issue:

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


Turris OS Version 3.11.4

Kernelversion 4.4.178-7bc33afbb1b35f5830b2b1b42c9cd8a0-0