I might have a working fix. Stay tuned.

Please try the code from #2208 and report back. For your specific case, you need to refresh at least files nselib/smb.lua and nselib/smb2.lua from the PR.

Note that this new code is likely not fully compatible with your dated version of Nmap. You should use at least 7.80, ideally 7.91.

Thanks for such a quick PR! 👍

Note that this new code is likely not fully compatible with your dated version of Nmap. You should use at least 7.80, ideally 7.91.

Well, I used the one available on CentOS 8 repo, I didn’t check if it was the latest version.

I have cloned your repo and built the code using ./configure && make && sudo make install, actually I didn’t ran sudo make install, I just simply run it from the local repo folder.

Now, it is much faster, although when I run the command my XPs (Windows XP Emdebbed), it still takees about 30 seconds to finish its job. I must note that it once took less then 2 seconds the same machine and once nearly 1.5 minutes, however, mostly it took only half a minute to complete the probing.

The problem with XP is that the SMB 2 probe needs to time out (in my code just once). It is possible to avoid the time-out completely by replacing the native SMB2 negotiation with a hybrid but it would require more substantial refactoring of the SMB code in NSE.

I see. I hope that one day it’ll gets refactored. Nevertheless, thanks for your help and time! 😉

If your network has low latency and the targets are responsive then you might try to tinker with the hard-coded time-out:

If your network has low latency and the targets are responsive

I need to test local network, freshly wired up for the needs of an application. From a physical server (which acts as a router for this network) via an unmanagable switch to the machines is at most 100 metres. All machines are connected via cable only.

then you might try to tinker with the hard-coded time-out:

I could do that, although why can’t we set it as a command-line option?

Just a side question: it there a way to calculate that timeout programmatically?

FYI: Actually, I need to know only the latest supported SMB version. I need it only to use CIFS to mount remote shares from Windows clients on a Linux server. As mount.cifs needs to know exact SMB version to be used and because in our network, there can be computers with Win95 though Win10, I need the latest supported SMB version, which we save it into our DB for reuse when needed.

With the code changes in #2208, there is only minor performance difference between determining all the supported dialects or just highest one. In both cases the highest revision is determined with a single SMB 2 handshake. If the target does not respond at all then further dialects are not tried so there is no penalty. If the target does respond then the script tests all the lower dialects, one at a time. However, at this point we know that the target is capable of SMB 2 so there should not be any timeouts. In my test environment the script execution against such targets takes less than 5 seconds, Samba being by far the fastest with less than 0.5s.

why can’t we set it as a command-line option?

It would not be difficult to implement. I am guessing that there was no need at the time it was coded.

it there a way to calculate that timeout programmatically?

That's a bit tricky. If you forget the technical implementation, how exactly would you calculate it? When the script starts, it is given a dynamically determined RTT timeout but this number does not in any way reflect how long it takes for the target to process an application-level request. IoT targets are poster examples for this issue. They might be on a reliable low-latency network but their processing power is sometimes very limited. You can connect to them in a fragment of a second but then wait 10-15s to complete a request.

The patch from #2208 has been committed as r38184. Thank you for reporting the issue.