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.
Hi, what is the status of this bug? Has a fix for it ever been committed? I am asking because I've encountered what I think is precisely the same problem. It's on a Ubuntu 20.04 5.4.0-54 Kernel: While writing into a file I saw: cp: failed to close '/mnt/sambafs/foobar': Input/output error After a write request from the Linux client the Windows server returns a `STATUS_INVALID_PARAMETER` over a `SMB2 Server Message Block Protokol version 2` (according to Wireshark) packet. This happens only when the data that gets written to the file is >= 65337 bytes. The problem does not appear when the data is <= 65336 bytes. (the trials were done with `dd if=/dev/urandom bs=1 count=$COUNT of=/mnt/sambafs/foobar` (strangely enough when I use `cp` to do the copying, then it takes one byte less to trigger the behavior)). In the present case libsmbclient was **not** used (as far as I understand libsmbclient would be used for userspace SMB access), but instead the in-kernel SMB client was used. The Windows Share was mounted via fstab with the options `vers=3.0`. I do not know what Windows version was used on the server side - it is out of my control. I was also seeing `CIFS VFS: \\windows_fileserver\somepath SMB signature verification returned error = -13` in the kernel logs, but the occurence of these log entries was not synchronous to the `STATUS_INVALID_PARAMETER` so maybe this is some different problem. The problem went away after upgrading to the 5.4.0-67 kernel, so maybe the problem was solved in the Ubuntu kernel or upsteam? I can see a fix in [Ubuntu's changelog](https://launchpad.net/ubuntu/+source/linux/5.4.0-67.75) that seems vaguely relevant: cifs: fix interrupted close commands However I'm not sure if that was the fix for the problem or if the reason this problem went away was the reboot after the kernel package upgrade. If this problem was indeed fixed by the mentioned changelog entry above then a link to the related bugzilla ticket would be appreciated (haven't found one). If there's interest I can provide the pcap of the problem on request (I am not sure what secrets are contained in it and it was not my machine where I had to analyze the problem, so I'm wary of attaching the pcap here - I solicit your comprehension).
This isn't the same bug. cifsfs doesn't use the smbclient code. I think this bug is fixed. If you can reproduce please log a new bug against cifsfs. Thanks !