Howdy guys,
so excited to hear about OpenVPN integration. Could we expect such an amazing settings like https://www.youtube.com/watch?v=xiy52Hn5bTc ?? 
Once again dnsmasq has had itās port reset to 0, disabling the dns part. leaving those of us running it without a usable router.
1 Like
I think there should be created a group of beta testers of experienced candidates from this forum (itās not me), in order to avoid such unnecessary errors dropped from among the public, which no wants to deal with openWRT code reusability. (thatās me).
My final decision is to Roll back to snapshot before 3.6 and disable updates for 10 days.
I did rollback already once, and as soon router grabbed 3.6, the same set of various problems.
- lighthttp stops responding
- Majordomo not working
- stats data not sent to turris
- high CPU for hours 5+ (openssld even OpenVPN not selected yet)
- cron does not work
I have to stress, I do have only standard setup, no custom modules, manual changes, etcā¦
My router was affected by the same issue, I had to set the dnsmasq port again.
Given that the dnsmasq port is part of the userās configuration, why did the update change it?
Could we have a statement from the Turris devs on this please?
Is setting dhcp.@dnsmasq[0].port=ā53ā not the correct way to prefer dnsmasq over knotdns?
The update broke IPv4 on one of my two routers (the other works fine). The broken router can route IPv6 internet traffic (not local), but doesnāt work at all on IPv4 (Foris, Luci, general HTTP/S, SAMBA).
How do I debug this thing without having a serial console? I save logfiles to an external harddrive, but there are no logs from starts with the updated system (only after a rollback).
I tried running opkg update and updater.sh from commandline, the same result. I saw these (probably problematic?) warnings (though Iām sure I havenāt manually edited most of the mentioned files):
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Config file /etc/updater/auto.lua modified by the user. Backing up the new one into /etc/
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Config file /etc/config/updater modified by the user. Backing up the new one into /etc/co
WARN:Config file /etc/config/user_notify modified by the user. Backing up the new one into /et
WARN:Config file /etc/config/resolver modified by the user. Backing up the new one into /etc/c
WARN:Config file /etc/config/foris modified by the user. Backing up the new one into /etc/conf
WARN:Config file /etc/passwd modified by the user. Backing up the new one into /etc/passwd-opk
WARN:Config file /etc/config/system modified by the user. Backing up the new one into /etc/con
WARN:Config file /etc/shadow modified by the user. Backing up the new one into /etc/shadow-opk
WARN:Config file /etc/profile modified by the user. Backing up the new one into /etc/profile-o
WARN:Config file /etc/inittab modified by the user. Backing up the new one into /etc/inittab-o
WARN:Config file /etc/shells modified by the user. Backing up the new one into /etc/shells-opk
WARN:Config file /etc/rc.local modified by the user. Backing up the new one into /etc/rc.local
WARN:Config file /etc/group modified by the user. Backing up the new one into /etc/group-opkg
WARN:Config file /etc/config/ucollect modified by the user. Backing up the new one into /etc/cWhen can we expect a fix for the awful wifi stability? Both the 2.4Ghz and 5Ghz are unusable. Devices drop off all the time complaining about no internet or connection quality. I tried everything I could find on the forum, channels, country settings, power settings, placement, antennas. Nothing makes a change.
I bought 4 Omnias and Iām close to returning them to Amazon this week. Non provides stable wifi, even tried in different houses in different cities running stable and nightly builds.
Itās a pity as the 80 EUR VR200v routers the Omnias where meant to replace just work ever since I got them without a single hickup.
I donāt mean to sound too harsh, I love this project, but what is it worth without working wifi and currently I have close 1400 EUR of hardware lying around which I canāt use.
By me wifi 2,4 and 5 all time withouth problem.
Same here, WiFi on both bands is rock solid.Only time I had problems was with the ath10k-CT firmware on the 5 GHz band.
I suspect some people got some dodgy hardware.
Iāve repaired cron after upgrading to 3.6 manually, Luci installs donāt work (I can live with that), data collection stopped.
Iāve turned upgrades off, thinking about reverting to 3.5.
Taking into account that my Omnia configuration is very close to āout-of-the-boxā one, more specifically, I have only
- network and wifi configured
- added two fw rules for ssh access from outside
- added two collectd-mod- packages
- and a single cron job (changing LED intensity :)),
Iād expect the upgrades to be butter-smooth. Iād expect this to be a plug-and-forget device, just much more secure than my previous router that hasnāt been updated for years.
My disappointment is extreme. I love the idea of the project, but I like having a working device much more, especially for the price.
Well I am surprised to see 3.6 coming out because my Turris is still sat on TurrisOS 3.2.1 !
After reading the contents here I have turned my updater off, though it looks like that wonāt trouble the router anyway if it hasnāt been updating! LOL
Is there a change log and a way of getting to 3.5 without going to 3.6 ?
Wait for 3.6.1. It should fix all the problems which 3.6 brought.
It will be released soon!
5 Likes
Does 3.6.1 also fix the problem of wifi cards not coming up anymore since the update? Wifi was rock solid before that. After update wifi is gone (both LEDs dark) no matter how often I restart. when I revert it works perfectly
EDIT: I schnapps I saw that since the non-working wifi version there were 2 more updates. So I reboted again and wifi came up just fine. So it seems wifi is (hopefully once and for all) fixed.
Last update again rewrote the path to data storage for graphs in Statistics section:
/mnt/sda1/rrd ... /tmp/rrd
There are known bugs in opkg for which I provided patches upstream. The patches have been accepted into LEDE, and I mentioned them to Turris support, but I donāt believe they have been integrated into Turris yet. opkg: return 255 when using Luci and Lighttpd to install software packages Ā· Issue #1922 Ā· openwrt/packages Ā· GitHub
As a workaround on Turris, please edit /etc/lighttpd/conf.d/luci.conf and change āsetenv.set-environmentā to be āsetenv.add-environmentā. Then, restart lighttpd and you will be able to install packages from within LuCI. (setenv.set-environment is a new directive in the not-yet-released lighttpd 1.4.46)
I apply youre recomendation
# lighttpd include file for LuCI
## Set CGI paths
cgi.assign += (
"/cgi-bin/luci" => ""
)
## Set aliases to LuCI install directory
alias.url += (
"/cgi-bin/" => "/www/cgi-bin/",
"/luci-static/" => "/www/luci-static/"
)
$HTTP["url"] =~ "^/cgi-bin/luci" {
# 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.set-environment = ( "PATH" => "/usr/bin:/usr/sbin:/bin:/sbin" )
setenv.add-environment = ( "PATH" => "/usr/bin:/usr/sbin:/bin:/sbin" )
}
===================================================================
And resume is good ā¦ thanks ā¦ what simply. !!! For me it fixed also Segmentation Fault !!!
It would be nice to have a detailed changelog of the changes linked from the announcement. At least if the banner would link to this thread, it would make it easier for people to discuss the changes! 
I had to dig around the forums and happened to find this thread by chanceā¦
For me, running updater.sh worked well. I had queued the removal of majordomo because of this issue so there was some noise about this, but otherwise I think everything is fine:
root@octavia:/tmp# updater.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1076 100 1076 0 0 2062 0 --:--:-- --:--:-- --:--:-- 2069
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
INFO:Queue install of vixie-cron/turris/7-2
INFO:Queue install of dhparam/turris/2.1
INFO:Queue install of turris-version/turris/3.6.1
INFO:Queue install of luci-app-statistics/turris/git-17.009.29435-7d19852-2
INFO:Queue install of luci-i18n-statistics-cs/turris/git-17.009.29435-7d19852-2
INFO:Queue install of luci-i18n-statistics-en/turris/git-17.009.29435-7d19852-2
INFO:Queue removal of luci-app-majordomo
INFO:Queue removal of lcollect-majordomo
INFO:Queue removal of ouidb
INFO:Queue removal of coreutils-timeout
INFO:Queue removal of lcollect
INFO:Queue removal of ucollect-lib
INFO:Queue removal of gdb
INFO:Executing preupdate hooks...
INFO:Subprogram output: /etc/updater/hook_preupdate/05_schnapps.sh:
Snapshot number 38 created
INFO:End of subprogram output
Output from lcollect-majordomo.postrm:
/usr/lib/opkg/info//lcollect-majordomo.postrm: line 2: /etc/init.d/lcollect: not found
ERROR:Failed operations:
lcollect-majordomo/postrm: /usr/lib/opkg/info//lcollect-majordomo.postrm: line 2: /etc/init.d/lcollect: not found
INFO:Executing postupdate hooks...
This gave me the following banner on the next login:
Update from 2017/03/25 10:05:44
ā¢ Installed version 7-2 of package vixie-cron
ā¢ Installed version 2.1 of package dhparam
ā¢ Installed version 3.6.1 of package turris-version
ā¢ Installed version git-17.009.29435-7d19852-2 of package luci-app-statistics
ā¢ Installed version git-17.009.29435-7d19852-2 of package luci-i18n-statistics-cs
ā¢ Installed version git-17.009.29435-7d19852-2 of package luci-i18n-statistics-en
ā¢ Removed package luci-app-majordomo
ā¢ Removed package lcollect-majordomo
ā¢ Removed package ouidb
ā¢ Removed package coreutils-timeout
ā¢ Removed package lcollect
ā¢ Removed package ucollect-lib
ā¢ Removed package gdb
News from 2017/03/25 10:05:42
ā¢ dhparams: fix symlink creation to fix OpenVPN plugin
ā¢ util-linux: fix building of some parts and dependent packages
ā¢ luci-app-statistics: mark configuration files as such to prevent overwriting
ā¢ vixie-cron: included empty currently needed directories
Iād love to hear more about those DNS resolvers changesā¦ Where can we find more detailed changelogs of releases?
Thanks for your hard work!
so farā¦ so good.
went to my backup router, took some backups of data and configuration fines on the Omnia and did a complete factory reset (it was running 3.2.1 after that). did a full upgrade to 3.6.1, then went about restoring my configuration. everything is good so far.
It seems that the errors
2017-03-28T06:40:34+02:00 warning []: Missing message-id in rpc-reply.
have something to do with the Turris not sending any Notifications about automatic restarts when using the previous custom setting.
The last notification I got was 17th feb.
I tried to send several test messages now but none arrives and the log states:
warning []: Missing message-id in rpc-reply.