Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2019-05-08T17:07:08+02:00https://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/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/309ddns-scripts: ERROR : IP update not accepted by DDNS Provider2022-02-16T17:00:46+01:00Darshaka Pathiranaddns-scripts: ERROR : IP update not accepted by DDNS ProviderUpdating the IP reports an error, but the update itself is successful:
```
123228 : Waiting 600 seconds (Check Interval)
124228 : Detect registered/public IP
124228 : #> /bin/nslookup myexample.ddnss.org >/var/run/...Updating the IP reports an error, but the update itself is successful:
```
123228 : Waiting 600 seconds (Check Interval)
124228 : Detect registered/public IP
124228 : #> /bin/nslookup myexample.ddnss.org >/var/run/ddns/myddns_ipv4.dat 2>/var/run/ddns/myddns_ipv4.err
124228 : Registered IP '213.xx.xx.84' detected
124228 info : Rerun IP check at 2019-01-22 12:42
124228 : Detect local IP on 'network'
124228 : Local IP '213.xx.xx.84' detected on network 'wan'
124228 : Forced Update - L: '213.xx.xx.84' == R: '213.xx.xx.84'
124228 : #> /usr/bin/curl -RsS -o /var/run/ddns/myddns_ipv4.dat --stderr /var/run/ddns/myddns_ipv4.err --noproxy '*' 'http://ip4.ddnss.de/upd.php?user=myusername&pwd=***PW***&host=myexample.ddnss.org&ip=213.xx.xx.84'
124229 : DDNS Provider answered:
<head>
<meta name="robots" content="noindex">
<title>DDNSS - Kostenloser DynDNS Service : Re-ProutDNS v5.01v</title>
</head>
<body>
<p><font face="Verdana" size="2"></font></p>
<p><font face="Verdana" size="2">Updated 1 hostname.</font></p>
</body>
124229 ERROR : IP update not accepted by DDNS Provider
124229 : Waiting 600 seconds (Check Interval)
```
I've created an upstream issue: https://github.com/openwrt/packages/issues/8013
I am not sure, if this can be fixed on our side until it is fixed on upstream.https://gitlab.nic.cz/turris/os/packages/-/issues/308provide dependant for open-plc-utils-mdiogen2019-07-08T11:07:17+02:00Ghost Userprovide dependant for open-plc-utils-mdiogenWith `open-plc-utils-mdiogen` available in the TOS 3.11.2 repo its dependant is missing however
> ERROR:
> inconsistent: Package open-plc-utils-mdiogen *requires package open-plc-utils that is not available*.With `open-plc-utils-mdiogen` available in the TOS 3.11.2 repo its dependant is missing however
> ERROR:
> inconsistent: Package open-plc-utils-mdiogen *requires package open-plc-utils that is not available*.https://gitlab.nic.cz/turris/os/packages/-/issues/307logread wrapper for LuCI packages2019-07-22T19:59:57+02:00Josef Schlehoferlogread wrapper for LuCI packagesI'm in touch with @dibdot and he said that Turris OS 4.x still doesn't have a wrapper for logread, which means e.g. **System Log** tab in LuCI is empty. He sent me a small [wrapper](/uploads/d13fb9996193f517aca3cda69dd8f325/logread), whi...I'm in touch with @dibdot and he said that Turris OS 4.x still doesn't have a wrapper for logread, which means e.g. **System Log** tab in LuCI is empty. He sent me a small [wrapper](/uploads/d13fb9996193f517aca3cda69dd8f325/logread), which we can re-use and copy it to /sbin. :-)
For now, I'm thinking about these solutions:
* add a dependency for syslog-ng to logread
* add logread to files in sys-log and copy it to /sbin
* and maybe more coming later?
I think this could also solve issues like this:
https://forum.turris.cz/t/logread-broken/1181/ (reproducible on Turris Omnia, TOS 3.11.2)
https://forum.turris.cz/t/combination-of-syslog-ng-luci-system-logging-configuration-mwan3/5975Turris OS 3.11.3https://gitlab.nic.cz/turris/os/packages/-/issues/305nextcloud (15.0.2) occ command broken due to missing php on PATH2022-02-16T17:01:02+01:00cmacq2nextcloud (15.0.2) occ command broken due to missing php on PATHThe `occ` script to manage the nextcloud from the command line has the following shebang: `#!/usr/bin/env php`
Checking over SSH, `$PATH` is set to: `/usr/bin:/usr/sbin:/bin:/sbin` and `which php` cannot find a `php` executable.
A fix c...The `occ` script to manage the nextcloud from the command line has the following shebang: `#!/usr/bin/env php`
Checking over SSH, `$PATH` is set to: `/usr/bin:/usr/sbin:/bin:/sbin` and `which php` cannot find a `php` executable.
A fix could be to add symlink: `ln -s /usr/bin/php-cli /usr/bin/php`.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/304nextcloud (15.0.2) lighttpd configuration broken2021-11-08T09:26:29+01:00cmacq2nextcloud (15.0.2) lighttpd configuration brokenUpgraded nextcloud from 14.06 to 15.02. The security check now complains about a missing `Referrer-Policy` header when, in fact, two `Referrer-Policy` headers are sent by the server.
It looks like as of 15.02 the previous fix for `/etc/...Upgraded nextcloud from 14.06 to 15.02. The security check now complains about a missing `Referrer-Policy` header when, in fact, two `Referrer-Policy` headers are sent by the server.
It looks like as of 15.02 the previous fix for `/etc/lighttpd/conf.d/nextcloud` to add this header is no longer applicable:
```
alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )
$HTTP["url"] =~ "^/nextcloud" {
# Add 'X-Frame-Options' header, making sure it the website is not embedded in a frame or iframe.
# This avoids clickjacking, and might be helpfull for HTTPS websites
# As frames are not used nowadays, this should be safe to enable at least SAMEORIGIN
# Other option might be DENY or ALLOW-FROM. DENY is not used as frame is used in some old LuCI modules
#setenv.add-response-header += ( "X-Frame-Options" => "SAMEORIGIN")
setenv.add-response-header += ( "Referrer-Policy" => "no-referrer")
}
$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
url.access-deny = ("")
}
```
Should now probably be:
```
alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )
$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
url.access-deny = ("")
}
```https://gitlab.nic.cz/turris/os/packages/-/issues/293nextcloud installation failing due to missing dependant perlbase-utf82023-08-01T11:53:49+02:00Ghost Usernextcloud installation failing due to missing dependant perlbase-utf8Reported in [TO forum](https://forum.turris.cz/t/nextcloud-error-installation/8765) the NC installation fails apparently due to missing the dependant `perlbase-utf8`. Installing `perlbase-utf8` appears to resolve the issue.
![c8ae1b7dfa...Reported in [TO forum](https://forum.turris.cz/t/nextcloud-error-installation/8765) the NC installation fails apparently due to missing the dependant `perlbase-utf8`. Installing `perlbase-utf8` appears to resolve the issue.
![c8ae1b7dfaf4a3d01899081fbba946600486481e](/uploads/3eec960bf39467c8588553ed16913f0f/c8ae1b7dfaf4a3d01899081fbba946600486481e.png)Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/291static route not being applied when a four 8-bit octets ipv4 subnet mask is set2019-06-05T19:03:24+02:00Ghost Userstatic route not being applied when a four 8-bit octets ipv4 subnet mask is setTOS 3.11.1
Adding a static subnet route via LuCI or ssh file edit the route is not applied when a subnet mask is set via four 8-bit octets. The route however is applied if the netmask is omitted and 255.255.255.255 is assumed and thus m...TOS 3.11.1
Adding a static subnet route via LuCI or ssh file edit the route is not applied when a subnet mask is set via four 8-bit octets. The route however is applied if the netmask is omitted and 255.255.255.255 is assumed and thus makes the target subnet a host address instead of a subnet.
According to the [upstream documentation](https://openwrt.org/docs/guide-user/network/routes_configuration) the syntax for subnets in ipv4 and ipv6 differs and yet seems that the ipv4 subnet mask for the target network receives the same parsing treatment as ipv6, i.e not as four 8-bit octets but its equivalent integer.
Not working (though it would be expected)
```
config route
option interface 'foobar'
option target 'ip'
option gateway 'ip'
option netmask ‘255.255.255.0’
```
Working instead (which is rather unexpected)
```
config route
option interface 'foobar'
option target 'ip/24'
option gateway 'ip'
```
Not sure whether it is a bug or by design and latter not having made into the documentation.
TO forum cross reference https://forum.turris.cz/t/static-route-not-applied/8525https://gitlab.nic.cz/turris/os/packages/-/issues/290provide dependant for luci-app-wifischedule2019-05-14T18:50:05+02:00Ghost Userprovide dependant for luci-app-wifischeduleWith `luci-app-wifischedule` available in the TOS 3.11.1 repo [its dependant](https://github.com/openwrt/packages/tree/openwrt-18.06/net/wifischedule) is missing however
> ERROR:
> inconsistent: Package luci-app-wifischedule requires pa...With `luci-app-wifischedule` available in the TOS 3.11.1 repo [its dependant](https://github.com/openwrt/packages/tree/openwrt-18.06/net/wifischedule) is missing however
> ERROR:
> inconsistent: Package luci-app-wifischedule requires package wifischedule that is not available.Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/283lxc.utsname not being parsed into container's hostname2019-05-06T17:21:52+02:00Ghost Userlxc.utsname not being parsed into container's hostnameWith the container's config `lxc.utsname = foobar` it would be expected that the container's hostname would be matching `foobar` (parsed into hostname file of the respective container).
However, having tested various container installat...With the container's config `lxc.utsname = foobar` it would be expected that the container's hostname would be matching `foobar` (parsed into hostname file of the respective container).
However, having tested various container installation the hostname ends up being the standard one of the respective distro, e.g. this one ArchLinux
https://forum.turris.cz/uploads/default/original/2X/8/824139afea2ab70c51fc45b12a92292fe3297e8b.png
TOS RC 3.11.1 |
liblxc 1.1.5-15 |
luci-app-lxc 20160616-1 |
lxc 1.1.5-15 |
lxc-attach 1.1.5-15 |
lxc-auto 1.1.5-15 |
lxc-autostart 1.1.5-15 |
lxc-cgroup 1.1.5-15 |
lxc-checkconfig 1.1.5-15 |
lxc-clone 1.1.5-15 |
lxc-common 1.1.5-15 |
lxc-config 1.1.5-15 |
lxc-configs 1.1.5-15 |
lxc-console 1.1.5-15 |
lxc-create 1.1.5-15 |
lxc-destroy 1.1.5-15 |
lxc-device 1.1.5-15 |
lxc-execute 1.1.5-15 |
lxc-freeze 1.1.5-15 |
lxc-hooks 1.1.5-15 |
lxc-info 1.1.5-15 |
lxc-init 1.1.5-15 |
lxc-ls 1.1.5-15 |
lxc-lua 1.1.5-15 |
lxc-monitor 1.1.5-15 |
lxc-monitord 1.1.5-15 |
lxc-snapshot 1.1.5-15 |
lxc-start 1.1.5-15 |
lxc-stop 1.1.5-15 |
lxc-templates 1.1.5-15 |
lxc-unfreeze 1.1.5-15 |
lxc-unshare 1.1.5-15 |
lxc-user-nic 1.1.5-15 |
lxc-usernsexec 1.1.5-15 |
lxc-wait 1.1.5-15 |
rpcd-mod-lxc 20141012https://gitlab.nic.cz/turris/os/packages/-/issues/282static DHCP lease times neglected2019-08-03T17:16:49+02:00Ghost Userstatic DHCP lease times neglectedTOS RC 3.11.1 | dnsmasq-full 2.78-3
"/etc/config/dhcp"
```
config dhcp 'lan'
option leasetime '1h'
config host
option leasetime '7d'
```
The lease time for the host does not exceed 1h from the lan setting. It would be expected that...TOS RC 3.11.1 | dnsmasq-full 2.78-3
"/etc/config/dhcp"
```
config dhcp 'lan'
option leasetime '1h'
config host
option leasetime '7d'
```
The lease time for the host does not exceed 1h from the lan setting. It would be expected that lease times set for hosts are honoured.https://gitlab.nic.cz/turris/os/packages/-/issues/280sfdisk build config2019-05-06T17:21:53+02:00Ghost Usersfdisk build configTOS 3.11 stable | sfdisk 2.29.2-1
`sfdisk`
```
/usr/sbin/sfdisk: line 143: /home/beast/beast/workspace/omnia-master/staging_dir/host/bin/sed: No such file or directory
/usr/sbin/sfdisk: line 147: /home/beast/beast/workspace/omnia-master...TOS 3.11 stable | sfdisk 2.29.2-1
`sfdisk`
```
/usr/sbin/sfdisk: line 143: /home/beast/beast/workspace/omnia-master/staging_dir/host/bin/sed: No such file or directory
/usr/sbin/sfdisk: line 147: /home/beast/beast/workspace/omnia-master/staging_dir/host/bin/sed: No such file or directory
/usr/sbin/sfdisk: line 199: cd: /home/beast/beast/workspace/omnia-master/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.15_eabi/util-linux-2.29.2: No such file or directory
/usr/sbin/sfdisk: line 199: ccache_cc: command not found
```Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/270wlan iface name convention clash2019-05-06T17:21:52+02:00Ghost Userwlan iface name convention clash@kkoci
Whilst the issue is not present with the `eth` iface name convention I noticed that there is a problem with the `wlan` iface names clashing and impeding the iface settings, at least their mtu but it might spread to other setting...@kkoci
Whilst the issue is not present with the `eth` iface name convention I noticed that there is a problem with the `wlan` iface names clashing and impeding the iface settings, at least their mtu but it might spread to other settings too and casuse some unintended issues and thus wanted to let you know at least.
test bed
```
/etc/config/wireless
config wifi-iface
option device 'radio0'
option ifname 'wlan1'
option network 'lan'
option mode 'ap'
option ieee80211w '1'
config wifi-iface
option device 'radio0'
option ifname 'wlan2'
option network 'guest'
option mode 'ap'
option ieee80211w '1'
config wifi-iface
option device 'radio1'
option ifname 'wlan3'
option network 'lan'
option mode 'ap'
option ieee80211w '1'
```
```
/etc/config/network/
config device
option name wlan1
option mtu 2304
config device
option name wlan2
option mtu 2304
config device
option name wlan3
option mtu 2304
```
After the network is restarted and all ifaces are fully up *only one out of the three* `wlan` ifaces has the correct mtu. Changing the name convention to the below and *all 3* `wlan` ifaces are showing the correct mtu.
```
/etc/config/wireless
config wifi-iface
option device 'radio0'
option ifname 'buffalo'
option network 'lan'
option mode 'ap'
option ieee80211w '1'
config wifi-iface
option device 'radio0'
option ifname 'elephant'
option network 'guest'
option mode 'ap'
option ieee80211w '1'
config wifi-iface
option device 'radio1'
option ifname 'tiger'
option network 'lan'
option mode 'ap'
option ieee80211w '1'
```
```
/etc/config/network/
config device
option name buffalo
option mtu 2304
config device
option name elephant
option mtu 2304
config device
option name tiger
option mtu 2304
```https://gitlab.nic.cz/turris/os/packages/-/issues/268Turris OS 3.11: miniupnpd no longer starts at router boot2019-05-06T17:21:51+02:00Tony QuanTurris OS 3.11: miniupnpd no longer starts at router bootStarting in Turris OS 3.11, miniupnpd isn't automatically started at router boot, even though it is configured in the init scripts as enabled/start on boot.
Problem seems to be with ``/etc/init.d/miniupnpd`` in particular how ``boot()``...Starting in Turris OS 3.11, miniupnpd isn't automatically started at router boot, even though it is configured in the init scripts as enabled/start on boot.
Problem seems to be with ``/etc/init.d/miniupnpd`` in particular how ``boot()`` is written
```
boot() {
return
}
```
Since boot does nothing, and boot() if present is run instead of start() at router boot up, this means miniupnpd is never started. I commented out this part of the script and now miniupnpd starts properly. The odd part though is that this init script seems to have no recent changes in the last 2 years. Possibly something else was starting miniupnpd before 3.11 and whatever that was is no longer doing so?Turris OS 3.11.1Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/260update hostapd/wpad/wpad-mesh to current OpenWRT version 2018-04-09-fa617ee6-52019-06-05T19:07:13+02:00Ghost Userupdate hostapd/wpad/wpad-mesh to current OpenWRT version 2018-04-09-fa617ee6-5The current package version 2016-12-19-8 in the TO repo is almost 2 years of age and since then there are various updates/fixes pushed in the OpenWRT repo.
https://openwrt.org/packages/pkgdata/hostapdThe current package version 2016-12-19-8 in the TO repo is almost 2 years of age and since then there are various updates/fixes pushed in the OpenWRT repo.
https://openwrt.org/packages/pkgdata/hostapdhttps://gitlab.nic.cz/turris/os/packages/-/issues/231ddns-script: reboot bug2023-08-16T14:57:58+02:00Jan Pavlinecddns-script: reboot bugddns-script is causing rebootddns-script is causing reboothttps://gitlab.nic.cz/turris/os/packages/-/issues/218shadowsocks-libev: update to version 3.2.02023-08-16T14:58:20+02:00Josef Schlehofershadowsocks-libev: update to version 3.2.0Package name: **shadowsocks-libev**
Short description of the package: **lightweight implementation of shadowsocks protocol**
OpenWRT repository:
https://github.com/openwrt/packages/tree/master/net/shadowsocks-libev
Upstream repos...Package name: **shadowsocks-libev**
Short description of the package: **lightweight implementation of shadowsocks protocol**
OpenWRT repository:
https://github.com/openwrt/packages/tree/master/net/shadowsocks-libev
Upstream repository:
https://github.com/shadowsocks/shadowsocks-libev/
_Version information_
We have version: 2.2.3.
Upstream and OpenWRT have version: 3.2.0
Dependencies:
* [x] libcares
We have version: 1.11.0
Upstream and OpenWRT have version: 1.14.0 ( https://github.com/openwrt/packages/blob/master/libs/c-ares/Makefile )
* [x] libev
We have version: 4.22
Upstream and OpenWRT have version: 4.22 ( https://github.com/openwrt/packages/blob/master/libs/libev/Makefile )
* [x] libpcre (commit in dev branch: https://gitlab.labs.nic.cz/turris/turris-os-packages/commit/57fb7f173d90ea6b299599a00b705b06b923915f)
We have version: 8.41
Upstream and OpenWRT have version: 8.42 ( https://github.com/openwrt/packages/blob/master/libs/pcre/Makefile )
* [ ] libpthread
We have version: 1.1.15
Upstream and OpenWRT have version:
* [x] libsodium
We have version: 1.0.10
Upstream and OpenWRT have version: 1.0.16 ( https://github.com/openwrt/packages/tree/master/libs/libsodium )
* [x] libmbedtls (commit in dev branch: https://gitlab.labs.nic.cz/turris/openwrt/commit/70303e1c8cb9b4734bb02479fb952078ffc14ff2)https://gitlab.nic.cz/turris/os/packages/-/issues/213update OpenSSL to 1.1.1 for applications (unbound) being reliant on it2019-05-06T13:57:06+02:00Ghost Userupdate OpenSSL to 1.1.1 for applications (unbound) being reliant on ithttps://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658#c16
> Do you have openssl 1.1.x? **Without that the SSL_set1_host call is not available, and unbound does not do verification**. This is detected at configure time, though.
> Yo...https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=658#c16
> Do you have openssl 1.1.x? **Without that the SSL_set1_host call is not available, and unbound does not do verification**. This is detected at configure time, though.
> You can see what openssl is linked with unbound with unbound -h
---
`unbound -h`
> Version 1.7.3
> linked libs: pluggable-event internal (it uses select), **OpenSSL 1.0.2o** 27 Mar 2018Jan PavlinecJan Pavlinec