TAILMON TAILMON v1.0.20 -July 27, 2024- WireGuard-based Tailscale Installer, Configurator and Monitor (THREAD #1 CLOSED)

[jksmurf]

No worries. Give me a minute while I downgrade my version, then try the Tailmon update again. Back in a wee while.

Sorry, had a couple of glitches but got there.

1. TS won't downgrade any more using the lines below, it just says:

tailscale update --version=1.66.1
installed stable version 1.66.4 is newer than the latest available version 1.66.1; no update needed

and

2. I had to turn off Tailmon's "Keep Alive" custom option to be able to copy the two older TS files (from a Browser-downloaded 1.66.1 version) across to /opt/bin/ using WinSCP ...

But yes Tailmon updates Tailscale just fine for me, see attached; 1.66.1 to 1.66.4.
Does not help you though, I am really not sure why it is complaining at your end?

 

[jksmurf]

net/http: TLS handshake timeout

Maybe a firewall issue?

 

[oldsweatyman]

Maybe a firewall issue?

Can't think of any... I tried to specifically whitelist the tailscale.com domain on Skynet.

I tried to turn off the exit node setting on my router to see if that would make a difference somehow but now it seems tailscale didn't automatically restart and I'll have to wait until I'm home to troubleshoot some more. Lol.

 

[jksmurf]

tailscale didn't automatically restart

If you have already updated to 1.66.4 that's another issue, see above.
Fix it by issuing (from the CLI) tailscale --reset, then (in Tailmon) restarting (S) and/or connecting (U) the service.

Anyway good luck, let us know how you get on; might help someone else.

[EDIT] Presumably you saw my successful test-update 1.66.1 to 1.66.4; went fine.

 

[oldsweatyman]

If you have already updated to 1.66.4 that's another issue, see above.
Fix it by issuing (from the CLI) tailscale --reset, then restarting (S) and/or connecting (U) the service.

Anyway good luck, let us know how you get on; might help someone else.

Lol I'm back. Was able to set tailscale on my unRAID server to advertise the local subnet and access my router again.

I still can't update to 1.66.4. Or other versions. It's bizarre to me.

oldsweatyman@RT-AX86U-BC30:/tmp/home/root# tailscale update --version=1.66.1
This will update Tailscale from 1.58 to 1.66.1. Continue? [y/n] y
Downloading "https://pkgs.tailscale.com/stable/tailscale_1.66.1_arm64.tgz"
Download size: 25789267
Get "https://dl.tailscale.com/stable/tailscale_1.66.1_arm64.tgz": net/http: TLS handshake timeout

It doesn't seem like a firewall issue because, like I mentioned before, if I am connected to tailscale with my unRAID server as the exit node (same). I can only think that maybe it is a DNS issue.

If I run "dig google.com" on my router via SSH, the DNS server that comes up is 127.0.0.1, which I have configured because I am using unbound. I tried to change this to 9.9.9.9 earlier but wasn't successful.

Using dig on my laptop with unraid as exit node, dig returns 100.100.100.100 as the DNS server, and the download of the tailscale package works.

- MagicDNS is disabled. Turning it on doesn't make a difference.
- The override local DNS toggle (with 9.9.9.9 configured) doesn't make a difference.

dig google.com via SSH on unraid returns 9.9.9.9, perhaps from my prior efforts. With SSH on unraid, wget similarly stalls:

root@unraid:~# wget -v https://pkgs.tailscale.com/stable/tailscale_1.66.1_arm64.tgz
--2024-05-22 23:19:28--  https://pkgs.tailscale.com/stable/tailscale_1.66.1_arm64.tgz
Resolving pkgs.tailscale.com (pkgs.tailscale.com)... 199.38.181.239
Connecting to pkgs.tailscale.com (pkgs.tailscale.com)|199.38.181.239|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://dl.tailscale.com/stable/tailscale_1.66.1_arm64.tgz [following]
--2024-05-22 23:19:28--  https://dl.tailscale.com/stable/tailscale_1.66.1_arm64.tgz
Resolving dl.tailscale.com (dl.tailscale.com)... 109.105.218.17
Connecting to dl.tailscale.com (dl.tailscale.com)|109.105.218.17|:443... connected.

Just stuck there...

 

[jksmurf]

Just stuck there...

I'm going to have to throw my hands up at this point, beyond my meagre experience and capabilities, sorry.

I had a wee look at the google results of Cannot update tailscale "net/http" AND "TLS handshake timeout" but I'm not sure it applies i.e. it might but I have no idea if it might .

Hopefully you'll get someone cleverer than me having a go.
You're just going to have to sweat it out on your own until then...

 

[Viktor Jaep]

Just stuck there...

The 302 error is weird... that's a redirect error, usually something on their end. But if it works for @jksmurf, it should work for you. I updated my device last night to .4 without issues either.

Just wanted to make sure you've done the basics, and have rebooted your router already, correct? Also, you're not forcing traffic out through any other devices like a VPN, or other hardware, right? No Pi's on your network, or other servers traffic might be interacting with? Your router's traffic isn't being forced outbound through your exit node, correct? To ensure it doesn't, perhaps disable the exit node capability, or bring the tailscale service down on that device? Last, does the time look in sync across your router/network compared to your other devices? If not, that could possibly also be a cause. Are you performing these actions using tailscale-over-ssh? If so, perhaps dialing in directly to the router just to see if it makes a difference?

 

[jksmurf]

Actually what I think is happening with the reset is this:

• In 1.66.0 the default stateful-filtering parameter was on.
• To fix connectivity issues folks were told to issue tailscale up --stateful-filtering=false to turn it off.
• In 1.66.4 the default stateful-filtering parameter is already off.
• Issuing tailscale —reset thus has tailscale up --stateful-filtering=false (i.e. switched off) without needing to actively switch it off i.e. the ‘fix’ is automatically applied.

I’d almost venture to say (unless tailscale stuff it up again) this is a one-off thing and after folks have updated to 1.66.4 and issued tailscale —reset just the once, you won’t have to deal with it ever, ever again. Famous last words…

@Viktor Jaep

Some more thoughts on this. The irony is, if I’m correct here, that folks who install Tailmon for the first time get the entware version, being vers 1.58.2-1, which (I believe) does not have that stateful-filtering parameter set to on (=true) as default.

They will then update to the latest (and ‘greatest’) version, being (currently) vers 1.66.4, for which the default stateful-filtering parameter is off (=false).

So this issue (requiring a tailscale up —reset as I suggested above) will possibly only affect those who went from 1.58.2-1 to 1.66.x to 1.66.4 and not from 1.58.2-1 to 1.66.4 directly.

Still worth having a tailscale up —reset line in the update procedure though ;-)

 

[Viktor Jaep]

@Viktor Jaep

Some more thoughts on this. The irony is, if I’m correct here, that folks who install Tailmon for the first time get the entware version, being vers 1.58.2-1, which (I believe) does not have that stateful-filtering parameter set to on (=true) as default.

They will then update to the latest (and ‘greatest’) version, being (currently) vers 1.66.4, for which the default stateful-filtering parameter is off (=false).

So this issue (requiring a tailscale up —reset as I suggested above) will possibly only affect those who went from 1.58.2-1 to 1.66.x to 1.66.4 and not from 1.58.2-1 to 1.66.4 directly.

Still worth having a tailscale up —reset line in the update procedure though ;-)

I think you're right... it may not affect a good majority of folks except for those who have been DILIGENTLY updating, and having to deal with the constant changes Tailscale is making to the client/backend. I probably will add the reset in there just so that people have a way to start from scratch if need be, should these switches get out of control for them -- and prevent basic operation -- which is what TAILMON is meant to provide.

 

[alan6854321]

@Viktor Jaep - I mentioned this earlier, but I think it got lost in the noise.

There's a problem where by TAILMON flashes up a (Sometimes lengthy) error message and then it disappears within seconds. You don't get time to read it.

Can you alter the script so that when it shows one of these messages, you get a "Hit any key to continue" type thing, rather than an instant return to the menu.

 

[Viktor Jaep]

@Viktor Jaep - I mentioned this earlier, but I think it got lost in the noise.

There's a problem where by TAILMON flashes up a (Sometimes lengthy) error message and then it disappears within seconds. You don't get time to read it.

Can you alter the script so that when it shows one of these messages, you get a "Hit any key to continue" type thing, rather than an instant return to the menu.

Can you tell when this happens? When it's starting services? I don't see that on my end... Are you not able to scroll back in your SSH window to see what it said?

It may be interesting to see what happens when you execute all these commands manually, to see if that error presents itself?

 

[alan6854321]

Can you tell when this happens? When it's starting services?

The first time I remember is when I tried to remove the "--advertise_routes" option and it was telling me I had to use the "--reset" flag.

It took me a long time to select + cut&paste the message. The screen gets cleared in seconds afterwards, you can't scroll back as something clears the screen.

 

[Viktor Jaep]

The first time I remember is when I tried to remove the "--advertise_routes" option and it was telling me I had to use the "--reset" flag.

It took me a long time to select + cut&paste the message. The screen gets cleared in seconds afterwards, you can't scroll back as something clears the screen.

Hum.... yeah, I would expect that if changes are being made to the commandline switches, that it will start complaining. I'll see if I add/delete some switches to see if I can replicate that... and see what can be done to catch that. As @jksmurf mentioned, there's another possible option to always run a "tailscale up --reset" after changes are made to the commandline, and then push the actual commandline through... hopefully that could prevent messages like that from appearing... but I'm not sure what damage it may do, or if it can require you to have to copy/paste another link to reactivate the device. That's going to take some testing.

The upcoming version of TAILMON will allow you to independently run a "tailscale up --reset" command in case you experience issues... so perhaps that might also be of help.

 

[jksmurf]

or if it can require you to have to copy/paste another link to reactivate the device.

Just a brief initial response on this, when I ran tailscale up —reset from the CLI to fix the issue of the Service not connecting after the 1.66.4 update, I was neither offered a new link nor did I have to reactivate the device.

It just reconnected and stayed that way even if I disconnected again manually. Admittedly I only tested in Kernel mode, did not test other modes.

So it reset stateful-filtering and ‘apparently’ nothing else, although it might have been re-adding the IP address, being the Router default, so it ‘appeared’ as if there were no other changes. As noted, initial feedback only.

[EDIT] The —reset command only resets unspecified switches (on any associated flag) to their defaults. It does not change or remove the flag itself; nor does it change a specified switch.

 

[Viktor Jaep]

Many thanks to @jksmurf for his feedback and testing on this... a few minor updates to help keep making TAILMON more functional! Enjoy!

What's new?
v1.0.12 - (May 23, 2024)
- PATCH: Added the ability to additionally (R)estart the service/connection under the Operations Menu as well as the setup/configuration menu. Instead of having to s(T)op and then (S)tart the service, and separately stopping/starting the connection, this will do it all in one swoop. It may also help prevent a loss of connection while remote, as stopping anything Tailscale-related it typically pretty dangerous, unless you have another way back in.
- PATCH: Added another menu item under the Setup/Configuration that will allow you to initiate a "tailscale up --reset" command. As of recent, with the latest changes being made to the way the client functions, it was necessary to issue this command in order for the connection to continue operating. While this command can be run manually, it was decided to incorporate this option in the TAILMON UI for ease-of-use. Appropriate warning language and further information has been added to this item (I) in the Setup/Config menu after running it.

Download link (or update directly within AMTM or TAILMON):

curl --retry 3 "https://raw.githubusercontent.com/ViktorJp/TAILMON/master/tailmon.sh" -o "/jffs/scripts/tailmon.sh" && chmod 755 "/jffs/scripts/tailmon.sh"

Significant Screenshots:

From the main Operations Menu, you can now (R)estart the Tailscale service/connection with 1 keypress.

Likewise, you can perform this same action under the setup/config menu, as well as the new (I)nitiate the "tailscale up --reset" commmand

When you hit (I), you will be presented with a warning and a note on how this functionality operates, and what to expect. Thanks much to @jksmurf for the suggestions on crafting this... Any questions? This was done out of a possible necessity when client 1.66.4 came out that cause a few small waves due to default switches that were turned off, then on, then off again... or something like that. LOL

 

[ohnggni]

Is there any way to update tailscale on Merlin? When I execute to update binary, the message, 'update command is not supported on this platform' came out.

 

[jksmurf]

Is there any way to update tailscale on Merlin? When I execute to update binary, the message, 'update command is not supported on this platform' came out. View attachment 58949

Hi,

If you have TAILMON installed, then press C for the config menu, then P, it should update it for you, but I see it gives you an error. Hmmm.

A RT-AX3000 (per your pic) should be ok, not sure what platform it is referring to. I am assuming the Router is v1, as the RT-AX3000 v2 does not support Merlin and you did mention “on Merlin”; plus you apparently have TAILMON installed (per your pic), so your router must support Merlin.

With Tailscale v1.46.1 installed (again per your pic) however, it seems you did not install Tailscale via amtm/TAILMON (with entware)? I ask, as the TAILMON Addon installs version 1.58.2-1, as the base version.

Perhaps try uninstalling, then reinstalling TAILMON (from within amtm), which should install all the dependencies, including entware?

This will give you a starting version v1.58.2-1, after which you can then do a C, P update to v1.66.4.

Let us know how you get on, feedback is always super useful, any kind.

@Viktor Jaep, interesting scenario here, in that it appears (from the supplied pic) that TAILMON was either (i) successfully installed on top of an old Tailscale (manual?) install but without updating the installed binaries or (ii) maybe an older version (v1.46.1) of the Tailscale binaries was placed over the TAILMON/entware v1.58.2 install.

Either way, for the first scenario (which I will admit is unusual), maybe an item for a future TAILMON update, to somehow check for a current Tailscale install and remove it/overwrite it (if it currently does not do that)? Might be a bit fiddly as any manual install wouldn’t be using the entware-based install directories…

 

[Jim Scardelis]

I just want to say "thank you" sooooooooooooo freaking much for creating this. I've been trying to get tailscale running on my router so that I can use it as an exit node when I'm traveling, and access devices, like my printer, that aren't able to run tailscale themselves.

 

[oldsweatyman]

The 302 error is weird... that's a redirect error, usually something on their end. But if it works for @jksmurf, it should work for you. I updated my device last night to .4 without issues either.

Just wanted to make sure you've done the basics, and have rebooted your router already, correct? Also, you're not forcing traffic out through any other devices like a VPN, or other hardware, right? No Pi's on your network, or other servers traffic might be interacting with? Your router's traffic isn't being forced outbound through your exit node, correct? To ensure it doesn't, perhaps disable the exit node capability, or bring the tailscale service down on that device? Last, does the time look in sync across your router/network compared to your other devices? If not, that could possibly also be a cause. Are you performing these actions using tailscale-over-ssh? If so, perhaps dialing in directly to the router just to see if it makes a difference?

Jesus Christ. Sorry everyone. Worked after I restarted my router and tried again.

 

[Viktor Jaep]

Jesus Christ. Sorry everyone. Worked after I restarted my router and tried again.

Whooo go @oldsweatyman!!