I’m not sure I understand why you said it’s not a workaround. I just meant that it does allow me to get past the broken default page and access the Reforis and Luci interfaces by using their direct URLs. Here are the response headers I get from api/apps.json:
I have no idea why the Content-Type header is missing for you guys, as it is set on a backend. Unfortunately, I can’t reproduce such a behavior.
I have some ideas on how to fix it and make the frontend more resilient. I will push it tomorrow. Thanks for your responses.
UPD: you can track the progress here Error “Expected JSON, got null” after 7.1 update (#24) · Issues · Turris / WebApps · GitLab
2 Likes
Maybe we should reformulate this? What it does is that it scans the firewall rules for any previously set Sentinel rules and deletes them so it can insert the up to date rules. During start it wouldn’t find any, but during the restart, it will.
What can I say, the update went pretty uneventful and boring, just as I like these updates 
Things seem to work as before (but my config is hardly challenging)…
1 Like
hi there, i already contacted support, and i get this after /etc/init.d/firewall reload
If i restart, it shows the same.
Actually even by replacing the /usr/share/turris-webapps/turris-webapps-json-cgi with the one you changed in your pull request Enhance JSON response handling and add Content-Type header to cgi script (!46) · Merge requests · Turris / WebApps · GitLab got the site to display the apps again.
I’m glad to hear that it helped, let’s wait for the distribution team to create a hotfix to HBS. 
After update to 7.1 I have problem with DNSSEC. Without DNSSEC mostly domains are OK, but with DNSSEC active a lot of domains are unavailable. It doesn’t matter if I use forwarding or not.
Any advice?
Turris 1.x
Také problém s DNS. Pro načtení webu je potřeba několikrát odeslat požadavek, než dojde k načtení stránky.
Have you explored this any further or gained any insights? I’m holding off updating for now.
Mně nepomáhá ani opakované načítání. Na základě starších komentářů jsem se, pomocí automatického snapshotu, vrátil na verzi 7.0.3 a nastavil ruční schvalování aktualizací. Nyní vyčkávám na opravnou verzi.
Everything works fine.
Omnia 2020, DualStack, 2x WiFi, 1TB SSD, WireGuard, Samba, MiniDlna, AdBlock.
My Turris 1.1 self-updated to the 7.1 (from 7.0.x) and most of the internet traffic stopped working all together. Mostly DNS and firewall related problems but not for all devices.
Rollback to pre-update snapshot did not help strangely. To save the situation I’ve replaced it with a different router.
1 Like
For those who has problem with turris 1.x can you please try this workaround if it works for you? I tried to reproduce DNS problem and only got some errors regarding unbound package and after this workaround problem disappeared.
echo "nameserver 1.1.1.1" >> /etc/resolv.conf
rm -rf /etc/unbound
opkg update
opkg install --force-reinstall unbound
reboot
After reboot my turris 1.x started behave normally.
Please let me know if it works for you or not. Thx.
1 Like
Regarding “expected JSON, got null”, can confirm @ivanek statement that adding changes to “turris-webapps-json-cgi” from patch of @Aleksan4eg solves my issue.
Thank you.
1 Like
If you remove lines related to sentinel and hass from WAN zone sentinel and hass stops working. Turris team already is looking for a way to get rid of warnings. At least of what I saw on GitLab.
Badically firewall4 doesnt recognize this options but they are relevant for Sentinel and should be there. I wonder if you can get rid of warnings without making changes to fw4
well, i have the strong impression no pot is working atm. They do run in the process , but afaik , no ping.
Don’t know how to test it, but Haas for example does not ping, and sentinel gives 1 hit an hour.
Both my machines are running standard, so maybe if support can’t find it, a factory rest might solve it. But that means a lot of work with reinstalling fail2ban on one machine and such.
What do you mean that it does not ping? Give me your public IP in DM and I will try to connext to your honeypot
1 Like
Nope. I’m waiting. Probable solution is to reconfigure docker containers to use host network mode as mentioned by @fordovo
1 Like
Presumably that means to access docker services from the rest of the lan you’d need a proxy running on the host directly that can talk to the docker containers? Doable for web things, but not as straightforward for a dockerised smtp server. Worth waiting to see if a better solution comes along.