telepresence
telepresence copied to clipboard
Telepresence fails to connect with no error in logs
Hi i'm trying to get telepresence to connect to my EKS cluster and i have not had any luck getting this to work. I've tried reinstalling, clearing caches/logs, running as sudo, etc. I'm running on MacOS BigSur 11.3.1
Client: v2.3.6 (api v3)
Root Daemon: not running
User Daemon: not running
[sean.sabour | ~]> telepresence connect
Launching Telepresence Daemon v2.3.6 (api v3)
Need root privileges to run: /usr/local/bin/telepresence daemon-foreground /Users/sean.sabour/Library/Logs/telepresence '/Users/sean.sabour/Library/Application Support/telepresence' ''
Password:
telepresence: error: daemon service did not start (see "/Users/sean.sabour/Library/Logs/telepresence/daemon.log" for more info)
[sean.sabour | ~]> ls /Users/sean.sabour/Library/Logs/telepresence/
daemon.log
[sean.sabour | ~]> cat /Users/sean.sabour/Library/Logs/telepresence/daemon.log
[sean.sabour | ~]>
[sean.sabour | ~]> sudo telepresence connect
Password:
Launching Telepresence Daemon v2.3.6 (api v3)
Connected to context arn:aws:eks:us-west-2:REDACTED/REDACTED(https://REDACTED.eks.amazonaws.com)
[sean.sabour | ~]> curl -ik https://kubernetes.default
curl: (7) Failed to connect to kubernetes.default port 443: Operation timed out```
@seansabour, please provide the answer to these questions:
- Do you have permission to read the
/var/run
directory? (the first thing the daemon tries to do is to create a socket in that directory. The message is reported when that socket doesn't show up). - Before and after the this happens, if you do
ls -l /var/run
, do you see atelepresence-daemon.socket
there? - Before and after the this happens, what's the output of
pgrep -lf daemon-foreground
?
I have this issue as well, i.e. daemon fails to start and the daemon log is created but remains at 0 bytes. I have read perms for /var/run. When it fails to start, there is no daemon.socket file.
My workaround was to run the daemon by hand, i.e. extract the command from the output above where it says "Need root privileges to run: ..." and run that with sudo, i.e. for me it is:
% sudo /usr/local/bin/telepresence daemon-foreground /Users/pxmante/Library/Logs/telepresence '/Users/pxmante/Library/Application Support/telepresence' ''
When run in the above manner, the daemon starts just fine - whereas it fails to start when run as part of a telepresence connect command. After running it manually, there is a socket file in/var/run.
Hi @thallgren -
I finally got some more time to test this:
-
Yes i do have read permissions on /var/run directory.
[sean.sabour | ~]> ls -l /var/run/
total 80
-rw-r--r-- 1 root daemon 6 Jul 20 11:12 PanGPS.pid
-rw-r--r-- 1 root daemon 4 Jul 19 12:59 appfwd.pid
-rw-r--r-- 1 root daemon 6 Jul 26 12:59 auditd.pid
-rw------- 1 root daemon 0 Jul 19 13:00 automount.initialized
drwxr-xr-x 3 _assetcache _assetcache 96 Jul 19 13:01 com.apple.AssetCache
---------- 1 root daemon 0 Jul 19 13:00 com.apple.WindowServer.didRunThisBoot
-r-------- 1 root daemon 0 Jul 19 12:59 com.apple.logind.didRunThisBoot
-r-------- 1 root daemon 0 Jul 19 13:00 com.apple.loginwindow.didRunThisBoot
-r-------- 1 root daemon 0 Jul 19 12:59 com.apple.mdmclient.daemon.didRunThisBoot
-rw-r--r-- 1 root daemon 0 Jul 19 13:00 com.apple.softwareupdate.availableupdatesupdated
drwxr-xr-x 2 root daemon 64 Jul 19 13:01 com.apple.wifivelocity
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 com.docker.vmnetd.sock
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 cupsd
-rw-r--r-- 1 root daemon 3 Jul 19 12:59 diskarbitrationd.pid
drwxr-xr-x 3 _displaypolicyd _displaypolicyd 96 Jul 19 12:59 displaypolicyd
lrwxr-xr-x 1 root daemon 76 Jul 19 13:04 docker-cli.sock -> /Users/sean.sabour/Library/Containers/com.docker.docker/Data/docker-cli.sock
lrwxr-xr-x 1 root daemon 72 Jul 19 13:04 docker.sock -> /Users/sean.sabour/Library/Containers/com.docker.docker/Data/docker.sock
-rw-r--r-- 1 root wheel 16 Jul 19 13:00 fudinit
-rw-r--r-- 1 root daemon 6 Jul 20 11:13 hdiejectd.pid
drwx------ 2 root admin 64 Jul 22 16:27 jamf
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 mDNSResponder
drwx------ 3 root daemon 96 Jul 19 13:00 mds
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 portmap.socket
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 pppconfd
-rw-r--r-- 1 root daemon 436 Jul 26 12:56 resolv.conf
-r-------- 1 root daemon 0 Jul 19 12:59 socketfilterfw.launchd
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 syslog
-rw-r--r--@ 1 root daemon 3 Jul 19 12:59 syslog.pid
-r--r--r-- 1 root daemon 0 Jul 19 12:59 systemkeychaincheck.done
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 systemkeychaincheck.socket
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 usbmuxd
-rw-r--r--@ 1 root daemon 6280 Jul 26 13:00 utmpx
srw------- 1 root daemon 0 Jul 19 12:59 vpncontrol.sock
-rw-r--r-- 1 root wheel 0 Jul 19 13:00 wifi
[sean.sabour | ~]> telepresence connect
Launching Telepresence Root Daemon
Need root privileges to run: /usr/local/bin/telepresence daemon-foreground /Users/sean.sabour/Library/Logs/telepresence '/Users/sean.sabour/Library/Application Support/telepresence' ''
Password:
telepresence: error: daemon service did not start (see "/Users/sean.sabour/Library/Logs/telepresence/daemon.log" for more info)
[sean.sabour | ~]> ls -l /var/run/
total 80
-rw-r--r-- 1 root daemon 6 Jul 20 11:12 PanGPS.pid
-rw-r--r-- 1 root daemon 4 Jul 19 12:59 appfwd.pid
-rw-r--r-- 1 root daemon 6 Jul 26 12:59 auditd.pid
-rw------- 1 root daemon 0 Jul 19 13:00 automount.initialized
drwxr-xr-x 3 _assetcache _assetcache 96 Jul 19 13:01 com.apple.AssetCache
---------- 1 root daemon 0 Jul 19 13:00 com.apple.WindowServer.didRunThisBoot
-r-------- 1 root daemon 0 Jul 19 12:59 com.apple.logind.didRunThisBoot
-r-------- 1 root daemon 0 Jul 19 13:00 com.apple.loginwindow.didRunThisBoot
-r-------- 1 root daemon 0 Jul 19 12:59 com.apple.mdmclient.daemon.didRunThisBoot
-rw-r--r-- 1 root daemon 0 Jul 19 13:00 com.apple.softwareupdate.availableupdatesupdated
drwxr-xr-x 2 root daemon 64 Jul 19 13:01 com.apple.wifivelocity
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 com.docker.vmnetd.sock
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 cupsd
-rw-r--r-- 1 root daemon 3 Jul 19 12:59 diskarbitrationd.pid
drwxr-xr-x 3 _displaypolicyd _displaypolicyd 96 Jul 19 12:59 displaypolicyd
lrwxr-xr-x 1 root daemon 76 Jul 19 13:04 docker-cli.sock -> /Users/sean.sabour/Library/Containers/com.docker.docker/Data/docker-cli.sock
lrwxr-xr-x 1 root daemon 72 Jul 19 13:04 docker.sock -> /Users/sean.sabour/Library/Containers/com.docker.docker/Data/docker.sock
-rw-r--r-- 1 root wheel 16 Jul 19 13:00 fudinit
-rw-r--r-- 1 root daemon 6 Jul 20 11:13 hdiejectd.pid
drwx------ 2 root admin 64 Jul 22 16:27 jamf
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 mDNSResponder
drwx------ 3 root daemon 96 Jul 19 13:00 mds
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 portmap.socket
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 pppconfd
-rw-r--r-- 1 root daemon 436 Jul 26 12:56 resolv.conf
-r-------- 1 root daemon 0 Jul 19 12:59 socketfilterfw.launchd
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 syslog
-rw-r--r--@ 1 root daemon 3 Jul 19 12:59 syslog.pid
-r--r--r-- 1 root daemon 0 Jul 19 12:59 systemkeychaincheck.done
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 systemkeychaincheck.socket
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 usbmuxd
-rw-r--r--@ 1 root daemon 6280 Jul 26 13:00 utmpx
srw------- 1 root daemon 0 Jul 19 12:59 vpncontrol.sock
-rw-r--r-- 1 root wheel 0 Jul 19 13:00 wifi
[sean.sabour | ~]> pgrep -lf daemon-foreground
[sean.sabour | ~]> telepresence connect
Launching Telepresence Root Daemon
Need root privileges to run: /usr/local/bin/telepresence daemon-foreground /Users/sean.sabour/Library/Logs/telepresence '/Users/sean.sabour/Library/Application Support/telepresence' ''
Password:
telepresence: error: daemon service did not start (see "/Users/sean.sabour/Library/Logs/telepresence/daemon.log" for more info)
[sean.sabour | ~]> pgrep -lf daemon-foreground
[sean.sabour | ~]>
Another thing to note is that when run with sudo i see all the sockets get created with no errors, but I still cannot connect to my k8s cluster..
[sean.sabour | ~]> sudo telepresence connect
Password:
Launching Telepresence Root Daemon
Launching Telepresence User Daemon
Connected to context arn:aws:eks:us-west-2:xxxxx:cluster/xxxx-eks (https://xxxxxx.gr7.us-west-2.eks.amazonaws.com)
[sean.sabour | ~]> ls -l /var/run/
total 80
-rw-r--r-- 1 root daemon 6 Jul 20 11:12 PanGPS.pid
-rw-r--r-- 1 root daemon 4 Jul 19 12:59 appfwd.pid
-rw-r--r-- 1 root daemon 6 Jul 26 12:59 auditd.pid
-rw------- 1 root daemon 0 Jul 19 13:00 automount.initialized
drwxr-xr-x 3 _assetcache _assetcache 96 Jul 19 13:01 com.apple.AssetCache
---------- 1 root daemon 0 Jul 19 13:00 com.apple.WindowServer.didRunThisBoot
-r-------- 1 root daemon 0 Jul 19 12:59 com.apple.logind.didRunThisBoot
-r-------- 1 root daemon 0 Jul 19 13:00 com.apple.loginwindow.didRunThisBoot
-r-------- 1 root daemon 0 Jul 19 12:59 com.apple.mdmclient.daemon.didRunThisBoot
-rw-r--r-- 1 root daemon 0 Jul 19 13:00 com.apple.softwareupdate.availableupdatesupdated
drwxr-xr-x 2 root daemon 64 Jul 19 13:01 com.apple.wifivelocity
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 com.docker.vmnetd.sock
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 cupsd
-rw-r--r-- 1 root daemon 3 Jul 19 12:59 diskarbitrationd.pid
drwxr-xr-x 3 _displaypolicyd _displaypolicyd 96 Jul 19 12:59 displaypolicyd
lrwxr-xr-x 1 root daemon 76 Jul 19 13:04 docker-cli.sock -> /Users/sean.sabour/Library/Containers/com.docker.docker/Data/docker-cli.sock
lrwxr-xr-x 1 root daemon 72 Jul 19 13:04 docker.sock -> /Users/sean.sabour/Library/Containers/com.docker.docker/Data/docker.sock
-rw-r--r-- 1 root wheel 16 Jul 19 13:00 fudinit
-rw-r--r-- 1 root daemon 6 Jul 20 11:13 hdiejectd.pid
drwx------ 2 root admin 64 Jul 22 16:27 jamf
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 mDNSResponder
drwx------ 3 root daemon 96 Jul 19 13:00 mds
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 portmap.socket
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 pppconfd
-rw-r--r-- 1 root daemon 436 Jul 26 12:56 resolv.conf
-r-------- 1 root daemon 0 Jul 19 12:59 socketfilterfw.launchd
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 syslog
-rw-r--r--@ 1 root daemon 3 Jul 19 12:59 syslog.pid
-r--r--r-- 1 root daemon 0 Jul 19 12:59 systemkeychaincheck.done
srw-rw-rw- 1 root daemon 0 Jul 19 12:59 systemkeychaincheck.socket
srwxrwxrwx 1 root daemon 0 Jul 26 13:06 telepresence-daemon.socket
srwxrwxrwx 1 root daemon 0 Jul 19 12:59 usbmuxd
-rw-r--r--@ 1 root daemon 6280 Jul 26 13:00 utmpx
srw------- 1 root daemon 0 Jul 19 12:59 vpncontrol.sock
-rw-r--r-- 1 root wheel 0 Jul 19 13:00 wifi
[sean.sabour | ~]> pgrep -lf daemon-foreground
75804 /usr/local/bin/telepresence daemon-foreground /Users/sean.sabour/Library/Logs/telepresence /Users/sean.sabour/Library/Application Support/telepresence TERM=xterm-256color
[sean.sabour | ~]> curl -ik https://kubernetes.default
curl: (7) Failed to connect to kubernetes.default port 443: Operation timed out
[sean.sabour | ~]> sudo telepresence status
Password:
Root Daemon: Running
Version : v2.3.7 (api 3)
DNS :
Local IP : <nil>
Remote IP : <nil>
Exclude suffixes: [.arpa .com .io .net .org .ru]
Include suffixes: []
Timeout : 4s
Also Proxy: (0 subnets)
User Daemon: Running
Version : v2.3.7 (api 3)
Ambassador Cloud : Logged out
Status : Connected
Kubernetes server : https://xxxxxx.gr7.us-west-2.eks.amazonaws.com
Kubernetes context: arn:aws:eks:us-west-2:xxxxxx:cluster/xxxx-eks
Telepresence proxy: ON (networking to the cluster is enabled)
Intercepts : 0 total
@petermant wrote
I have this issue as well, i.e. daemon fails to start and the daemon log is created but remains at 0 bytes. I have read perms for /var/run. When it fails to start, there is no daemon.socket file.
So before launching the daemon, the CLI process creates the daemon.log
file ahead of time to make sure the permissions are correct (now, looking at rotatingfile.go
I'm not sure that's actually the correct thing for it to do, but that's what it does). So what I'm thinking is that telepresence connect
is creating the file, but then the daemon can't open it.
% sudo /usr/local/bin/telepresence daemon-foreground /Users/pxmante/Library/Logs/telepresence '/Users/pxmante/Library/Application Support/telepresence' ''
When run in the above manner, the daemon starts just fine
Does it work when you sudo /usr/local/bin/telepresence daemon-foreground /Users/pxmante/Library/Logs/telepresence '/Users/pxmante/Library/Application Support/telepresence' '' | cat
? When stdout is a terminal it doesn't try to log to files, so by piping to cat
we can get it to try to log to files like normal, and then on stdout see what problems it has doing that.
@LukeShu wrote
Does it work when you sudo /usr/local/bin/telepresence daemon-foreground /Users/pxmante/Library/Logs/telepresence '/Users/pxmante/Library/Application Support/telepresence' '' | cat?
Yes, it seems to. When I do that, I get nothing in the terminal after the sudo pwd prompt, but in the daemon.log I get this:
2021/07/27 09:20:47.1690 info : No config found. Using default (from pkg/client/config.go:540)
2021/07/27 09:20:47.1748 info daemon : --- (from pkg/client/daemon/service.go:147)
2021/07/27 09:20:47.1749 info daemon : Telepresence daemon v2.3.7 (api v3) starting... (from pkg/client/daemon/service.go:148)
2021/07/27 09:20:47.1749 info daemon : PID is 6459 (from pkg/client/daemon/service.go:149)
2021/07/27 09:20:47.1749 info daemon : (from pkg/client/daemon/service.go:150)
2021/07/27 09:20:47.1758 info daemon/server-grpc : gRPC server started (from pkg/client/daemon/service.go:207)
...which looks OK, and the root daemon shows as running in telepresence status.
I then have this:
% pgrep -lf daemon-foreground
6451 sudo /usr/local/bin/telepresence daemon-foreground /Users/pxmante/Library/Logs/telepresence /Users/pxmante/Library/Application Support/telepresence
6459 /usr/local/bin/telepresence daemon-foreground /Users/pxmante/Library/Logs/telepresence /Users/pxmante/Library/Application Support/telepresence SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.ObwPc4cQJ9/Listeners
I ended up figuring out what was causing all my connections to time out. Digging deeper into the route table on my mac i noticed i had an overlapping route setup by the VPN i was using that was causing issues. When i disabled the VPN and deleted the route i was able to successfully connect to the cluster. However, I still cannot run telepresence connect without sudo, unless i open a separate terminal run the daemon-foreground then open another terminal and run telepresence connect.
@seansabour @petermant this problem with telepresence being unable to connect unless you start the root daemon manually, is that related to M1?
No, I don't think it is related to M1. My machine has a Core i7 in it.
@seansabour @petermant If possible, please try the latest nightly build. It contains some changes related to the daemon start process. If it doesn't fix the problem, then at least it might provide some more info about what's causing it.
hi @thallgren i just tested with the latest build and I didn't see much of a difference...
[sean.sabour | ~]> rm /Users/sean.sabour/Library/Logs/telepresence/*
rm: /Users/sean.sabour/Library/Logs/telepresence/*: No such file or directory
[sean.sabour | ~]> telepresence connect
Launching Telepresence Root Daemon
Need root privileges to run: /usr/local/bin/telepresence daemon-foreground /Users/sean.sabour/Library/Logs/telepresence '/Users/sean.sabour/Library/Application Support/telepresence' ''
Password:
telepresence: error: daemon service did not start (see "/Users/sean.sabour/Library/Logs/telepresence/daemon.log" for more info)
failed to scan connector logs: open /Users/sean.sabour/Library/Logs/telepresence/connector.log: no such file or directory
[sean.sabour | ~]> cat /Users/sean.sabour/Library/Logs/telepresence/daemon.log
[sean.sabour | ~]> touch /Users/sean.sabour/Library/Logs/telepresence/connector.log
[sean.sabour | ~]> telepresence connect
Launching Telepresence Root Daemon
Need root privileges to run: /usr/local/bin/telepresence daemon-foreground /Users/sean.sabour/Library/Logs/telepresence '/Users/sean.sabour/Library/Application Support/telepresence' ''
Password:
telepresence: error: daemon service did not start (see "/Users/sean.sabour/Library/Logs/telepresence/daemon.log" for more info)
[sean.sabour | ~]> cat /Users/sean.sabour/Library/Logs/telepresence/daemon.log
[sean.sabour | ~]> ls /Users/sean.sabour/Library/Logs/telepresence/
connector.log daemon.log
[sean.sabour | ~]> cat /Users/sean.sabour/Library/Logs/telepresence/*
[sean.sabour | ~]>
@seansabour I don't see the log output that I would have expected. It changed in a commit that was merged 7 days ago. In particular, the (see "/Users/sean.sabour/Library/Logs/telepresence/daemon.log" for more info)
should not be there. Can you check again and include the output from telepresence version
?
Or, just try the 2.4.3 release which is being published right now.
I have the same thing as before, on the 2.4.3 version - although as you say, the logging output is different:
% rm ~/Library/Logs/telepresence/*
zsh: sure you want to delete all 6 files in /Users/pxmante/Library/Logs/telepresence [yn]? y
% telepresence version
Client: v2.4.3 (api v3)
Root Daemon: not running
User Daemon: not running
% telepresence connect
Launching Telepresence Root Daemon
Need root privileges to run: /usr/local/bin/telepresence daemon-foreground /Users/pxmante/Library/Logs/telepresence '/Users/pxmante/Library/Application Support/telepresence' ''
Password:
telepresence: error: daemon service did not start: timeout while waiting for daemon to start
failed to scan connector logs: open /Users/pxmante/Library/Logs/telepresence/connector.log: no such file or directory
Then in the logs folder there is a single new file, daemon.log - which has 0 bytes.
I've retested this on 2.4.4 and it still occurs. Logs are attached in case this helps. telepresence_logs.zip
@petermant hmm i see lines like the following in your connector.log files:
2021-10-01 10:23:37.4156 error the helm operation timed out. The current timeout 30s can be configured as "timeouts.helm" in "/Users/pxmante/Library/Application Support/telepresence/config.yml"
telepresence: error: the helm operation timed out. The current timeout 30s can be configured as "timeouts.helm" in "/Users/pxmante/Library/Application Support/telepresence/config.yml"
Could you try installing the traffic manager yourself via helm? See the README here for instructions on doing so -- if there's something preventing your traffic manager from starting up, it will be a little more transparent if you install it manually
Just an update, met with Cindy and Noah today. In the meeting i showed that with a fresh install of telepresence 2.4.6-nightly-b4c29d4b the following issues occurred: On first connect attempt
[sean.sabour | ~]> telepresence connect
Launching Telepresence Root Daemon
Need root privileges to run: /usr/local/bin/telepresence daemon-foreground /Users/sean.sabour/Library/Logs/telepresence '/Users/sean.sabour/Library/Application Support/telepresence' ''
Password:
telepresence: error: daemon service did not start: timeout while waiting for daemon to start
failed to scan connector logs: open /Users/sean.sabour/Library/Logs/telepresence/connector.log: no such file or directory
If you think you have encountered a bug, please run `telepresence gather-logs` and attach the telepresence_logs.zip to your github issue or create a new one: https://github.com/telepresenceio/telepresence/issues/new?template=Bug_report.md .
After this I manually created the connector.log file and re-ran the connect:
[sean.sabour | ~]> touch /Users/sean.sabour/Library/Logs/telepresence/connector.log
[sean.sabour | ~]> telepresence connect
Launching Telepresence Root Daemon
Need root privileges to run: /usr/local/bin/telepresence daemon-foreground /Users/sean.sabour/Library/Logs/telepresence '/Users/sean.sabour/Library/Application Support/telepresence' ''
Password:
telepresence: error: daemon service did not start: timeout while waiting for daemon to start
If you think you have encountered a bug, please run `telepresence gather-logs` and attach the telepresence_logs.zip to your github issue or create a new one: https://github.com/telepresenceio/telepresence/issues/new?template=Bug_report.md .
Tried to look for logs to show why the daemon did not start, but both connector and daemon logs were empty.
If i run the telepresence connect as root user it successfully connects to the cluster, however when trying to connect to a k8s service it is timing out. I am using GlobalProtect VPN and suspect there is an issue with how telepresence and GPVPN interact.
We have been struggling with the fact that Telepresence doesn't work when McAfee system extensions were enabled - so we always had to disable them before starting work. Then they'd randomly switch back on and I'd get high CPU usage (which I'm still intending to raise as a separate defect, but it gets so high that I cannot collect logs when it happens).
However, as part of trying to discover what ports & applications we need for telepresence in order to configure the McAfee firewall, they have temporarily set my firewall config to allow all ports and all applications. The issue I was having in this ticket as originally raised by Sean has now gone away.
However, I do still get the high CPU usage problems, where docker CPU usage goes to 350% and telepresence to 150% plus - and that even prevented me from posting this until after I had restarted my computer because it blocks all network traffic.
So I think the problem must be related to firewall blocking ports, not the VPN itself.
We currently have a ticket open with McAfee for investigation, and will let you know when we have a conclusive response from them.
Some of the problems described here are very likely caused by what's being described in #2314.
I have the same issue with v2.7.1
same for me, but after i run below command, it suddenly works
% telepresence version
Client: v2.9.2 (api v3)
Root Daemon: not running
User Daemon: not running
Enhanced client version v1.4.4
sudo rm -f /var/run/telepresence-daemon.socket
sudo /usr/local/bin/telepresence daemon-foreground /Users/xxxx.xxxx/Library/Logs/telepresence '/Users/xxxx.xxxx/Library/Application Support/telepresence'
ctrl+c
rm /Users/xxxx.xxxx/Library/Logs/telepresence/*
Closing as the remaining issue appears to be a firewall issue, not caused by Telepresence.