Could it be WINS or some Microsoft proprietary stuff?
Ok, I've researched a bit more: this is done via NetBIOS. If you check out this answer it'll use nmblookup __SAMBA__, which is something you can also do on macOS via smbutil view //__SAMBA__.
So you may need to find a NetBIOS library to do the lookup from within your app.
Edit: Further investigation shows that it's indeed the WINS protocol that's used here. nmblookup performs an UDP broadcast, which I've captured with Wireshark (in this case via nmblookup WORKGROUP, which in my setup returns the same information as nmblookup "*"):
The answers come in one after the other and their UDP packets contain the IP-Addressed in their last for bytes:
I've tried creating an example Python script that opens an UDP socket and sends the request, but receiving turned out to be a bit more difficult.
Another update: I've found a UDP broadcast example and adapted it a WINS request: GitHub Gist.
Basically you create a socket via socket(), enable broadcasts via setsockopt() and then you send the packet via sendto().
To read the various responses, use select() and recvfrom() multiple times. Provide a reasonable timeout to not wait indefinitely, in case no further responses have been received.
Sockets are weird API for sure.
Answer from Karsten on Stack OverflowSo here's a weird problem I'm trying to diagnose, and I wonder if anyone out there has any ideas on how to proceed. I work in an environment where we use Microsoft DFS servers for file sharing, and they're pretty straightforward configurations that hundreds of Windows users have mounted as drive letters for both personal and departmental file sharing. No performance issues for them.
However, we're starting to bring on board more Mac OS X users who are mounting these shares in Finder and having performance problems. Transfer times up and down are reasonable, but simply opening a folder to view its contents takes 30-300 seconds to display files. This is the same whether we use Finder directly or pop open an terminal window and ls the contents in /Volumes/driveshare. Most users assume their shares are empty because it takes so long to view what's in them (and this is the same whether there are 20 files in a folder or 2000.)
These users are all running Mac OS X 10.9.2+, and while the performance is worse off campus through VPN, even on campus over fast Ethernet / wired connections the browse times are consistently ridiculous.
We've contacted Apple professional services, who basically said 'meh' and suggested we try Dave from Thursby software. This product replaces the SMB stack in Mac OS X, and it improved performance almost not at all. We've tried mounting shares using CIFS path names instead of SMB, and that doesn't really change anything.
Packet captures show a lot of file listings going on while this browsing is happening, and very often there will be a lot of host not found or path not found errors returned. Despite those errors browsing always produces a view of the directory eventually. Both DNS and WINS servers are in place and the Macs are using them.
Any thoughts on other ways to investigate this issue or variables to tweak?
Could it be WINS or some Microsoft proprietary stuff?
Ok, I've researched a bit more: this is done via NetBIOS. If you check out this answer it'll use nmblookup __SAMBA__, which is something you can also do on macOS via smbutil view //__SAMBA__.
So you may need to find a NetBIOS library to do the lookup from within your app.
Edit: Further investigation shows that it's indeed the WINS protocol that's used here. nmblookup performs an UDP broadcast, which I've captured with Wireshark (in this case via nmblookup WORKGROUP, which in my setup returns the same information as nmblookup "*"):
The answers come in one after the other and their UDP packets contain the IP-Addressed in their last for bytes:
I've tried creating an example Python script that opens an UDP socket and sends the request, but receiving turned out to be a bit more difficult.
Another update: I've found a UDP broadcast example and adapted it a WINS request: GitHub Gist.
Basically you create a socket via socket(), enable broadcasts via setsockopt() and then you send the packet via sendto().
To read the various responses, use select() and recvfrom() multiple times. Provide a reasonable timeout to not wait indefinitely, in case no further responses have been received.
Sockets are weird API for sure.
The way I would approach it would be to do an IP scan looking for IPs that report an mDNS or SMB name/capability.
Some googling later, it seems that the most suitable command is: dns-sd -B _smb
I don't know if this is what apps like LanScan use to do it, but it might give you enough to go on. There seems to be the start of a code trail that could be relevant at: https://apple.stackexchange.com/a/65679/15281
Hello,
My business is a hybrid Mac-Windows environment. To access our SMB shares, Mac users use a server path smb:\\nameofserver, while Windows users use a letter drive (P:\, M:\, etc), or a UNC path (\\nameofserver). Is it possible for Windows file explorer to correctly navigate to a smb:\\ path without any translation? It would make file sharing between OS's much more seamless. Please let me know if anyone has found a solution, thanks!
Under the finder menu, choose 'Go' -> 'Connect to Server'.
In the box that appears you need to type the path to the SMB server share.
SMB stands for Server Message Block, which windows understands.
The path would look like this...
smb://ServerName/SharedFolder
I have done this on OSX Tiger and Lion.
There are many tutorials available, such as this one on lifehacker
I've used WinShortcutter in the past - seems to work OK. This will allow you to open Windows style UNC paths (\\servername\path\to\directory) when they appear in emails, etc.