The Samba-Bugzilla – Bug 11228
smbclient 4.0.7 fails transfer with STATUS_INVALID_PARAMETER and SMB2 but not with NT1
Last modified: 2015-04-22 19:34:19 UTC
Created attachment 10970 [details] smbclient wireshark trace We get STATUS_INVALID_PARAMETER failures when smbclient uses SMB2 but passes with NT1. We do get some success, but mostly failures. It appears to happen after it transfers the PDF file. These are the packets leading up to SMB2 failing after the transfer: No. Time Source Destination Protocol Length Info 266 2015-04-09 08:30:43.688568000 10.5.12.227 10.6.161.184 TCP 1514 [TCP segment of a reassembled PDU] No. Time Source Destination Protocol Length Info 267 2015-04-09 08:30:43.688696000 10.5.12.227 10.6.161.184 TCP 1514 [TCP segment of a reassembled PDU] No. Time Source Destination Protocol Length Info 268 2015-04-09 08:30:43.688699000 10.5.12.227 10.6.161.184 SMB2 627 Write Request Len:72845 Off:0 File: scsmuser\Scan\DOC002.pdf No. Time Source Destination Protocol Length Info 269 2015-04-09 08:30:43.688701000 10.6.161.184 10.5.12.227 TCP 66 445→35119 [ACK] Seq=1611 Ack=74211 Win=26704 Len=0 TSval=1545474022 TSecr=464076 No. Time Source Destination Protocol Length Info 270 2015-04-09 08:30:43.729116000 10.6.161.184 10.5.12.227 TCP 66 445→35119 [ACK] Seq=1611 Ack=74772 Win=26704 Len=0 TSval=1545474063 TSecr=464077 No. Time Source Destination Protocol Length Info 271 2015-04-09 08:30:43.758999000 10.6.161.184 10.5.12.227 SMB2 143 Write Response, Error: STATUS_INVALID_PARAMETER This is happening at a remote site, and we are not able to recreate it here. Does anyone have any input as to why this may be happening.
Just want to check - is this with your SMB2 backport of the client code to 4.0.x ? If so, can you try and reproduce with 4.1.x just so we can exclude a back-porting bug ? Thanks. Jeremy.
This is not reproducible at our lab, but several customers have had this happen. Since we can't reproduce it, we need to know if there is some info in the wireshark trace that may help us. It appears to transfer the file and then the server reports an error in the transfer, correct ? Is it possible the server is reporting a status, that not an error, but we may be treating it as an error. We would like you to tell us if the server is generating an error code or if our smbclient is generating it. Thanks, Mike -----Original Message----- From: samba-bugs@samba.org [mailto:samba-bugs@samba.org] Sent: Tuesday, April 21, 2015 7:49 PM To: Tompkins, Michael Subject: [Bug 11228] smbclient 4.0.7 fails transfer with STATUS_INVALID_PARAMETER and SMB2 but not with NT1 https://bugzilla.samba.org/show_bug.cgi?id=11228 --- Comment #1 from Jeremy Allison <jra@samba.org> --- Just want to check - is this with your SMB2 backport of the client code to 4.0.x ? If so, can you try and reproduce with 4.1.x just so we can exclude a back-porting bug ? Thanks. Jeremy. -- You are receiving this mail because: You reported the bug.
OK, the INVALID_PARAMETER is real, and it's happening when you're sending an SMB2 write larger than 64k. Packet 1715 in the trace. You're negotiating SMB 2.10 but you're not setting the credit charge in the request packet. From the SMB2 spec: CreditCharge (2 bytes): In the SMB 2.002 dialect, this field MUST NOT be used and MUST be reserved. The sender MUST set this to 0, and the receiver MUST ignore it. In all other dialects, this field indicates the number of credits that this request consumes. You're not setting it in any of the other requests either, so the server is probably implicitly assuming a charge of '1'. However, once the packet size goes over 64k, then the charge should be '2' or bigger - so now it cares. Looks like you don't have the credit processing right in your port, but for normal use (write chunk sizes < 64k) you're getting away with it.