Bug 7025 - unable to browse windows network with broadcasting addresses resolution
unable to browse windows network with broadcasting addresses resolution
Status: RESOLVED WORKSFORME
Product: Samba 3.4
Classification: Unclassified
Component: libsmbclient
3.4.3
x86 Linux
: P3 normal
: ---
Assigned To: Derrell Lipman
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-07 16:32 UTC by Slav Grig
Modified: 2010-02-12 07:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Slav Grig 2010-01-07 16:32:22 UTC
I configured a very simple network with two computers in the private network zone: 192.164.1.0/255.255.255.0. There is no WINS servers. Computers:
0) Router with dhcp support.
1) Computer with Windows XP Professional.
2) Computer with Linux (custom edition), samba 3.4.3.

wins server/support is switched off. Names resolution only via broadcasting. Samba is forbidden to be a local master browser.

When I use smbtree utility, I see both servers in my net. But, when I use gnome gvfs (which uses daemon gvfs-smb-browse, which uses libsmbclient.so), I can't see WORKGROUP content. I compiled gvfs and samba in debug mode and traced gvfs-smb-browse to find an answer.

Function SMBC_opendir_ctx in libsmb_dir.c is used to open "smb://workgroup". It finds the IP address of another computer and calls "name_status_find" with server=workgroup, q_type=0x20, type=0x20. And the last one returns an error due to "node_status_query" function can't get answer from that computer. But the same "node_status_query" function is invoked when I use nmblookup utility to get info about node (nmblookup -A xx.xx.xx.xx). And in that case it gets answer! I found that difference is in the q_type field: SMBC_opendir_ctx use 0x20, but nmblookup utility use 0x00. When I changed this constant in SMBC_opendir_ctx to 0x00, I got answer and saw whole WORKGROUP content in the gnome through gvfs.

I read about NetBOIS names at http://technet.microsoft.com/en-us/library/cc779578%28WS.10%29.aspx. If I correctly understand a topic "NetBIOS group names", group name with 0x00 is for receiving browser broadcasts, and group name 0x20 - to work with WINS. May be SMBC_opendir_ctx should try to find nodes with both 0x00 and 0x20 (for correct work in WINS- and broadcast- networks). I guess, my changing will not work in the WINS-powered network.

Kernel version: 2.6.31.4
glibc: 2.5.1

smb.conf content:
----------------------
[global]
        dos charset = cp866
        server string = Win3.11 Server
        log level = 5
        log file = /var/log/samba-log.%m
        max log size = 500
        name resolve order = bcast
        local master = No
        dns proxy = No
        hosts allow = 192.168.0., 192.168.1., 127., 192.168.2.

[printers]
        comment = All Printers
        path = /usr/spool/samba
        printable = Yes
        browseable = No
        browsable = No
----------------------

part of gvfsd-smb-browse console output:
----------------------
### SMB-BROWSE: do_mount - [smb://; 0] dir = 0x80d5428, cancelled = 0, errno = [0] 'Победа' 
### SMB-BROWSE: update_cache - updating...
### SMB-BROWSE: update_cache - done.
### SMB-BROWSE: do_mount - login successful, res = 1
Using netbios name ARMAG-LIN.
Using workgroup WORKGROUP.
### SMB-BROWSE: do_mount - URI = smb://workgroup/
### SMB-BROWSE: do_mount - try #0 
parsed path: fname='smb://workgroup/' server='workgroup' share='' path='' options=''
SMBC_check_options(): server='workgroup' share='' path='' options=''
### SMB-BROWSE: auth_callback - anonymous pass
### SMB-BROWSE: auth_callback - out: last_user = 'slava', last_domain = 'WORKGROUP'
name_resolve_bcast: Attempting broadcast lookup for name workgroup<0x1d>
nmb packet from 192.168.1.34(137) header: id=2759 opcode=Query(0) response=Yes
    header: flags: bcast=No rec_avail=No rec_des=Yes trunc=No auth=Yes
    header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0
    answers: nmb_name=WORKGROUP<1d> rr_type=32 rr_class=1 ttl=300000
    answers   0 char ....."   hex 0000C0A80122
Got a positive name query response from 192.168.1.34 ( 192.168.1.34 )
Could not get name of local/domain master browser for server workgroup
### SMB-BROWSE: do_mount - [smb://workgroup/; 0] dir = (nil), cancelled = 0, errno = [1] 'Операция не позволяется' 
### SMB-BROWSE: do_mount - after anon, enabling NTLMSSP fallback
### SMB-BROWSE: do_mount - try #1 
parsed path: fname='smb://workgroup/' server='workgroup' share='' path='' options=''
SMBC_check_options(): server='workgroup' share='' path='' options=''
### SMB-BROWSE: auth_callback - normal pass
### SMB-BROWSE: auth_callback - asking for password...
### SMB-BROWSE: auth_callback - out: last_user = 'slava', last_domain = 'WORKGROUP'
name_resolve_bcast: Attempting broadcast lookup for name workgroup<0x1d>
nmb packet from 192.168.1.34(137) header: id=7882 opcode=Query(0) response=Yes
    header: flags: bcast=No rec_avail=No rec_des=Yes trunc=No auth=Yes
    header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0
    answers: nmb_name=WORKGROUP<1d> rr_type=32 rr_class=1 ttl=300000
    answers   0 char ....."   hex 0000C0A80122
Got a positive name query response from 192.168.1.34 ( 192.168.1.34 )
Could not get name of local/domain master browser for server workgroup
### SMB-BROWSE: do_mount - [smb://workgroup/; 1] dir = (nil), cancelled = 0, errno = [1] 'Операция не позволяется' 
### SMB-BROWSE: do_mount - try #2 
parsed path: fname='smb://workgroup/' server='workgroup' share='' path='' options=''
SMBC_check_options(): server='workgroup' share='' path='' options=''
### SMB-BROWSE: auth_callback - normal pass
### SMB-BROWSE: auth_callback - asking for password...
### SMB-BROWSE: auth_callback - out: last_user = 'ABORT', last_domain = 'WORKGROUP'
name_resolve_bcast: Attempting broadcast lookup for name workgroup<0x1d>
nmb packet from 192.168.1.34(137) header: id=1630 opcode=Query(0) response=Yes
    header: flags: bcast=No rec_avail=No rec_des=Yes trunc=No auth=Yes
    header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0
    answers: nmb_name=WORKGROUP<1d> rr_type=32 rr_class=1 ttl=300000
    answers   0 char ....."   hex 0000C0A80122
Got a positive name query response from 192.168.1.34 ( 192.168.1.34 )
Could not get name of local/domain master browser for server workgroup
### SMB-BROWSE: do_mount - [smb://workgroup/; 2] dir = (nil), cancelled = 1, errno = [1] 'Операция не позволяется' 
### SMB-BROWSE: do_mount - (errno != EPERM && errno != EACCES), breaking
----------------------
Comment 1 Derrell Lipman 2010-01-15 15:00:14 UTC
I just tested using version 3.5. With no WINS server, an XP system, a Linux system, and the samba/examples/libsmbclient/testbrowse test application, browsing works properly.

I have seen this type of problem when various network misconfigurations exist:
- two computers with the same IP address
- two computers with the same NetBIOS name

and, frequently, when the master browser gets confused. In this latter case, rebooting the master browser system for the workgroup typically solves the problem.

> I read about NetBOIS names at
> http://technet.microsoft.com/en-us/library/cc779578%28WS.10%29.aspx.

The bible for understanding NetBIOS is http://ubiqx.org/cifs/ by our very own Chris Hertel. You'll gain a great understanding of NetBIOS if you study that.

Please test with the testbrowse application. Note that it typically links dynamically, so you must install your freshly-compiled samba-3.5 and ensure that its libraries will be found in preference to any system libraries that are already installed. Let me know the results.

Cheers,

Derrell
Comment 2 Slav Grig 2010-01-18 15:39:57 UTC
I downloaded and compiled samba-3.5.0pre2. 'testbrowse' utility works fine. And gvfsd too. I think, it is due to changes in the libsmb_dir.c, which I described earlier.

Should I change the bug status (for samba 3.4.3) to 'fixed'?
Comment 3 Derrell Lipman 2010-02-02 07:42:10 UTC
Yes, if the current version works for you, you can change the status to "fixed". Thanks.
Comment 4 Derrell Lipman 2010-02-12 07:17:49 UTC
No recent response, and OP's most recent comment indicates it works too. Closing.