Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2022-12-03T15:54:21+01:00https://gitlab.nic.cz/turris/os/packages/-/issues/869turris-maintain: use tar command relative path for "maintain-config-backup" s...2022-12-03T15:54:21+01:00Martin Matějekturris-maintain: use tar command relative path for "maintain-config-backup" scriptReported on forum: https://forum.turris.cz/t/turris-os-6-0-is-released/17830/147
> /bin/tar is not a symbolic link to busybox now, but to /usr/libexec/tar-gnu.
>
> In your script /usr/bin/maintain-config-backup you use /usr/bin/tar as ...Reported on forum: https://forum.turris.cz/t/turris-os-6-0-is-released/17830/147
> /bin/tar is not a symbolic link to busybox now, but to /usr/libexec/tar-gnu.
>
> In your script /usr/bin/maintain-config-backup you use /usr/bin/tar as a command, but this link is now missing completely.Turris OS 6.0.2https://gitlab.nic.cz/turris/os/packages/-/issues/865Rainbow package is missing compat.sh file2023-08-16T14:54:03+02:00Josef SchlehoferRainbow package is missing compat.sh fileReported here: https://forum.turris.cz/t/po-upgrade-nefunguje-rainbow/17916?u=pepeReported here: https://forum.turris.cz/t/po-upgrade-nefunguje-rainbow/17916?u=pepeTurris OS 6.0.1https://gitlab.nic.cz/turris/os/packages/-/issues/864Turris OS 6.0, HBS autoupdate broke WAN2022-10-21T18:14:26+02:00qbitr8Turris OS 6.0, HBS autoupdate broke WANI have cold booted modem without Turris connected, cold booted Turris then connected LAN cable. ROKU (multiple) connect and work. Phones and tablet complain that they connect but without internet. Phones and tablet wifi connection pass...I have cold booted modem without Turris connected, cold booted Turris then connected LAN cable. ROKU (multiple) connect and work. Phones and tablet complain that they connect but without internet. Phones and tablet wifi connection passwords have been "forgotten" and retyped.
Device Turris Omnia
Serial number 47244694365
reForis version 1.3.1
Turris OS version 6.0
Turris OS branch HBS
Kernel version 5.15.74
--Attempted to update via ssh
# pkgupdate
line not found
line not found
line not found
ERROR:
runtime: [string "requests"]:432: [string "utils"]:443: Unable to finish URI (https://repo.turris.cz/hbs/omnia/lists/pkglists/3g.lua): Download failed: Could not resolve host: repo.turris.cz
--ssh
# check_connection
Pinging 24.26.128.1 ... OK
IPv4 Gateway: OK
Pinging 217.31.205.50 ... OK
Pinging 198.41.0.4 ... OK
Pinging 199.7.83.42 ... OK
Pinging 8.8.8.8 ... OK
IPv4: OK
Pinging fe80::201:5cff:fe8d:2a46%eth2 ... OK
IPv6 Gateway: OK
Pinging 2001:1488:0:3::2 ... OK
Pinging 2001:500:3::42 ... OK
Pinging 2001:500:2d::d ... OK
Pinging 2606:2800:220:6d:26bf:1447:1097:aa7 ... OK
IPv6: OK
Resolving repo.turris.cz ... FAILED
Resolving www.nic.cz ... FAILED
Resolving c.root-servers.net ... FAILED
DNS: FAILED
DNSSEC: UNKNOWN
# cat /etc/config/dhcp
config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option localservice '1'
option port '53'
option nonwildcard '0'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
config dhcp 'lan'
option interface 'lan'
option start '100'
option dhcpv6 'server'
option ra 'server'
option ignore '0'
option leasetime '43200'
option limit '50'
list dhcp_option '6,172.28.19.1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
config domain
***
I couldn't fix it with my limited skills so I rolled it back to "Automatic pre-update snapshot (TurrisOS 5.4.4)". All is well.https://gitlab.nic.cz/turris/os/packages/-/issues/861Include turris-diagnostics-web package2022-10-19T16:00:47+02:00Aleksandr GumroianInclude turris-diagnostics-web packageFor some reason, I was not able to access the diagnostics web, with @mmatejek we found out that it should be installed first via `opkg`.
The package is named `turris-diagnostics-web`.For some reason, I was not able to access the diagnostics web, with @mmatejek we found out that it should be installed first via `opkg`.
The package is named `turris-diagnostics-web`.https://gitlab.nic.cz/turris/os/packages/-/issues/860No wifi on Turris 1.0 after upgrade to Turris OS 6.02022-10-19T14:37:12+02:00Vlastimil ZimaNo wifi on Turris 1.0 after upgrade to Turris OS 6.0Turris 1.0 router is broken after upgrade to TurrisOS 6.0:
* Wifi dies and probably takes the whole router with it. I can't connect to it any more.
* When restarted, wifi is off and can't be set up. Reforis shows warning "Unfortunately,...Turris 1.0 router is broken after upgrade to TurrisOS 6.0:
* Wifi dies and probably takes the whole router with it. I can't connect to it any more.
* When restarted, wifi is off and can't be set up. Reforis shows warning "Unfortunately, we were unable to detect any wireless cards in your router."
* WAN seem to be off after restart as well. Not sure if it's connected or not.
* Factory reset doesn't help. Wifi can be set up correctly, but it fails after a short while and goes back to point 1.https://gitlab.nic.cz/turris/os/packages/-/issues/859Web UI openly available on wan after TurrisOS 6.0 update, until reboot2022-10-20T23:28:26+02:00LinAGKarWeb UI openly available on wan after TurrisOS 6.0 update, until rebootAfter the update to TurrisOS 6.0, reForis was openly available from the internet (though LuCi was broken), and what's worse, it didn't require a password. It stopped happening after reboot, but administration was briefly openly available...After the update to TurrisOS 6.0, reForis was openly available from the internet (though LuCi was broken), and what's worse, it didn't require a password. It stopped happening after reboot, but administration was briefly openly available to the internet, until I noticed the router was broken and rebooted it. It did not reboot automatically, presumably due to #858. I notice that lighttpd is listening on all interfaces (0.0.0.0), it would be better if it only listened on br-lan.
I don't know if this is related, but I've got some port forwardings from port 80 and 443 on wan to a local computer, but wan input is set to REJECT.https://gitlab.nic.cz/turris/os/packages/-/issues/856cronie: update to version 1.6.12023-08-16T14:40:52+02:00Josef Schlehofercronie: update to version 1.6.1Turris OS 6.0.4https://gitlab.nic.cz/turris/os/packages/-/issues/854lighttpd run it under its own user2023-08-16T14:35:34+02:00Josef Schlehoferlighttpd run it under its own user1. Our Lighttpd package runs under root
- Related: https://gitlab.nic.cz/turris/os/packages/-/commit/f699fff40ce2e9c2607ad4f1536268d3135472ae + https://forum.turris.cz/t/shield-s-hbk-nefunguje-reforis/17711 (you need to start lighttpd ...1. Our Lighttpd package runs under root
- Related: https://gitlab.nic.cz/turris/os/packages/-/commit/f699fff40ce2e9c2607ad4f1536268d3135472ae + https://forum.turris.cz/t/shield-s-hbk-nefunguje-reforis/17711 (you need to start lighttpd manually = ``lighttpd -D -f /etc/lighttpd/lighttpd.conf``)
2. OpenWrt package runs under http/www-data
- User and group its created by its init script, which I find odd. It should be done by Makefile.
- [ ] Switch to upstream solution
- [ ] Drop lighttpd from our feedTurris OS 6.2.0Filip HronFilip Hronhttps://gitlab.nic.cz/turris/os/packages/-/issues/852turris-maintain: fix IP addresses order in notification2022-10-20T16:25:08+02:00Martin Matějekturris-maintain: fix IP addresses order in notificationFollowup of !959
Unfortunately, we missed few pieces that needed to be adjusted as well.
It is still possible to get list of IP addresses in notification in random order.Followup of !959
Unfortunately, we missed few pieces that needed to be adjusted as well.
It is still possible to get list of IP addresses in notification in random order.Turris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/849Avoid usage of mtdblock2024-02-16T10:50:43+01:00Ghost UserAvoid usage of mtdblockmtdblock is another layer on top of mtd which in most cases (since Linux 3.0 and new busybox) is unnecessary. For reading or mounting FS from mtd is enough to use just mtd device.
For example this file mounts `/dev/mtdblock4` with jffs2...mtdblock is another layer on top of mtd which in most cases (since Linux 3.0 and new busybox) is unnecessary. For reading or mounting FS from mtd is enough to use just mtd device.
For example this file mounts `/dev/mtdblock4` with jffs2 filesystem: \
https://gitlab.nic.cz/turris/os/packages/-/blob/master/hardware/cert-backup/files/turris1x_backend.sh \
Replacing `/dev/mtdblock4` by just `mtd4` also works fine and avoids usage of unnecessary mtdblock layer.
For mount and read cases simple `sed 's/\/dev\/mtdblock/mtd/g'` is enough.Turris OS 6.2.0Tomas ZakTomas Zakhttps://gitlab.nic.cz/turris/os/packages/-/issues/848Nextcloud - forbidden2023-08-16T14:35:36+02:00Josef SchlehoferNextcloud - forbiddenIn Turris OS 6.0, Nextcloud does not work as it shows "403 Forbidden". This was tested in new Nextcloud installations, but it should affect the existing ones.In Turris OS 6.0, Nextcloud does not work as it shows "403 Forbidden". This was tested in new Nextcloud installations, but it should affect the existing ones.Turris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/846Turris 1.x Btrfs kernel install can not find boot.scr2022-08-11T19:44:31+02:00Josef SchlehoferTurris 1.x Btrfs kernel install can not find boot.scrPackage: turris1x-btrfs
```
root@turris:~# /usr/sbin/turris1x-btrfs-kernel-install
cmp: /boot/boot.scr: No such file or directory
cp: can't stat '/boot/boot.scr': No such file or directory
```
Caused by this https://gitlab.nic.cz/turri...Package: turris1x-btrfs
```
root@turris:~# /usr/sbin/turris1x-btrfs-kernel-install
cmp: /boot/boot.scr: No such file or directory
cp: can't stat '/boot/boot.scr': No such file or directory
```
Caused by this https://gitlab.nic.cz/turris/os/packages/-/merge_requests/921
Temporary workaround:
- remove this row ``deploy boot.scr`` from file: /usr/sbin/turris1x-btrfs-kernel-install
It's a thing, when boot.scr can not be found in folder /boot. See:
```
Package turris1x-support (5.4.203-1-f70e9c9745643e220f2338b431a1b5ff) is installed on root and has the following files:
/boot/turris1x.dtb
/boot/fdt
/boot.scr
```
**Because of that a new kernel version is not installed.**Turris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/844treewide: switch to AUTORELEASE2023-08-16T14:35:37+02:00Josef Schlehofertreewide: switch to AUTORELEASEWe should switch to the [AUTORELEASE variable](https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9ae3c6f94c616cfbf854d3ec749c7fafc9893942) instead of manually increasing PKG_RELEASE. This avoids cases, where it was forgotten.We should switch to the [AUTORELEASE variable](https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9ae3c6f94c616cfbf854d3ec749c7fafc9893942) instead of manually increasing PKG_RELEASE. This avoids cases, where it was forgotten.Turris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/843openpvn-client: Use VPN native DNS server to avoid DNS leaks2022-08-18T20:28:02+02:00Martin Matějekopenpvn-client: Use VPN native DNS server to avoid DNS leaksUpon activation, VPN client will successfully create it's own `resolv.conf.vpn.<my_vpn_connection>.conf` file with preferred DNS resolver.
DNS switching might work automatically on upstream OpenWrt with dnsmasq as default resolver, see ...Upon activation, VPN client will successfully create it's own `resolv.conf.vpn.<my_vpn_connection>.conf` file with preferred DNS resolver.
DNS switching might work automatically on upstream OpenWrt with dnsmasq as default resolver, see https://protonvpn.com/support/how-to-set-up-protonvpn-on-openwrt-routers/
However, unlike upstream OpenWrt, Turris OS is using Kresd as DNS resolver, so default resolv conf file (`/tmp/resolv.conf.d/resolv.conf.auto`) will be used instead of the vpn specific `resolf.conf`, which leads to DNS leaks.
We need to figure out how to switch the resolv files upon VPN client startup and shutdown. The `resolv.conf.vpn.<my_vpn_connection>.conf` file is created by the openvpn hotplug scripts, so perhaps we could adjust these scripts to switch DNS resolvers.
For example (crude idea):
```
# up
mv resolv.conf.auto resolv.conf.auto.bkp
ln -s resolv.conf.vpn.myvpn resolv.conf.auto
/etc/init.d/resolver restart
# down
rm resolv.conf.auto
/etc/init.d/resolver restart
```Turris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/842[TurrisOS 6.0 HBL - Omnia] Egress traffic on second Omnia limited to circa 9,...2022-08-07T15:43:17+02:00Orest Worhacz[TurrisOS 6.0 HBL - Omnia] Egress traffic on second Omnia limited to circa 9,5Mbit/sHi,
I have really uncommon issue described on the forum here: https://forum.turris.cz/t/tos6-0-bottleneck-of-circa-10mbit-s-on-egress-traffic-only/17273
I am using two Omnias with TOS6.0 and was wondering if you could somehow reproduce...Hi,
I have really uncommon issue described on the forum here: https://forum.turris.cz/t/tos6-0-bottleneck-of-circa-10mbit-s-on-egress-traffic-only/17273
I am using two Omnias with TOS6.0 and was wondering if you could somehow reproduce the issue in your lab.https://gitlab.nic.cz/turris/os/packages/-/issues/841schnapps: add dependency on "gnupg" (GPG 1.4) package2023-08-28T16:36:16+02:00Simon Borekschnapps: add dependency on "gnupg" (GPG 1.4) packageGPG is required for the encrypted export to work. Should user be able to use the whole documented Schnapps functionality `gnupg` package must be installed by default.
`gnupg2` currently doesn't work well on OpenWrt and TOS, so it does n...GPG is required for the encrypted export to work. Should user be able to use the whole documented Schnapps functionality `gnupg` package must be installed by default.
`gnupg2` currently doesn't work well on OpenWrt and TOS, so it does not seem like a suitable default (see #840 ).Richard MuzikRichard Muzikhttps://gitlab.nic.cz/turris/os/packages/-/issues/840schnapps: Encrypted export fails if `gnupg2` package is installed2023-08-28T16:36:51+02:00Simon Borekschnapps: Encrypted export fails if `gnupg2` package is installedRunning `schnapps export NUMBER DEST` with password encryption set and `gnupg2` package installed (on Omnia HBL, TOS 6) leads to export failure. This happens even in case both gnupg and gnupg2 are installed as gnupg2 then becomes the de...Running `schnapps export NUMBER DEST` with password encryption set and `gnupg2` package installed (on Omnia HBL, TOS 6) leads to export failure. This happens even in case both gnupg and gnupg2 are installed as gnupg2 then becomes the default 'gpg' (no matter the installation order).
stderr:
```
gpg: keybox '/tmp/tmp.cbbaAi/gpg/pubring.kbx' created
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: problem with the agent: No agent running
tar: Child returned status 2
tar: Error is not recoverable: exiting now
Snapshot export failed!
```
Might defaulting to gnupg (GPG 1.4) be the solution (as gnupg2 is missing some important components in OpenWrt packages such as pinentry [and probably gpg-agent as well] and it's usefulness is therefore pretty limited even in other scenarios)?
Or would it be better for [Schnapps](https://gitlab.nic.cz/turris/schnapps) to explicitly use gpg1 (might be problematic if running outside TOS)?Richard MuzikRichard Muzikhttps://gitlab.nic.cz/turris/os/packages/-/issues/838Turris-auth version 0.4.02022-08-15T13:30:31+02:00Karel KociTurris-auth version 0.4.0Turris-auth can be bumped to 0.4.0 to include the LuCI integration. It should also be enabled in the configuration using the new argument.
https://gitlab.nic.cz/turris/turris-auth/-/tags/v0.4.0Turris-auth can be bumped to 0.4.0 to include the LuCI integration. It should also be enabled in the configuration using the new argument.
https://gitlab.nic.cz/turris/turris-auth/-/tags/v0.4.0Turris OS 6.02022-08-17https://gitlab.nic.cz/turris/os/packages/-/issues/836dev-detect: new device is detected, but notification is not created2022-03-23T16:31:32+01:00Martin Matějekdev-detect: new device is detected, but notification is not createdLogs in /var/log/message contains these information, but not propagated to webui or in notification
For example:
```
Mar 13 01:36:31 gw dev-detect-daemon[6819]: INFO: New device detected on interface 'br-lan'. MAC: 00:MEH | IPv4 address...Logs in /var/log/message contains these information, but not propagated to webui or in notification
For example:
```
Mar 13 01:36:31 gw dev-detect-daemon[6819]: INFO: New device detected on interface 'br-lan'. MAC: 00:MEH | IPv4 address: 192.168.1.165
Mar 13 09:55:25 gw dev-detect-daemon[6819]: INFO: New device detected on interface 'br-lan'. MAC: 88:MEH | IPv4 address: 192.168.1.45
Mar 13 10:16:25 gw dev-detect-daemon[6819]: INFO: New device detected on interface 'br-lan'. MAC: 1c:MEH | IPv4 address: 192.168.1.230
Mar 13 21:39:23 gw dev-detect-daemon[6819]: INFO: New device detected on interface 'br-lan'. MAC: f0:MEH | IPv4 address: 192.168.1.238
```
original reporter: @pschonmann
Moved here to keep distinction between separate issues.https://gitlab.nic.cz/turris/os/packages/-/issues/835ouidb: fix "OUT DB file doesn't exists"2023-08-16T14:35:39+02:00Martin Matějekouidb: fix "OUT DB file doesn't exists"Fix `oui.db` file location so it could be actually utilized for MAC vendor lookup.
See original script:
https://gitlab.nic.cz/turris/ouidb/-/blob/master/ouidb#L19
and more recent version:
https://gitlab.nic.cz/turris/os/packages/-/bl...Fix `oui.db` file location so it could be actually utilized for MAC vendor lookup.
See original script:
https://gitlab.nic.cz/turris/ouidb/-/blob/master/ouidb#L19
and more recent version:
https://gitlab.nic.cz/turris/os/packages/-/blob/develop/utils/ouidb/files/ouidb#L19