I’m using Ziti for a private file server, only two endpoints, my Mac Pro hosting the server, and my MacBook Pro connecting to it. I’ve managed to get everything up and running now, however I’m getting a ton of errors in the log on my MacBook Pro whenever I have the webdav connection open through finder:
ERROR tunnel-sdk:tunnel_tcp.c:181 on_tcp_client_err() client=tcp:100.64.0.1:57054 err=-14, terminating connection
ERROR ziti-sdk:channel.c:488 dispatch_message() ch[1] received message without conn_id or for unknown connection ct[ED71] conn_id[1232]
These errors are only in the logs on my client device, the host device shows no errors in the log, just a ton of incoming connections, all within a few seconds of one another.
The port numbers and ID’s change from error to error, but I get probably about a dozen of these errors every minute just from having the webdav share open on my Mac. Using the webinterface to upload files through ziti does not yield this error. Connecting directly to the webdav share on my local network without ziti does not yield this error.
Does anyone know of a reason macOS Finder would throw up errors in Ziti when connected to a Webdav share that a standard https connection to a webinterface wouldn’t cause? Any idea how to fix this? Is this a fixable problem, or something inherently flawed in Apple’s implementation of mounting webdav shares?
Any advice appreciated, even if that advice is just to ask elsewhere.
I am pretty sure that those two errors on the client side are benign and not a real indicator of a problem. If memory serves, this is an indicator that the server on the far side terminated the connection while the client was still trying to send/receive data. I think @ekoby is probably the best person to reply here with more a more exact response, but @scareything might know as well.
I do think it’s entirely reasonable to expect OpenZiti to behave exactly as though you were local. The question I would have is do you as the user, notice these “ERRORS”? Or are you just noticing them by looking through the logs? For example, lots of network-based applications are very tolerant of connections just getting dropped and reconnect, but as a user we might not know.
I’m more interested in understanding if there was some difference in behavior that made you look into these errors. If the experience is the same (Finder isn’t constantly disconnecting or logging UI errors etc), well then maybe we just need to make the log mesage better. If there’s an “experience difference” though, that I think we’d want to find/fix/address.
Ah, duh. I think I spent so much time troubleshooting this week, I started fishing for more problems…
The only experience difference I’m noticing is that while the log gets flooded with these errors, the temps on my MacBook Pro spike, and my fans start spinning up to full, so it seems like the constant attempts to reconnect are an unexpectedly high CPU load, but as I’m typing that, I’m thinking it would be reasonable to assume that’s more of a Finder issue with mounted webdav shares than it is a Ziti issue. With the host machine running the latest version of Ziti Desktop Edge I didn’t have any functional failures in the connection, it would just often take a long time to load a folder, and file copies would hang right at 67 megabytes copied for a minute or two before finishing, but it did always eventually finish.
I probably wouldn’t have noticed a problem if I was not looking in the logs. I would have just assumed my Mac was running hot, because it’s an intel-era MacBook running modern macOS, and they all run hot.
Thanks for the detailed response, and I appreciate your patience!
Great, thanks for following up. Those kinds of small differences do matter though, so if you find yourself thinking “hey, that’s not quite normal”, please do let us know. I will still bring this up with the team and see what they think. I don’t know if we have anyone that can really test this in the same way but we can add this experience to our base of knowledge and if someone ever has this same issue they can find our discourse thread here and hopefully it’ll help them!
For some reason, despite the fact that I am not using Xsan at all, when my WebDAV share is mounted via Finder, macOS Keeps trying to access these Xsan ports. Changing from a simple service that just forwards 443 to an advanced service that also forwards all the ports in the Xsan range resolved this error. It didn't appear to be causing any problems, but I still felt it worth noting the reason for this line in the log in case it's relevant to anyone else.
