Remote Access Brainstorm - Windows 10 and Crashed Sunshine [Accessed, continuing to debug]

Operating Systems & Open Source Windows
1

tl;dr How could I access a remote windows 10 PC to reboot it without physical access? RDP is not enabled, sunshine has crashed such that a remote connection (and web UI) is not available. In the past rebooting my router (mikrotik hex) has somehow brought sunshine back up, but that didn’t work this time.

Background

I use moonlight + sunshine to remotely access my home PC while I travel.

There is some kind of bug with the switch port of moonlight that crashes sunshine when you exit a session and makes the service unavailable. The half dozen or so times that this happened before, rebooting my router has made the sunshine host available again. I hadn’t diagnosed the problem beyond that because that step was easy and always worked.

I’m out of state for the next two weeks and, for reasons that I don’t yet understand, rebooting my router has not brought the sunshine service back up.

I’m not going to die not having access to my home PC for a couple weeks, but I’m curious if there is some avenue I could use to reboot or otherwise access my home PC with my current configuration that I haven’t considered.

  • I plan on enabling RDP once I get home for a backup connection option, but for the moment the service is disabled.

  • Wsl is not installed/running

  • I am able to ping the PC from a terminal in my router.

  • The OS that the host is logged into currently is not tied to a Microsoft account.

  • I access my home network through a wire guard VPN.

  • I have the ability to send WOL packets from my home server.

  • The host has every form of UAC/firewall/defender disabled

I’m aware of devices like pikvm, but I’m curious if there are options for accessing this PC in the next two weeks while I’m away.

Any ideas?

2

I don’t think there is much you can do for your PC without physical access or the remote service beginning to work.

You’d be better off using an IP KVM or another remote software like parsec in the future.

3

Have ssh access?

Or does it happen to be on a smart plug where you could hard-boot and that’d get sunshine going?

1 Like
4

I tried just now just in case, but I hadn’t enabled ssh on this machine.

It’s on a UPS, but until I looked it up just now I didn’t think it had any remote management capabilities (BN1500M2). I’ll look into a good way to set that up when I get home, I already do something similar with my ups for my home server.

5

Look up Jeff Geerling’s recent-ish video with regards to NUT (Network UPS Tools)

Also cmon guys, if NASA can somehow reboot Voyager remotely, surely we can do something here?

Maybe you should schedule a reboot everyday so that weird issues can be cleared somewhat? Do you need 24/7 strict uptime?

2 Likes
6

Ha! I don’t know if we have enough sexy 90s cartoon girl shirts for that.

The only uptime requirement this system has is that it not reboot while I’m using it. Along the same lines as a daily reboot, I was considering ending the remote session from the offending switch BY rebooting the host device.

1 Like
7

I’ve hard-locked myself out of a computer a time or two. Last week, I remoted in to the virtual desktop, and clicked to cycle off the network connection instead of running a command in ssh to turn it off and back on.

This must be why I won’t get hired at NASA

1 Like
8

The host does have every form of UAC/firewall/defender completely disabled, in case that can be abused somehow in this situation.

9

There is probably no magic way to get into the machine without doing this first.

That in itself would be an extreme security risk.

Keep trying to restart the router or a specific port. If the UPS has the ability to manage, maybe off/on here.

You won’t think of anything more.

You are basically in a situation where you want to break into a PC… And how are we sure that it is your PC? :slight_smile:

1 Like
10

Scouts honor :raised_hand:

And admin credentials :joy:

All things told, the lack of a default-on remote access tool is certainly a good thing. But it sure would be convenient.

11

I’m digging a little more into what is happening with sunshine to see if I can make any progress that way.

The client on my phone cannot see the host, but my switch somehow can. So I’ll start there and enable a debug mode.

When initiating a connection with the host, moonlight makes a curl “request” (that’s what the logs call it) to the host over port 47989. This one is successful.

Next moonlight makes another request over port 47984, which times out. I verified that the dstnat rule is set up correctly and active, so next is to try to figure out what exactly is happening over 47984 since this seems to be what has failed.

12

It’s something to do with a timed out https loop not responding to a request. I’m going to re-create the program on a computer locally so I can see the server logs.

13

It felt me getting ready to violate it’s brothers and sisters to figure out what the problem was and started working again.

Earlier today I tried disabling it’s dhcp lease for a few minutes instead of rebooting the router, that’s probably what actually did it.

Suck it computer, I win :tada:

1 Like
14

In b4 it was DNS all along…

1 Like
15

In theory it’s a curl request to the hosts ip address over https that is timing out, but I’m not gonna rule that out :joy:

16

I was going to suggest calling up your power company to see if they’d do a quick power cycle (seems easy if you have a smart meter), but it’d probably be a little longer of an outage with a UPS (maybe they can shut it off for an hour?)

This reminded me to figure out a daily reboot script for my server; I use a laptop which also has a pretty good battery :stuck_out_tongue:

17

I’ve recreated the failure with verbose logging, so now it’s just a matter of getting out my reading glasses.

There are newer versions of both sunshine and moonlight, updating those will be the first step now that I’ve got logs.

Also, the act of logging into an RDP session to the host has been correcting the issue with a (seeming) 100% success rate :man_shrugging:

1 Like
18

Two final conclusions from my investigation:

Verbose logging in the current stable sunshine is not very useful in diagnosing this kind of problem.

The pre -release branch has much more through logging, but I’ve been unable to recreate the problem in that version.

I’m going to leave logging on in case it does ever happen again, but otherwise my answer is “something to do with resetting the host’s state on exit”.