Linux CIFS filesystem development
 help / color / mirror / Atom feed
From: VALETTE Eric RD-MAPS-REN <eric2.valette-C0LM0jrOve7QT0dZR+AlfA@public.gmane.org>
To: Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Linux 3.2.17 and netapp 8.1
Date: Mon, 14 May 2012 18:23:15 +0200	[thread overview]
Message-ID: <4FB13173.1070509@orange.com> (raw)
In-Reply-To: <20120514121824.273198a9-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>

On 05/14/2012 06:18 PM, Jeff Layton wrote:
> On Mon, 14 May 2012 18:06:09 +0200
> VALETTE Eric RD-MAPS-REN<eric2.valette-C0LM0jrOve7QT0dZR+AlfA@public.gmane.org>  wrote:
>
>> On 05/14/2012 06:01 PM, Jeff Layton wrote:
>>> On Mon, 14 May 2012 14:43:06 +0200
>>> VALETTE Eric RD-MAPS-REN<eric2.valette-C0LM0jrOve7QT0dZR+AlfA@public.gmane.org>   wrote:
>>>
>>>> Hi,
>>>>
>>>> Middle of next week, a netapp filer was replaced by a new netapp FAS
>>>> 3270 with 8.1 firmware. While previously I had no problem accessing, all
>>>> the share, now, my log is full of CIFS errors preventing me to access my
>>>> own content:
>>>>
>>>> Mount options:
>>>>
>>>> domain=ZZZZ,credentials=/xxxx/xxxx/.sambaShareId,uid=yyyyy,gid=zzz,iocharset=utf8,noserverino
>>>> 0 0
>>>>
>>>> Is there any known problem with this netapp firmware?
>>>>
>>>> Note that I have other shares on different using different netapp
>>>> machine with older firmware that work like a charm.
>>>>
>>>> -- eric
>>>>
>>>>
>>>>           ________________________________________________________________
>>>> [  315.788485] CIFS VFS: RFC1001 size 248 smaller than SMB for mid=34
>>>> [  315.788493] Bad SMB: : dump of 48 bytes of data at 0xffff880123045c00
>>>> [  315.788501]  f8000000 424d53ff 00000032 80018800 . . . \xfffffff8
>>>> \xffffffff S M B 2 . . . . . . .
>>>> [  315.788508]  00000000 00000000 00000000 19db0040 . . . . . . . . . .
>>>> . . @ . \xffffffdb .
>>>> [  315.788518]  00220800 c400020a 02000000 00003800 . . " . . . .
>>>> \xffffffc4 . . . . . 8 . .
>>>> [  315.791476] CIFS VFS: RFC1001 size 248 smaller than SMB for mid=35
>>>> [  315.791481] Bad SMB: : dump of 48 bytes of data at 0xffff880123045dc0
>>>> [  315.791489]  f8000000 424d53ff 00000032 80018800 . . . \xfffffff8
>>>> \xffffffff S M B 2 . . . . . . .
>>>> [  315.791495]  00000000 00000000 00000000 19db0040 . . . . . . . . . .
>>>> . . @ . \xffffffdb .
>>>> [  315.791502]  00230800 c400020a 02000000 00003800 . . # . . . .
>>>> \xffffffc4 . . . . . 8 . .
>>>> [  315.791577] CIFS VFS: Unexpected lookup error -5
>>>> [  315.794489] CIFS VFS: RFC1001 size 248 smaller than SMB for mid=36
>>>> [  315.794495] Bad SMB: : dump of 48 bytes of data at 0xffff880126a8fb80
>>>> [  315.794503]  f8000000 424d53ff 00000032 80018800 . . . \xfffffff8
>>>> \xffffffff S M B 2 . . . . . . .
>>>> [  315.794510]  00000000 00000000 00000000 19db0040 . . . . . . . . . .
>>>> . . @ . \xffffffdb .
>>>> [  315.794516]  00240800 c400020a 02000000 00003800 . . $ . . . .
>>>> \xffffffc4 . . . . . 8 . .
>>>> [  315.794542] CIFS VFS: Unexpected lookup error -5
>>>> [  315.797494] CIFS VFS: RFC1001 size 248 smaller than SMB for mid=37
>>>> [  315.797500] Bad SMB: : dump of 48 bytes of data at 0xffff8801115c5880
>>>> [  315.797507]  f8000000 424d53ff 00000032 80018800 . . . \xfffffff8
>>>> \xffffffff S M B 2 . . . . . . .
>>>> [  315.797514]  00000000 00000000 00000000 19db0040 . . . . . . . . . .
>>>> . . @ . \xffffffdb .
>>>> [  315.797521]  00250800 c400020a 02000000 00003800 . . % . . . .
>>>> \xffffffc4 . . . . . 8 . .
>>>> [  315.797542] CIFS VFS: Unexpected lookup error -5
>>>>
>>> I'm not sure, but just to confirm -- that's almost certainly an OnTap
>>> bug. Those messages mean that the filer is sending back SMB responses
>>> that have lengths in them that go beyond the end of the frame.
>>>
>>> It's almost certainly a similar problem to that reported here:
>>>
>>>       https://bugzilla.samba.org/show_bug.cgi?id=8914
>>>
>>> In the past, netapp has not shown much interest in interoperating with
>>> clients other than windows. Perhaps though if enough paying customers
>>> complain they'd be willing to fix it.
>>>
>>> I'm also not opposed to sensible workarounds in the client for these
>>> sorts of bugs, as long as they aren't too invasive or risky. At the end
>>> of the day though, these are server side bugs and the real fix for this
>>> problem would have to be done there.
>>>
>> Just too follow my own post: Ontrack 8.1 implements SMB 2.1 and in my
>> traces I see "S M B 2 ". I'm just curious if we do not try to parse
>> SMB2.1 protocol via CIFS and if ontrack has been correctly configured.
>>
>> Anyone capable to test with 8.1 on the list?
>>
> No, it's SMB1. The protocol version header is actually "0xff S M B".
> For SMB2, it would be "0xfe S M B".
>
> The '2' there is from the "Command" field that immediately follows the
> protocol version. The command is SMB_COM_TRANSACTION2, which is 0x32.
> It just happens that the ASCII code for '2' is 0x32.
>
> Cheers,
Thanks for clarification.  Now I'm afraid netapp will drag their feet to 
fix it. Maybe I should require NFS access in the meantime

BTW: I've seen prototype SMB2 support in git tress pushed in october. 
Any plan to submit something upstream?

Thanks for your support,

-- eric

  parent reply	other threads:[~2012-05-14 16:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-14 12:43 Linux 3.2.17 and netapp 8.1 VALETTE Eric RD-MAPS-REN
     [not found] ` <4FB0FDDA.5080604-C0LM0jrOve7QT0dZR+AlfA@public.gmane.org>
2012-05-14 16:01   ` Jeff Layton
     [not found]     ` <20120514120159.2f6de2fa-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2012-05-14 16:06       ` VALETTE Eric RD-MAPS-REN
     [not found]         ` <4FB12D71.3040403-C0LM0jrOve7QT0dZR+AlfA@public.gmane.org>
2012-05-14 16:18           ` Jeff Layton
     [not found]             ` <20120514121824.273198a9-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2012-05-14 16:23               ` VALETTE Eric RD-MAPS-REN [this message]
     [not found]                 ` <4FB13173.1070509-C0LM0jrOve7QT0dZR+AlfA@public.gmane.org>
2012-05-14 17:15                   ` Jeff Layton
     [not found]                     ` <20120514131559.7ca0cdc4-4QP7MXygkU+dMjc06nkz3ljfA9RmPOcC@public.gmane.org>
2012-05-14 19:04                       ` Don Gray
2012-05-15  7:20                       ` VALETTE Eric RD-MAPS-REN
     [not found]                         ` <4FB203AE.3020408-C0LM0jrOve7QT0dZR+AlfA@public.gmane.org>
2012-05-15 13:09                           ` Jeff Layton
     [not found]                             ` <20120515090907.39197340-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2012-05-15 13:29                               ` VALETTE Eric RD-MAPS-REN
2012-05-15 13:45                               ` Suresh Jayaraman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FB13173.1070509@orange.com \
    --to=eric2.valette-c0lm0jrove7qt0dzr+alfa@public.gmane.org \
    --cc=jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org \
    --cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox