Well, the tunneler logs don’t show any attempt to intercept an SMB connection. I looked for both the ports (445, 139) and the hostname that you’re using. It doesn’t look like the tunneler is stealing your SMB connections, at least not in the manner that it’s designed to. So if the tunneler seems oblivious to your SMB connections (which it should be), then let’s look elsewhere…
Can you please run the following set of commands while attempting SMB connections: once when the tunneler is turned off and once when it is running?
First turn off the tunneler and run this from a Terminal window:
(netstat -rn -finet; scutil --dns; sudo tcpdump -w zde.off.pcap -ni all port 445 or port 139) > zde.off.log
Leave that running while switching to the finder to make an smb connection. Once you’ve made the connection:
press ^C in the terminal
start the tunneler
run the following from terminal:
(netstat -rn -finet; scutil --dns; sudo tcpdump -w zde.on.pcap -ni all port 445 or port 139) > zde.on.log
While that command is running try to make an smb connection, then press ^C in the terminal. When all of this is done you should have 4 files to send us:
Hi @Eric just to set some expecations here, we have some high-priority work going on that will probably make it hard for us to take a look at this until next week probably. We appreciate your help so far and we should return to looking at this probably mid next week. cheers
Sorry @Eric, we are still working on the high priority issue and haven't had a chance to get back to this. We'll keep coming back to it - hopefully the high priority item will ease this week... Thanks for being patient with us - and sorry we can't get to this just yet. Cheers
Hi @TheLumberjack, It's annoying, but I'm not desperate yet!
Actually, our highest priority is in this post: New SDK version 0.28.0 connect - #6 by dorianEliptec. Node.js sdk is not working on Windows. Thus we are not able to start the deployment. I hope someone can provide us with the solution without too much delay. Cheers
Hi Eric, and thanks for your patience on this thread!
Today I took a closer look at everything you sent so far, specifically the packet captures zde.on.pcap and zde.off.pcap. zde.on.pcap does not show any sign of the tunneler interfering with your samba connections, but it only contains packets for ports 445 (which is what I requested). I also tried recreating the issue that you described here but I was unable.
One thing I noticed about the captures is that zde.pcap.on seems to show a continuation of the same connection that was started in zde.pcap.off (both captures show packets with the same source ip:port - 10.137.137.11:60073). It would be interesting to see if connections work when you disconnect the working connection (with the "Disconnect" button in the Finder window) before starting the tunneler and attempt to connect again. If you don't see a Disconnect button then restarting Finder (via Apple menu -> Force Quit -> Finder) should achieve the same result.
If disconnecting makes no difference then I think the next thing to try is a wider packet capture filter to check for other potential influences on the smb connections. So instead of capturing ports 445, etc let's get all of the packets for the IP ranges that might be involved. I think the command will look like this:
tcpdump -w smb.pcap -ni any host 10.137.137.1 or net 100.64/10
edit: one more thing that came to mind was try using an ip address for smb connections instead of the hostname. You would do this from Finder's "Go" menu -> "Connect to Server..." (or cmd-k).
Cheers