1.3.297 is released (a 1.4.0 pre-release)

Please try the new 1.3.297 “unstable” build:


We’re aiming for a stable 1.4.0 soon here and the more testing we can get on these final 1.3.x series builds the better! (Our odd minor numbers are the dev branch series for the even minor branch stable series, cut from the end of the dev series) So things should be pretty stable at this point.

We’ll be working on release notes, but the main thing I’m excited about that the moment is that Tailscale now idles much better than it did in the past. It should use less CPU, bandwidth, battery than it did previously. It also has prettier tailscale status output.



Hi @bradfitz. I’m not having any luck with this 1.3.293 build on Win 10. I can’t ping any other Tailscale nodes. I rolled back to 1.3.147 and it works fine again. (I repeated this a couple of times trying to get 1.3.293 working, but no luck).

When it’s in the broken state, tailscale.exe ping $Tailscale_IP works, but ping.exe $Tailscale_IP does not. The tailscale.exe status output is very different between versions, and the new output doesn’t look right to me. I don’t want to paste it all here, but I noticed the new status output 1) it seems to be missing any IP, RX, TX, location info and 2) it is referencing what looks like Magic DNS hostnames, but I don’t have Magic DNS enabled and don’t need it.

Please let me know where I can send some additional output if you think it would be helpful.

What’s your Tailscale IP address? I can look at your logs and try to see what happened.

Testing on Rasbian (Stretch, not Buster, but that hasn’t caused an issue in the past). I wasn’t able to start it via systemd: tailscaled complains that:

tailscaled[4977]: 2021/01/22 10:39:47 --state is required

However, running tailscaled manually appears to work, and it’s certainly using less outgoing bandwidth, hooray!

(BTW, I tried blowing away /var/lib/tailscale/tailscaled.state, but still got the “–state is required” error, and /lib/systemd/system/tailscale.service does pass --state, so I’m not sure what’s going on there…)

@emoon, thanks! I found the issue. It was the --cleanup phase that was requiring it but it shouldn’t be.

1 Like

… but I’m confused why the default implementation --state value wasn’t working. On Linux it should use /var/lib/tailscale/tailscaled.state as the default if it’s read+writable or if /var/lib/tailscale/ or /var/lib/ is.

That does work here for a normal (non- --cleanup) invocation:

sudo /usr/sbin/tailscaled --socket=/run/tailscale/tailscaled.sock

@bradfitz Tailscale IP for the Win 10 box is

@33b5e5, fix coming soon. Details in Failed to write packet to TUN device: packet dropped by filter · Issue #1192 · tailscale/tailscale · GitHub. I’ll cut a new build shortly here. Thanks for the report!

1 Like

@emoon, @33b5e5, new build is going up now… 1.3.296 should address both of your issues. Thanks again!

1 Like

Thanks @bradfitz. I can confirm 1.3.296 resolved my issue.

I still find the new output for tailscale.exe status a bit strange, as it’s showing these Magic DNS names that I don’t use. The previous output just showed the short machine names, exactly as I see them on the admin console. This makes more sense when Magic DNS is disabled, in my opinion.

Edit to add: I use my own domain for DNS, and my names are considerably shorter, which is perhaps another reason I find the new output with these incredibly long Magic DNS names off-putting.

@33b5e5, can you email me the output you see from tailscale status? bradfitz at tailscale.

You should only be seeing the first name components of magic DNS names in your network and only the super long names for shared devices.

If you’re seeing the super long names for all your devices then something is broken and it’ll probably be less disagreeable once it’s prettier.

And hah… I was about to send you a screenshot of how pretty it looks to me but now I see the long ugly names too.

Something must’ve just changed somewhere in the past day. I’ll fix.

@33b5e5, nevermind, I was using the wrong version.

But I can reproduce now. It’s only ugly if you have MagicDNS off. The CLI was depending some response fields that are only sent when MagicDNS is enabled.

Will fix, thanks!

1 Like

Okay, the build machinery is cranking out 1.3.297 builds that make tailscale status format as we’d intended when MagicDNS is disabled. You may still not subjectively like it as much as the old format, but it’ll at least be how it was meant to look.

If you really dislike it, though, let us know and why. Details for the motivation of the various changes are in cmd/tailscale: change formatting of "tailscale status" · tailscale/tailscale@5efb0a8 · GitHub

Ah… much better on 1.3.297. No other complaints about the new format. Thanks again @bradfitz!

1 Like

Hi @bradfitz, updated to 1.3.306 on Windows. Everything looks OK, I actually had an RDP connection open, and the update installed and brought up the network quickly enough that the RDP connection reconnected automatically!

I like the tailscale status output when using MagicDNS. I see tailscale status -web does not show MaginDNS though? Also not sure if it’s in scope for this piece of work, but when right clicking on the menubar and going to Network Devices it shows hostnames, but I wonder if that should show MagicDNS names as well/instead?

@gilbert, good finds! Both fixed. They’ll be in the next build.

Okay, try 1.3.313 now.