We released Turris OS 5.1.4 from the Testing (Turtles ) branch to the Stable (Snails )”. It means that it is available to all of you running Turris 1.x, Turris Omnia, Turris MOX, and Turris Shield routers.
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.
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.
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.
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
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.
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:
) branch to the Stable (Snails 
)”. It means that it is available to all of you running Turris 1.x, Turris Omnia, Turris MOX, and Turris Shield routers.
)”
)”