Has smbclient behavior changed from 2.2.8a to 3.0.0?

Brenden J. Bain bbain at cs.newcastle.edu.au
Wed Nov 5 01:32:40 GMT 2003


Hi All,

Sorry if this is redundant. My in my last e-mail is that Samba 3.0.0
already drops to a 139 connection when executing the "NetServerEnum2"
call. That is, the client first connects to 445 to execute the
"NetServerEnum" and then reconnects to the same server on 139 for the
"NetServerEnum2" call. This is coded in the "static int
do_host_query(char *query_host)" fuction from client/client.c in my
Samba 3.0.0 source.

As for adding "-p 139" still does not work as already reported. The
client is forced to connect to the server on 139, however, the
"NetServerEnum2" call is still empty.

Again in all these cases the "NetServerEnum2" call to port 139  
has the server name in the "Enumeration Domain" rather than the
workgroup/domain name. I still can't see why the "Enumeration Domain"
should be set to the server name over the workgroup/domain name,
especially for 139 connections.

I had a quick glance through the source. To me it seems that the
that extended security could cause the problem. In the
client/client.c the workgroups are listed in"static BOOL
list_servers(char*wk_grp):2039" with the call:

  cli_NetServerEnum(cli, cli->server_domain, SV_TYPE_DOMAIN_ENUM,
                    server_fn, NULL);

Now "cli->server_domain" is set in "cli_session_setup". Now my client
authenticates over extended security using "ntlmssp". In the
libsmb/cliconnect.c the function 
"static BOOL cli_session_setup_ntlmssp:523" cli->server_domain is set
in the following:

	if (NT_STATUS_IS_OK(nt_status)) {
		fstrcpy(cli->server_domain, ntlmssp_state->server_domain);
		set_cli_session_key(cli, ntlmssp_state->session_key);
	}

>From my ethereal traces the "server_domain" is the name of the server
that I contaced rather than the workgroup it is associated with.
Hence when eventually I make the call to cli_NetServerEnum is is passed
the server name rather than "domain/workgroup".

This could be a result of our setup. We basically have a highly dynamic
netbios lan. The server I connect to is not part of any "domain" (though
it is part of a workgroup) and as such it may be correct to send the
machine name back to the client. On the other hand, as
extended security was negioated with the XP box, maybe XP thinks the
client is another XP/2000 box and ignores all concepts of NetBIOS names.

The problem is solved when we are forced to connect to a machine using
the old "NTLM" or "LM" hashes as the workgroup name is correctly
returned by the server and set in "struct cli".

Maybe Samba sould not use extended security when trying to connect on
port 139? Then again I could be completely wrong.

Again I am sorry if this has already been addressed.

Brenden.


>> CH> Try adding "-p 139" to the command line and see if that fixes it.
>> 
>> Nope.

>Weird.

>3.0.0 tries connecting on port 445.  Windows does not support the
>NetServerEnum2 call (the one that returns the servers and workgroups)
>on that port (as I recall).  Forcing smbclient to connect to port 139
>*should* fix the problem, since NetServerEnum2 is supported on port
>139.
>
>Dang.
>
>If you grab a trace of smbclient 3.0.9, please verify that it is 
>connecting on 139 rather than 445.
>
>Thanks.
>
>Chris -)-----




More information about the samba-technical mailing list