Bug 191112 - CIFS VFS: bad smb size detected
Summary: CIFS VFS: bad smb size detected
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: Brian Brock
: 379451 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2006-05-08 22:47 UTC by Paul Lemmons
Modified: 2014-06-18 07:35 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-09-21 12:06:15 UTC
Type: ---

Attachments (Terms of Use)
Wireshark capture of conversation with NetApp mount/umount (4.73 KB, application/octet-stream)
2007-09-20 21:12 UTC, Paul Lemmons
no flags Details

Description Paul Lemmons 2006-05-08 22:47:35 UTC
Description of problem:

During shut down I get the following messages:

CIFS VFS: Calculated size 0x126 vs actual length 0x27
CIFS VFS: bad smb size detected for Mid=6008
CIFS VFS: No response for cmd 116 mid 6008

Version-Release number of selected component (if applicable):

$ uname -a
Linux lemix.tmcaz.com 2.6.16-1.2111_FC5smp #1 SMP Thu May 4 21:35:09 EDT 2006
i686 i686 i386 GNU/Linux
$ rpm -qa | grep samba

How reproducible:

Steps to Reproduce:
1. Simply shutdown and watch log
Actual results:

Does not seem serious but I am not sure.

Expected results:

CIFS should come down cleanly

Additional info:

Contents of fstab:

$ cat fstab
/dev/VolGroup00/LogVol00        /                               ext3    defaults
       1 1
LABEL=/boot                     /boot                           ext3    defaults
       1 2
/dev/devpts                     /dev/pts                        devpts 
gid=5,mode=620  0 0
/dev/shm                        /dev/shm                        tmpfs   defaults
       0 0
/dev/proc                       /proc                           proc    defaults
       0 0
/dev/sys                        /sys                            sysfs   defaults
       0 0
/dev/VolGroup00/LogVol01        swap                            swap    defaults
       0 0
//tmcshare1/Users               /home/tspdlp/my/tmcshare1       cifs   
credentials=/home/tspdlp/.smbpasswd,gid=tspdlp,uid=tspdlp 0 0
//lemmons/c$                    /home/tspdlp/my/lemmons         cifs   
credentials=/home/tspdlp/.smbpasswd,gid=tspdlp,uid=tspdlp 0 0

Comment 1 Jay Fenlason 2006-05-09 13:55:41 UTC
the CIFS filesystem is part of the kernel.  Only the mount.cifs helper 
application is included in the Samba rpms, and it's only used when initially 
mounting the remote filesystem. 

Comment 2 Dave Jones 2006-10-16 17:51:42 UTC
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Comment 3 Paul Lemmons 2006-10-30 16:29:27 UTC
I retested and the problem persists, unchanged. 

Comment 4 Dave Jones 2006-11-07 06:27:10 UTC
2.6.18-1.2224.fc5 (currently in updates-testing) had a fix for a really dumb
cifs bug. Can you re-test again please ?

Comment 5 Steve French 2006-11-25 21:04:59 UTC
The log is indicating a server bug (bad smb) - it is probably harmless on
unmount, but would slow unmount by a few seconds.  The only example of a server
that IIRC had this problem was various NetApp filers, which used to leave an
unitialized byte in the response to ulogoffX

What is the server type?

Comment 6 Paul Lemmons 2006-11-28 20:59:16 UTC
It is indeed a NetApp filer. I am not sure if this is a problem that you need to
fix or if it is a problem with the filer. In case you want to cover for it I am
still seeing the problem with:

$ uname -a
Linux xxx.com 2.6.18-1.2849.fc6 #1 SMP Fri Nov 10 12:45:28 EST 2006 i686 i686
i386 GNU/Linux

Comment 7 Jeff Layton 2007-09-20 19:37:31 UTC
As Steve mentioned, this is almost assuredly a problem with the filer. Is this
only seen on shutdown, or is it also seen when you unmount a CIFS share manually?

If this is still reproducible, the ideal thing would be to get some network traces 
when it's occurring and see if Steve's theory about malformed packets from the
server is the cause.

Comment 8 Paul Lemmons 2007-09-20 21:12:06 UTC
Created attachment 201311 [details]
Wireshark capture of conversation with NetApp mount/umount

This is the requested network trace. If you wish for something different,
please ask.

Comment 9 Paul Lemmons 2007-09-20 21:14:08 UTC
The problem does persist and I am currently run Fedora 7 with kernel:
$ uname -a
Linux xxx.com #1 SMP Thu Aug 30 13:47:21 EDT 2007 i686 i686 i386

After the last response I just blamed it on the filer and considered this
problem not the fault of Linux. It causes a minor pause when shutting down or
umounting the share. It always reports the same problem.

I have attached a wireshark trace to this. It is filtered on the IP address of
the NetApp device. It represents a mount and subsequent umount. 

Comment 10 Paul Lemmons 2007-09-20 21:31:45 UTC
On a whim I checked dmesg:

 CIFS VFS: RFC1001 size 35 bigger than SMB for Mid=11
Bad SMB: : dump of 48 bytes of data at 0xeb874800
 00000023 424d53ff 00000074 00018800 # . . . � S M B t . . . . . . .
 00000000 00000000 00000000 6c4a0000 . . . . . . . . . . . . . . J l
 000b0000 0000ff00 705a0640 4c040b0a . . . . . � . . @ . Z p . . . L
 CIFS VFS: server not responding
 CIFS VFS: No response for cmd 116 mid 11

Looked interesting, so  thought I would share :)

Comment 11 Jeff Layton 2007-09-21 12:06:15 UTC
Yep, I think Steve is correct here. The 't' following SMB is the command code
there. That's 0x74 which is SMB_COM_LOGOFF_ANDX. In the data dump above and in
frame #31 of the capture we see:

    Multiplex ID: 11
Logoff AndX Response (0x74)
    Word Count (WCT): 0
    Byte Count (BCC): 255

I believe this is wrong and the byte count here should be 0. I'd suggest filing
a case with NetApp. I think we can close this as NOTABUG.

Please reopen if you believe this to be incorrect.

Comment 12 Jeff Layton 2007-11-28 14:02:41 UTC
*** Bug 379451 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.