Bug 11228 - smbclient 4.0.7 fails transfer with STATUS_INVALID_PARAMETER and SMB2 but not with NT1
Summary: smbclient 4.0.7 fails transfer with STATUS_INVALID_PARAMETER and SMB2 but not...
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: 4.0.7
Hardware: All All
: P5 major (vote)
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-20 13:58 UTC by Mike
Modified: 2021-03-18 18:20 UTC (History)
0 users

See Also:


Attachments
smbclient wireshark trace (870.84 KB, application/octet-stream)
2015-04-20 13:58 UTC, Mike
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike 2015-04-20 13:58:30 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.
Comment 1 Jeremy Allison 2015-04-21 23:48:31 UTC
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.
Comment 2 Mike 2015-04-22 01:26:01 UTC
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.
Comment 3 Jeremy Allison 2015-04-22 19:34:19 UTC
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.
Comment 4 Tomas Pospisek 2021-03-18 10:56:26 UTC
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).
Comment 5 Jeremy Allison 2021-03-18 18:20:33 UTC
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 !