No. I was taking about the repo domain that have a ipv6 and an ipv4 record set. opkg was trying to connect through ipv6 but I could not establish connection as my provider doesn’t support it. I deactivated ipv6 some weeks ago to ensure everything is working properly but it seems that some more configurations where required to deactivate all ipv6 related things.
I installed Turris OS 4.0 on my Omnia and I am facing issue with Nextcloud (fresh installation). It seems that Nextcloud 15.0.7 is correctly installed, I can access the login screen but cannot login.
The error message after logging attempt is:
Internal Server Error
The server was unable to complete your request.
If this happens again, please send the technical details below to the server administrator.
More details can be found in the server log.
And the server log contains following error: base64_encode() expects parameter 1 to be string, null given.
Full entry form the log:
{"reqId":"T7RUw2dNNTXJ9qQPRXwG","level":3,"time":"2019-05-19T22:33:24+00:00","remoteAddr":"192.168.1.116","user":"ivanek","app":"index","method":"POST","url":
"\/nextcloud\/index.php\/login?user=ivanek","message":{"Exception":"TypeError","Message":"base64_encode() expects parameter 1 to be string, null given","Code"
:0,"Trace":[{"file":"\/srv\/www\/nextcloud\/lib\/private\/Authentication\/Token\/PublicKeyTokenProvider.php","line":242,"function":"base64_encode","args":["**
* sensitive parameter replaced ***"]},{"file":"\/srv\/www\/nextcloud\/lib\/private\/Authentication\/Token\/PublicKeyTokenProvider.php","line":309,"function":"
encryptPassword","class":"OC\\Authentication\\Token\\PublicKeyTokenProvider","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"\/srv\/www
\/nextcloud\/lib\/private\/Authentication\/Token\/PublicKeyTokenProvider.php","line":70,"function":"newToken","class":"OC\\Authentication\\Token\\PublicKeyTok
enProvider","type":"->","args":["*** sensitive parameter replaced ***","*** sensitive parameter replaced ***","*** sensitive parameter replaced ***","*** sens
itive parameter replaced ***","*** sensitive parameter replaced ***","*** sensitive parameter replaced ***","*** sensitive parameter replaced ***"]},{"file":"
\/srv\/www\/nextcloud\/lib\/private\/Authentication\/Token\/Manager.php","line":69,"function":"generateToken","class":"OC\\Authentication\\Token\\PublicKeyTok
enProvider","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"\/srv\/www\/nextcloud\/lib\/private\/User\/Session.php","line":641,"functio
n":"generateToken","class":"OC\\Authentication\\Token\\Manager","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"\/srv\/www\/nextcloud\/
core\/Controller\/LoginController.php","line":340,"function":"createSessionToken","class":"OC\\User\\Session","type":"->","args":["*** sensitive parameters re
placed ***"]},{"file":"\/srv\/www\/nextcloud\/lib\/private\/AppFramework\/Http\/Dispatcher.php","line":166,"function":"tryLogin","class":"OC\\Core\\Controller
\\LoginController","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"\/srv\/www\/nextcloud\/lib\/private\/AppFramework\/Http\/Dispatcher.
php","line":99,"function":"executeController","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->","args":[{"__class__":"OC\\Core\\Controller\\LoginContro
ller"},"tryLogin"]},{"file":"\/srv\/www\/nextcloud\/lib\/private\/AppFramework\/App.php","line":118,"function":"dispatch","class":"OC\\AppFramework\\Http\\Dis
patcher","type":"->","args":[{"__class__":"OC\\Core\\Controller\\LoginController"},"tryLogin"]},{"file":"\/srv\/www\/nextcloud\/lib\/private\/AppFramework\/Ro
uting\/RouteActionHandler.php","line":47,"function":"main","class":"OC\\AppFramework\\App","type":"::","args":["OC\\Core\\Controller\\LoginController","tryLog
in",{"__class__":"OC\\AppFramework\\DependencyInjection\\DIContainer"},{"_route":"core.login.tryLogin"}]},{"function":"__invoke","class":"OC\\AppFramework\\Ro
uting\\RouteActionHandler","type":"->","args":[{"_route":"core.login.tryLogin"}]},{"file":"\/srv\/www\/nextcloud\/lib\/private\/Route\/Router.php","line":297,
"function":"call_user_func","args":[{"__class__":"OC\\AppFramework\\Routing\\RouteActionHandler"},{"_route":"core.login.tryLogin"}]},{"file":"\/srv\/www\/next
cloud\/lib\/base.php","line":987,"function":"match","class":"OC\\Route\\Router","type":"->","args":["\/login"]},{"file":"\/srv\/www\/nextcloud\/index.php","li
ne":42,"function":"handleRequest","class":"OC","type":"::","args":[]}],"File":"\/srv\/www\/nextcloud\/lib\/private\/Authentication\/Token\/PublicKeyTokenProvi
der.php","Line":242,"CustomMessage":"--"},"userAgent":"Mozilla\/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko\/20100101 Firefox\/66.0","version":"15.0.
7.0"}
I have found this issue on nextcloud github but no real solution to the problem. I also tried to reset the password for the the user but login still fails. Any idea how to fix it?
I also posted the question on Nextcloud forum: https://help.nextcloud.com/t/after-fresh-installation-cannot-login/53626
added issue on gitlab #398
Despite of setting new token for haas in the https://haas.nic.cz/, the service is not running correctly (port 22 is not open on my omnia). When trying to access the honeypot from outside, I only got an error: ssh: connect to host __hidden__ port 22: Connection refused.
When starting the service manually I got these errors:
/etc/init.d/haas-proxy start
/etc/rc.common: line 1: can't create /sys/fs/cgroup/cpu/haas/cpu.cfs_period_us: Permission denied
/etc/rc.common: line 1: can't create /sys/fs/cgroup/cpu/haas/cpu.cfs_quota_us: Permission denied
Gitlab issue: #394
Dear busy and appreciated developers and contributors for the Turris Omnia OS Software,
Thanks for spending your time and effort!
I just installed the 4beta and would like to share some impressions:
-
Reconnect IPv6
The bug about reconnecting IPv6 is not solved. Host can not use IPv6 after temp outage of upstream router. Reproducible.
IPv4 is working as expected. -
WAN setup step
Minor issue: a misleading announcement about a disconnected WAN cable (not true, not helpful). Occurs during guided setup tour at WAN topic. Not reproducible at 2nd device. -
DNS config 1
An ongoing major design issue (in Foris at least) is to force the user to use a small “choice” of DNS Servers. I do not want to use any of these servers! No thanks! Most of them belong to intelligence and surveillance organisations. Some of them do not even comply with European law. Disagree! I want to use none of these as DNS! I need a trustworthy one that knows at least DNSSEC, DNS-over-TLS and IPv6. My personal preference is German Digitalcourage. Choice of DNS Server should be up to the user.
I strongly suggest to offer (in Foris) an option to use a server of choice (both, IPv6 and old)! -
DNS config 2
In Foris there is a very important check-mark for „forwarding“?! Description is incomprehensible. In German and in English the description is really bad in 1 point:- What does it exactly mean NOT to check the box? What does it exactly mean to CHECK the box?
- PLEASE describe, who is forwarding what to whom! Is this about Transparent DNS proxies?
- What exactly is enabled, disabled? Who is getting what request forwarded? What leg of routing DNS is meant?
- Is this the same in v6 like in v4?
I strongly suggest to explain, what the „Weiterleitung benutzen“ / „Use forwarding“ really does. The description is insufficient now.
-
config persistence
In 3.11 and in 4beta I sometimes lose one config if I change another. In both versions „Storage“ was gone after changing something different. Currently I have no details at hand.
You have proven to do a brilliant job. Turris Omnia is great, no worries.
I’d like to ask you please to consider fixing these issues.
Best regards, Dietmar
My setup:
Devices
requesting router:
a) Turris Omnia - rtrom01, update: 4beta1 (no longer: OS 3.11.4), config mostly default ; routing and firewall: factory;
b) temp: Turris 2G using OS4beta1, config is default
delegating router (upstream): Fritz 7430, FRITZ!OS 07.01
Layout: like in RFC 3633 page 3
ISP: v6 native Hansenet provides Prefix Delegation + v4 Telefonica
PS: I described the hassle about DNS in general here:
(German only)
https://www.schweinekraftland.de/DNS_sicherer_machen/sicherer%20surfen%20und%20mailen%20mit%20gesichertem%20DNS.html
1 Like
Hello,
I tried to enable the Qualcomm Atheros AR9287 Wireless Network Adapter, but when i tried to load the ath9k kmod driver i get the error:
“vmap allocation for size 348160 failed: use vmalloc= to increase size”
The Qualcomm Atheros QCA986x/988x 802.11ac work fine.
Thank you for appreciation.
I answered to relevant topic here on forum.
That is not as easy as providing different IP address. We allow you to configure not only simple forwarding but also forward using TLS which requires more than just IP address. It is possible to add all required fields to Foris but question is: is it good approach? Foris is for inexperienced users and for them six fields with need to specify certificate is just too complicated. If you want to have different provider then you can just add its configuration to /etc/resolver/dns_servers/. You can use existing configurations as a reference. You can then set your server in Foris.
I would also note that one of offered servers is CZ.NIC ODVR. You are already trusting us with updates and we are under European law. 
It means that all DNS traffic is forwarded to different DNS server instead of resolving it locally against authoritative servers. I don’t think that there is one sentence explanation for non-insightful user that explains considerations you are asking for. We have companion documentation for our product and this is explained in depth in it: Turris Documentation
DNS is configured for both IP v4 and v6 at the same time. That is common so I don’t see how specifying that it is for both helps.
To whom it is forwarded is just one field underneath that checkbox. I don’t see how that is not clear.
I suspect that you have disabled NAS or Pakon in Updater tab. Storage plugin is part of those package lists. This is not configuration per say but list of features that are optionally added to system. It makes sense that if you unselect that feature then that specific feature disappears from system. I know that it is not clear now that storage plugin is part of NAS but we are working on that Sign in · GitLab
Hello,
unfortunately, I was unable to replicate the error in HBK, which is a slightly newer version than you mention. The bug is not reflected in the latest version of HBD. Can I ask for the diagnostics to be sent to our technical support? info@turris.cz
Since i upgraded to TOS4 i noticed a few times (maybe about once a week) that resolving internet sites gets very slow and even stops (site unreachable). This situation lasts a few minutes or so and seems to restore itself.
During this black-out I pinged 8.8.8.8 (and restores itself)
C:\WINDOWS\system32>ping 8.8.8.8 -t
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=1754ms TTL=55
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1606ms TTL=55
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1364ms TTL=55
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1554ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1745ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1186ms TTL=55
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1708ms TTL=55
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1267ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1184ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1631ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1656ms TTL=55
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=2029ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1839ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1293ms TTL=55
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1646ms TTL=55
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1738ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1647ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1583ms TTL=55
Request timed out.
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=1908ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=69ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=132ms TTL=55
Request timed out.
Reply from 8.8.8.8: bytes=32 time=81ms TTL=55
Reply from 8.8.8.8: bytes=32 time=20ms TTL=55
Reply from 8.8.8.8: bytes=32 time=27ms TTL=55
Reply from 8.8.8.8: bytes=32 time=14ms TTL=55
Reply from 8.8.8.8: bytes=32 time=13ms TTL=55
Reply from 8.8.8.8: bytes=32 time=17ms TTL=55
Reply from 8.8.8.8: bytes=32 time=11ms TTL=55
Reply from 8.8.8.8: bytes=32 time=15ms TTL=55
Reply from 8.8.8.8: bytes=32 time=11ms TTL=55
Reply from 8.8.8.8: bytes=32 time=12ms TTL=55
Reply from 8.8.8.8: bytes=32 time=12ms TTL=55
Reply from 8.8.8.8: bytes=32 time=16ms TTL=55
Reply from 8.8.8.8: bytes=32 time=17ms TTL=55
About the same time i found this in the systemlog. I don't know if both are related.
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'a.root-servers.net.', type: 1
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'a.root-servers.net.', type: 28
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'b.root-servers.net.', type: 1
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'c.root-servers.net.', type: 1
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'c.root-servers.net.', type: 28
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'd.root-servers.net.', type: 1
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'e.root-servers.net.', type: 1
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'e.root-servers.net.', type: 28
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'f.root-servers.net.', type: 28
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'g.root-servers.net.', type: 28
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'h.root-servers.net.', type: 1
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'h.root-servers.net.', type: 28
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'j.root-servers.net.', type: 1
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'j.root-servers.net.', type: 28
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'k.root-servers.net.', type: 1
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'k.root-servers.net.', type: 28
May 30 12:33:33 TurrisJK kresd[1487]: [priming] cannot resolve address 'l.root-servers.net.', type: 1
May 30 12:33:33 TurrisJK kresd[1487]: [ ta ] key: 20326 state: Valid
May 30 12:33:33 TurrisJK kresd[1487]: [ ta ] next refresh for . in 11.89875 hours
May 30 12:33:34 TurrisJK mosquitto[4061]: 1559219614: Client 2e4ba149-0b96-4a3f-8fb5-a660aeac8eec-controller-notification already connected, closing old connection.
May 30 12:33:59 TurrisJK mosquitto[4061]: 1559219639: Client 2e4ba149-0b96-4a3f-8fb5-a660aeac8eec-controller-notification already connected, closing old connection.
May 30 12:34:01 TurrisJK /usr/sbin/cron[1822]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
May 30 12:34:10 TurrisJK kresd[1724]: [ ta ] key: 20326 state: Valid
May 30 12:34:10 TurrisJK kresd[1724]: [ ta ] next refresh for . in 11.89875 hours
May 30 12:34:26 TurrisJK kresd[1963]: [ ta ] key: 20326 state: Valid
May 30 12:34:26 TurrisJK kresd[1963]: [ ta ] next refresh for . in 11.89875 hoursI have the same issue once every 2-3 days, once also after 1 day. For me it doesn’t resolve itself (even after several hours) and I have to reboot the Turris Omnia.
So I installed from https://repo.turris.cz/hbk/medkit/omnia-medkit-latest.tar.gz (2019-05-31 18:12)
Seems like it’s yet-unannounced beta2:
TurrisOS 4.0-beta2, Turris Omnia
And I get
root@turris:~# ping 8.8.4.4
PING 8.8.4.4 (8.8.4.4) 56(84) bytes of data.
64 bytes from 8.8.4.4: icmp_req=1 ttl=55 time=1.74 ms
64 bytes from 8.8.4.4: icmp_req=2 ttl=55 time=0.790 ms
64 bytes from 8.8.4.4: icmp_req=3 ttl=55 time=0.722 ms
^C
--- 8.8.4.4 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2047ms
rtt min/avg/max/mdev = 0.722/1.084/1.741/0.465 ms
root@turris:~# pkgupdate
line not found
line not found
line not found
ERROR:
runtime: [string "requests"]:395: [string "utils"]:427: URI download failed: The requested URL returned error: 404 Not Found
EDIT:
I did
switch-branch hbs
switch-branch hbk
and that seems to have fixed the issue.
Yes, that’s what you need to do as you installed development branch, you need to use switch-branch to the branch, where you want to be as it points to HBS by default. We are working on beta2. It’s not announced, yet. Because it isn’t released to RC or to deploy.
1 Like
I see that with @p4p4 you have the same issue. We are not aware of that issue, which you described to us. Can I request both of you for more details about your configurations and also if you can send us diagnostics to tech.support@turris.cz?
May I ask you if you install the Nextcloud with our script nextcloud_install or you installed it by another way? In any case, I updated and tested Nextcloud to version 16.0.1 and it will be available in the upcoming version. I haven’t been able to reproduce your issue. It will be really hard to fix it if we can not reproduce it. But from your provided details it looks like an issue in Nextcloud itself.
Thank you for reporting to us the problem with haas! We responded to the issue, which you created on our Gitlab. It is currently on review and once it is reviewed, it will be part of the next release.
Thanks!
I’m just getting up to speed with this. I started with now obsolete howtos because those were the first which turned up via Google or local search and I finally (luckily!) ended up here.
My configuration is:
DNS forwarding active, forwarder cloudflare (TLS), DNSSEC active
OpenVPN connection to ExpressVPN
VPN policy based routing active, most clients go through WAN not VPN
the rest is standard configuration
I had the same configuration with Turris OS 3 with no problems.
The last 2d no issues, I’ll save diagnostics when it happens again and email it.
Since on 4B1 my logfile is filling up with the sequence shown below. I see the sequence gets logged mostly many times per second but also only once (sometimes). The time between those sequences seem more or less random (<0.5h to >1h).
The mentioned *.lan clients are defined in DHCP and DNS, Static leases.
Is there an explanation for this?
Jun 3 08:11:52 TurrisJK 99-dhcp_host_domain_ng.py: Add_lease, hostname check failed
Jun 3 08:11:52 TurrisJK 99-dhcp_host_domain_ng.py: Add_lease, hostname check failed
Jun 3 08:11:52 TurrisJK 99-dhcp_host_domain_ng.py: Add_lease, hostname check failed
Jun 3 08:11:52 TurrisJK 99-dhcp_host_domain_ng.py: DHCP unknown update operation
Jun 3 08:11:52 TurrisJK kresd[1963]: > hints.del('Jack.lan')
Jun 3 08:11:52 TurrisJK kresd[1963]: [result] => false
Jun 3 08:11:52 TurrisJK kresd[1963]:
Jun 3 08:11:52 TurrisJK kresd[1963]: > hints.del('Thule.lan')
Jun 3 08:11:52 TurrisJK kresd[1963]: [result] => false
Jun 3 08:11:52 TurrisJK kresd[1963]:
Jun 3 08:11:52 TurrisJK kresd[1963]: > hints.del('EvoHome.lan')
Jun 3 08:11:52 TurrisJK kresd[1963]: [result] => false
Jun 3 08:11:52 TurrisJK kresd[1963]:
Jun 3 08:11:52 TurrisJK kresd[1963]: > hints.del('OTMonitor.lan')
Jun 3 08:11:52 TurrisJK kresd[1963]: [result] => false
Jun 3 08:11:52 TurrisJK kresd[1963]:
Jun 3 08:11:52 TurrisJK kresd[1963]: > hints.del('XBoxOne.lan')
Jun 3 08:11:52 TurrisJK kresd[1963]: [result] => false
Jun 3 08:11:52 TurrisJK kresd[1963]:
Jun 3 08:11:52 TurrisJK kresd[1963]: > hints.del('XBox360.lan')
Jun 3 08:11:52 TurrisJK kresd[1963]: [result] => false
Jun 3 08:11:52 TurrisJK kresd[1963]:
Jun 3 08:11:52 TurrisJK kresd[1963]: > hints.add_hosts('/tmp/kresd/hints.tmp')
Jun 3 08:11:52 TurrisJK kresd[1963]: [result] => true
Jun 3 08:11:52 TurrisJK kresd[1963]:
Jun 3 08:11:52 TurrisJK 99-dhcp_host_domain_ng.py: Refresh kresd leasesTo @paja
I responded to your information request but don’t know if this reached you. Please let me know if it did.
I too have seen this, but associated with a previous incarnation where it had it appending .lan - I have removed that requiremnet, but even through multiple reboots and restarts the .lan extensions remain
Jun 4 06:48:00 Hyperion kresd[6361]: > hints.del('pluto.lan')
Jun 4 06:48:00 Hyperion kresd[6361]: [result] => true
Jun 4 06:48:00 Hyperion kresd[6361]:
Jun 4 06:48:00 Hyperion kresd[6361]: > hints.del('phobos.lan')
Jun 4 06:48:00 Hyperion kresd[6361]: [result] => true
Jun 4 06:48:00 Hyperion kresd[6361]:I’m not sure what you mean. The .lan suffix can be changed in Foris / DNS / Domain of DHCP clients in DNS.
I agree it’s not ideal that commands (hints.del(...) etc.) get logged, as they aren’t a sign of anything abnormal; unfortunately I can’t see a simple way of changing that (without losing some abnormal logs).