Teleport does not start controlling

[roderik]

Question

I might be doing something wrong, but I installed the latest version, shared one computer, I can see it in the config of the other computer, I can arrange the screens.

But how do I "activate" the controlling. It worked once for a while, but I rebooted and now I cannot get it to start, is there a key combo I need to use?

[roderik]

I noticed that the screens I wanted to control did not have the settings option they used to have. When I quit and restarted the app, the screen arrangement was reset. I did this about 10 times and then it suddenly connected. #magic 😂

[johndbritton]

But how do I "activate" the controlling.

On the Mac you want to control, make sure the "Share this Mac" checkbox is ticked:

@roderik There are definitely some parts of the app that are finicky which I hope to improve over time. Glad you got it sorted. I'm going to close this for now but feel free to reopen or file a new issue if you can give steps to reproduce the issue.

[roderik]

Yeah, best description I can give is "it appeared it could not save the modified settings so it just kept displaying the current state and not save it". Not much to go on 😆

[roderik]

I keep having the same issue. After closing one of the teleport clients, I cannot get it working again. Everything looks perfect, screens are configured on the right location, I see the red bar on the screen where it should be, but my mouse cannot move to the other screen. And after giving up, at some point, sometimes they start working again... Very frustrating because it is magic ;)

Are there any logs I can see? Maybe something is up with the connection attempts or who knows what?

[roderik]

FYI, the Console app does not show something I recognize as an error.

I made a video recording on the behavior, it is really consistent and I experience this at least 50% of the time that i want to use teleport to control my other machine (m1 MacBook -> iMac Pro)

https://cln.sh/MPvq3c

@johndbritton would you mind reopening this?

[johndbritton]

@roderik Does it ever work when you try to attach to the top of the screen? I wonder if the menubar is somehow interfering with Teleport's hidden window.

Can you see if you can reproduce the behavior when the other machine is to the left, right, or bottom? Also can you try going into your mac's preferences and selecting "auto-hide menubar" to see if that helps.

You can turn on debug mode for teleport with defaults write com.abyssoft.teleport enableLogging 1 then messages will appear in console.

[roderik]

I figured out how I can consistently connect. Only if both computers have 'share this mac' enabled teleport connects. As far as I understood only the computer that needs to be controlled needed to be shared?

[johndbritton]

Only if both computers have 'share this mac' enabled teleport connects.

That's very strange.

As far as I understood only the computer that needs to be controlled needed to be shared?

Me too. I don't think you need to enable sharing on both for this to work. Is it possible it's unrelated to your solution?

[roderik]

Well, look at it like a patient googling before a doctors visit ;) I figured out what buttons to press to make it work consistently for me. YMMV 😂

[adamm]

I too have this issue happening intermittently. Source is 2017 Macbook Pro running Mojave, Dest is mid-2010 iMac running High Sierra. Both instances are running teleport 1.3.3 released Jan 5.

Upon Roderik's suggestion I tried turning on "Share this mac" on both locations and it didn't have any change to the random inconsistency connecting. I also tried limiting both Mac's to one ethernet connection (no wifi), as well disabled VPN on the MBP. Still random inconsistency connecting.

One thing is consistent though is the pattern of the hot border flashing after teleport has been restarted on both machines:

1. When it works, the hot border is solid, then flashes quickly.
2. When it fails, the hot border is solid, then disappears.

I'll try to get you console logs of it failing to connect and it working.

[hyperjeff]

Same thing happening here. One Big Sur Mac (Mini on Apple Silicon), and one Catalina Mac (x86 MBP). It was working perfectly for a while, then, after a reboot of one of the machines, they no longer connect. They do see each other as soon as I check the "Share this Mac" box, but they now only do the solid border with no flash, as adamm described. After about a minute my Catalina Mac will display the message "Connection to ... failed" (etc), whether or not I even enable encryption or all permutations of checkboxes. Baffling! I'll keep trying scenarios. Maybe i'll download the project and try to catch it in code.

[hyperjeff]

Odd extra detail, in case it helps debug: On the M1 Mini, I arrange the layout and it gives a red solid bar only as long as i drag the other monitor representation around, lift up the mouse button and it stops. But nothing indicates that the connection went bad. However, on my Catalina MBP, lifting up the mouse button leaves the red glow border for about 2 seconds before disappearing, and then after about 1 or 2 minutes I get an error about not being able to connect and then it puts the other monitor representation "back on the shelf", something which doesn't happen on the Mini. (I'd make a video if someone would find that helpful.)

[adamm]

Totally aligns with what i'm seeing, @hyperjeff . ... I have a theory that this issue is related to the Bonjour discovery layer which allows teleport to determine the IP, capabilities, screen size, etc of other hosts on the network.

I'm going to try some experiments, enhance some logging, hardcode some values, and see if i can influence connection stability.

[hyperjeff]

I have it working now, and this is my recipe, but I don't understand why it worked:

    MBP (Catalina) ------ ⎡ ethernet ⎤ ------- cable modem
    Mini (Big Sur) ------ ⎣  switch  ⎦

I connected each Mac to an ethernet switch and turned off wifi. Still not working, as expected by now. Then I unplug the internet from the switch to force them to try to talk to each other directly (see topology above). Still no go. Then I disable ethernet on each and hit Apply. Then back on, and Apply. After a minute they see each other for things like file sharing, so I fire up teleport, and it immediately starts working. Obviously I want more, so I plug back in the internet to the switch, wait a bit as it forces me to eject file sharing as it switches how it connects, and teleport stalls and I have to force quit it on one of the machines, but I can deal, ok. Relaunch teleport on each: working!

Next steps would be to see if I can change to wifi-only, but thought I'd report this success, as it covers my main use case.

Perhaps there is some useful debug info in there.

[adamm]

I think i found a smoking gun... and a way for it to consistently work on my side. Here's my setup.

    192.168.2.2      192.168.0.31
     ,------- imac2010 --------,
[switch1]                       \
     `-------- mbp2017 ----- [switch2] ---- [router] ------ internet
    192.168.2.1   |   192.168.0.26                              \ 
                 vpn                                      company network 10.x.x.x
              10.x.x.x

Long story short, I want to access company resources under vpn from imac2010, so I've setup a pfctl NAT rule on mbp2017 forwarding traffic on the 192.168.2.1 ethernet to 10.x.x.x interface. (I know i could do something similar and stay on the 192.168.0 subnet, but I have other hardware tied to switch1 that needed the same VPN access but must remain isolated.)

I have teleport setup on my mbp2017 to be the source keyboard/mouse, and imac2010 to destination to connect to.

Anyway, back to the issue. With multiple network interfaces on the destination teleport box, I found occasionally it would work, occasionally it will fail. Hooking up xcode on both boxes, I found a pattern:

Whenever it failed to connect to the imac2010, I would see the log entry:

2021-03-23 12:57:03.598992-0600 teleport[8343:16800972] could not determine which host has IP 192.168.2.2, will use encrypted connection by default

Yet, when it worked i would always see

2021-03-23 13:46:34.701213-0600 teleport[9283:16870649] connect to 192.168.0.31 on port 44276

So, clearly, teleport on the source mbp2017 only trusted the imac2010 on one IP, not on the secondary IP. It seemed to be random as to which IP it used to connect based upon bonjour or whatever, but it would only ever trust one at a time.

I wanted to take encryption out of the equation, so as a proof of concept I made this change on the source teleport codebase on the mbp2017:

diff --git a/TPConnectionsManager.m b/TPConnectionsManager.m
index 148e6f1..3c086c6 100644
--- a/TPConnectionsManager.m
+++ b/TPConnectionsManager.m
@@ -274,8 +274,8 @@ static TPConnectionsManager * _connectionsManager = nil;
        NSString * remoteAddress = [tcpSocket remoteAddress];
        TPRemoteHost * remoteHost = [[TPHostsManager defaultManager] hostWithAddress:remoteAddress];
        if(remoteHost == nil) {
-               NSLog(@"could not determine which host has IP %@, will use encrypted connection by default", remoteAddress);
-               return YES; // encrypted by default
+               NSLog(@"could not determine which host has IP %@, will use non-encrypted connection by default", remoteAddress);
+               return NO; // non-encrypted by default
        }
        else {
                return [[TPLocalHost localHost] pairWithHost:remoteHost hasCapability:TPHostEncryptionCapability];

And now I've got connectivity 100% of the time! (Oh, I also had to turn on "Control Requests" -> "Automatically Accept" in the imac2010's settings.)

TLDR: In summary, I assume that TPHostsManager should be multiple-IP aware, and not tied to not a single IP.

[adamm]

Thinking about this further, I actually think the issue is in the Encryption handler layer. Regardless of what line 278 returns, encryption should still work. The problem may be in the encryption initial negotiation.

@hyperjeff, I would be curious if my change has a positive impact for your scenario, too. Can you compile and test?

Regardless, this is beyond my abilities to resolve in xcode/Obj-C. What are your thoughts, @johndbritton ?

[johndbritton]

So, clearly, teleport on the source mbp2017 only trusted the imac2010 on one IP, not on the secondary IP. It seemed to be random as to which IP it used to connect based upon bonjour or whatever, but it would only ever trust one at a time.

Good find. I also had similar issues on my machine related to multiple IP addresses. I solved by modifying the "service order" in the "Network" preference pane.

This way, Teleport always connects via ethernet and the associated IP address:

Regardless, this is beyond my abilities to resolve in xcode/Obj-C. What are your thoughts, @johndbritton ?

I'd be willing to review a PR that makes this work over multiple IP addresses, or even if it just gives a better error message that is visible to the user so they can resolve it by setting the service order. I don't think we should just change the return value of that method and default to unencrypted if the user asked for encryption.

[FliegenKLATSCH]

As this issue describes very closely what I also observed: https://github.com/johndbritton/teleport/pull/100 This was the reason it did not work for me.

[johndbritton]

I believe this issue is resolved by #100. I've made a prerelease with the fix available here: https://github.com/johndbritton/teleport/releases/tag/v1.3.4-pre. Once we've confirmed this issue as resolved I will create a stable release for the auto updater and close this.