Updated Samba Client

[Paul Smedley]

Confirming 'net rpc user' lack of output seems to be a bug. On my linux box running Samba 4.18 it shows a list of users. If I run 'net rpc user -d 10' it shows me:

Code: [Select]

tconx ok
     NetQueryDisplayInformation: struct NetQueryDisplayInformation
        out: struct NetQueryDisplayInformation
            entries_read             : *
                entries_read             : 0x00000000 (0)
            result                   : UNKNOWN_ENUM_VALUE (2152)
return code = 2152
Freeing parametrics:

I assume this is the same for you?

Edit: the output of 'net rpc user -d 10' from a working (4.15?) and non-working net.exe  might be interesting.

I'll have to work out what's going on with smbtree.... Is there anyway to determine how smbtree is being called? ie what command line parameters are used.

[David McKenna]

Paul,

 I see the same as you with server 4.19 with 'net rpc user -d 10' at the end:

gensec_update_send: spnego[20049570]: subreq: 2004b1a0
gensec_update_done: spnego[20049570]: NT_STATUS_OK tevent_req[2004b1a0/../../aut
h/gensec/spnego.c:1631]: state[2] error[0 (0x0)]  state[struct gensec_spnego_upd
ate_state (2004b2a0)] timer[0] finish[../../auth/gensec/spnego.c:2116]
 session setup ok
signed SMB2 message (sign_algo_id=2)
 tconx ok
     NetQueryDisplayInformation: struct NetQueryDisplayInformation
        out: struct NetQueryDisplayInformation
            entries_read             : *
                entries_read             : 0x00000000 (0)
            result                   : UNKNOWN_ENUM_VALUE (2152)
return code = 2152
Freeing parametrics:

 and server 4.15 shows at the end:

[0000] 00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   ........ ........
[0010] 00 00 00 00 00 00 00 00                             ........
Got pdu len 48, data_len 24
rpc_api_pipe: got frag len of 48 at offset 0: NT_STATUS_OK
rpc_api_pipe: host localhost returned 24 bytes.
     samr_Close: struct samr_Close
        out: struct samr_Close
            handle                   : *
                handle: struct policy_handle
                    handle_type              : 0x00000000 (0)
                    uuid                     : 00000000-0000-0000-0000-000000000
000
            result                   : NT_STATUS_OK
Freeing parametrics:

 Couldn't figure out how to capture the whole thing - is there a way?

 I'll look at the Rexx code of the SAMBA Status Monitor (on the Netlabs Trac site) and see if I can figure out the actual SMBTREE command used there after work...

Regards,

[Dave Yeo]

Try 'net rpc user -d 10 2>&1 | tee net_rpc_user.log' to capture all the output.

[David McKenna]

 Thanks Dave! I forgot about that...

 Attached are the full results for the 4.15 and 4.19 servers...

Regards,

[David McKenna]

 Hey Paul,

 Spent the last couple of evenings pondering the forgotten lore of Netlabs SAMBA apps code to try to figure out the SMBTREE command that causes the trap in server 4.19 and it seems to be something like this:

SMBTREE -S -N -d 2 2>smberror.txt 1>smbtree.txt

 I'll attach the results. They show a trap, and I tried with both 'null passwords = Yes' and 'No' in smb.conf, but no difference.

 So also tried SMBTREE -S -U DaveM%password -d 2 2>smberror2.txt 1>smbtree2.txt

 and don't get a trap, but it still doesn't seem to work quite right - I'll attach them too. The SMBMon app probably needs to be updated to work properly with server 4.19 in any case...

 Comparing the logs for 'net rpc user' from the 4.15 and 4.19 server, it seems the 4.19 server doesn't even use the 'rpc' part - it is completely missing from the log...

Regards,

[Paul Smedley]

Thanks Dave, I'll try review over the weekend. I've been busy on some stuff for OpenHAB this week.

Edit: net.exe  is bailing here for some reason - https://github.com/psmedley/samba-os2/blob/samba-os2-4.19.x/source3/rpc_client/cli_pipe.c#L3278

[Paul Smedley]

Thanks Dave, I'll try review over the weekend. I've been busy on some stuff for OpenHAB this week.

Edit: net.exe  is bailing here for some reason - https://github.com/psmedley/samba-os2/blob/samba-os2-4.19.x/source3/rpc_client/cli_pipe.c#L3278

Interesting. net.exe seems to be working - it may be a server issue.

running:

Code: [Select]

net rpc user -S 192.168.1.200works -  where 192.168.1.200 is the IP of my linux server.  Using the IP of the OS/2 server doesn't work. Using an older client against the new OS/2 server also doesn't  work.  Using an older client against my linux server works.

Next step is to get some server logs of the attempt to run net.exe.

Update, found the below in the server logs:

Code: [Select]

[2024/02/10 13:09:48.555000, 10, pid=35737, effective(109, 514), real(0, 0)] ../../source3/rpc_client/local_np.c:391(start_rpc_host_send)
  start_rpc_host_send: posix_spawn() failed: No such file or directory
[2024/02/10 13:09:48.555000, 10, pid=35737, effective(109, 514), real(0, 0)] ../../source3/rpc_client/local_np.c:739(local_np_connect_started)
  local_np_connect_started: start_rpc_host_recv failed: No such file or directory
[2024/02/10 13:09:48.555000, 10, pid=35737, effective(109, 514), real(0, 0), class=rpc_srv] ../../source3/rpc_server/srv_pipe_hnd.c:91(np_open)
  np_open: local_np_connect failed: No such file or directory
[2024/02/10 13:09:48.555000, 10, pid=35737, effective(109, 514), real(0, 0)] ../../source3/smbd/smb2_pipes.c:141(open_np_file)
  np_open(samr) returned NT_STATUS_OBJECT_NAME_NOT_FOUND

OK couple of problems - it's trying to spawn samba-dcerpcd (which wasn't built), and it was also being attempted to run from the wrong directory.  However, hardcoding the path to one that's valid, we get a new error:

Code: [Select]

[2024/02/10 14:24:03.708000, 10, pid=37058, effective(109, 514), real(0, 0)] ../../source3/rpc_client/local_np.c:179(np_sock_connect_connected)
  np_sock_connect_connected: async_connect_recv returned Can't assign requested address
[2024/02/10 14:24:03.708000, 10, pid=37058, effective(109, 514), real(0, 0)] ../../source3/rpc_client/local_np.c:703(local_np_connect_connected)
  local_np_connect_connected: np_sock_connect failed: Can't assign requested address


[Paul Smedley]

Maybe making some  progress.... error from  net is now:

Code: [Select]

cli_rpc_pipe_open_noauth: rpc_pipe_bind for pipe samr failed with error NT_STATUS_IO_TIMEOUT
Corresponding  server log is:

Code: [Select]

[2024/02/10 17:13:02.532000, 10, pid=50843, effective(109, 514), real(0, 0), class=smb2] ../../source3/smbd/smb2_ioctl_named_pipe.c:168(smbd_smb2_ioctl_pipe_read_done)
  smbd_smb2_ioctl_pipe_read_done: np_read_recv nread = -1 is_data_outstanding = 0, status = NT_STATUS_CONNECTION_DISCONNECTED
[2024/02/10 17:13:02.536000, 10, pid=50843, effective(109, 514), real(0, 0), class=smb2] ../../source3/smbd/smb2_ioctl.c:314(smbd_smb2_request_ioctl_done)
  smbd_smb2_request_ioctl_done: smbd_smb2_ioctl_recv returned 4280 status NT_STATUS_CONNECTION_DISCONNECTED
[2024/02/10 17:13:02.536000,  3, pid=50843, effective(109, 514), real(0, 0), class=smb2] ../../source3/smbd/smb2_server.c:4033(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_CONNECTION_DISCONNECTED] || at ../../source3/smbd/smb2_ioctl.c:353
[2024/02/10 17:13:02.536000, 10, pid=50843, effective(109, 514), real(0, 0), class=smb2] ../../source3/smbd/smb2_server.c:3918(smbd_smb2_request_done_ex)
  smbd_smb2_request_done_ex: mid [5] idx[1] status[NT_STATUS_CONNECTION_DISCONNECTED] body[8] dyn[yes:1] at ../../source3/smbd/smb2_server.c:4084


[Paul Smedley]

OK - if my  theory is right -  I know what's going wrong, and think I know how to fix it....

[David McKenna]

Hey Paul,

 Curious how your theory panned out...

Regards,

[Paul Smedley]

Apologies for the delay.  We were away last weekend (16th - 18th) and I was side tracked last week.

I still think I'm right,  but I haven't found the smoking gun yet.  I did manage to patch the source to 4.19.5 last week - will post binaries at some point.

[Paul Smedley]

4.19.5 binaries
smbcl419.dll  (for use with previous 4.19.x ndpsmb.dll): https://smedley.id.au/tmp/smbcl419-4.19.5-20240225.zip
All executables including server: https://smedley.id.au/tmp/samba-4.19.5-os2-20240225.zip

This doesn't fix the bug with 'net rpc user', things now die around:

Code: [Select]

file_new: new file fnum 1809131870
file_name_hash: C:/var/temp/samr hash 0xf50f54d6
local_np_connect_send: socket_dir = C:\MPTN\ETC/samba/ncalrpc, state->socketpath = \socket\samr, lower_case_pipename = samr
np_sock_connect_send: sockpath = \socket\samr
push_sec_ctx(109, 514) : sec_ctx_stack_ndx = 1
push_conn_ctx(2061744258) : conn_ctx_stack_ndx = 0
setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1
Security token: (NULL)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
pop_sec_ctx (109, 514) - sec_ctx_stack_ndx = 0
np_sock_connect_connected: async_connect_recv returned Can't assign requested address
local_np_connect_connected: np_sock_connect failed: Can't assign requested address


[David McKenna]

Thanks Paul!

  This 4.19.5 server seems to perform about the same as the 4.19.4 version, except WINBINDD will not start - log ends with this message:

[2024/02/25 09:07:58.200000,  5] ../../librpc/rpc/dcesrv_core.c:430(dcesrv_interface_register_b)
  dcesrv_interface_register_b: Interface 'winbind' registered on endpoint 'ncalrpc:' (single process required)
[2024/02/25 09:07:58.200000,  1] ../../source3/winbindd/winbindd.c:1038(winbindd_setup_listeners)
  lp_winbindd_socket_directory() = \socket\winbindd, WINBINDD_SOCKET_NAME = pipe
[2024/02/25 09:07:58.200000,  0] ../../lib/util/util.c:225(directory_create_or_exist)
  directory_create_or_exist: mkdir failed on directory \socket\winbindd: No such file or directory
[2024/02/25 09:07:58.200000,  0] ../../lib/util/become_daemon.c:123(exit_daemon)
  exit_daemon: daemon failed to start: Winbindd failed to setup listeners, error code 32

 Didn't we see something like this before?

Regards,

EDIT: added net rpc user log for comparison...

[Paul Smedley]

This is a side effect of me trying to fix 'net RPC user'

[Paul Smedley]

Sorry all,  I've  been busy.  I have some ideas from Steven re: the net rpc  user issue,  and I did manage to  merge the 4.20.0  code this evening.  Will see if I can build it tomorrow.