Qubes R4.1 - Tor's Control Port could not be reached. - Time sanity check error

Qubes-Whonix
1

I have the latest packages installed in my GW and WS VM templates on Qubes 4.1, and I keep hitting this error in the WS VM:

2021-05-05 14:53:15 - sdwdate - INFO - PREPARATION:
2021-05-05 14:53:15 - sdwdate - INFO -
/usr/lib/helper-scripts/onion-time-pre-script: Start.
Static Time Sanity Check: Within minimum time 'Sun Jan 17 00:00:00 UTC 2021' and expiration timestamp 'Tue May 17 10:00:00 UTC 2033', ok.
Tor Bootstrap Result:    ERROR (124).
 Please report this bug!
/usr/lib/helper-scripts/onion-time-pre-script: END: Exiting with exit_code '1' indicating 'wait, show error icon and retry.'.
2021-05-05 14:53:15 - sdwdate - INFO - PREPARATION RESULT: (known) ERROR.
2021-05-05 14:53:15 - sdwdate - INFO -

systemcheck says that the gateway is running fine, but running it in the workstation says:

[INFO] [systemcheck] Tor Connection Result:
Tor's Control Port could not be reached. Attempt 1 of 5. Could be temporary due to a Tor restart. Trying again...
2

Found this (while going through the onion-time-pre-script checks):

user@host:~$ /usr/bin/tor-circuit-established-check
Unable to authenticate: socket connection failed ([Errno 104] Connection reset by peer)
3

Totally unrelated to timesanitycheck / sdwdate.

That is the only worthwhile symptom. Everything else are follow up issues.

Quite likely some dom0 settings are wrong.

Properly installed?

Using anon-whonix default VM?

How did you create that workstation?

If additional workstation, did you create it as per instructions?

4

I’m using the whonix-ws-15-dvm, which was created using:

sudo qubesctl state.sls qvm.anon-whonix

EDIT: Just checked anon-whonix and it shows the same error. This was working a week ago before it broke after I applied updates.

5

Networking of anon-whonix is set to sys-whonix in Qubes VM Manger (QVMM)?

6

Yes, and the dvm too.

7

Unsupported. Not yet supported.

I didn’t look into Qubes R4.1 yet. Qubes-Whonix works fine in R4.0. No reports of breakage through Whonix upgrades. Possibly some Qubes R4.1 upgrade has broken it.

8

Here’s why Whonix wasn’t working in Qubes R4.1 - some update set IPv6 to “1”. Unsetting that makes it work again FYI @Patrick

Hi there, I have had the exact same problem and have been trying to resolve it for the last 4 days or so. It also occured for me after a dom0 update, i had also updated to kernel-latest and kernel-latest-qubes-vm (5.12.4-1).

I tried booting off the other kernels, and i tried setting as default all versions I had of qubes-vm kernel, which made no difference at all, I tried restoring all whonix related templates and appVM’s from a backup where they all previously worked and spent countless hours looking up what the problem might be.

I finally found what fixed the issue for me with the information on this page: #5110 . I issued in dom0 as su the commands:
qvm-features sys-whonix ipv6 ‘’ and
qvm-features anon-whonix ipv6 ‘’

I do not know if the second command was needed as I issued both at the same time.

I shutdown anon-whonix, restarted sys-whonix and ran anon-whonix tor browser and the issue was gone (kernel-qubes-vm 5.10.37-1). I started a whonix-ws-15-dvm and was able to connect without issue. I decided to check the kernel-latest and rebooted qubes after setting kernel-latest-qubes-vm 5.12.4-1 to default and booted at grub with kernel 5.12.4-1 and the issue was still gone. I also tried running a fedora-33-dvm through sys-whonix and this also had tor connectivity.

I am guessing that one of the updates enabled ipv6 in the whonix templates somehow, I am very new to github so I don’t claim to have technically diagnosed this in anyway, but hope this information will be of use to @jpds and maybe to @adrelanos and @marmarek with fixing it.

1 Like