search

minoca / os

Minoca operating system
Other
2.71k stars 232 forks source link

smbclient network failure under qemu #119

Closed d-hoke closed 7 years ago

d-hoke commented 7 years ago

Build samba-4.0.26.tar.gz, source3 ('configure' method), after modifying 'configure' script to ignore absence of locking.

running minoca under qemu on linux host, smbclient will load and connect to remote node, but seems that attempts to access files (via 'get') larger than 64512 bytes are truncated to 64512 bytes, and smbclient reports 'parallel_read returned NT_STATUS_CONNECTION_DISCONNECTED'.

File of less than 64512 transferred without error.

Have not pursued why, but same samba source archive built and run on host where qemu is running, smbclient can access files via 'get' from same attempted target without such failures.

ccstevens commented 7 years ago

From errmap_unix.c in the samba source, I see that NT_STATUS_CONNECTION_DISCONNECTED maps to EPIPE.

While there could be an actual pipe error, the socket send C library routine can return EPIPE when:

The socket is shut down for writing, or the socket is connection-mode and is no longer connected. In the latter case, and if the socket is of type SOCK_STREAM or SOCK_SEQPACKET and the MSG_NOSIGNAL flag is not set, the SIGPIPE signal is generated to the calling thread.

EPIPE maps to Minoca's STATUS_BROKEN_PIPE and STATUS_BROKEN_PIPE_SILENT which are used in 'NetpTcpSend', 'NetpUdpSend' and 'NetpRawSend'. A search of the Samba source shows it uses TCP, UDP, and the raw sockets protocol.

So, I think the next step would be to validate that sockets are the culprit and not an actual pipe. That's more easily done under the kernel debugger, but a check for EPIPE (print or assert) in the sendto() C library routine would also give us a hint.

I'd be happy to take a quick look at this myself if you send me your samba binaries.

d-hoke commented 7 years ago

smbclientitems.tar.gz hopefully attached... (it wasn't - had to add through github web interface) extract stuff... LD_LIBRARY_PATH= /smbclient ////<sharename -U usertoaccess

get ________________________________ From: Chris Stevens Sent: Monday, April 10, 2017 7:32 PM To: minoca/os Cc: d-hoke; Author Subject: Re: [minoca/os] smbclient network failure under qemu (#119) From errmap_unix.c in the samba source, I see that NT_STATUS_CONNECTION_DISCONNECTED maps to EPIPE. While there could be an actual pipe error, the socket send C library routine can return EPIPE when: The socket is shut down for writing, or the socket is connection-mode and is no longer connected. In the latter case, and if the socket is of type SOCK_STREAM or SOCK_SEQPACKET and the MSG_NOSIGNAL flag is not set, the SIGPIPE signal is generated to the calling thread. EPIPE maps to Minoca's STATUS_BROKEN_PIPE and STATUS_BROKEN_PIPE_SILENT which are used in 'NetpTcpSend', 'NetpUdpSend' and 'NetpRawSend'. A search of the Samba source shows it uses TCP, UDP, and the raw sockets protocol. So, I think the next step would be to validate that sockets are the culprit and not an actual pipe. That's more easily done under the kernel debugger, but a check for EPIPE (print or assert) in the sendto() C library routine would also give us a hint. I'd be happy to take a quick look at this myself if you send me your samba binaries. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
ccstevens commented 7 years ago

While I was able to reproduce what you were seeing, it doesn't appear that there is a magical line at 64512 bytes. I was able to transfer some files with over 66000 bytes. That said, I got the same NT_STATUS_CONNECTION_DISCONNECTED error on 100kb+ files.

My initial hunch was wrong. NetpTcpSend, etc. are not returning STATUS_BROKEN_PIPE or STATUS_BROKEN_PIPE_SILENT. The NetGlobalDebug flag was useful here as it printed that NetUserControl failed with STATUS_NOT_SUPPORTED on the larger downloads. Breaking in on that routine showed that ioctl was being called with FIONREAD to get the amount of available data in the socket's receive buffer. We, however, do not implement that ioctl for TCP sockets. I've added a change to support that and the get command started working better. This all checks out with the samba source, as a failed call to the FIONREAD gets converted to an EPIPE error.

Related, are you seeing NT_STATUS_NO_MEMORY errors when trying to execute dir commands in the samba client? Seems like the next thing to poke at.

d-hoke commented 7 years ago

I don't ATM recall seeing any of these errors, but I think I was using 'ls' and not 'dir' (if there's a difference - I don't use samba extensively, just find smbclient handy occasionally.)

Will have to try and update this with observation...

update: No, do not see any such errors with either 'dir' or 'ls' (long listings scroll off, and haven't found how to page back to view all, but nothing on short listings)

Related, are you seeing NT_STATUS_NO_MEMORY errors when trying to execute dir commands in the samba client? Seems like the next thing to poke at.

ccstevens commented 7 years ago

ls and dir result in the same error for me. What system is your smb server running on? I was connecting to a Windows box and I think it was tripping up on interpreting the directory entry formats.

I found a report of a similar error on the samba mailing list (dated 2013), which has me wondering why you're building Samba-4.0.26 (Spring 2015) and not something newer. I'd update to a newer version before digging into any more issues.

d-hoke commented 7 years ago

winxp and winvista (I may have also ref'd a win7 earlier)

I'm using 4.0.26 because that's the last version to build via configure, generally useable under minoca, and I couldn't (quickly?) get samba's homegrown/custom build system tool to build under minoca... :)

From: Chris Stevens notifications@github.com Sent: Thursday, April 13, 2017 6:08 PM To: minoca/os Cc: d-hoke; Author Subject: Re: [minoca/os] smbclient network failure under qemu (#119)

ls and dir result in the same error for me. What system is your smb server running on? I was connecting to a Windows box and I think it was tripping up on interpreting the directory entry formats.

I found a report https://lists.samba.org/archive/samba/2013-January/170926.html of a similar error on the samba mailing list (dated 2013), which has me wondering why you're building Samba-4.0.26 (Spring 2015) and not something newer. I'd update to a newer version before digging into any more issues.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/minoca/os/issues/119#issuecomment-293978161, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AYGXTM_I6Snm_Sti12fyYamIMbsVBEfVks5rvmSugaJpZM4M32td.

ccstevens commented 7 years ago

Sounds like a good reason to be using 4.0.26 for now. Custom build systems are usually a headache.

Hmm. I'm serving from Win10. It'll be easier to debug the NT_STATUS_NO_MEMORY with some smbclient symbols and the user mode debugger. cli_list is the function that's failing and the kernel isn't failing any allocations.

I'll push the fix for the NT_STATUS_CONNECTION_DISCONNECTED error once the builds pass. Give me a few days.

ccstevens commented 7 years ago

In case you didn't already retry this, change 8d4bff07 has the fix and was pushed a few weeks ago.