As discussed in april (http://lists.samba.org/pipermail/samba-technical/2003-April/043899.html), libsmbclient fails to get NetServerEnum2 correctly with XP servers (have no NT here, but I guess it's the same problem) because they reply to 445 but only with nonsense. Because win9x refuse 445 connections, it works because of the port 139 fallback. Actually it's all a bit more complicated, but fact is: it doesn't work the way it is and this works: - /* try 445 first, then 139 */ - int port = cli->port?cli->port:445; + /* try 139 first, then 445 */ + int port = cli->port?cli->port:139; (there is a 139 later that needs to be changed to 445, but I don't want to create an attachment with full patch)
this should all be worked out now.
In what branch? My patch still applies cleanly against samba/branches/SAMBA_3_0 and that makes listing work groups with svn still impossible ;( examples/libsmbclient/testbrowse: nmb packet from 10.10.103.204(137) header: id=9011 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=MSHEIMNETZ<1d> rr_type=32 rr_class=1 ttl=300000 answers 0 char `...g. hex 60000A0A67CC Got a positive name query response from 10.10.103.204 ( 10.10.103.204 ) found master browser MSHEIMNETZ, 10.10.103.204 Connecting to host=10.10.103.204 share=IPC$ Connecting to 10.10.103.204 at port 445 Serverzone is -7200 Doing spnego session setup (blob length=16) server didn't supply a full spnego negprot using workgroup MSHEIMNETZ 10.10.103.204 smbc_server: server_n=[10.10.103.204] server=[10.10.103.204] -> server_n=[10.10.103.204] server=[10.10.103.204] Connecting to 10.10.103.204 at port 445 session request ok Doing spnego session setup (blob length=16) server didn't supply a full spnego negprot session setup ok tconx ok Server connect ok: //10.10.103.204/IPC$: 0x8123bf0 Could not open [smb://] (0:Success) So it still tries port 445 first and then finds out, that this doesn't work (huch!) and for that it returns the perfect errno: 0.
Hmm, it seems testbrowse was using an older version, now I get a different error: Could not open [smb://] (101:Network is unreachable) Debugging
Adding some quite some debug output, I found that it tries to look up my work group as WORKGROUP<20> because it took the 0x1d type from the response it got from the server ip as server name. I wonder why it did that, but this patch makes it query for the server name in the response. --- libsmb/libsmbclient.c (revision 490) +++ libsmb/libsmbclient.c (working copy) @@ -1902,8 +1902,8 @@ * the first choice and fall back to MSBROWSE if the * wildcard query fails. */ - if (!name_status_find("*", 0, 0x1d, server_ip, server) && - !name_status_find(MSBROWSE, 1, 0x1d, server_ip, server)) { + if (!name_status_find("*", 0, 0x20, server_ip, server) && + !name_status_find(MSBROWSE, 1, 0x1b, server_ip, server)) { errno = ENOENT; return NULL; }
I checked and the commit introducing that was 1.79 in cvs and it's marked in the commit log as untested. Now I'm puzzled what's the right thing to do here ; ( - if (!name_status_find("*", 0, 0, server_ip, server)) { + /* + * Do a name status query to find out the name of the + * master browser. We use <01><02>__MSBROWSE__<02>#01 if + * *#00 fails because a domain master browser will not + * respond to a wildcard query (or, at least, an NT4 + * server acting as the domain master browser will not). + * + * We might be able to use ONLY the query on MSBROWSE, but + * that's not yet been tested with all Windows versions, + * so until it is, leave the original wildcard query as + * the first choice and fall back to MSBROWSE if the + * wildcard query fails. + */ + if (!name_status_find("*", 0, 0x1d, server_ip, server) && + !name_status_find(MSBROWSE, 1, 0x1d, server_ip, server)) {
Hmmm, I am not sure what the confusion is, but the current approach looks OK.
it queries for <1d> on the server IP and gets the work group name and then tries to do a nmb_lookup for <20> with that name - which of course doesn't return anything. This is a critical bug as with this change in samba 3.0.3, it's basically impossible to use smb:// ;(
OK, I am willing to believe that the following should work: --- libsmb/libsmbclient.c (revision 490) +++ libsmb/libsmbclient.c (working copy) @@ -1902,8 +1902,8 @@ * the first choice and fall back to MSBROWSE if the * wildcard query fails. */ - if (!name_status_find("*", 0, 0x1d, server_ip, server) && - !name_status_find(MSBROWSE, 1, 0x1d, server_ip, server)) { + if (!name_status_find("*", 0, 0x20, server_ip, server) && + !name_status_find(MSBROWSE, 1, 0x1b, server_ip, server)) { errno = ENOENT; return NULL; } Because looking for the name of "*" against a 0x1d name does not make any sense Can I confirm that what you are saying is that change the name type to 0x20 above makes things work?
I don't see the difference to my patch in #4 - but yes only the 1d->20 change is important
it's fixed in r559 - so if someone could hit the resolve option :)
Marked as fixed on request of Stephan. Thanks.
Perhaps we can also mark it as verified?
originally reported against one of the 3.0.0rc[1-4] releases. Cleaning up non-production versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
database cleanup