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.
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…)
… 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.
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, 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.
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.
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?