Open tomershvueli opened 3 years ago
You can do this by configuring interface priority in system preferences: https://support.apple.com/guide/mac-help/change-order-network-ports-mac-mchlp2711/mac
@johndbritton true, I was able to get it working! However, this system isn't quite perfect. If I ever sever the connection (such as when I need to take one of the laptops out and about) and then plug it back in, Teleport defaults back to the Wifi connection, not the hardwired. Is there a way to manually add addresses to the Trusted Hosts list? I'd like to add my server's Ethernet address and Wifi address (in that order) so that it'll look for the other machine properly.
@tomershvueli I would expect that your Mac should remember the interface priority and use the wired connection going forward after reconnecting.
Intuitively I expect the problem is that once the connection is made by teleport over WiFi it will not reconnect over the wired connection unless the reconnection process is started again. The reason it reconnects over wifi after disconnecting wired is that the wired connection is severed.
Try restarting Teleport after reconnecting wired and see if it still prefers wired. If it does, the solution to this would be to make a feature for Teleport that restarts the connection whenever a new network interface is attached. I bet there's a way to do this at the operating system level using something like NSNotificationCenter
or similar.
I'd be open to merging a feature to solve this problem. Reopening and labeling this as a feature-request
.
Confirming my experience: Teleport works fine and respects interface priority on multi homed machines since v1.3.5 resolved the default encryption method problem.
But.... Teleport does not like interface changes on the fly. I agree with @johndbritton in that I think Teleport (on both master and slave) somehow holds on to the interface it acquired on startup, so if interface priority order changes you experience the laggy/bursty mouse tracking that @tomershvueli talks about. Speculation: this is because of an asymmetric route. Packets are being transmitted on the original interface but received on the default interface. Super easy to simulate; just use two Macs, each connected overh both Ethernet and Airport interfaces, then disable wifi on the slave Mac. You'll see the bursty lag immediately on the slave.
On the other hand, if an interface goes down (since 1.3.5) communications are terminated but recover in a few seconds after the routing tables on both hosts reconverge.
Prior to 1.3.5, restarting Teleport under these conditions was a crapshoot because of the #100 bug selecting an incompatible default encryption method; unless you had a static IP address that was pre-trusted reconnection would fail. Typically Teleport needs to be restarted as John says if that happens (haven't found a pattern to this).
I know it's not an elegant solution, but we could merge a PR that detects the issue and then calls the network setup again without a restart.
Alternatively, if macOS notifies on interface connect / disconnect we could restart the connection process automatically.
I won't be working on a fix for this, I'm ok restarting the app when I change connections (I'm almost always wired when using teleport) but as always open to review and helping out if someone makes a fix.
Something like: https://developer.apple.com/forums/thread/113446 or https://stackoverflow.com/a/61705698 perhaps.
Feature request
Create connection between client and server over a hardwire instead of Wifi.
A detailed description of the proposed feature
Sometimes there's a bit of a lag on the client depending on Wifi conditions. If I hook up an Ethernet port between the server and the client, it'd be great if Teleport could communicate over that for a more seamless experience.
The motivation for the feature
A laggy keyboard is doable, but a laggy mouse is quite frustrating :/
How the feature would be relevant to at least 90% of Teleport users
No more lag for anyone!
What alternatives to the feature have been considered
Alternative applications.