Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2023-08-16T14:38:04+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/343turris-maintain: Network restart leaves net-related services in a broken state2023-08-16T14:38:04+02:00David Beiteyturris-maintain: Network restart leaves net-related services in a broken stateI noticed this a while back when attempting to change network-related settings within Foris — if you change any such settings, Foris will restart the networking stack via `/usr/bin/maintain-network-restart` which in turn calls `/etc/init...I noticed this a while back when attempting to change network-related settings within Foris — if you change any such settings, Foris will restart the networking stack via `/usr/bin/maintain-network-restart` which in turn calls `/etc/init.d/network restart`. Upon doing so, certain services on the router - at least OpenVPN and networking in LXC containers - are now non-functional, requiring different manual restart strategies to get them working again. This becomes a significant problem if you're relying on them when you make the change (eg you're connected via OpenVPN or your DNS served by process in LXC). Likewise, it's easily forgotten if you change wifi settings and forget that this restarts the whole networking stack, which then flows on.
Here's my breakdown so far:
* OpenVPN - the service remains up and connectable from a client, but traffic does not route. Looking into this, the `tun_turris` network interface on the router loses its IP addresses as shown in `ifconfig tun_turris` after the network restart occurs. OpenVPN requires a restart to bring it back online.
* LXC containers - the containers remain up but processes inside the container can't connect out (even to the the Turris Omnia host) and likewise nothing can connect in, even if the network is bridged. The state of the container shows interfaces still up with IP addresses but an empty routing table (eg output from `route` is empty) after the network restart occurs. A full restart of the container (eg `lxc-stop` & `lxc-start`) corrects the interface/routing problem.
In short, there should be some strategy in place for restarting services that depend on the network after it restarts. I'm unfamiliar with specifics of OpenWrt's init system, but that might be an option if it support dependencies. Otherwise, adding to `turris-maintain`'s scripts directly (if no other code is directly restarting the network) or else associating hook scripts to be trigged when `/etc/init.d/network` gets run.
As a workaround, I've amended `/usr/bin/maintain-network-restart` with the following at the end of the file (eg after [network restart](https://gitlab.labs.nic.cz/turris/turris-os-packages/blob/master/cznic/turris-maintain/files/network-restart.py#L86)):
```python
time.sleep(5) # Allow time for network to come online; OpenVPN needs this
subprocess.call(['/etc/init.d/openvpn', 'restart'])
subprocess.call(['/usr/bin/lxc-stop', '--name', 'mydnsserver'])
subprocess.call(['/usr/bin/lxc-start', '--name', 'mydnsserver'])
"
```
This way, at least when I make changes to LAN/WAN, OpenVPN or WiFi in Foris, all my services come back up okay and my network is functional.Turris OS 5.1https://gitlab.nic.cz/turris/os/packages/-/issues/342luci-app-wireguard: status fail to load; JavaScript error TypeError: String.f...2022-02-16T16:59:48+01:00David Beiteyluci-app-wireguard: status fail to load; JavaScript error TypeError: String.format is not a functionLoading the Wireguard status page in LuCI has worked at least once in the past, but now shows a screen stating "Collecting data...". In JavaScript, the page is making XHR requests but data processing is failing because of the following ...Loading the Wireguard status page in LuCI has worked at least once in the past, but now shows a screen stating "Collecting data...". In JavaScript, the page is making XHR requests but data processing is failing because of the following error:
```
TypeError: String.format is not a function wireguard:74:21
<anonymous> /cgi-bin/luci/admin/status/wireguard:74
onreadystatechange /luci-static/resources/xhr.js?v=git-18.328.59464-9636605:72
```
and this error occurs every few seconds as continued XHRs take place.
The issue appears to be that the JS function `String.format` from ` /www/luci-static/resources/cbi.js` isn't being loaded on this page and is thus null, causing the error. Looking into the JS that is loaded and only `xhr.js` (in the traceback above) and the inline JS on the HTML page are what's present.
I don't know the internals of LuCI or its pages, but manually defining that `String.format` function sees the rest of the page work as a test.
I'm on Turris Omnia `v3.11.2` with luci-app-wireguard version `git-18.328.59464-9636605-1`https://gitlab.nic.cz/turris/os/packages/-/issues/341ddns: writes ever 10 min to emmc2019-05-06T17:21:48+02:00Jan Pavlinecddns: writes ever 10 min to emmcIt is probably related to usage of HSTS (affected 3.x TO)
https://forum.turris.cz/t/ddns-hsts-writes-to-mmcblk0p1-every-10-minutes/9745It is probably related to usage of HSTS (affected 3.x TO)
https://forum.turris.cz/t/ddns-hsts-writes-to-mmcblk0p1-every-10-minutes/9745Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/336wrong iw command output2023-08-16T14:57:48+02:00Štěpán Henekwrong iw command outputMight be caused by some kernel bug. `iw` uses netlink to obtain information from the kernel...
Problem occurs on Omnia and TurrisOS 4.0.
```bash
root@turris:~# iw phy0 info
Wiphy phy0
max # scan SSIDs: 16
max scan IEs length: 195 byte...Might be caused by some kernel bug. `iw` uses netlink to obtain information from the kernel...
Problem occurs on Omnia and TurrisOS 4.0.
```bash
root@turris:~# iw phy0 info
Wiphy phy0
max # scan SSIDs: 16
max scan IEs length: 195 bytes
max # sched scan SSIDs: 0
max # match sets: 0
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports RSN-IBSS.
Device supports AP-side u-APSD.
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CMAC (00-0f-ac:6)
* CMAC-256 (00-0f-ac:13)
* GMAC-128 (00-0f-ac:11)
* GMAC-256 (00-0f-ac:12)
Available Antennas: TX 0x7 RX 0x7
Configured Antennas: TX 0x7 RX 0x7
Supported interface modes:
* IBSS
* managed
* AP
* monitor
* mesh point
* P2P-client
* P2P-GO
* P2P-device
Band 1:
Capabilities: 0x19ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-23
VHT Capabilities (0x338001b2):
Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (30.0 dBm)
* 2417 MHz [2] (30.0 dBm)
* 2422 MHz [3] (30.0 dBm)
* 2427 MHz [4] (30.0 dBm)
* 2432 MHz [5] (30.0 dBm)
* 2437 MHz [6] (30.0 dBm)
* 2442 MHz [7] (30.0 dBm)
* 2447 MHz [8] (30.0 dBm)
* 2452 MHz [9] (30.0 dBm)
* 2457 MHz [10] (30.0 dBm)
* 2462 MHz [11] (30.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
Band 2:
Capabilities: 0x19ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-23
VHT Capabilities (0x338001b2):
Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 5180 MHz [36] (23.0 dBm)
* 5200 MHz [40] (23.0 dBm)
* 5220 MHz [44] (23.0 dBm)
* 5240 MHz [48] (23.0 dBm)
* 5260 MHz [52] (23.0 dBm) (radar detection)
* 5280 MHz [56] (23.0 dBm) (radar detection)
* 5300 MHz [60] (23.0 dBm) (radar detection)
* 5320 MHz [64] (23.0 dBm) (radar detection)
* 5500 MHz [100] (23.0 dBm) (radar detection)
* 5520 MHz [104] (23.0 dBm) (radar detection)
* 5540 MHz [108] (23.0 dBm) (radar detection)
* 5560 MHz [112] (23.0 dBm) (radar detection)
* 5580 MHz [116] (23.0 dBm) (radar detection)
* 5600 MHz [120] (23.0 dBm) (radar detection)
* 5620 MHz [124] (23.0 dBm) (radar detection)
* 5640 MHz [128] (23.0 dBm) (radar detection)
* 5660 MHz [132] (23.0 dBm) (radar detection)
* 5680 MHz [136] (23.0 dBm) (radar detection)
* 5700 MHz [140] (23.0 dBm) (radar detection)
* 5720 MHz [144] (23.0 dBm) (radar detection)
* 5745 MHz [149] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
* 5845 MHz [169] (disabled)
* 5865 MHz [173] (disabled)
Supported commands:
* new_interface
* set_interface
* new_key
* start_ap
* new_station
* new_mpath
* set_mesh_config
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* join_mesh
* remain_on_channel
* set_tx_bitrate_mask
* frame
* frame_wait_cancel
* set_wiphy_netns
* set_channel
* set_wds_peer
* probe_client
* set_noack_map
* register_beacons
* start_p2p_device
* set_mcast_rate
* testmode
* connect
* disconnect
* channel_switch
* set_qos_map
* set_multicast_to_unicast
Supported TX frame types:
* IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* IBSS: 0x40 0xb0 0xc0 0xd0
* managed: 0x40 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* mesh point: 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-device: 0x40 0xd0
software interface modes (can always be added):
* monitor
valid interface combinations:
* #{ managed, P2P-client } <= 16, #{ P2P-GO } <= 3, #{ AP } <= 7, #{ IBSS } <= 1,
total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 80+80 MHz, 160 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports TX status socket option.
Device supports HT-IBSS.
Device supports SAE with AUTHENTICATE command
Device supports scan flush.
Device supports AP scan.
Device supports per-vif TX power setting
Driver supports full state transitions for AP/GO clients
Driver supports a userspace MPM
Driver/device bandwidth changes during BSS lifetime (AP/GO mode)
Device supports static SMPS
Device supports configuring vdev MAC-addr on create.
Supported extended features:
* [ VHT_IBSS ]: VHT-IBSS
* [ RRM ]: RRM
* [ SET_SCAN_DWELL ]: scan dwell setting
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
```
Shows that `Band 1` has `VHT Capabilities` although it is 11g mode.
Output for a 11g only cards seems to be fine (without `VHT Capabilities`). It also works properly on TurrisOS 3.X.https://gitlab.nic.cz/turris/os/packages/-/issues/334Unable to disable dnssec from foris2023-08-16T14:49:19+02:00Štěpán HenekUnable to disable dnssec from forissetting
```
config resolver 'common'
...
option ignore_root_key '1'
```
Doesn't make disable dnssec validation in omnia nightly kresd.setting
```
config resolver 'common'
...
option ignore_root_key '1'
```
Doesn't make disable dnssec validation in omnia nightly kresd.Štěpán HenekŠtěpán Henekhttps://gitlab.nic.cz/turris/os/packages/-/issues/333syslog-ng: update to version 3.20.12023-08-16T14:49:21+02:00Josef Schlehofersyslog-ng: update to version 3.20.1Pull request for upstream: https://github.com/openwrt/packages/pull/8335Pull request for upstream: https://github.com/openwrt/packages/pull/8335Turris OS 3.11.3https://gitlab.nic.cz/turris/os/packages/-/issues/332Script `/etc/resolver/dhcp_host_domain_ng.py` seems to be run as shell by dns...2023-08-16T14:49:29+02:00Karel KociScript `/etc/resolver/dhcp_host_domain_ng.py` seems to be run as shell by dnsmasqThis was reported by user of Turris Mox. The output from logs is as follows:
```
Feb 24 15:09:57 turris dnsmasq-dhcp[20356]: read /etc/ethers - 0 addresses
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /e...This was reported by user of Turris Mox. The output from logs is as follows:
```
Feb 24 15:09:57 turris dnsmasq-dhcp[20356]: read /etc/ethers - 0 addresses
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 3: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 4: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 5: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 6: from: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 7: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 8: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 9: import: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 10: from: not found
Feb 24 15:09:57 turris dnsmasq-script[20356]: /usr/lib/dnsmasq/dhcp-script.sh: /etc/resolver/dhcp_host_domain_ng.py: line 13: syntax error: unexpected “(”
Feb 24 15:09:57 turris dnsmasq[20356]: script process exited with status 2
```
This is clearly a shell interpretation of python script. I am not sure why this is happening but I suspect that some patch or even upstream dnsmasq introduced change of in from that they source scripts instead of starting them.
Problematic script seems to have correct hashbang at the beginning (or might we migrate it to python3?):
```
head /etc/resolver/dhcp_host_domain_ng.py
#!/usr/bin/python
import subprocess
import sys
import syslog
from syslog import LOG_ERR, LOG_INFO, LOG_DEBUG, LOG_WARNING
import re
import socket
import os
from os import listdir
```
Forum reference: https://forum.turris.cz/t/hostname-resolution-without-domain-doesnt-work/9606Turris OS 4.0Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/329[4.HBD on Omina] medkit installation not working - dhcp & lighttpd servers ar...2019-05-17T14:11:37+02:00Ghost User[4.HBD on Omina] medkit installation not working - dhcp & lighttpd servers are not startedomnia-medkit-latest.tar.gz 2019-02-21 04:37 33M
Neither dhcp not lighttpd servers are up/running upon medkit installation. [bootlog enclosed](/uploads/29eb3554504a885323d62995831353de/boot.log)
The issue is not present with HBS alpha2omnia-medkit-latest.tar.gz 2019-02-21 04:37 33M
Neither dhcp not lighttpd servers are up/running upon medkit installation. [bootlog enclosed](/uploads/29eb3554504a885323d62995831353de/boot.log)
The issue is not present with HBS alpha2https://gitlab.nic.cz/turris/os/packages/-/issues/328luci-app-ddns: Update to upstream to improve LuCI performance2019-05-08T17:07:08+02:00David Beiteyluci-app-ddns: Update to upstream to improve LuCI performanceUpdating `luci-app-ddns` was originally mentioned in https://forum.turris.cz/t/set-persistent-nameserver-entries-in-etc-resolv-conf/8926/ where I dug into why LuCI was making 1000s of DNS requests.
The short answer to that is because of...Updating `luci-app-ddns` was originally mentioned in https://forum.turris.cz/t/set-persistent-nameserver-entries-in-etc-resolv-conf/8926/ where I dug into why LuCI was making 1000s of DNS requests.
The short answer to that is because of the `luci-app-ddns` package, because LuCI’s dispatcher imports all controllers for every request that gets made to LuCI. Turns out that the DDNS controller `ddns.lua` gets imported for every request which means its `has_nslookup` check got called each time. This made a DNS request for localhost, which by design, does not use `/etc/hosts`, thus querying the DNS server.
My PR to LuCI upstream at https://github.com/openwrt/luci/pull/2384 to fix this issue was merged a while ago and the app itself has had a significant restructuring for performance compared to its version on Turris OS (https://github.com/openwrt/luci/commits/master/applications/luci-app-ddns).
So, since the performance benefits of these changes actually affect _all_ of LuCI, can `luci-app-ddns` be updated in 3.11.x? Thanks.Turris OS 3.11.4https://gitlab.nic.cz/turris/os/packages/-/issues/327netdata: update to version 1.12.02019-02-17T23:32:39+01:00Josef Schlehofernetdata: update to version 1.12.0Turris OS 3.11.3https://gitlab.nic.cz/turris/os/packages/-/issues/325lighttpd: update to version 1.4.532020-01-04T23:32:06+01:00Josef Schlehoferlighttpd: update to version 1.4.53Package name: **lighttpd**
Short description of the package: **open-source web server - security, speed, compliance, and flexibility**
OpenWRT repository:
https://github.com/openwrt/packages/tree/master/net/lighttpd
Upstream repo...Package name: **lighttpd**
Short description of the package: **open-source web server - security, speed, compliance, and flexibility**
OpenWRT repository:
https://github.com/openwrt/packages/tree/master/net/lighttpd
Upstream repository:
https://github.com/lighttpd/lighttpd1.4
_Version information_
We have version: 1.4.50
OpenWrt has version: 1.4.49
Upstream has version: 1.4.53
Quite interesting changes between 1.4.50 and 1.4.53 are:
* TLS-ALPN-01
* security fixes
* support for WolfSSLTurris OS 4.0https://gitlab.nic.cz/turris/os/packages/-/issues/320unbound version bump 1.9.02019-02-11T16:47:47+01:00Ghost Userunbound version bump 1.9.0Unbound 1.9.0 is available:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.9.0.tar.gz
sha256 415af94b8392bc6b2c52e44ac8f17935cc6ddf2cc81edfb47c5be4ad205ab917
pgp https://www.nlnetlabs.nl/downloads/unbound/unbound-1.9.0.tar.gz.a...Unbound 1.9.0 is available:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.9.0.tar.gz
sha256 415af94b8392bc6b2c52e44ac8f17935cc6ddf2cc81edfb47c5be4ad205ab917
pgp https://www.nlnetlabs.nl/downloads/unbound/unbound-1.9.0.tar.gz.asc
> This release contains the DNS Flag Day changes for Unbound. See the
> reference here, https://dnsflagday.net/ . Or this presentation:
> https://indico.dns-oarc.net/event/29/contributions/662/attachments/634/1063/EDNS_Flag_Day_-_OARC29.pdf
> . The EDNS timeouts are not used to fallback to nonEDNS queries.
>
> Out of order processing is implemented, for TCP and TLS. It can be
> configured with a maximum amount of memory to use to store pending
> answers, and the current memory usage is in the statistics output. This
> is with stream-wait-size in unbound.conf and mem.streamwait in
> unbound-control stats output. Streams that cause the total memory
> counted to exceed the maximum are dropped, but it is possible to get a
> number of responses with little memory used.
>
> There is also TLS session resumption support, that can be enabled with
> the tls-session-ticket-keys option. Together with the already existing
> TCP fast open, enabled with --enable-tfo-server --enable-tfo-client,
> that enables zero RTT stream reconnections to the server. Make sure to
> also increase incoming-num-tcp if you expect a lot of TCP and TLS users.
>
> Options are added to set the TLS ciphers and TLS ciphersuites from
> unbound.conf. This can be done with the tls-chiphers and
> tls-ciphersuites options.
>
> TLS can be used from libunbound, with the ub_ctx_set_tls config call,
> use that together with ub_ctx_set_fwd to select DNS over TLS transport.
>
>
> Features
> - log-tag-queryreply: yes in unbound.conf tags the log-queries and
> log-replies in the log file for easier log filter maintenance.
> - ip-ratelimit-factor of 1 allows all traffic through, instead of the
> previous blocking everything.
> - Fix #4206: **support openssl 1.0.2 for TLS hostname verification**,
> alongside the 1.1.0 and later support that is already there.
> - Add contrib/unbound-fuzzme.patch from Jacob Hoffman-Andrews,
> the patch adds a program used for fuzzing.
> - streamtcp option -a send queries consecutively and prints answers
> as they arrive.
> - out-of-order processing for TCP and TLS.
> - Add stream-wait-size: 4m config option to limit the maximum
> memory used by waiting tcp and tls stream replies. This avoids
> a denial of service where these replies use up all of the memory.
> - unbound-control stats has mem.streamwait that counts TCP and TLS
> waiting result buffers.
> - Patch from Manabu Sonoda with tls-ciphers and tls-ciphersuites
> options for unbound.conf.
> - Patch for TLS session resumption from Manabu Sonoda,
> enable with tls-session-ticket-keys in unbound.conf.
> - ub_ctx_set_tls call for libunbound that enables DoT for the machines
> set with ub_ctx_set_fwd. Patch from Florian Obser.
>
> Bug Fixes
> - Fix that unbound-checkconf does not complains if the config file
> is not placed inside the chroot.
> - Refuse to start with no ports.
> - Remove clang analysis warnings.
> - Patch for typo in unbound.conf man page.
> - Fix icon, no ragged edges and nicer resolutions available, for eg.
> Win 7 and Windows 10 display.
> - cache-max-ttl also defines upperbound of initial TTL in response.
> - Fix config parser memory leaks.
> - Fix for FreeBSD port make with dnscrypt and dnstap enabled.
> - **Fixup openssl 1.0.2 compile**
> - Fix for crash in dns64 module if response is null.
> - On FreeBSD warn if systcl settings do not allow server TCP FASTOPEN,
> and server tcp fastopen is enabled at compile time.
> - Document interaction between the tls-upstream option in the server
> section and forward-tls-upstream option in the forward-zone sections.
> - Fix syntax in comment of local alias processing.
> - Fix NSEC3 record that is returned in wildcard replies from
> auth-zone zones with NSEC3 and wildcards.
> - Log query name for looping module errors.
> - For caps-for-id fallback, use the whitelist to avoid timeout
> starting a fallback sequence for it.
> - increase mesh max activation count for capsforid long fetches.
> - Fix for #4219: secondaries not updated after serial change, unbound
> falls back to AXFR after IXFR gives several timeout failures.
> - Fix that auth zone after IXFR fallback tries the same master.
> - Fix for IXFR fallback to reset counter when IXFR does not timeout.
> - Newer aclocal and libtoolize used for generating configure scripts,
> aclocal 1.16.1 and libtoolize 2.4.6.
> - Fix unit test for python 3.7 new keyword 'async'.
> - clang analysis fixes, assert arc4random buffer in init,
> no check for already checked delegation pointer in iterator,
> in testcode check for NULL packet matches, in perf do not copy
> from NULL start list when growing capacity. Adjust host and file
> only when present in test header read to please checker. In
> testcode for unknown macro operand give zero result. Initialise the
> passed argv array in test code. In test code add EDNS data
> segment copy only when nonempty.
> - Patch from Florian Obser fixes some compiler warnings:
> include mini_event.h to have a prototype for mini_ev_cmp
> include edns.h to have a prototype for apply_edns_options
> sldns_wire2str_edns_keepalive_print is only called in the wire2str,
> module declare it static to get rid of compiler warning:
> no previous prototype for function
> infra_find_ip_ratedata() is only called in the infra module,
> declare it static to get rid of compiler warning:
> no previous prototype for function
> do not shadow local variable buf in authzone
> auth_chunks_delete and az_nsec3_findnode are only called in the
> authzone module, declare them static to get rid of compiler warning:
> no previous prototype for function...
> copy_rrset() is only called in the respip module, declare it
> static to get rid of compiler warning:
> no previous prototype for function 'copy_rrset'
> no need for another variable "r"; gets rid of compiler warning:
> declaration shadows a local variable in libunbound.c
> no need for another variable "ns"; gets rid of compiler warning:
> declaration shadows a local variable in iterator.c
> - Moved includes and make depend.
> - updated contrib/fastrpz.patch to cleanly diff.
> - remove compile warnings from libnettle compile.
> - output of newer lex 2.6.1 and bison 3.0.5.
> - Set build system for added call in the libunbound API.
> - List example config for root zone copy locally hosted with auth-zone
> as suggested from draft-ietf-dnsop-7706-bis-02. But with updated
> B root address.
> - Fixed spelling of tls-ciphers option in example.conf.Turris OS 3.11.3Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/319kernel-source package?2019-05-06T17:21:44+02:00Griefkernel-source package?How about providing us with the kernel-source package? It would be much easier to build kernel modules on the router itself. Now you can install Debian or Ubuntu in LXC container and compile sources in it. However, lack of kernel source ...How about providing us with the kernel-source package? It would be much easier to build kernel modules on the router itself. Now you can install Debian or Ubuntu in LXC container and compile sources in it. However, lack of kernel source package requires downloading of the kernel source separately and keeping it aligned with the latest Omnia's kernel version.
P.S. maybe linux-headers or kernel-headers is a better namehttps://gitlab.nic.cz/turris/os/packages/-/issues/318Missing kernel module rtl8192eu2019-05-06T17:21:45+02:00GriefMissing kernel module rtl8192euCould you please add this module to the Turris OS? I need this for TP-Link TL-WN821N v5.Could you please add this module to the Turris OS? I need this for TP-Link TL-WN821N v5.https://gitlab.nic.cz/turris/os/packages/-/issues/317pytest-xdist: add new package2023-08-16T14:49:30+02:00Jan Pavlinecpytest-xdist: add new packagexdist is used in deckard to run multiple tests in parallel https://pypi.org/project/pytest-xdist/xdist is used in deckard to run multiple tests in parallel https://pypi.org/project/pytest-xdist/Turris OS 5.2.0Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/316sync lang/python with upstream2023-08-16T14:55:24+02:00Jan Pavlinecsync lang/python with upstreamPackages in lang folder:
- [ ] cython
- [ ] python-bottle-i18n
- [ ] python-libatsha204
- [ ] python-pbkdf2
- [ ] python-periphery
- [ ] python-ubus
- [ ] pyzmqPackages in lang folder:
- [ ] cython
- [ ] python-bottle-i18n
- [ ] python-libatsha204
- [ ] python-pbkdf2
- [ ] python-periphery
- [ ] python-ubus
- [ ] pyzmqTurris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/315Remove packages and use the upstream one or send it to upstream2019-07-08T11:21:44+02:00Josef SchlehoferRemove packages and use the upstream one or send it to upstream* [x] logrotate (We have slightly modified logrotate.conf and cron job.)
* [x] w_scan (It's available in our repo could be pretty useful for DVB scanning, but currently it's not compiled.)
* [x] dvb-apps (as a replacement for w_scan)
...* [x] logrotate (We have slightly modified logrotate.conf and cron job.)
* [x] w_scan (It's available in our repo could be pretty useful for DVB scanning, but currently it's not compiled.)
* [x] dvb-apps (as a replacement for w_scan)
* [x] tor (Would you please look to this @jpavlinec?)
* [ ] tvheadend (The upstream has an old version and there were some unsuccessful attempts to update.) and also upstream CZ DVB-T2 MUXes
* [x] poco (@jpavlinec is this needed? Couldn't we use the upstream one?)
* [x] rrdtool-1.0.x ~~(No longer in upstream)~~ https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/315#note_96840
* [x] torsocks - https://github.com/openwrt/packages/pull/8099
* [x] hashdeep - https://github.com/openwrt/packages/pull/7792
* [x] ssdeep - https://github.com/openwrt/packages/pull/7982
* [x] czmq - https://github.com/openwrt/packages/pull/8014
* [x] dovecot - package in upstream is actively maintainedhttps://gitlab.nic.cz/turris/os/packages/-/issues/313nut-driver-apcsmart is missing2022-02-16T17:00:28+01:00Josef Schlehofernut-driver-apcsmart is missingIn our latest releases (Turris OS 3.11.x), we don't have package nut-driver-apcsmart, which we had in past (Turris OS 3.10.x). This package is available in Turris OS 4.x.In our latest releases (Turris OS 3.11.x), we don't have package nut-driver-apcsmart, which we had in past (Turris OS 3.10.x). This package is available in Turris OS 4.x.https://gitlab.nic.cz/turris/os/packages/-/issues/312openssh client fails to listen on ipv6 socket at boot time2019-05-15T09:35:01+02:00Ghost Useropenssh client fails to listen on ipv6 socket at boot timeobserved on 3.11.2 & 3.11.3 RC | `dnsmasq` removed and `odchpd` acting as sole dhcp server for both ipv4 and ipv6
___
```
config interface 'foo'
option type 'bridge'
option proto 'static'
option ifname 'eth2.3'
option ipaddr '192.16...observed on 3.11.2 & 3.11.3 RC | `dnsmasq` removed and `odchpd` acting as sole dhcp server for both ipv4 and ipv6
___
```
config interface 'foo'
option type 'bridge'
option proto 'static'
option ifname 'eth2.3'
option ipaddr '192.168.112.12'
option netmask '255.255.255.0'
option macaddr 'd8:58:d7:00:87:5c'
list ip6addr 'fd30:d64c:1eed:4c3a::12'
```
```
config openssh
option AddressFamily any
list ListenAddress 192.168.112.12
list ListenAddress fd30:d64c:1eed:4c3a::12
```
___
upon system boot `sshd` has the ipv4 socket up but not the ipv6 socket. Once the system is fully booted the ipv6 socket for sshd becomes available *only after manually restarting/reloading* `sshd`
This likely being caused by `sshd` starting prior the releated ipv6 iface (foo) is fully up. Supposedly `sshd` should only start after the target iface is fully online.https://gitlab.nic.cz/turris/os/packages/-/issues/310lua vs. luajit libraries2023-08-16T14:57:52+02:00Vladimír Čunátvladimir.cunat@nic.czlua vs. luajit librariesAs it is now, no lua libraries are usable from kresd, except those that come with luajit or kresd itself.
Well it doesn't really need any ATM, because we don't do root trust anchor bootstrapping, http module or other less usual stuff. ...As it is now, no lua libraries are usable from kresd, except those that come with luajit or kresd itself.
Well it doesn't really need any ATM, because we don't do root trust anchor bootstrapping, http module or other less usual stuff. I guess cqueues would be considered useful by some, as we'll add auto-reloading feature for RPZ that depends on that.
I actually don't know how the `*.so` parts of lua libs are shareable between vanilla lua and luajit. That would need investigation. I've seen distros packaging for each implementation separately (5.1, 5.2, luajit), but I don't know if that's truly necessary.
Cross-link that brought me to this: https://forum.turris.cz/t/luajit-require-not-work-in-omnii/9289