Turris OS 4.0 beta1 is released!

viktor · May 9, 2019, 12:03pm

audricschiltknecht · May 9, 2019, 2:49pm

Hello,

Is there a way to get the associated SDK tar.gz (last one that I found was named turrisos-sdk-4.0-mvebu-cortexa9_gcc-7.3.0_musl_eabi.Linux-x86_64.tar.xz) associated with this release?
Thanks!

anon50890781 · May 9, 2019, 2:58pm

For some reason local ipv6 addresses are not reachable between different ifaces. ipv6 forwarding is enabled in the kernel and forwarding also not restricted between firewall zones.

The 2 ifaces in play are `lan`

ip a show br-lan

22: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether d8:58:d7:00:79:7a brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 xxxx:xxxx:6b09:3400::1/60 scope global dynamic
valid_lft 84250sec preferred_lft 84250sec
inet6 fd89:d3e5:f7ea::1/60 scope global
valid_lft forever preferred_lft forever
inet6 fe80::da58:d7ff:fe00:797a/64 scope link
valid_lft forever preferred_lft forever

and `mgt`

ip a show br-mgt

23: br-mgt: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether d8:58:d7:00:79:7a brd ff:ff:ff:ff:ff:ff
inet 192.168.112.12/24 brd 192.168.112.255 scope global br-mgt
valid_lft forever preferred_lft forever
inet6 xxxx:xxxx:6b09:3410:e505:8147:b298:b759/64 scope global tentative dynamic
valid_lft 84513sec preferred_lft 84513sec
inet6 fd89:d3e5:f7ea:4c3a:2c10:1d64:913e:6a9/64 scope global tentative
valid_lft forever preferred_lft forever

Being connected to br-lan and executing traceroute 192.168.112.12 via ssh cmd produces

traceroute to 192.168.112.12 (192.168.112.12), 30 hops max, 38 byte packets
1 192.168.112.12 (192.168.112.12) 0.014 ms 0.009 ms 0.006 ms

however the same with ipv6 traceroute6 fd89:d3e5:f7ea:4c3a:2c10:1d64:913e:6a9 produces

traceroute to fd89:d3e5:f7ea:4c3a:2c10:1d64:913e:6a9 (fd89:d3e5:f7ea:4c3a:2c10:1d64:913e:6a9) from fd89:d3e5:f7ea::1, 30 hops max, 16 byte packets
1 fd89:d3e5:f7ea::1 (fd89:d3e5:f7ea::1) 3090.23 ms !H 3129.51 ms !H 3109.96 ms !H

It is a mystery why the local ipv4 address is reachable but the ipv6 equivalent is not?

The ipv6 address on the same iface br-lan is reachable traceroute6 fd89:d3e5:f7ea::1

traceroute to fd89:d3e5:f7ea::1 (fd89:d3e5:f7ea::1) from fd89:d3e5:f7ea::1, 30 hops max, 16 byte packets
1 fd89:d3e5:f7ea::1 (fd89:d3e5:f7ea::1) 0.126 ms 0.066 ms 0.05 ms

The cause of this seems to the link status. Without a client connected to the ifcae the state is DOWN and the ipv6 address is unreachable. As soon a client connects and the state changes to UP the ipv6 address is reachable.

Lodged at gitlab issue #381

The cause seems to be that if no client is connected to the iface there is no ipv6 route generated for the iface whilst it is for ipv4

with no client connected to the mgt iface

with a client connected to the mgt iface

having added a dummy iface to the mgt bridge solved the issue

anon50890781 · May 9, 2019, 3:47pm

There is basically no documentation for umdns and nothing explains what the settings in /etc/config/umdns are supposed to achieve.
IMHO umdns does not belong in the base package, just bloats the code and consumes resources whilst likely benefiting a very few users.

anon50890781 · May 9, 2019, 4:14pm

Is socat essential for any of the router functionality? Whilst being enabled in init.d to start up it is set to disabled in /etc/config/socat

config socat 'http'
	option enable '0'

and apparently not running in a vanilla installation.

If is non-essential then perhaps it could be removed from the router installation routine.

chris-89 · May 9, 2019, 8:05pm

My provider doesn’t offen ipv6 now and I want to deactivate ipv6 completely. DHCP ipv6 settings are deactivated.
How can I deactivate the ipv6 local link (fe80:…) on wlan0 and wlan1 device? I didn’t found a solution that will consist after reboot.

anon50890781 · May 9, 2019, 9:30pm

This not really related to this topic.

Nonetheless, it would require ipv6 to be disabled in the kernel.

chris-89 · May 10, 2019, 4:02am

Somehow it is related. Since beta 1 I have an issue with ipv6. As soon as I open a website it takes 5-10s seconds until it loads. I changed several things in my general network setup like the software of my providers box, the providers contract etc.

Yesterday I identified that it is related to the ipv6 setup in OpenWRT. Probably it is just a routing error. For this reason I want to deactivate ipv6 to investigate further.

I found a solution to deactivate now ipv6 on startup.
Jut added the following to startup in Luci:

sysctl -w net.ipv6.conf.all.disable_ipv6=1 echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6 sysctl -w net.ipv6.conf.default.disable_ipv6=1

Weafyr · May 10, 2019, 12:09pm

In luci -> system -> software there is a bug that forces to update package lists every single time.

anon50890781 · May 11, 2019, 3:47pm

btrfs support for acl is not working since not compiled in kernel (lodged gitlab #384)

Trying to mount btrfs with acl results in

BTRFS error (device): support for ACL not compiled in!

gzip -cd /proc/config.gz | grep ACL

CONFIG_EXT4_FS_POSIX_ACL is not set
CONFIG_REISERFS_FS_POSIX_ACL is not set
CONFIG_JFS_POSIX_ACL is not set
CONFIG_XFS_POSIX_ACL is not set
CONFIG_BTRFS_FS_POSIX_ACL is not set
CONFIG_F2FS_FS_POSIX_ACL is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_TMPFS_POSIX_ACL is not set
CONFIG_HFSPLUS_FS_POSIX_ACL is not set
CONFIG_JFFS2_FS_POSIX_ACL is not set
CONFIG_NFS_V3_ACL is not set
CONFIG_NFSD_V3_ACL is not set
CONFIG_CIFS_ACL is not set

Looks like it might become available in the next beta output.

anon50890781 · May 12, 2019, 12:34pm

Noticed that the CPU is spiking abnormally high (during autorefresh) when logged into LuCI pages that provide status information

iddqd · May 12, 2019, 2:16pm

That is a known problem with LuCI

p4p4 · May 12, 2019, 7:31pm

Anyone using VPN policy based routing with OS 4.0 b1(@anon50890781 ?) ? I updated my Turris Omnia today to 4.0b1 and installed VPN PBR and it behaves different compared to OS 3:

in OS3 all traffic was routed over the VPN tunnel and I had to use PBR to choose the clients that should use WAN.
in OS4 all traffic is routed through WAN (even though VPN tunnel is active) and I have to choose the clients that should use VPN

anon50890781 · May 12, 2019, 7:47pm

I do indeed. Same settings as used in TOS3.11.4, no difference in its behaviour, with wireguard as choice of VPN.

What you are describing might be due to setting of the VPN rather than VBR?

p4p4 · May 12, 2019, 8:12pm

Thanks for your quick reply. Then I will have to check my VPN settings, I used the same like in OS3…

anon50890781 · May 13, 2019, 9:55pm

I am concerned that sysntpd is not working, both client and server.

With the client side, which is most important, there is no indication in the logs that the time is being synchronized with the specified upstream servers, e.g. via /foris/config/main/time/ > Update Time.
Is there any way via cli to run the client and see the output, could not find any documentation?

→ This been sorted after discovery of the settings from 3.11.4 copied/pasted to 4.x not working.

With the server side up/running

ss -tulpn | grep ntp

udp UNCONN 0 0 *:123 : users:((“ntpd”,pid=10918,fd=3))

ntpq -p is producing

localhost: timed out, nothing received
***Request timed out

In addition the server should not be listening globally but on dhcp_interface, if list interface is omitted then on every interface or else on the specified interface. But apparently it does not.

Not sure whether it makes difference but this node is using odhcp for ipv4 and ipv6.

anon50890781 · May 15, 2019, 9:49am

consistently on every boot

[ 4.424950] libphy: mv88e6xxx SMI: probed
[ 4.429872] ------------[ cut here ]------------
[ 4.434524] WARNING: CPU: 0 PID: 1 at fs/proc/generic.c:572 remove_proc_entry+0x140/0x154
[ 4.442726] remove_proc_entry: removing non-empty directory ‘irq/58’, leaking at least ‘mv88e6xxx-g2’

[ 17.305282] random: crng init done
[ 17.308697] random: 2 urandom warning(s) missed due to ratelimiting
[ 20.699652] watchdog: watchdog0: nowayout prevents watchdog being stopped!
[ 20.699656] watchdog: watchdog0: watchdog did not stop!
[ 20.708014] watchdog: watchdog0: nowayout prevents watchdog being stopped!
[ 20.708017] watchdog: watchdog0: watchdog did not stop!

chris-89 · May 18, 2019, 9:08pm

I’m facing an issue with opkg update over ssh and as well with the update on Luci.
Both showing the following error:

opkg update details

Downloading https://repo.turris.cz/hbs/omnia/packages/core/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_core
Downloading https://repo.turris.cz/hbs/omnia/packages/core/Packages.sig
Signature file download failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbs/omnia/packages/base/Packages.gz
*** Failed to download the package list from https://repo.turris.cz/hbs/omnia/packages/base/Packages.gz

Downloading https://repo.turris.cz/hbs/omnia/packages/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_luci
Downloading https://repo.turris.cz/hbs/omnia/packages/luci/Packages.sig
Signature file download failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbs/omnia/packages/luci_theme_rosy/Packages.gz
*** Failed to download the package list from https://repo.turris.cz/hbs/omnia/packages/luci_theme_rosy/Packages.gz

Downloading https://repo.turris.cz/hbs/omnia/packages/openwisp/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_openwisp
Downloading https://repo.turris.cz/hbs/omnia/packages/openwisp/Packages.sig
Signature file download failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbs/omnia/packages/packages/Packages.gz
*** Failed to download the package list from https://repo.turris.cz/hbs/omnia/packages/packages/Packages.gz

Downloading https://repo.turris.cz/hbs/omnia/packages/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_routing
Downloading https://repo.turris.cz/hbs/omnia/packages/routing/Packages.sig
Signature file download failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbs/omnia/packages/sidn/Packages.gz
*** Failed to download the package list from https://repo.turris.cz/hbs/omnia/packages/sidn/Packages.gz

Downloading https://repo.turris.cz/hbs/omnia/packages/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_telephony
Downloading https://repo.turris.cz/hbs/omnia/packages/telephony/Packages.sig
Signature file download failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbs/omnia/packages/turrispackages/Packages.gz
*** Failed to download the package list from https://repo.turris.cz/hbs/omnia/packages/turrispackages/Packages.gz

Collected errors:

* opkg_download: Failed to download https://repo.turris.cz/hbs/omnia/packages/core/Packages.sig, wget returned 4.
* opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://repo.turris.cz/hbs/omnia/packages/base/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://repo.turris.cz/hbs/omnia/packages/luci/Packages.sig, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://repo.turris.cz/hbs/omnia/packages/luci_theme_rosy/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://repo.turris.cz/hbs/omnia/packages/openwisp/Packages.sig, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://repo.turris.cz/hbs/omnia/packages/packages/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://repo.turris.cz/hbs/omnia/packages/routing/Packages.sig, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://repo.turris.cz/hbs/omnia/packages/sidn/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://repo.turris.cz/hbs/omnia/packages/telephony/Packages.sig, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

 * opkg_download: Failed to download https://repo.turris.cz/hbs/omnia/packages/turrispackages/Packages.gz, wget returned 4.
 * opkg_download: Check your network settings and connectivity.

wget for https://repo.turris.cz/hbs/omnia/packages/base/Packages.gz on ssh connection is working

working wget example

wget https://repo.turris.cz/hbs/omnia/packages/base/Packages.gz
–2019-05-18 23:04:06-- https://repo.turris.cz/hbs/omnia/packages/base/Packages.gz
Resolving repo.turris.cz… 217.31.192.69, 2001:1488:ac15:ff80::69
Connecting to repo.turris.cz|217.31.192.69|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 50621 (49K) [application/x-gzip]
Saving to: ‘Packages.gz’

Packages.gz 100%[==============================================================================================>] 49.43K --.-KB/s in 0.02s

2019-05-18 23:04:06 (2.42 MB/s) - ‘Packages.gz’ saved [50621/50621]

Has anyone a idea what is wrong here or how it can be resolved?

chris-89 · May 18, 2019, 9:39pm

[quote=“chris-89, post:78, topic:10107”]

I’m facing an issue with opkg update over ssh and as well with the update on Luci.

Resolved: Even if IPv6 is globally deactivated opkg try to connect through IPv6 if domain provides ipv6. It was required to add “option ipv6 0” in /etc/config/network for all devices

vcunat · May 19, 2019, 8:11am

Wait… do you say that connections through IPv6 do succeed and they serve different content? That would be just evil.