GNOME Bugzilla – Bug 568851
refuses to enumerate workgroup if master browser has space in name
Last modified: 2009-04-20 11:29:04 UTC
The change to fix bug #524485 broke some workgroup browsing cases, if you have several workgroups which can be browsed anynomously and try to browse one which is not the one configured in your box it gives a "Failed to retrieve share list from server" error now, that was working correctly before the update
smb debug log "resolve_hosts: getaddrinfo failed for name WORKGROUPNAME [No address associated with hostname] name_resolve_bcast: Attempting broadcast lookup for name WORKGROUPNAME<0x20> got no contact to IPC$ ### SMB-BROWSE: do_mount - [smb://workgroupname/; 0] dir = (nil), cancelled = 0, errno = [110] 'Connection timed out' ### SMB-BROWSE: do_mount - (errno != EPERM && errno != EACCES), breaking send_reply, failed: 1"
Created attachment 127096 [details] gvfsd debug log Attaching full log for reference. Browsing a workgroup is tricky as there's no machine name to resolve. smbclient does resolving through broadcasts (seen in the log). But for some reason it tries to resolve workgroup name which fails of course. name_resolve_bcast: Attempting broadcast lookup for name INTRANET<0x20> got no contact to IPC$ Note that smbtree can discover machines in the specified workgroup for this case.
That looks really weird. First it asks for INTRANET#1d (the workgroup) and finds it, giving the name of the server handling the workgroup. But then it tries to loop up INTRANET#20 (i.e. the workgroup name as a server name). Which fails, because there is no server named INTRANET. Can you verify that smbtree enumerates this correctly? Also, can you get a wireshark log for the gvfs run, and if it works, the smbtree run.
Ok, i can reproduce here. For this to break, the local domain master for the domain you're enumerating has to have a space in the name. When looking up the name of the local master browser (WORKGROUP#1d) in SMBC_opendir_ctx we get, without space: nmb packet from 10.32.208.36(137) header: id=23020 opcode=Query(0) response=Yes header: flags: bcast=No rec_avail=No rec_des=No trunc=No auth=Yes header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0 answers: nmb_name=TESTGROUP<00> rr_type=33 rr_class=1 ttl=0 answers 0 char .X31 hex 07583331202020202020202020202020 answers 10 char ...X31 hex 00040058333120202020202020202020 answers 20 char ...X31 hex 20200304005833312020202020202020 answers 30 char ....__MSBRO hex 2020202020040001025F5F4D5342524F answers 40 char WSE__....TESTGRO hex 5753455F5F020184005445535447524F answers 50 char UP ...TESTG hex 55502020202020201D04005445535447 answers 60 char ROUP ...TES hex 524F55502020202020201E8400544553 answers 70 char TGROUP .... hex 5447524F555020202020202000840000 answers 80 char ................ hex 00000000000000000000000000000000 answers 90 char ................ hex 00000000000000000000000000000000 answers a0 char ............. hex 00000000000000000000000000 But with space: nmb packet from 10.32.208.36(137) header: id=6480 opcode=Query(0) response=Yes header: flags: bcast=No rec_avail=No rec_des=No trunc=No auth=Yes header: rcode=0 qdcount=0 ancount=1 nscount=0 arcount=0 answers: nmb_name=TESTGROUP<00> rr_type=33 rr_class=1 ttl=0 answers 0 char ...__MSBROWSE__. hex 0701025F5F4D5342524F5753455F5F02 answers 10 char ...TESTGROUP hex 0184005445535447524F555020202020 answers 20 char ...TESTGROUP hex 20201D04005445535447524F55502020 answers 30 char ...TESTGROUP hex 202020201E84005445535447524F5550 answers 40 char ...X31 LAP hex 202020202020008400583331204C4150 answers 50 char TOP ...X31 L hex 544F502020202020000400583331204C answers 60 char APTOP ...X31 hex 4150544F502020202020030400583331 answers 70 char LAPTOP ... hex 204C4150544F50202020202020040000 answers 80 char ................ hex 00000000000000000000000000000000 answers 90 char ................ hex 00000000000000000000000000000000 answers a0 char ............. hex 00000000000000000000000000 Notice how the order is different in the "X31" and "X31 LAPTOP" cases. SMBC_opendir_ctx looks for the first name with type 0 in this response, which in the first case is X31 (right) and in the second case is "TESTGROUP" (wrong). I don't know why a) the reply is reordered if it has spaces, and b) why it looks for responses of type 0, and not 0x20 (there is only one 0x20, and its is right).
To verify this without using gvfs, I tried with a single machine in the workgroup "TESTGROUP", first called "X31", then "X31 LAPTOP", restarting nmbd inbetween changes and waiting 5 minutes for it to grab the local master name. Here is the results with "X31": nmblookup -S TESTGROUP querying TESTGROUP on 10.32.208.255 10.32.208.36 TESTGROUP<00> Looking up status of 10.32.208.36 X31 <00> - B <ACTIVE> X31 <03> - B <ACTIVE> X31 <20> - B <ACTIVE> ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> TESTGROUP <1d> - B <ACTIVE> TESTGROUP <1e> - <GROUP> B <ACTIVE> TESTGROUP <00> - <GROUP> B <ACTIVE> MAC Address = 00-00-00-00-00-00 Here is the results with "X31 LAPTOP": nmblookup -S TESTGROUP querying TESTGROUP on 10.32.208.255 10.32.208.36 TESTGROUP<00> Looking up status of 10.32.208.36 ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> TESTGROUP <1d> - B <ACTIVE> TESTGROUP <1e> - <GROUP> B <ACTIVE> TESTGROUP <00> - <GROUP> B <ACTIVE> X31 LAPTOP <00> - B <ACTIVE> X31 LAPTOP <03> - B <ACTIVE> X31 LAPTOP <20> - B <ACTIVE> MAC Address = 00-00-00-00-00-00
I filed a bug upstream about this: http://bugzilla.gnome.org/show_bug.cgi?id=568851
Sorry, https://bugzilla.samba.org/show_bug.cgi?id=6235
upstream fix exists