3.8.3 in RC: dnsmasq security fixes and more

Dear Turris testers,
we will release Turris OS 3.8.3 into an RC branch in following minutes. It is already tested but we would like to test it more :wink:

You know, DNS and DHCP could be tricky, so please, try as much testing scenarios as possible. We are using dnsmasq only for DHCP by default but everything is possible with open system. :slight_smile: Other changes could brings the smile to NAS box users and make openssh more secure again.

Changes are:

  • dnsmasq: various security fixes
  • kernel: various small fixes
  • openssh: security update
  • asm1062: workaround for error with SATA controller

The whole Turris team wishes you happy testing and we are looking forward to reading your feedback!

Sooner feedback means sooner release. And we want to keep you secure :wink:

One more thing!

There is a typo error in Czech version of release message in Foris. We are sorry for that, we had already corrected it but we did not want to postpone the release (building the release takes some time) just because of it :wink:

Have a nice day!

It works for me. Wifi, DNS, DHCP etc. work.

Some errors during update, sent to tech support, waiting for reply, restart planned after reply from tech support.
Turris 1.1 , btrfs

So I switched to RC branch on mine Turris 1.0 and I see there are four minor issues:

Output from openssh-server.postinst:
/var/etc/ssh/sshd_config line 5: Deprecated option UsePrivilegeSeparation
/var/etc/ssh/sshd_config line 5: Deprecated option UsePrivilegeSeparation

and the second one is really minor. There is just a typo:

You can discuss problems on forim (https://forum.test.turris.cz).

The third is about tvheadend package, I tried also remove some other things, but I can see it only in this case:

root@turris:~# opkg install tvheadend
Installing tvheadend (4.2.3-0) to root…
Downloading https://repo.turris.cz/turris-rc/packages//turrispackages/tvheadend_4.2.3-0_mpc85xx.ipk
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7048k 100 7048k 0 0 3595k 0 0:00:01 0:00:01 --:–:-- 3725k
Configuring tvheadend.
root@turris:~# opkg remove tvheadend
Removing package tvheadend from root…
Command failed: Not found
root@turris:~# tvheadend
-ash: tvheadend: not found

So TVheadend it’s uninstalled, but why it says command failed?

and the last one (is still valid) and it’s only for Turris 1.x in Foris under tab “Updater” it says that I have Turris Omnia instead of Turris (I also created issue #62 in Gitlab - Foris 3 months ago) :wink:

I see there’s kernel update for us as well, but my question is about driver for MediaTek MT76x2 or RTL8812AU
Can it be included in next Turris version? I think I can compile it by myself, but if I’m right then I’d need to manually install it (or compile it, too) after each kernel update.
I was thinking that I can use atleast one of those USB WiFi dongles (Comfast CF-912AC or CF-926AC) as Access Points. Because chipset MT7612U looks very promising atleast for my case of usage.

Btw wasnt the typo error in English message instead of Czech? :wink:

Thanks, will look into this.

Probably some minor issue in init script that it outputs some useless errors when stoping service that isn’t started.

If somebody packaged it somewhere or you send a pull request with package, shouldn’t be a big issue to include it in 3.9 (as long as it compiles and we wouldn’t have fix bugs in it).


If somebody packaged it somewhere or you send a pull request with package, shouldn’t be a big issue to include it in 3.9 (as long as it compiles and we wouldn’t have fix bugs in it).

The latest I can find here:
LEDE (then OpenWRT, but there it is almost 2 yrs old)

I also found packages pre-compiled it both repositories - in OpenWRT - kernel doesn’t match and in LEDE (one that I have incompatible architecture and the second one more common: ‘cannot install’)

I think better questions are:

  • Why it was mt76 removed from TurrisOS repo and why it isn’t there?
  • Why we need to ask for something, which is supported in LEDE/OpenWRT? (I know that TurrisOS will be based on LEDE soon and hopefully we will have same or more modules/packages as LEDE than right now)
    If I can use packages from one of those repositories I woudn’t complain about it, but right now
    there are three solutions for me:
  1. Spend time and compile it by myself (why I would do that, when somebody already spent his/her time to have it in OpenWRT/LEDE? :slight_smile: )

  2. Wait to have it in TurrisOS repository

  3. Ask for support.

Hopefully things will improve in near future.

Back to issues:

And another issue is still there from 3.8.x for Turris 1.x.
We don’t have locale support for Nextcloud as it is mention there:

and there is also your’s reply when you said 21 days ago that you will look into it. :confused:

Ok, will try whether it will compile.

From git log: Remove as it doesn’t build and we don’t need it

Simple. Because that it was built once somewhere somehow doesn’t mean that it will build everywhere all the time :slight_smile: And we have limited resources, so we are not fixing every might be helpful to somebody package if it doesn’t build.

You can’t use those repositories, because the build system is a mess and federation is something light years ahead :slight_smile: There is fourth option, compile it and send a pull request :wink:

Yep, I still plan to look into it deeper, but based on the preliminary findings it would need more radical change and thus a lot more testing and thus no go for fix-up releases.

1 Like

Updated to RC 3.8.3 after some hesitation :wink: SFSG :slight_smile: but I do have simple configuration only. Found discrepancy between documentation How to test Turris OS branches and releases and hint in forum How to test RC branches - different URL in /etc/opkg/distfeeds.conf. Anyhow, Omnia is up and running!

Still does not build - https://gitlab.labs.nic.cz/turris/openwrt/commit/32ff9631f8c2c10ca68f5ab80abbdccabaabb644 So the answer why is it not present is simple - it doesn’t build and it is not a priority for anybody.

Is this a new feature (time settings in firewall policies) or I was only sleeping - I like it!

Restarted, everything works.
Edit: Another kernel update to 4.4.91, restarted, everything works.

It was there all the time.

1 Like