libsmbclient ignore "interfaces" and "bind interfaces only" options of smb.conf and ~/.smb/smb.conf. So it send broadcast query to resolve netbios names on all interfaces.

Look to attached file (debug.diff). I attach it to clear the problem. This is a difference in debug level 10 output of "smbclient -L ORRY -d10" and similar program using libsmbclient. As you can see smbclient use 10.0.14.13/16 and 127.0.0.1/24 interfaces, so it query for ORRY only on 10.0.14.13 interface.  libsmbclient use all(except lo) my interfaces, so it query for ORRY on 195.19.252.52/24 interface (this fail) and then on 10.0.14.13/16 interface.  This is the reason for annoying me delay during the scanning shares list by NetBIOS name.

I made more accurate measurement. Here is a results of time required  to smbc_opendir() for 2 situations:

Situation 1.
============
  I have 3 network interface: 195.19.252.72/24, 10.0.14.13/16, 10.0.14.133/16.
  smbd/nmbd listen on 10.0.14.13 and 127.0.0.1.

  smb://10.0.14.13/bbs   0.04 sec
  smb://10.0.14.13       0.04 sec
  smb://laska/bbs        1.14 sec    (see note 1 below)
  smb://laska            7.22 sec    (see note 2 below)

Situation 2.
============
  I have 1 network interface: 10.0.14.13/16
  smbd/nmbd listen on 10.0.14.13 and 127.0.0.1.

  smb://10.0.14.13/bbs   0.04 sec
  smb://10.0.14.13       0.04 sec
  smb://laska/bbs        0.32 sec   (see note 1 below)
  smb://laska            2.25 sec   (see note 2 below)

==========================================================================

Note 1
------
  in Situation 1 we have 3 failed query before NetBIOS name was resolved.
  This is 3 broadcast query of laska<0x20> on 195.19.252.72/24. 

  So we got:
    time of failed query = 0.3 sec
    time of success query = 0.3 sec

Note 2
------
  in Situation 1 we have 21 failed query before NetBIOS name was resolved.
  This is:
    3 broadcast query of laska<0x1d> on 195.19.252.72/24
    3 broadcast query of laska<0x1d> on 10.0.14.13/16
    3 broadcast query of laska<0x1d> on 10.0.14.133/16 
    3 broadcast query of laska<0x1b> on 195.19.252.72/24 
    3 broadcast query of laska<0x1b> on 10.0.14.13/16  
    3 broadcast query of laska<0x1b> on 10.0.14.133/16 
    3 broadcast query of laska<0x20> on 195.19.252.72/24
  in Situation 2 we have only 6 failed query before NetBIOS name was resolved.
  This is:
    3 broadcast query of laska<0x1d> on 10.0.14.133/16
    3 broadcast query of laska<0x1b> on 10.0.14.13/16

  So we got:
    time of failed query = 0.3 sec
    time of success query = 0.3 sec

=======================================================
Conclusion
=======================================================
What can be done to improve the situation:

1) do not ignore "interfaces" and "bind interfaces only" options.
   In the Situation 1 this will allow us to avoid 15 failed broadcast queries,
   so we can decrease the time of shares listing up to 5 sec.

2) We can assume, what people more ofthen want to see shares list then 
   computers/groups list, so we can reorder the queries to find the 
   NetBIOS names of type <0x20>.

3) I think, it's possible to query NETBIOS name of type <0x00>, analyse the
   first reply (i mean something like "nmblookup -S name"). If it hostname
   we got ip already, if it group/domain name, then query for NetBIOS names
   of type <0x1d> and <0x1b>.