Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2019-07-22T19:59:57+02:00https://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/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/192luci-app-unbound is a no show2019-07-08T11:07:14+02:00Ghost Userluci-app-unbound is a no showmentioned here https://forum.turris.cz/t/luci-app-unbound-is-a-no-show/7308mentioned here https://forum.turris.cz/t/luci-app-unbound-is-a-no-show/7308https://gitlab.nic.cz/turris/os/packages/-/issues/405[syslog-ng] stop | restart not working2019-06-10T13:17:06+02:00Ghost User[syslog-ng] stop | restart not working"4.14.123","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta2","revision":"a6dba1a","target":"mvebu\/cortexa9","d..."4.14.123","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta2","revision":"a6dba1a","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta2 a6dba1a"}}
___
`/etc/init.d/syslog-ng stop` does not kill the process and instead it remains running. Also its `upd` socket remains alive.
Looking at with `htop` is seems that one `syslog-ng` child instance of its parent `supervising syslog-ng` gets terminated whilst a secondary child instance stays alive and the parent also does not terminate.
similar `/etc/init.d/syslog-ng restart`, the PID remains the same after the command been executed and it can be tested also by adding another destination in the syslog-ng conf. After the command been executed there is no file at the added destination. However, killing and starting the process manually the new log file is appearing at the added destination.
As a causality train post-installation scripts that restart `syslog-ng` do not report a fail of the restart whilst an actual restart did not happen. Same for logrotate with
```
postrotate
/etc/init.d/syslog-ng restart
```
Enclosed the `strace` logs for both events. [restart](/uploads/51e771530f577a017689333155122913/restart) [stop](/uploads/263831a45cf003dc26fd5bb346ac666a/stop)https://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/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/285provide package from upstream for running unpriviliged lxc containers on the TO2019-06-05T18:48:15+02:00Ghost Userprovide package from upstream for running unpriviliged lxc containers on the TOApparently [this package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/lxc-unprivileged_2.1.1-2_arm_cortex-a9.ipk) being essential for running unprivilged containers on OpenWRT, however it appears absent...Apparently [this package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/lxc-unprivileged_2.1.1-2_arm_cortex-a9.ipk) being essential for running unprivilged containers on OpenWRT, however it appears absent from the TO repo.
cross reference https://patchwork.ozlabs.org/patch/844848/
It would nessessitate an up to date shadow package https://patchwork.ozlabs.org/patch/837829/ for newgidmap and newuidmap mapping.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/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/377resolver/unbound not listening on ipv6 iface2019-05-14T18:38:53+02:00Ghost Userresolver/unbound not listening on ipv6 iface@jpavlinec
TOS 3.11.4 | unbound 1.9.1
/etc/config/resolver
```
config resolver 'common'
list interface '127.0.0.1'
list interface '192.168.112.12'
list interface '::1'
list interface 'fd30:d64c:1eed:4c3a::12'
option forward_upstre...@jpavlinec
TOS 3.11.4 | unbound 1.9.1
/etc/config/resolver
```
config resolver 'common'
list interface '127.0.0.1'
list interface '192.168.112.12'
list interface '::1'
list interface 'fd30:d64c:1eed:4c3a::12'
option forward_upstream '0'
option prefered_resolver 'unbound'
option ignore_root_key '0'
option static_domains '1'
option dynamic_domains '1'
option keyfile '/etc/root.keys'
config resolver 'kresd'
option rundir '/tmp/kresd'
option log_stderr '1'
option log_stdout '1'
option forks '1'
option keep_cache '1'
#option include_config '/tmp/kresd.custom.conf'
#list hostname_config '/etc/hosts'
#list rpz_file '/tmp/file.rpz'
config resolver 'unbound'
option dhcp_link 'odhcpd'
option root_hints '/etc/unbound/named.cache'
config resolver 'unbound_includes'
list include_path "/etc/unbound/unbound_srv.conf"
list include_path "/etc/unbound/unbound_ext.conf"
config resolver 'unbound_remote_control'
option control_enable 'yes'
option control_use_cert 'no'
list control_interface '::1'
list control_interface '127.0.0.1'
```
With the above config it is expected that the resolver/unbound would be listening on the respective ipv4/ipv6 ifaces/addresses but it is only listening on the listed ipv4 ifaces/addresses but not on the ipv6.
![listening_ports](/uploads/74f0d80b246c432d69b6956d7a25c11e/listening_ports.png)Jan PavlinecJan Pavlinechttps://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/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/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/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/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/97mt76 - fix build error2019-05-06T17:21:41+02:00Josef Schlehofermt76 - fix build errormt76 [was](https://gitlab.labs.nic.cz/turris/openwrt/commit/65d2b7e2d74daf5e4c85fe9ee3e408d429e474e3#8b78dc46afb71709deefbbac0b0a67e21406fbe5) in Turris repo, but nowdays it isn't included.
According to @mhrusecky it doesn't build.
Mo...mt76 [was](https://gitlab.labs.nic.cz/turris/openwrt/commit/65d2b7e2d74daf5e4c85fe9ee3e408d429e474e3#8b78dc46afb71709deefbbac0b0a67e21406fbe5) in Turris repo, but nowdays it isn't included.
According to @mhrusecky it doesn't build.
More details here:
https://forum.turris.cz/t/3-8-3-in-rc-dnsmasq-security-fixes-and-more/5290/7?u=pepe
https://forum.turris.cz/t/3-8-3-in-rc-dnsmasq-security-fixes-and-more/5290/10?u=pepehttps://gitlab.nic.cz/turris/os/packages/-/issues/23Can we get pulseaudio-daemon-avahi?2019-05-06T17:21:40+02:00Michal ČihařCan we get pulseaudio-daemon-avahi?Is there chance to include pulseaudio built with avahi support? It's necessary to make network sound server work without any configuration on clients.
See also https://wiki.openwrt.org/doc/howto/pulseaudio#avahizeroconfIs there chance to include pulseaudio built with avahi support? It's necessary to make network sound server work without any configuration on clients.
See also https://wiki.openwrt.org/doc/howto/pulseaudio#avahizeroconfJan PavlinecJan Pavlinechttps://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