A customer reported problems while retrieving a file from a Windows XP (SP3) client via a ISDN connection. I'm able to reproduce this problem using "trickle" to slow down my connection: # trickle -d 8 -u 8 smbclient -A .auth -W DOMAIN //hostname/c$ -c "cd tv; get 20111222.jrn jrnfiles/hostname/20111222-$(date +%H%M%S).jrn" Domain=[DOMAIN] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager] parallel_read returned NT_STATUS_IO_TIMEOUT Only the first 196602 bytes of the 1263753 byte test file get transfered (in 10 out of 10 tests). With -d10 I get the following output: ... num_setup=1, max_setup=0, param_total=4, this_param=4, max_param=2, data_total=0, this_data=0, max_data=4356, param_offset=68, param_disp=0, data_disp=0 getting file \tv\20111222.jrn of size 1263753 as jrnfiles/hostname/20111222-150614.jrn cli_pull_read_done: Pushing 65534 bytes, 0 already pushed cli_pull_read_done: Requesting 65534 bytes at 524272, position 0 cli_pull_read_done: Pushing 65534 bytes, 65534 already pushed cli_pull_read_done: Requesting 65534 bytes at 589806, position 1 cli_pull_read_done: Pushing 65534 bytes, 131068 already pushed cli_pull_read_done: Requesting 65534 bytes at 655340, position 2 Running timed event "tevent_req_timedout" 0x9145cf0 parallel_read returned NT_STATUS_IO_TIMEOUT Running timed event "tevent_req_timedout" 0x9141948 write_socket(4,39) write_socket(4,39) wrote 39 got smb length of 12851 size=12851 ... If I set "iosize 16384" within the command ("iosize 16384; cd tv; get 20111222.jrn jrnfiles/hostname/20111222-$(date +%H%M%S).jrn") the file is transfered correctly. # smbclient --version Version 3.5.4
Hmmm. Seems like it could be a latency problem ? smbclient will fill the pipe with up to max_mux (usually 50) simultaneous requests, and if any one of them take more than 10 seconds to complete I think they'll time out. With a smaller iosize the latency doesn't affect us as much. Jeremy.