DNS resolving self-test doesn't work [Partially solved]

For me the same behauviour, even for http, even I confirming the certificate before. But I am on 3.9.1 Turris OS, and 443 redirected to 8443 if that matters. Fortunatelly, you can run check_connection through SSH. I remember, that Foris GUI works before, so that comes with the new Foris stuff…

I have the same problem, works over HTTP, does not work over HTTPS. Turris OS 3.9.6.

Did you try port 443 or 9000? Because you must confirm security exception also for the port 9000.

i just checked via CLI:

root@turris:~# check_connection
IPv4 Gateway: FAILED
IPv6 Gateway: FAILED

It’s weird cuz I can ping manually all of the IPv4 addresses in the check_connection script and I do get response.

When I tried again in foris webinterface (HTTP) I do get error now instead of being stuck on loading:

I tried with forwarding on and off. Same result -> error.

Obviously, since I can reply to that topic, my internet connection works just fine.

@sid how do I do that? I thought that you make a exception in browser for a certificate not for the port.

Hey guys,
I have discovered some bug in that test as well some weeks ago. Feel free to join me in this issue I raised on Gitblab.
Even though I have to provide you with small note: I found similiar problem, not the same. But it is the same backend, so you could output your experience and needs there.

Don’t know if the same problem exists for another browsers but for firefox it seems that this bugreport is relevant https://bugzilla.mozilla.org/show_bug.cgi?id=1187666

@sid I deleted the exception rule, tried to connect using workaround described in that bug report (mentioned by fresheneesz) and I cannot connect on port 9000 I do not get prompt to add security exception. So it might be related to that bug. could someone not using firefox elaborate?

I had this problem when I had to factory-reset my Turris 1.0 after I completely botched its config and wiping it seemed easier than fixing it. The problem was identified by the NIC.CZ helpdesk to originate in expired certificates in the freshly wiped router, and it corrected itself after it self-updated a few hours later. Until then I just used the assigned DNS servers from my ISP, after update I switched back to NIC.CZ’s DNSSEC servers and had no problem since.

Could you do a

cat /etc/resolv.conf

If it is, change it to for example

Then test it again, if the resolv.conf is, then PROBABLY that may be the problem.

Hi @Big_boss thanks for the idea, I had my resolv.conf pointing to (I think it’s turrisOS default) but still:

cat /etc/resolv.conf
search lan

I have change it then to:
search lan

(I don’t like to use google)

Still same error via http and stuck at loading via https.

Oke, to be very sure. Just for this test, change it to that of Google, then DIRECTLY after changing it, give a

ping www.microsft.com

If it does not work, do a

cat /etc/resolv.conf

Because it just might be, that you just changed it, and it automatically changed back to again. Let me how it went.

I found next one strange think:

Under http there you should test the DNS and DNSSEC sucessfully just once in approx. 5 seconds. If you perform test faster, the result will be ERROR. I am able to get one sucessfull test answer followed by two DNS/DNSSEC errors. I did tried that many times.

I confirm also the HTTPS will break the functionality.

For those who doubt whether their settings or the “web app” is at fault, you may try the corresponding check_connection command over ssh. No case of “stuck at Loading…” I’ve heard of so far was confirmed to be a real DNS problem.

I’m kind surprised that here we’re mixing up things together.

If you’re using the latest version, which is 3.9.6 and you’re using https then as you an added exception for https (443) you need to add the exception for WebSocket (9443) as well.
This is not new and it is even written in Errata and the post, where it is explained is currently in Czech, but I tried to use translator and it’s not so bad and you will understand it.

If it shows Loading… on http then my experience with this issue is that you’re trying to connect to your router from outside (I don’t mean VPN) and you don’t have enabled port for WebSocket as well.

If it shows Error then I recommend using check_connection, which doesn’t work as @AreYouLoco said and I wonder why there is $OTHER_IP_FROM_MY_ISP_HERE$, so it seems that this could be culprit why it doesn’t work. Can you tell me what did you change?

In Turris version 3.10, which is currently in RC the WebSockets listen on the same ports as http/https.

1 Like

Why 443/9000? I wrote, it doesnt work for me even from http port…

@Pepe I just tried to obscure my ip like that. Normally there is some valid ip address here.

I also checked with the latest version of check_connection from gitlab:
Same result. Everything ends up with an error message.

root@turris:~# check_connection
Pinging 37.109.128.xx … FAILED
IPv4 Gateway: FAILED
IPv6 Gateway: FAILED

Ok there is a progress. I’ve deleted the exception for self signed cert. And I tried to connect like this first: (in my case) and I successfully added exception for port 9443 and then same story for default ssl port And after that I am no longer “stuck at loading” via HTTPS when I try to test connection.

@Jirka @guinhas @honzakrivohlavy you should all try that solution I marked as well.

But still I do get this error in every case. So is it a DNS problem then? @vcunat ?

The test seems to show worse breakage than just DNS.

1 Like

@vcunat You might be just right.

I just checked with my other modem that acts like a small router; connecting via DHCP and ‘double NAT’. And when I check_connection on it it’s fine. Everything works except IPv6 but that’s fine I just get IPv4 from ISP.

I will try to check some more and update here…

Here is topic where I explain my -strange someone might say- way to access the Internets.

EDIT: Yup I just checked it seems like an error comes from a (not yet!)-supported protocol. I thought it’s related to that, that my WAN was set on different interface name but if it’s on wan it’s the same problem.

config interface 'wan'
option ifname 'wan'
option proto 'ncm'

Turris 3.9.6, DNS check still doesnt work on some conditions.

Please note, this is unrelated to the HTTPS / certificate!

My configuration:

config interface 'wan'
	option ifname 'eth1'
	option proto 'static'
	option ipaddr '<public_IP>' #public IP

config interface 'lan'
	option ifname 'eth0 eth2'
	option force_link '1'
	option type 'bridge'
	option proto 'static'
	option netmask ''
	option ipaddr ''
	option ip6assign '64'

config interface 'wifi'
	option proto 'static'
	option ipaddr ''
	option netmask ''
	option delegate '0'       #no IPv6

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '24h'
	list dhcp_option '6,'
	option dhcpv6 'server'
	option ra 'server'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'
	list dhcp_option '6,<public_IP>'

config dhcp 'wifi'
	option interface 'wifi'
	option start '100'
	option limit '150'
	option leasetime '4h'
	list dhcp_option '6,'

config zone
	option name 'lan'
	list network 'lan'
	list network 'vpn0'
	list network 'wifi'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

DNS check works on (both HTTP&HTTPS):

  • from WIFI network
  • <public_IP>/foris from LAN network

GET [HTTP/1.1 101 Switching Protocols 9ms]
“WS registering for: dns” foris.min.js:1:3262
“WS message received: {“result”: true, “subscriptions”: [“dns”]}”


GET [HTTP/1.1 101 Switching Protocols 43ms]
“WS registering for: dns” foris.min.js:1:3262
“WS message received: {“result”: true, “subscriptions”: [“dns”]}” foris.min.js:1:3347


DNS check doesnt work for (both HTTP&HTTPS):

  • from LAN network
GET [2ms]
"WS error occured:[object Event]" foris.min.js:1:3500
"WS connection closed." foris.min.js:1:3559
Pale Moon nemůže navázat spojení se serverem ws:// foris.min.js:1:0


GET [31ms]
“WS error occured:[object Event]” foris.min.js:1:3500
“WS connection closed.” foris.min.js:1:3559
Pale Moon nemůže navázat spojení se serverem wss:// foris.min.js:1:0



It would be good to make ports customizable, as I think it could interfere with some user application(s) (?). I think I am not only one, who has configured other port for HTTPS in lighttp configuration, for example…

In case of automatic way, I am little bit afraid, as lighttp could be stopped/not-used, or not used for Foris, or configured other way; in that case websocket ports would be taken without reason, and most importantly, user could not be aware of this at all, when he will plan his custom applications / firewall rules.