Turris OS 5.1.4 is out!

Dear Turris users,

We released Turris OS 5.1.4 from the Testing (Turtles :turtle:) branch to the Stable (Snails :snail:)”. It means that it is available to all of you running Turris 1.x, Turris Omnia, Turris MOX, and Turris Shield routers.

What is new or fixed in this release?

  • There is updated kernel, which mitigates Sad DNS vulnerability. (CVE-2020-25705)
  • Updated DNS rules based on DNS Flag Day 2020. Lowered size of EDNS buffer size to 1232 bytes, which is default right now.
  • We updated netmetr and mariadb packages and new improvements for diagnostics package.

When you are using automatic updates, you will be updated to this version soon automatically, but you need to reboot your router to apply all changes as soon as possible. If you are not using automatic updates, but approvals or delayed updates, you need to login to reForis and approve this update. Also, you can use SSH to update your router by using command pkgupdate.

We will appreciate any feedback regarding this release.

4 Likes

Indiegogo Omnia updated. No problem detected.

I guess that the “from the Testing (Turtles :turtle:)”
means “to the Stable (Snails :snail:)”
I better checked.

Btw, does the:

apply only for kresd or also dnsmasq?

Thank you.

I saw it done for kresd and unbound. It’s aligned with respective upstream default changes (meaning NLnet Labs, not OpenWrt), but it needed explicit action as the limits were explicitly re-defaulted in local config.

Thanks for the feedback in OP, I added it there.

In the previous release, we done changes in BIND including changes in OpenWrt 19.07. In this release, we applied changes for Unbound and Knot Resolver as those packages come from our repository.
Regarding Unbound and Dnsmasq in upstream, these changes are done by us in OpenWrt master. You might ask OpenWrt developers to backport related changes to stable releases.

Is Domoticz still supported on Turris 1.x in TOS5.1.4 ? I use this to switch several firewall rules via Domoticz web ui.

Domoticz is not provided by us and it comes from OpenWrt packages feed. If there are any issues with Domoticz, they needs to be reported here.

I couldn’t login to LuCI after the update…

Google Chrome dev console said:

GET http://192.168.1.1/cgi-bin/luci/ 403 (Forbidden) (index):1
GET http://192.168.1.1/cgi-bin/luci/admin/translations/en?v=git-20.313.59566-7460e9d net::ERR_ABORTED 403 (Forbidden) (index):10

Clearing the cookies didn’t help, had to clear all local site data. Seems like some cache issue.

Hi,
Just update my Omnia to 5.1.4, I have the following error :

kresd[6110]: ERROR: udp sendmmsg() sent -1 / 1; Permission denied

Any idea?

I’ve heard these happen sometimes on Omnia. I honestly don’t know why exactly, but even if a few packets really get lost, you most likely couldn’t tell a difference. Well, I assume you also get only several of such error lines (per day)…

Thanks vcunat, it’s the first time but I just started my router 2 weeks ago.
I also received that this morning, first time ever since the 5.1.4 Upgrade :

sentinel-dynfw-client[3220]: ipset v7.3: Error in line 1: Element cannot be deleted from the set: it’s not added

Hi @talisker,

Could you take a look if there any issues with DynFW client in syslog and also if there are some addresses in ipset? The warning which you posted means that DynFW tries to remove IP which is not present.

More details can be found here:

Just this in syslog.

Nov 17 21:00:20 turris sentinel-dynfw-client[3220]: ipset v7.3: Error in line 1: Element cannot be deleted from the set: it’s not added
Nov 17 21:00:20 turris sentinel-dynfw-client[3220]: 2020-11-17 22:00:20,267 - WARNING - Error running ipset command: return code 1.
Nov 17 21:11:57 turris sentinel-dynfw-client[3220]: ipset v7.3: Error in line 1: Element cannot be deleted from the set: it’s not added
Nov 17 21:11:57 turris sentinel-dynfw-client[3220]: 2020-11-17 22:11:57,991 - WARNING - Error running ipset command: return code 1.
Nov 17 22:12:16 turris sentinel-dynfw-client[3220]: ipset v7.3: Error in line 1: Element cannot be deleted from the set: it’s not added
Nov 17 22:12:16 turris sentinel-dynfw-client[3220]: 2020-11-17 23:12:16,701 - WARNING - Error running ipset command: return code 1.
Nov 18 04:27:24 turris sentinel-dynfw-client[3220]: ipset v7.3: Error in line 1: Element cannot be deleted from the set: it’s not added
Nov 18 04:27:24 turris sentinel-dynfw-client[3220]: 2020-11-18 05:27:24,521 - WARNING - Error running ipset command: return code 1.
Nov 18 09:55:18 turris sentinel-dynfw-client[3220]: ipset v7.3: Error in line 1: Element cannot be deleted from the set: it’s not added
Nov 18 09:55:18 turris sentinel-dynfw-client[3220]: 2020-11-18 10:55:18,819 - WARNING - Error running ipset command: return code 1.

ipset list is working

Name: turris-sn-dynfw-block
Type: hash:ip
Revision: 4
Header: family inet hashsize 2048 maxelem 65536
Size in memory: 82136
References: 0
Number of entries: 4279
Members:
113.91.170.250
178.93.137.129
123.132.65.76
182.117.152.16
185.216.140.31
113.116.226.160
111.70.4.215
193.56.29.15
185.54.178.195
125.46.243.48

I seem to be having some weird DNS issues after the upgrade.

For some reason google.com no longer works using the TLS forwarders.

If I set the TLS forwarders to the Google addresses even, it doesn’t work. I get a different answer if I use the TLS forwarders than I do if I go directly to Google.

However, if I set the “nameserver” setting to 8.8.8.8 in “/etc/resolv.conf” in my local machine, it works fine.

I’m not sure if this is a kresd issue or if it’s something else.

I’m not sure what exact setup you mean. Now I quickly tried some of the forwarders selected in (re)Foris, including “Google (TLS)”, and tried resolving stuff, including google.com… but no issue. I expect it will be best to gather more information, e.g. I expect that getting verbose logs of this failure would move the issue forward: https://doc.turris.cz/doc/en/howto/dnsdebug#enable_verbose_logging

Darn, it looks like a Adblock/RPZ issue. google.com looks up, but going to google.com in a browser redirects to www.google.com, which is blacklsted somewhere:

; AUTHORITY SECTION:
www.google.com. 10800 IN SOA www.google.com. nobody.invalid. 1 3600 1200 604800 10800

Sorry about that. I’ll see which dingbat adblock list added www.google.com.

1 Like

Yes, that SOA does look exactly like one from kresd’s RPZ (or its another policy rule).

Is there a solution to flush list and rebuild a new one to avoid this alert ?

seems that setting dnsmasq.ednspacket_max to ‘1232’ either by running:

uci set dhcp.@dnsmasq[0].ednspacket_max='1232'

or adding:
option ednspacket_max '1232'
to /etc/config/dhcp section “dnsmasq” configures maximum EDNS packet for dnsmasq.