Jak jsem pozoroval já, tak to nefungovalo tak, že resolver vracel náhodně na stejný dotaz validní IP a také SERVFAIL (nenašel jsem v tom žádnou pravidelnost). Chovalo se to stejně i když jsem nastavil servery Google (port 53).
1 Like
Ok, both TO an Mox are now on 7.1, and on both machines Haas does not ping anymore, and sentinel view is almost empty.
When i try to save sentinel settings in reforis, it crashes after 2 times, see picture
Both are running standard TOS, no containers, a basic setup and config
Contacted support, since this is happening on both machines.
1 Like
Hi,
regarding DNS on Turris 1.X, we are trying to reproduce, but not really reliably succeeding. We have two wild guesses. Can someone try to update to 7.1 and try
ethtool -K eth2 tx off
And afterwards check whether it helps? This should modify the router behaviour only until the next reboot.
Alternativelly, update to 7.1 and revert back to iptables based firewall after disabling updates:
opkg remove --force-removal-of-dependent-packages firewall4
opkg install firewall
reboot
This will change the firewall back to iptables, but next update will fix it.
Untill we can reproduce it and figure out what is different in our setup, trying wild guess (option number one) xor verifying whether the only major change potentially related is causing this (option number two), would help.
Wild guess number three would be to test whether replacing unbound with knot will help. Only differences between Turris 1.X and Omnia/MOX are hardware and default resolver.
1 Like
Hey, in my surrounding, two Turris 1.X were suffering from Unbound issue, both were fixed by reinstalling libevent2. Hopefully this will help tracing down the issue.
6 Likes
So we have a potential fix number number four, thank you @Ondrej_Caletka , reinstalling libevent:
opkg install --force-reinstall libevent2
/etc/init.d/resolver restart
You probably need to first overwrite local resolver list to make DNS work for opkg (this change will get reverted after reboot):
echo nameserver 1.1.1.1 > /etc/resolv.conf
Did you find a solution?
Update Omnia OK, 1.x DNS chyba
No solution yet @Leonardo.
My Omnia acting as dumb AP just got an update all smooth 7.1.0. Waiting for the tag of that release so I may update my second Omnia.
Since the kernel version didnt change I gave it a go and updated my main Omnia router. All fine so far. Just reinstalled old compiled kernel.
Edit:
Actually i also had problem with miniupnpd package even I don’t use that it was there. And there are suspicious entries in firewall reload:
root@router:~# /etc/init.d/firewall reload
Section @zone[1] (wan) specifies unknown option '
haas_proxy'
Section @zone[1] (wan) specifies unknown option '
sentinel_dynfw'
Section @zone[1] (wan) specifies unknown option '
sentinel_minipot'
Section @zone[1] (wan) specifies unknown option '
sentinel_fwlogs'
[...]
Section @include[0] is not marked as compatible w
ith fw4, ignoring section
Section @include[0] requires 'option fw4_compatib
le 1' to be considered compatible
Section @include[1] option 'reload' is not suppor
ted by fw4
Automatically including '/usr/share/nftables.d/ta
ble-post/20-miniupnpd.nft'
Automatically including '/usr/share/nftables.d/ch
ain-post/dstnat/20-miniupnpd.nft'
Automatically including '/usr/share/nftables.d/ch
ain-post/forward/20-miniupnpd.nft'
Automatically including '/usr/share/nftables.d/ch
ain-post/srcnat/20-miniupnpd.nft'
* Cleaning up the remnants of the old firewall
* Dynamic blocking on zone 'wan'
* Logging of zone 'wan'
* HaaS proxy on zone 'wan' (22 -> 2525)
And each time after reload and reboots the info about Cleaning up the remaints of old firewall stays there. I am loosing hope that you guys actually know what you are doing…
I cleaned up a bit myself still getting that info about removing remaints of old firewall. Additional thing for others in this version of fw4 Comment to ipsets is wrongly a Boolean instead of String. So if you have some comment added to your ioset this wont work. I learned the hard way. Just remove comment alltogether and ipset will load.
Also HaaS doent work for me.
2 Likes
I do have the same issue, on Omnia and Mox too.
Can you please open DevTools in your browser and look at Console or Network tab for failed requests and share them here under a spoiler.
Example
This text will be hidden
It’s hard to tell without details what can be wrong. Alternatively you can gather all the information you have and open an issue on our GitLab in respectvie repository Turris / WebApps · GitLab or contact our support. Thanks!
Share them here under a spoiler.
I’m having the same “expected JSON, got null” issue and did find a workaround. The issue occurs when you navigate to the base URL, as in https://192.168.1.1. If you instead navigate directly to the reforis path, as in https://192.168.1.1/reforis/ then the application loads correctly.
The error occurs in the index-LRQhn-Wy.js file. It calls fetch on /api/apps.json which does return valid JSON, but the response contains no headers. The code is expecting a “content-type” header with “application/json”. The code explicitly throws this exception when it finds the header is missing.
So, this does seem to be a bug, but you can avoid it by including /reforis/ in the URL. The trailing slash is required. Otherwise it will return 404 not found.
3 Likes
I’m having the same “expected JSON, got null” issue and did find a workaround.
It’s not a workaround. It seems that the problem is with the response itself.
What do you have in the response headers of /api/apps.json?
And the spoiler content?
Please check the version of turris-auth, it should be 1.2.0:
opkg list-installed | grep turris-auth
turris-auth - 1.2.0-3.10-2