Turris OS 6.0.2 is now released

Sorry for the late reply, I missed this message. Could you give us more details? The router uses a different method of managing LEDs when it’s booting up, so it’s possible that method works and then when the rainbow script takes over, it breaks. You mentioned it worked before, was that with 6.0.1, 6.0.0 or Turris OS 5? Could you post your /etc/config/rainbow and which router you are using?

I’ve been using Tailscale on my Omnia for some time now, but thus far have been installing it by hand using the static binaries they provide, since I need the most up to date upstream version for things like 6in4 subnet routers to work.

How up to date is the version (to be) packaged for TOS? I’ve searched through the CZNIC Gitlab repositories, but can’t figure out what version you’re using.

1.24.2-1 is in 6.0.3, currently in HBT phase.

That’s ancient, I presume it’s what OpenWRT 21.02 ships? It would be good to have a way to provide a more recent and regularly updated version for TOS.

I’m planning on going to the CZ.NIC conference in Prague on the 22nd, let’s discuss possibilities there.

Hi, thanks for the interest. I plan to install new medkit and start from scratch. There is more things I want to move to default (config). Many things broken, and I actually have simple setup (not considering VLANs) but other than that it is simple setup.

I will answer it ahead of time, so you don’t need to wait until CZ.NIC conference. :wink:

Since we are based on top of OpenWrt. You will not find it in our repositories. What you can find on our GitLab instance are patches located in the Turris Build repository and then our Turris-specific feed.

The proper question is - how up to date version of tailscale is in OpenWrt? Each OpenWrt version has the same version, which is now 1.24.2. Because I recently updated it in OpenWrt 21.02, and thus it is going to be present in Turris OS 6.0.3.

Reference:

Any pull requests are welcome. :wink: OpenWrt will appreciate it, but first, check my response here:

TL;DR: We are not going to maintain every package, which you can find in OpenWrt, nor update it, so feel free to do it yourself. :+1:

Thanks for the pointer.So, the Tailscale version in OpenWRT 21.02 is 1.24.2. Upstream is at 1.32.2. I think we don’t have to argue about why 1.32.2 might be better than 1.24.2.

Let me rephrase my question(s):

  1. I presume that Tailscale will stay at 1.24.2 in OpenWRT 21.02 for the lifetime of that release. Correct?
  2. I presume that Tailscale will stay at 1.24.2 in TOS until TOS upgrades to a newer OpenWRT. Correct?
  3. Given the pace of Tailscale development, if we wanted to ensure that TOS has a version of Tailscale that is as up to date as possible (TBD what “possible” means), how would we go about it?

Sure. I’d like to understand what process changes, if any, we might need to get to (3) above. If any update of Tailscale is always in lockstep with OpenWRT with the current state of how TOS release processes work, then (3) is not achievable, right?

Edit: We can also take this to a Gitlab issue if you like, so as not to spam this thread.

I presume that Tailscale will stay at 1.24.2 in OpenWRT 21.02 for the lifetime of that release. Correct?

It could be, but Tailscale should be updated in the OpenWrt master branch, and then it could be backported. Still, since the newer Tailscale version requires a newer version of Golang, thus it could be complicated to have it backported to OpenWrt 21.02, so you will see if you will create a pull request to OpenWrt packages feed.

I presume that Tailscale will stay at 1.24.2 in TOS until TOS upgrades to a newer OpenWRT. Correct?

As I said, currently, in all OpenWrt supported versions, there is the same version of Tailscale. If someone updates it in the meantime in OpenWrt 22.03, then you will see the new Tailscale version once we update Turris OS to OpenWrt 22.03. Otherwise, the version would be the same if nobody steps in.

Given the pace of Tailscale development, if we wanted to ensure that TOS has a version of Tailscale that is as up to date as possible (TBD what “possible” means), how would we go about it?

Short version: The community should step it, and prepare OpenWrt build system, or you can use scripts to prepare the Turris environment. You need to get familiar with how to compile packages for OpenWrt. Then you can test it on your router, upstream it.

That will be closed immediately since this does not belong to our GitLab as I said in the first place because it is an upstream issue not ours.

Yes, that’s problematic but not impossible.

What sort of timeframes are we talking about here? If someone were to update Tailscale in OpenWRT, how long would you expect it for that upstream version to make it into TOS? To be clear, I’m not asking for a commitment from you here, I’m just trying to understand the process involved as it stands today.

So, what you’re saying is that the current preferred (only?) way for Tailscale to get shipped in TOS is via upstream OpenWRT? If I were to submit a set of patches to TOS directly that updated Tailscale in TOS then those wouldn’t be accepted?

Alternatively, if someone were to provide a maintained package repository with upstream Tailscale packages that work on TOS 6.0, would you be willing to point TOS + Tailscale users at that repository? (Via the Wiki, documentation, etc?)

We are following or tracking the OpenWrt branches, so each Turris OS version uses the latest changes, which were in that time for the relevant OpenWrt version. I’m sure that this is described somewhere (in Turris Build repository documentation, or you can find it in user-docs repository).

You can check the git-hash file on repo.turris.cz for each branch.

Yes, everything belongs to upstream and since most packages come from OpenWrt as it is, then it should be there.

Why would we increase our maintainership and efforts if it happens that it does not compile or it does not run as it should? It could be broken anytime that it means that we will need to take a look, at why it is broken, and what we can do about it. That’s why it should be sent to upstream in the first place. Everything is about priorities and some things have higher priority than others.

Nope, we are not going to that. It will mean that we will need to support it. Our support has different duties than supporting any package in OpenWrt. We provide support only for things, which you can do in reForis and configure it, there.

I guess you could roll on a personal patchset if you require specific sw versions?

Or build your personal TOS build?

If the way with upstream openwrt is not ”fast” enough

1 Like

I could do all of those things. But, if I’m doing it solely for my own use, I may as well keep using the static binaries provided by Tailscale and /etc/rc.local. I was just trying to figure out if it was worth and possible to maintain a “better” and up to date integration of Tailscale for TOS from which others could benefit.

AFAICT there’s no way to to ship such a thing to users, so there’s no point in working on it.

@Pepe explained it enough, you can maintain it yourself if you need newer version and moreover you can do pull request in order other Turris users may benefit also :wink:

There are thousands of packages which cant be maintained per user request. Turris OS 6.0 is simply based on OpenWrt 21.02. If you are not happy you can try Turris OS 7.0.

@iron-maiden I’m not asking anyone to maintain anything, I was trying to understand what the process was for a package (specifically, Tailscale) to make it from upstream into TOS.

I understand that now, and the constraints involved so thanks @pepe for explaining. Having slept on it, I have an idea for an automated process to get upstream Tailscale updates that’s as “maintenance-free” as possible. Will try and implement it and come back when I have something that works.

1 Like

If maintaining the OpenWrt package doesn’t fit your requirements (in terms of update frequency or whatever) then you could still run your own repository and package feed and point users to it through a forum thread such as this one. If there’s substantial interest in that feed then I’m sure that it will be possible to reference it in more prominent places as well.

Yeah, that’s the idea. I’ll see if I can figure out an automated and transparent way of doing that using the binaries built by upstream (which sidesteps the issue of needing a newer Golang in the OpenWRT base).

But it doesn’t work… My MOX is up to date, Nextcloud was freshly added to system afterwards, but the problem is still there.

Please start a new thread and describe the problem.

This problem is also present on my Turris Omnia since TOS6.0.
The issue tracker only mentions Turris 1.1.

root@turris:~# sentinel-fwlogs
Packet handling failed: Resource temporarily unavailable

From the issue tracker I gather that the problem is not fixable at the moment?

Following up on this as promised, I’ve developed some automated tooling to build packages of upstream Tailscale for Turris OS. Github repo is here and feedback welcome in a separate forum thread.