Share mounts in SMBv1 mode, but fails to mount in SMBv2 mode

Share mounts in SMBv1 mode, but fails to mount in SMBv2 mode

[Hadrien Grasland]

Dear CIFS VFS maintainers,

At work, I'm currently mounting our CIFS shares in SMBv1 mode, and it 
works perfectly. But for security reasons, our friendly sysadmins would 
like to drop support for that protocol version in the medium term. So 
I'm trying to mount our network shares in SMBv2 mode instead, which 
hopefully should have just been a matter of adjusting the fstab.

Unfortunately, the mount fails instead, in a way that someone who is not 
a CIFS/kernel specialist cannot easily understand. Can you help me 
figure out what is going on, and hopefully fix this?

hadrien@linux-2ak3:~> uname -r
4.13.5-1-default
hadrien@linux-2ak3:~> /sbin/mount.cifs -V
mount.cifs version: 6.5
hadrien@linux-2ak3:~> sudo mount -v -t cifs //nfsserv22/expsi test -o credentials=<path to credentials file>,vers=2.0
domain=LAL
mount.cifs kernel mount options: ip=134.158.91.155,unc=\\nfsserv22\expsi,vers=2.0,user=grasland,,domain=LAL,pass=********
mount error(95): Operation not supported
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
hadrien@linux-2ak3:~> dmesg | tail
(...)
[ 1553.195516] Status code returned 0xc0000016 STATUS_MORE_PROCESSING_REQUIRED
[ 1553.227109] Status code returned 0xc0000225 STATUS_NOT_FOUND
[ 1553.227118] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2
[ 1553.240200] Status code returned 0xc00000bb STATUS_NOT_SUPPORTED
[ 1553.246179] Status code returned 0xc00000bb STATUS_NOT_SUPPORTED
[ 1553.246824] CIFS VFS: cifs_read_super: get root inode failed

I can also provide a wireshark capture of the client-server traffic or 
ask for details of server configuration if you need that. For the later, 
please keep in mind that I'm a total CIFS newbie and be specific about 
what you want to know.

Cheers,
Hadrien Gasaldn

Re: Share mounts in SMBv1 mode, but fails to mount in SMBv2 mode

[Aurélien Aptel]

Hadrien Grasland <grasland-dJj/bURytuEtnUBFBimtzg@public.gmane.org> writes:
> I can also provide a wireshark capture of the client-server traffic or 
> ask for details of server configuration if you need that. For the later, 
> please keep in mind that I'm a total CIFS newbie and be specific about 
> what you want to know.

Yes this would be helpful.

    # make the kernel as verbose as possible
    echo 'module cifs +p' > /sys/kernel/debug/dynamic_debug/control
    echo 'file fs/cifs/* +p' > /sys/kernel/debug/dynamic_debug/control
    echo 1 > /proc/fs/cifs/cifsFYI
    echo 1 > /sys/module/dns_resolver/parameters/debug

    # get kernel output + network trace
    dmesg --clear
    tcpdump -w trace.pcap & pid=$!
    sleep 3
    mount.cifs ....cd ... ls.. blahblah
    sleep 3
    kill $pid
    dmesg > trace.log

this should produce a trace.pcap and trace.log file.

If the server is a samba server, the /etc/samba/smb.conf would be
helpful.

Cheers,

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: Share mounts in SMBv1 mode, but fails to mount in SMBv2 mode

[Hadrien Grasland]

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]


Le 16/10/2017 à 12:11, Aurélien Aptel a écrit :
> Hadrien Grasland <grasland-dJj/bURytuEtnUBFBimtzg@public.gmane.org> writes:
>> I can also provide a wireshark capture of the client-server traffic or
>> ask for details of server configuration if you need that. For the later,
>> please keep in mind that I'm a total CIFS newbie and be specific about
>> what you want to know.
> Yes this would be helpful.
>
>      # make the kernel as verbose as possible
>      echo 'module cifs +p' > /sys/kernel/debug/dynamic_debug/control
>      echo 'file fs/cifs/* +p' > /sys/kernel/debug/dynamic_debug/control
>      echo 1 > /proc/fs/cifs/cifsFYI
>      echo 1 > /sys/module/dns_resolver/parameters/debug
>
>      # get kernel output + network trace
>      dmesg --clear
>      tcpdump -w trace.pcap & pid=$!
>      sleep 3
>      mount.cifs ....cd ... ls.. blahblah
>      sleep 3
>      kill $pid
>      dmesg > trace.log
>
> this should produce a trace.pcap and trace.log file.
>
> If the server is a samba server, the /etc/samba/smb.conf would be
> helpful.

Output enclosed. Since a quick look suggests that all interesting 
traffic is on port 445, I added a "port 445" rule to tcpdump in order to 
reduce noise and keep unrelated local network traffic private, hope 
that's fine.

I'm going to ask whether the server is samba-based or not, and if so 
I'll try to have a look at the smb.conf file.

Cheers,
Hadrien



[-- Attachment #2: trace.log --]
[-- Type: text/x-log, Size: 10802 bytes --]

[16483.016147] device enp0s25 entered promiscuous mode
[16483.292154] ../fs/cifs/cifssmb.c: In echo request
[16483.292161] ../fs/cifs/transport.c: For smb_command 43
[16483.292164] __smb_send_rqst: 12 callbacks suppressed
[16483.292166] ../fs/cifs/transport.c: Sending smb: smb_len=38
[16483.292777] cifs_demultiplex_thread: 12 callbacks suppressed
[16483.292780] ../fs/cifs/connect.c: RFC1002 header 0x26
[16483.292786] ../fs/cifs/misc.c: checkSMB Length: 0x2a, smb_buf_length: 0x26
[16491.674256] ../fs/cifs/cifsfs.c: Devname: //nfsserv22/expsi flags: 0
[16491.674288] ../fs/cifs/connect.c: Domain name set
[16491.674294] ../fs/cifs/connect.c: Username: grasland
[16491.674298] ../fs/cifs/connect.c: file mode: 0x1ed  dir mode: 0x1ed
[16491.674301] ../fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 2938 with uid: 0
[16491.674303] ../fs/cifs/connect.c: UNC: \\nfsserv22\expsi
[16491.674316] ../fs/cifs/connect.c: Socket created
[16491.674319] ../fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x6d6
[16491.679054] ../fs/cifs/connect.c: Demultiplex PID: 8864
[16491.679058] ../fs/cifs/fscache.c: cifs_fscache_get_client_cookie: (0xffff98f2827d2000/0xffff98f2d1355730)
[16491.679063] ../fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 2939 with uid: 0
[16491.679065] ../fs/cifs/connect.c: Existing smb sess not found
[16491.679070] ../fs/cifs/smb2pdu.c: Negotiate protocol
[16491.679078] ../fs/cifs/transport.c: Sending smb: smb_len=102
[16491.681046] ../fs/cifs/connect.c: RFC1002 header 0xd3
[16491.681052] smb2_check_message: 12 callbacks suppressed
[16491.681054] ../fs/cifs/smb2misc.c: smb2_check_message length: 0xd7, smb_buf_length: 0xd3
[16491.681056] smb2_calc_size: 3 callbacks suppressed
[16491.681058] ../fs/cifs/smb2misc.c: SMB2 data length 83 offset 128
[16491.681059] smb2_calc_size: 12 callbacks suppressed
[16491.681060] ../fs/cifs/smb2misc.c: SMB2 len 215
[16491.681080] cifs_sync_mid_result: 12 callbacks suppressed
[16491.681085] ../fs/cifs/transport.c: cifs_sync_mid_result: cmd=0 mid=0 state=4
[16491.681088] cifs_small_buf_release: 10 callbacks suppressed
[16491.681090] ../fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[16491.681095] ../fs/cifs/smb2pdu.c: mode 0x1
[16491.681097] ../fs/cifs/smb2pdu.c: negotiated smb2.0 dialect
[16491.681105] ../fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
[16491.681109] ../fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
[16491.681112] ../fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
[16491.681116] ../fs/cifs/connect.c: Security Mode: 0x1 Capabilities: 0x300001 TimeAdjust: 0
[16491.681118] ../fs/cifs/smb2pdu.c: Session Setup
[16491.681120] ../fs/cifs/smb2pdu.c: sess setup type 4
[16491.681124] ../fs/cifs/transport.c: Sending smb: smb_len=120
[16491.681734] ../fs/cifs/connect.c: RFC1002 header 0xee
[16491.681740] ../fs/cifs/smb2misc.c: smb2_check_message length: 0xf2, smb_buf_length: 0xee
[16491.681743] ../fs/cifs/smb2misc.c: SMB2 data length 166 offset 72
[16491.681744] ../fs/cifs/smb2misc.c: SMB2 len 242
[16491.681781] ../fs/cifs/transport.c: cifs_sync_mid_result: cmd=1 mid=1 state=4
[16491.681787] ../fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc0000016 to POSIX err -5
[16491.681788] ../fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[16491.681792] ../fs/cifs/smb2pdu.c: rawntlmssp session setup challenge phase
[16491.681841] ../fs/cifs/transport.c: Sending smb: smb_len=348
[16491.697275] ../fs/cifs/connect.c: RFC1002 header 0x48
[16491.697281] ../fs/cifs/smb2misc.c: smb2_check_message length: 0x4c, smb_buf_length: 0x48
[16491.697283] ../fs/cifs/smb2misc.c: SMB2 data length 0 offset 72
[16491.697285] ../fs/cifs/smb2misc.c: SMB2 len 77
[16491.697287] ../fs/cifs/smb2misc.c: Calculated size 77 length 76 mismatch mid 2
[16491.697322] ../fs/cifs/transport.c: cifs_sync_mid_result: cmd=1 mid=2 state=4
[16491.697325] ../fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[16491.697329] ../fs/cifs/smb2pdu.c: SMB2/3 session established successfully
[16491.697333] ../fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 2939) rc = 0
[16491.697338] ../fs/cifs/connect.c: CIFS VFS: in cifs_get_tcon as Xid: 2940 with uid: 0
[16491.697339] ../fs/cifs/smb2pdu.c: TCON
[16491.697343] ../fs/cifs/transport.c: Sending smb: smb_len=108
[16491.698001] ../fs/cifs/connect.c: RFC1002 header 0x50
[16491.698007] ../fs/cifs/smb2misc.c: smb2_check_message length: 0x54, smb_buf_length: 0x50
[16491.698009] ../fs/cifs/smb2misc.c: SMB2 len 84
[16491.698044] ../fs/cifs/transport.c: cifs_sync_mid_result: cmd=3 mid=3 state=4
[16491.698047] ../fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[16491.698051] ../fs/cifs/smb2pdu.c: connection to disk share
[16491.698054] ../fs/cifs/connect.c: CIFS VFS: leaving cifs_get_tcon (xid = 2940) rc = 0
[16491.698055] ../fs/cifs/connect.c: Tcon rc = 0
[16491.698060] ../fs/cifs/fscache.c: cifs_fscache_get_super_cookie: (0xffff98f2d1355730/0xffff98f2d1355c30)
[16491.698062] ../fs/cifs/smb2pdu.c: create/open
[16491.698066] ../fs/cifs/transport.c: Sending smb: smb_len=128
[16491.698763] ../fs/cifs/connect.c: RFC1002 header 0x98
[16491.698768] ../fs/cifs/smb2misc.c: smb2_check_message length: 0x9c, smb_buf_length: 0x98
[16491.698770] ../fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[16491.698772] ../fs/cifs/smb2misc.c: SMB2 len 157
[16491.698774] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 4
[16491.698809] ../fs/cifs/transport.c: cifs_sync_mid_result: cmd=5 mid=4 state=4
[16491.698812] ../fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[16491.698817] ../fs/cifs/smb2pdu.c: Query FSInfo level 5
[16491.698820] ../fs/cifs/transport.c: Sending smb: smb_len=105
[16491.699452] ../fs/cifs/connect.c: RFC1002 header 0x5c
[16491.699458] ../fs/cifs/smb2misc.c: smb2_check_message length: 0x60, smb_buf_length: 0x5c
[16491.699460] ../fs/cifs/smb2misc.c: SMB2 data length 20 offset 72
[16491.699461] ../fs/cifs/smb2misc.c: SMB2 len 96
[16491.699497] ../fs/cifs/transport.c: cifs_sync_mid_result: cmd=16 mid=5 state=4
[16491.699500] ../fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[16491.699504] ../fs/cifs/smb2pdu.c: Query FSInfo level 4
[16491.699508] ../fs/cifs/transport.c: Sending smb: smb_len=105
[16491.700059] ../fs/cifs/connect.c: RFC1002 header 0x50
[16491.700062] ../fs/cifs/smb2misc.c: smb2_check_message length: 0x54, smb_buf_length: 0x50
[16491.700064] ../fs/cifs/smb2misc.c: SMB2 data length 8 offset 72
[16491.700065] ../fs/cifs/smb2misc.c: SMB2 len 84
[16491.700097] ../fs/cifs/transport.c: cifs_sync_mid_result: cmd=16 mid=6 state=4
[16491.700100] ../fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[16491.700103] ../fs/cifs/smb2pdu.c: Close
[16491.700106] ../fs/cifs/transport.c: Sending smb: smb_len=88
[16491.700695] ../fs/cifs/connect.c: RFC1002 header 0x7c
[16491.700700] ../fs/cifs/smb2misc.c: smb2_check_message length: 0x80, smb_buf_length: 0x7c
[16491.700702] ../fs/cifs/smb2misc.c: SMB2 len 128
[16491.700741] ../fs/cifs/transport.c: cifs_sync_mid_result: cmd=6 mid=7 state=4
[16491.700745] ../fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[16491.700751] ../fs/cifs/connect.c: build_unc_path_to_root: full_path=\\nfsserv22\expsi
[16491.700753] ../fs/cifs/smb2pdu.c: TCON
[16491.700757] ../fs/cifs/transport.c: Sending smb: smb_len=116
[16491.701397] ../fs/cifs/connect.c: RFC1002 header 0x50
[16491.701403] ../fs/cifs/smb2misc.c: smb2_check_message length: 0x54, smb_buf_length: 0x50
[16491.701405] ../fs/cifs/smb2misc.c: SMB2 len 84
[16491.701443] ../fs/cifs/transport.c: cifs_sync_mid_result: cmd=3 mid=8 state=4
[16491.701447] ../fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[16491.701451] ../fs/cifs/connect.c: Tcon rc = 0 ipc_tid = 65
[16491.701453] ../fs/cifs/smb2ops.c: smb2_get_dfs_refer path <\nfsserv22\expsi>
[16491.701457] ../fs/cifs/smb2pdu.c: SMB2 IOCTL
[16491.701460] ../fs/cifs/smb2pdu.c: replacing tid 0x40 with IPC tid 0x41
[16491.701463] ../fs/cifs/transport.c: Sending smb: smb_len=156
[16491.702055] ../fs/cifs/connect.c: RFC1002 header 0x49
[16491.702062] ../fs/cifs/smb2misc.c: smb2_check_message length: 0x4d, smb_buf_length: 0x49
[16491.702067] ../fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[16491.702069] ../fs/cifs/smb2misc.c: SMB2 len 77
[16491.702106] ../fs/cifs/transport.c: cifs_sync_mid_result: cmd=11 mid=9 state=4
[16491.702113] ../fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc0000225 to POSIX err -2
[16491.702115] ../fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[16491.702119] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2
[16491.702126] ../fs/cifs/smb2pdu.c: create/open
[16491.702771] ../fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[16491.702774] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 10
[16491.702814] ../fs/cifs/smb2pdu.c: Close
[16491.703473] ../fs/cifs/smb2pdu.c: create/open
[16491.704114] ../fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[16491.704117] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 12
[16491.704130] ../fs/cifs/smb2pdu.c: Close
[16491.704785] ../fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 2938) rc = 0
[16491.704895] ../fs/cifs/inode.c: CIFS VFS: in cifs_root_iget as Xid: 2941 with uid: 0
[16491.704897] ../fs/cifs/inode.c: Getting info on 
[16491.704904] ../fs/cifs/smb2pdu.c: create/open
[16491.705550] ../fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[16491.705553] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 14
[16491.705593] ../fs/cifs/smb2pdu.c: Query Info
[16491.706223] ../fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc00000bb to POSIX err -95
[16491.706228] ../fs/cifs/smb2pdu.c: Close
[16491.706861] ../fs/cifs/smb2pdu.c: create/open
[16491.707476] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 17
[16491.707514] ../fs/cifs/smb2pdu.c: Query Info
[16491.708101] ../fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc00000bb to POSIX err -95
[16491.708106] ../fs/cifs/smb2pdu.c: Close
[16491.708752] CIFS VFS: cifs_read_super: get root inode failed
[16491.724234] ../fs/cifs/connect.c: cifs_put_tcon: tc_count=1
[16491.724238] ../fs/cifs/connect.c: CIFS VFS: in cifs_put_tcon as Xid: 2942 with uid: 0
[16491.724239] ../fs/cifs/smb2pdu.c: Tree Disconnect
[16491.724581] ../fs/cifs/fscache.c: cifs_fscache_release_super_cookie: (0xffff98f2d1355c30)
[16491.724586] ../fs/cifs/connect.c: cifs_put_smb_ses: ses_count=1
[16491.724588] ../fs/cifs/connect.c: CIFS VFS: in cifs_put_smb_ses as Xid: 2943 with uid: 0
[16491.724590] ../fs/cifs/smb2pdu.c: disconnect session ffff98f32b761400
[16491.725182] ../fs/cifs/fscache.c: cifs_fscache_release_client_cookie: (0xffff98f2827d2000/0xffff98f2d1355730)
[16498.749502] device enp0s25 left promiscuous mode

[-- Attachment #3: trace.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 9982 bytes --]

Re: Share mounts in SMBv1 mode, but fails to mount in SMBv2 mode

[Aurélien Aptel]

Hadrien Grasland <grasland-dJj/bURytuEtnUBFBimtzg@public.gmane.org> writes:
>> If the server is a samba server, the /etc/samba/smb.conf would be
>> helpful.
>
> Output enclosed. Since a quick look suggests that all interesting 
> traffic is on port 445, I added a "port 445" rule to tcpdump in order to 
> reduce noise and keep unrelated local network traffic private, hope 
> that's fine.

When kerberos or DNS is involved it's always nice to see those too but
here I think it's fine with just SMB.

> I'm going to ask whether the server is samba-based or not, and if so 
> I'll try to have a look at the smb.conf file.

Great.

> [16491.702119] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2

cifs.ko always does a DFS referal when mounting because some server
don't report DFS roots properly (Windows Server 2008, supposedly). Any
errors at this step are ignored so this is not the problem.

The actual issue is when we try to create the root inode of the fs. To
create a linux inode we need the file metadata from the SMB server. This
is done via a QUERY INFO requests which has a field to specify how much
metadata you need. cifs.ko always require the AllInfo level.

> [16491.704895] ../fs/cifs/inode.c: CIFS VFS: in cifs_root_iget as Xid: 2941 with uid: 0
> [16491.704897] ../fs/cifs/inode.c: Getting info on 
> [16491.704904] ../fs/cifs/smb2pdu.c: create/open
> [16491.705550] ../fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
> [16491.705553] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 14
> [16491.705593] ../fs/cifs/smb2pdu.c: Query Info
> [16491.706223] ../fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc00000bb to POSIX err -95
> [16491.706228] ../fs/cifs/smb2pdu.c: Close
> [16491.706861] ../fs/cifs/smb2pdu.c: create/open
> [16491.707476] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 17
> [16491.707514] ../fs/cifs/smb2pdu.c: Query Info
> [16491.708101] ../fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc00000bb to POSIX err -95
> [16491.708106] ../fs/cifs/smb2pdu.c: Close
> [16491.708752] CIFS VFS: cifs_read_super: get root inode failed

Call tree for this output is

cifs_read_super
  cifs_root_iget
    cifs_get_inode_info
      ops->query_path_info (smb2_query_path_info)


This function does the 2 query info requests:

>	rc = smb2_open_op_close(xid, tcon, cifs_sb, full_path,
>				FILE_READ_ATTRIBUTES, FILE_OPEN, 0,
>				smb2_data, SMB2_OP_QUERY_INFO);
>	if (rc == -EOPNOTSUPP) {
>		*symlink = true;
>		/* Failed on a symbolic link - query a reparse point info */
>		rc = smb2_open_op_close(xid, tcon, cifs_sb, full_path,
>					FILE_READ_ATTRIBUTES, FILE_OPEN,
>					OPEN_REPARSE_POINT, smb2_data,
>					SMB2_OP_QUERY_INFO);
>	}
>	if (rc)
>		goto out;

Looking at the trace the query info level used is FILE_ALL_INFORMATION
(0x12) and both fail with STATUS_NOT_SUPPORTED (frame #38,#39 and
#44,#45).

Regarding query info requests [MS-SMB2] 3.3.5.20.1 "Handling
SMB2_0_INFO_FILE" reads:

> Requests for information classes that are not listed in section 2.2.37
> but which are documented in section 2.4 of [MS-FSCC] SHOULD<351> be
> failed with STATUS_NOT_SUPPORTED.

AllInfo is listed in 2.2.37 so this is not it.

> The server MUST query the information requested from the underlying
> object store.<354> If the store does not support the data requested,
> the server MUST fail the request with STATUS_NOT_SUPPORTED.

This is the more likely explanation so far. This would mean "the
underlying filesystem on the server doesnt store all the fields the ALL
INFO level requires".

There was another query done by cifs.ko on the server FS info (frame #18
#19) which reported it as NTFS, which should support all the fields so
this doesn't make sense... Let's look at the wireshark trace more
closely.

Wireshark is a bit confused by some of the query info request fields:

>    GetInfo Request (0x10)
>        StructureSize: 0x0029
>            0000 0000 0010 100. = Fixed Part Length: 20
>            .... .... .... ...1 = Dynamic Part: True
>        Class: FILE_INFO (0x01)
>        InfoLevel: SMB2_FILE_ALL_INFO (0x12)
>        Max Response Size: 8293
>        unknown: 68000000000000000000000000000000
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ what's this?
>        GUID handle File: [unknown]
>            File Id: 002b8237-0000-0000-0500-000000000000
>            [Frame handle opened: 37]

The "[unknown]" part is ok, because we're querying the root of the
share, which is the empty filename ("").

Let's see what the unknown *field* corresponds to by reading the
specs. This could just be a wireshark issue as this code works against
other SMB servers just fine.

68 00        "InputBufferOffset"     (hmm.. see next)
00 00        "Reserved"              (specs says it must be zeros, ok)
00 00 00 00  "InputBufferLength"     (hmm.. actual buffer length is 1 but
                                      saying its zero in the packet
                                      might explain why it's working on
                                      others servers?)
00 00 00 00  "AdditionalInformation" (for security info queries, ok)
00 00 00 00  "Flags"                 (for EA info queries, ok)

> InputBufferOffset (2 bytes): The offset, in bytes, from the beginning
> of the SMB2 header to the input buffer. For quota requests, the input
> buffer MUST contain an SMB2_QUERY_QUOTA_INFO, as specified in section
> 2.2.37.1. For FileFullEaInformation requests, the input buffer MUST
> contain the user supplied EA list with zero or more
> FILE_GET_EA_INFORMATION structures, specified in [MS-FSCC] section
> 2.4.15.1. For other information queries, this field SHOULD<69> be set
> to 0.

InputBufferOffset is an offset from the start of the smb2 header so
that's 0x46 + 0x68 = 0xAE which points to the very last byte of the
packet, a NULL byte. This doesn't seem right. The specs clearly says the
offset must either be pointing to a proper {SMB2_QUERY_QUOTE_INFO,
FILE_GET_EA_INFO} struct or be null.

This also explains the length mismatch warning in the kernel console:

> [16491.707476] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 17

I'll try to write a patch for this so you can test it.

Cheers,

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: Share mounts in SMBv1 mode, but fails to mount in SMBv2 mode

[Hadrien Grasland]

Le 16/10/2017 à 16:51, Aurélien Aptel a écrit :
> Hadrien Grasland <grasland-dJj/bURytuEtnUBFBimtzg@public.gmane.org> writes:
>>> If the server is a samba server, the /etc/samba/smb.conf would be
>>> helpful.
>> Output enclosed. Since a quick look suggests that all interesting
>> traffic is on port 445, I added a "port 445" rule to tcpdump in order to
>> reduce noise and keep unrelated local network traffic private, hope
>> that's fine.
> When kerberos or DNS is involved it's always nice to see those too but
> here I think it's fine with just SMB.
>
>> I'm going to ask whether the server is samba-based or not, and if so
>> I'll try to have a look at the smb.conf file.
> Great.
>
>> [16491.702119] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2
> cifs.ko always does a DFS referal when mounting because some server
> don't report DFS roots properly (Windows Server 2008, supposedly). Any
> errors at this step are ignored so this is not the problem.
>
> The actual issue is when we try to create the root inode of the fs. To
> create a linux inode we need the file metadata from the SMB server. This
> is done via a QUERY INFO requests which has a field to specify how much
> metadata you need. cifs.ko always require the AllInfo level.
>
>> [16491.704895] ../fs/cifs/inode.c: CIFS VFS: in cifs_root_iget as Xid: 2941 with uid: 0
>> [16491.704897] ../fs/cifs/inode.c: Getting info on
>> [16491.704904] ../fs/cifs/smb2pdu.c: create/open
>> [16491.705550] ../fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
>> [16491.705553] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 14
>> [16491.705593] ../fs/cifs/smb2pdu.c: Query Info
>> [16491.706223] ../fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc00000bb to POSIX err -95
>> [16491.706228] ../fs/cifs/smb2pdu.c: Close
>> [16491.706861] ../fs/cifs/smb2pdu.c: create/open
>> [16491.707476] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 17
>> [16491.707514] ../fs/cifs/smb2pdu.c: Query Info
>> [16491.708101] ../fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc00000bb to POSIX err -95
>> [16491.708106] ../fs/cifs/smb2pdu.c: Close
>> [16491.708752] CIFS VFS: cifs_read_super: get root inode failed
> Call tree for this output is
>
> cifs_read_super
>    cifs_root_iget
>      cifs_get_inode_info
>        ops->query_path_info (smb2_query_path_info)
>
>
> This function does the 2 query info requests:
>
>> 	rc = smb2_open_op_close(xid, tcon, cifs_sb, full_path,
>> 				FILE_READ_ATTRIBUTES, FILE_OPEN, 0,
>> 				smb2_data, SMB2_OP_QUERY_INFO);
>> 	if (rc == -EOPNOTSUPP) {
>> 		*symlink = true;
>> 		/* Failed on a symbolic link - query a reparse point info */
>> 		rc = smb2_open_op_close(xid, tcon, cifs_sb, full_path,
>> 					FILE_READ_ATTRIBUTES, FILE_OPEN,
>> 					OPEN_REPARSE_POINT, smb2_data,
>> 					SMB2_OP_QUERY_INFO);
>> 	}
>> 	if (rc)
>> 		goto out;
> Looking at the trace the query info level used is FILE_ALL_INFORMATION
> (0x12) and both fail with STATUS_NOT_SUPPORTED (frame #38,#39 and
> #44,#45).
>
> Regarding query info requests [MS-SMB2] 3.3.5.20.1 "Handling
> SMB2_0_INFO_FILE" reads:
>
>> Requests for information classes that are not listed in section 2.2.37
>> but which are documented in section 2.4 of [MS-FSCC] SHOULD<351> be
>> failed with STATUS_NOT_SUPPORTED.
> AllInfo is listed in 2.2.37 so this is not it.
>
>> The server MUST query the information requested from the underlying
>> object store.<354> If the store does not support the data requested,
>> the server MUST fail the request with STATUS_NOT_SUPPORTED.
> This is the more likely explanation so far. This would mean "the
> underlying filesystem on the server doesnt store all the fields the ALL
> INFO level requires".
>
> There was another query done by cifs.ko on the server FS info (frame #18
> #19) which reported it as NTFS, which should support all the fields so
> this doesn't make sense... Let's look at the wireshark trace more
> closely.
>
> Wireshark is a bit confused by some of the query info request fields:
>
>>     GetInfo Request (0x10)
>>         StructureSize: 0x0029
>>             0000 0000 0010 100. = Fixed Part Length: 20
>>             .... .... .... ...1 = Dynamic Part: True
>>         Class: FILE_INFO (0x01)
>>         InfoLevel: SMB2_FILE_ALL_INFO (0x12)
>>         Max Response Size: 8293
>>         unknown: 68000000000000000000000000000000
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ what's this?
>>         GUID handle File: [unknown]
>>             File Id: 002b8237-0000-0000-0500-000000000000
>>             [Frame handle opened: 37]
> The "[unknown]" part is ok, because we're querying the root of the
> share, which is the empty filename ("").
>
> Let's see what the unknown *field* corresponds to by reading the
> specs. This could just be a wireshark issue as this code works against
> other SMB servers just fine.
>
> 68 00        "InputBufferOffset"     (hmm.. see next)
> 00 00        "Reserved"              (specs says it must be zeros, ok)
> 00 00 00 00  "InputBufferLength"     (hmm.. actual buffer length is 1 but
>                                        saying its zero in the packet
>                                        might explain why it's working on
>                                        others servers?)
> 00 00 00 00  "AdditionalInformation" (for security info queries, ok)
> 00 00 00 00  "Flags"                 (for EA info queries, ok)
>
>> InputBufferOffset (2 bytes): The offset, in bytes, from the beginning
>> of the SMB2 header to the input buffer. For quota requests, the input
>> buffer MUST contain an SMB2_QUERY_QUOTA_INFO, as specified in section
>> 2.2.37.1. For FileFullEaInformation requests, the input buffer MUST
>> contain the user supplied EA list with zero or more
>> FILE_GET_EA_INFORMATION structures, specified in [MS-FSCC] section
>> 2.4.15.1. For other information queries, this field SHOULD<69> be set
>> to 0.
> InputBufferOffset is an offset from the start of the smb2 header so
> that's 0x46 + 0x68 = 0xAE which points to the very last byte of the
> packet, a NULL byte. This doesn't seem right. The specs clearly says the
> offset must either be pointing to a proper {SMB2_QUERY_QUOTE_INFO,
> FILE_GET_EA_INFO} struct or be null.
>
> This also explains the length mismatch warning in the kernel console:
>
>> [16491.707476] ../fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 17
> I'll try to write a patch for this so you can test it.

Thanks for the investigation and clear explanations! :)

I've never patched a kernel module before, but I assume it should 
involve something like getting a copy of my kernel's sources, applying 
the patch, rebuilding the relevant module, unloading the old module and 
putting the new one in its place, right?

Re: Share mounts in SMBv1 mode, but fails to mount in SMBv2 mode

[Steve French]

On Mon, Oct 16, 2017 at 11:05 AM, Hadrien Grasland
<grasland-dJj/bURytuEtnUBFBimtzg@public.gmane.org> wrote:
> Le 16/10/2017 à 16:51, Aurélien Aptel a écrit :
>>
>> Hadrien Grasland <grasland-dJj/bURytuEtnUBFBimtzg@public.gmane.org> writes:
>>>>
>>>> If the server is a samba server, the /etc/samba/smb.conf would be
>>>> helpful.
>>>
>>> Output enclosed. Since a quick look suggests that all interesting
>>> traffic is on port 445, I added a "port 445" rule to tcpdump in order to
>>> reduce noise and keep unrelated local network traffic private, hope
>>> that's fine.
>>
>> When kerberos or DNS is involved it's always nice to see those too but
>> here I think it's fine with just SMB.
>>
>>> I'm going to ask whether the server is samba-based or not, and if so
>>> I'll try to have a look at the smb.conf file.
>>
>> Great.
>>
>>> [16491.702119] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2
>>
>> cifs.ko always does a DFS referal when mounting because some server
>> don't report DFS roots properly (Windows Server 2008, supposedly). Any
>> errors at this step are ignored so this is not the problem.
>>
>> The actual issue is when we try to create the root inode of the fs. To
>> create a linux inode we need the file metadata from the SMB server. This
>> is done via a QUERY INFO requests which has a field to specify how much
>> metadata you need. cifs.ko always require the AllInfo level.
>>
>>> [16491.704895] ../fs/cifs/inode.c: CIFS VFS: in cifs_root_iget as Xid:
>>> 2941 with uid: 0
>>> [16491.704897] ../fs/cifs/inode.c: Getting info on
>>> [16491.704904] ../fs/cifs/smb2pdu.c: create/open
>>> [16491.705550] ../fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
>>> [16491.705553] ../fs/cifs/smb2misc.c: Calculated size 157 length 156
>>> mismatch mid 14
>>> [16491.705593] ../fs/cifs/smb2pdu.c: Query Info
>>> [16491.706223] ../fs/cifs/smb2maperror.c: Mapping SMB2 status code
>>> 0xc00000bb to POSIX err -95
>>> [16491.706228] ../fs/cifs/smb2pdu.c: Close
>>> [16491.706861] ../fs/cifs/smb2pdu.c: create/open
>>> [16491.707476] ../fs/cifs/smb2misc.c: Calculated size 157 length 156
>>> mismatch mid 17
>>> [16491.707514] ../fs/cifs/smb2pdu.c: Query Info
>>> [16491.708101] ../fs/cifs/smb2maperror.c: Mapping SMB2 status code
>>> 0xc00000bb to POSIX err -95
>>> [16491.708106] ../fs/cifs/smb2pdu.c: Close
>>> [16491.708752] CIFS VFS: cifs_read_super: get root inode failed
>>
>> Call tree for this output is
>>
>> cifs_read_super
>>    cifs_root_iget
>>      cifs_get_inode_info
>>        ops->query_path_info (smb2_query_path_info)
>>
>>
>> This function does the 2 query info requests:
>>
>>>         rc = smb2_open_op_close(xid, tcon, cifs_sb, full_path,
>>>                                 FILE_READ_ATTRIBUTES, FILE_OPEN, 0,
>>>                                 smb2_data, SMB2_OP_QUERY_INFO);
>>>         if (rc == -EOPNOTSUPP) {
>>>                 *symlink = true;
>>>                 /* Failed on a symbolic link - query a reparse point info
>>> */
>>>                 rc = smb2_open_op_close(xid, tcon, cifs_sb, full_path,
>>>                                         FILE_READ_ATTRIBUTES, FILE_OPEN,
>>>                                         OPEN_REPARSE_POINT, smb2_data,
>>>                                         SMB2_OP_QUERY_INFO);
>>>         }
>>>         if (rc)
>>>                 goto out;
>>
>> Looking at the trace the query info level used is FILE_ALL_INFORMATION
>> (0x12) and both fail with STATUS_NOT_SUPPORTED (frame #38,#39 and
>> #44,#45).
>>
>> Regarding query info requests [MS-SMB2] 3.3.5.20.1 "Handling
>> SMB2_0_INFO_FILE" reads:
>>
>>> Requests for information classes that are not listed in section 2.2.37
>>> but which are documented in section 2.4 of [MS-FSCC] SHOULD<351> be
>>> failed with STATUS_NOT_SUPPORTED.
>>
>> AllInfo is listed in 2.2.37 so this is not it.
>>
>>> The server MUST query the information requested from the underlying
>>> object store.<354> If the store does not support the data requested,
>>> the server MUST fail the request with STATUS_NOT_SUPPORTED.
>>
>> This is the more likely explanation so far. This would mean "the
>> underlying filesystem on the server doesnt store all the fields the ALL
>> INFO level requires".
>>
>> There was another query done by cifs.ko on the server FS info (frame #18
>> #19) which reported it as NTFS, which should support all the fields so
>> this doesn't make sense... Let's look at the wireshark trace more
>> closely.
>>
>> Wireshark is a bit confused by some of the query info request fields:
>>
>>>     GetInfo Request (0x10)
>>>         StructureSize: 0x0029
>>>             0000 0000 0010 100. = Fixed Part Length: 20
>>>             .... .... .... ...1 = Dynamic Part: True
>>>         Class: FILE_INFO (0x01)
>>>         InfoLevel: SMB2_FILE_ALL_INFO (0x12)
>>>         Max Response Size: 8293
>>>         unknown: 68000000000000000000000000000000
>>
>>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ what's this?
>>>
>>>         GUID handle File: [unknown]
>>>             File Id: 002b8237-0000-0000-0500-000000000000
>>>             [Frame handle opened: 37]
>>
>> The "[unknown]" part is ok, because we're querying the root of the
>> share, which is the empty filename ("").
>>
>> Let's see what the unknown *field* corresponds to by reading the
>> specs. This could just be a wireshark issue as this code works against
>> other SMB servers just fine.
>>
>> 68 00        "InputBufferOffset"     (hmm.. see next)
>> 00 00        "Reserved"              (specs says it must be zeros, ok)
>> 00 00 00 00  "InputBufferLength"     (hmm.. actual buffer length is 1 but
>>                                        saying its zero in the packet
>>                                        might explain why it's working on
>>                                        others servers?)
>> 00 00 00 00  "AdditionalInformation" (for security info queries, ok)
>> 00 00 00 00  "Flags"                 (for EA info queries, ok)
>>
>>> InputBufferOffset (2 bytes): The offset, in bytes, from the beginning
>>> of the SMB2 header to the input buffer. For quota requests, the input
>>> buffer MUST contain an SMB2_QUERY_QUOTA_INFO, as specified in section
>>> 2.2.37.1. For FileFullEaInformation requests, the input buffer MUST
>>> contain the user supplied EA list with zero or more
>>> FILE_GET_EA_INFORMATION structures, specified in [MS-FSCC] section
>>> 2.4.15.1. For other information queries, this field SHOULD<69> be set
>>> to 0.
>>
>> InputBufferOffset is an offset from the start of the smb2 header so
>> that's 0x46 + 0x68 = 0xAE which points to the very last byte of the
>> packet, a NULL byte. This doesn't seem right. The specs clearly says the
>> offset must either be pointing to a proper {SMB2_QUERY_QUOTE_INFO,
>> FILE_GET_EA_INFO} struct or be null.
>>
>> This also explains the length mismatch warning in the kernel console:
>>
>>> [16491.707476] ../fs/cifs/smb2misc.c: Calculated size 157 length 156
>>> mismatch mid 17
>>
>> I'll try to write a patch for this so you can test it.
>
>
> Thanks for the investigation and clear explanations! :)
>
> I've never patched a kernel module before, but I assume it should involve
> something like getting a copy of my kernel's sources, applying the patch,
> rebuilding the relevant module, unloading the old module and putting the new
> one in its place, right?

Yes.  One option we have is to fall back to a lower, less complete info level
to work around this server bug.


-- 
Thanks,

Steve

Re: Share mounts in SMBv1 mode, but fails to mount in SMBv2 mode

[Aurélien Aptel]

Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> Yes.  One option we have is to fall back to a lower, less complete info level
> to work around this server bug.

Ok

What do you think about the extra null byte and the wrong offset in the
query info request? It definitely looks like an error to me.

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: Share mounts in SMBv1 mode, but fails to mount in SMBv2 mode

[Aurélien Aptel]

Hadrien Grasland <grasland-dJj/bURytuEtnUBFBimtzg@public.gmane.org> writes:
> I've never patched a kernel module before, but I assume it should 
> involve something like getting a copy of my kernel's sources, applying 
> the patch, rebuilding the relevant module, unloading the old module and 
> putting the new one in its place, right?

You can also build the kernel and directly boot the resulting binary in
a qemu vm. You can find many tutorials for this online:

http://ncmiller.github.io/2016/05/14/linux-and-qemu.html
https://www.collabora.com/news-and-blog/blog/2017/01/16/setting-up-qemu-kvm-for-kernel-development/
etc

I'd also suggest using the bridge setup described here so you can access
your host network from the vm transparently.

http://blog.elastocloud.org/2015/07/qemukvm-bridged-network-with-tap.html

Depending on your experience you might find this easier.

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

[PATCH] CIFS: do not send invalid input buffer on QUERY_INFO requests

[Aurelien Aptel]

query_info() doesn't use the InputBuffer field of the QUERY_INFO
request, therefore according to [MS-SMB2] it must:

a) set the InputBufferOffset to 0
b) send a zero-length InputBuffer

Doing a) is trivial but b) is a bit more tricky.

The packet is allocated according to it's StructureSize, which takes
into account an extra 1 byte buffer which we don't need
here. StructureSize fields must have constant values no matter the
actual length of the whole packet so we can't just edit that constant.

Both the NetBIOS-over-TCP message length ("rfc1002 length") L and the
iovec length L' have to be updated. Since L' is computed from L we
just update L by decrementing it by one.

Signed-off-by: Aurelien Aptel <aaptel-IBi9RG/b67k@public.gmane.org>
---
 fs/cifs/smb2pdu.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 6f0e6343c15e..b927e131f997 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -2191,9 +2191,13 @@ query_info(const unsigned int xid, struct cifs_tcon *tcon,
 	req->PersistentFileId = persistent_fid;
 	req->VolatileFileId = volatile_fid;
 	req->AdditionalInformation = cpu_to_le32(additional_info);
-	/* 4 for rfc1002 length field and 1 for Buffer */
-	req->InputBufferOffset =
-		cpu_to_le16(sizeof(struct smb2_query_info_req) - 1 - 4);
+
+	/*
+	 * We do not use the input buffer (do not send extra byte)
+	 */
+	req->InputBufferOffset = 0;
+	inc_rfc1001_len(req, -1);
+
 	req->OutputBufferLength = cpu_to_le32(output_len);
 
 	iov[0].iov_base = (char *)req;
-- 
2.12.3

Re: [PATCH] CIFS: do not send invalid input buffer on QUERY_INFO requests

[Hadrien Grasland]

[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]

Just tried out this patch, and the CIFS module does indeed produce 
well-formed GetInfo requests now (according to Wireshark's definition at 
least, didn't check myself).

However, the server will still reject the request with a 
STATUS_NOT_SUPPORTED error, suggesting that Steve's interpretation was 
the right one: this is likely a server-side bug.

Cheers,
Hadrien


Le 17/10/2017 à 14:47, Aurelien Aptel a écrit :
> query_info() doesn't use the InputBuffer field of the QUERY_INFO
> request, therefore according to [MS-SMB2] it must:
>
> a) set the InputBufferOffset to 0
> b) send a zero-length InputBuffer
>
> Doing a) is trivial but b) is a bit more tricky.
>
> The packet is allocated according to it's StructureSize, which takes
> into account an extra 1 byte buffer which we don't need
> here. StructureSize fields must have constant values no matter the
> actual length of the whole packet so we can't just edit that constant.
>
> Both the NetBIOS-over-TCP message length ("rfc1002 length") L and the
> iovec length L' have to be updated. Since L' is computed from L we
> just update L by decrementing it by one.
>
> Signed-off-by: Aurelien Aptel <aaptel-IBi9RG/b67k@public.gmane.org>
> ---
>   fs/cifs/smb2pdu.c | 10 +++++++---
>   1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 6f0e6343c15e..b927e131f997 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -2191,9 +2191,13 @@ query_info(const unsigned int xid, struct cifs_tcon *tcon,
>   	req->PersistentFileId = persistent_fid;
>   	req->VolatileFileId = volatile_fid;
>   	req->AdditionalInformation = cpu_to_le32(additional_info);
> -	/* 4 for rfc1002 length field and 1 for Buffer */
> -	req->InputBufferOffset =
> -		cpu_to_le16(sizeof(struct smb2_query_info_req) - 1 - 4);
> +
> +	/*
> +	 * We do not use the input buffer (do not send extra byte)
> +	 */
> +	req->InputBufferOffset = 0;
> +	inc_rfc1001_len(req, -1);
> +
>   	req->OutputBufferLength = cpu_to_le32(output_len);
>   
>   	iov[0].iov_base = (char *)req;


[-- Attachment #2: trace.log --]
[-- Type: text/x-log, Size: 9634 bytes --]

[ 1808.856080] device enp0s25 entered promiscuous mode
[ 1815.757524] fs/cifs/cifsfs.c: Devname: //nfsserv22/expsi flags: 0
[ 1815.757565] fs/cifs/connect.c: Domain name set
[ 1815.757571] fs/cifs/connect.c: Username: grasland
[ 1815.757575] fs/cifs/connect.c: file mode: 0x1ed  dir mode: 0x1ed
[ 1815.757578] fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 6 with uid: 0
[ 1815.757580] fs/cifs/connect.c: UNC: \\nfsserv22\expsi
[ 1815.757594] fs/cifs/connect.c: Socket created
[ 1815.757596] fs/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x6d6
[ 1815.758284] fs/cifs/fscache.c: cifs_fscache_get_client_cookie: (0xffff883a2bbf8000/0xffff883b522ef960)
[ 1815.758287] fs/cifs/connect.c: Demultiplex PID: 15841
[ 1815.758292] fs/cifs/connect.c: CIFS VFS: in cifs_get_smb_ses as Xid: 7 with uid: 0
[ 1815.758293] fs/cifs/connect.c: Existing smb sess not found
[ 1815.758299] fs/cifs/smb2pdu.c: Negotiate protocol
[ 1815.758307] fs/cifs/transport.c: Sending smb: smb_len=102
[ 1815.761290] fs/cifs/connect.c: RFC1002 header 0xd3
[ 1815.761297] fs/cifs/smb2misc.c: smb2_check_message length: 0xd7, smb_buf_length: 0xd3
[ 1815.761300] fs/cifs/smb2misc.c: SMB2 data length 83 offset 128
[ 1815.761301] fs/cifs/smb2misc.c: SMB2 len 215
[ 1815.761341] fs/cifs/transport.c: cifs_sync_mid_result: cmd=0 mid=0 state=4
[ 1815.761344] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[ 1815.761349] fs/cifs/smb2pdu.c: mode 0x1
[ 1815.761350] fs/cifs/smb2pdu.c: negotiated smb2.0 dialect
[ 1815.761358] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
[ 1815.761360] fs/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0x1bb92
[ 1815.761362] fs/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
[ 1815.761366] fs/cifs/connect.c: Security Mode: 0x1 Capabilities: 0x300001 TimeAdjust: 0
[ 1815.761367] fs/cifs/smb2pdu.c: Session Setup
[ 1815.761368] fs/cifs/smb2pdu.c: sess setup type 4
[ 1815.761372] fs/cifs/transport.c: Sending smb: smb_len=120
[ 1815.762083] fs/cifs/connect.c: RFC1002 header 0xee
[ 1815.762089] fs/cifs/smb2misc.c: smb2_check_message length: 0xf2, smb_buf_length: 0xee
[ 1815.762091] fs/cifs/smb2misc.c: SMB2 data length 166 offset 72
[ 1815.762092] fs/cifs/smb2misc.c: SMB2 len 242
[ 1815.762128] fs/cifs/transport.c: cifs_sync_mid_result: cmd=1 mid=1 state=4
[ 1815.762134] fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc0000016 to POSIX err -5
[ 1815.762135] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[ 1815.762139] fs/cifs/smb2pdu.c: rawntlmssp session setup challenge phase
[ 1815.762187] fs/cifs/transport.c: Sending smb: smb_len=348
[ 1815.782014] fs/cifs/connect.c: RFC1002 header 0x48
[ 1815.782020] fs/cifs/smb2misc.c: smb2_check_message length: 0x4c, smb_buf_length: 0x48
[ 1815.782022] fs/cifs/smb2misc.c: SMB2 data length 0 offset 72
[ 1815.782023] fs/cifs/smb2misc.c: SMB2 len 77
[ 1815.782025] fs/cifs/smb2misc.c: Calculated size 77 length 76 mismatch mid 2
[ 1815.782064] fs/cifs/transport.c: cifs_sync_mid_result: cmd=1 mid=2 state=4
[ 1815.782067] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[ 1815.782071] fs/cifs/smb2pdu.c: SMB2/3 session established successfully
[ 1815.782075] fs/cifs/connect.c: CIFS VFS: leaving cifs_get_smb_ses (xid = 7) rc = 0
[ 1815.782079] fs/cifs/connect.c: CIFS VFS: in cifs_get_tcon as Xid: 8 with uid: 0
[ 1815.782080] fs/cifs/smb2pdu.c: TCON
[ 1815.782084] fs/cifs/transport.c: Sending smb: smb_len=108
[ 1815.782739] fs/cifs/connect.c: RFC1002 header 0x50
[ 1815.782744] fs/cifs/smb2misc.c: smb2_check_message length: 0x54, smb_buf_length: 0x50
[ 1815.782746] fs/cifs/smb2misc.c: SMB2 len 84
[ 1815.782781] fs/cifs/transport.c: cifs_sync_mid_result: cmd=3 mid=3 state=4
[ 1815.782784] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[ 1815.782787] fs/cifs/smb2pdu.c: connection to disk share
[ 1815.782790] fs/cifs/connect.c: CIFS VFS: leaving cifs_get_tcon (xid = 8) rc = 0
[ 1815.782792] fs/cifs/connect.c: Tcon rc = 0
[ 1815.782797] fs/cifs/fscache.c: cifs_fscache_get_super_cookie: (0xffff883b522ef960/0xffff883b522efaf0)
[ 1815.782799] fs/cifs/smb2pdu.c: create/open
[ 1815.782803] fs/cifs/transport.c: Sending smb: smb_len=128
[ 1815.783498] fs/cifs/connect.c: RFC1002 header 0x98
[ 1815.783503] fs/cifs/smb2misc.c: smb2_check_message length: 0x9c, smb_buf_length: 0x98
[ 1815.783505] fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[ 1815.783507] fs/cifs/smb2misc.c: SMB2 len 157
[ 1815.783509] fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 4
[ 1815.783543] fs/cifs/transport.c: cifs_sync_mid_result: cmd=5 mid=4 state=4
[ 1815.783547] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[ 1815.783551] fs/cifs/smb2pdu.c: Query FSInfo level 5
[ 1815.783555] fs/cifs/transport.c: Sending smb: smb_len=105
[ 1815.784202] fs/cifs/connect.c: RFC1002 header 0x5c
[ 1815.784208] fs/cifs/smb2misc.c: smb2_check_message length: 0x60, smb_buf_length: 0x5c
[ 1815.784210] fs/cifs/smb2misc.c: SMB2 data length 20 offset 72
[ 1815.784211] fs/cifs/smb2misc.c: SMB2 len 96
[ 1815.784225] fs/cifs/transport.c: cifs_sync_mid_result: cmd=16 mid=5 state=4
[ 1815.784228] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[ 1815.784232] fs/cifs/smb2pdu.c: Query FSInfo level 4
[ 1815.784236] fs/cifs/transport.c: Sending smb: smb_len=105
[ 1815.784815] fs/cifs/connect.c: RFC1002 header 0x50
[ 1815.784821] fs/cifs/smb2misc.c: smb2_check_message length: 0x54, smb_buf_length: 0x50
[ 1815.784823] fs/cifs/smb2misc.c: SMB2 data length 8 offset 72
[ 1815.784824] fs/cifs/smb2misc.c: SMB2 len 84
[ 1815.784862] fs/cifs/transport.c: cifs_sync_mid_result: cmd=16 mid=6 state=4
[ 1815.784865] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[ 1815.784868] fs/cifs/smb2pdu.c: Close
[ 1815.784872] fs/cifs/transport.c: Sending smb: smb_len=88
[ 1815.785815] fs/cifs/connect.c: RFC1002 header 0x7c
[ 1815.785821] fs/cifs/smb2misc.c: smb2_check_message length: 0x80, smb_buf_length: 0x7c
[ 1815.785823] fs/cifs/smb2misc.c: SMB2 len 128
[ 1815.785860] fs/cifs/transport.c: cifs_sync_mid_result: cmd=6 mid=7 state=4
[ 1815.785863] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[ 1815.785869] fs/cifs/connect.c: build_unc_path_to_root: full_path=\\nfsserv22\expsi
[ 1815.785871] fs/cifs/smb2pdu.c: TCON
[ 1815.785875] fs/cifs/transport.c: Sending smb: smb_len=116
[ 1815.786587] fs/cifs/connect.c: RFC1002 header 0x50
[ 1815.786593] fs/cifs/smb2misc.c: smb2_check_message length: 0x54, smb_buf_length: 0x50
[ 1815.786595] fs/cifs/smb2misc.c: SMB2 len 84
[ 1815.786632] fs/cifs/transport.c: cifs_sync_mid_result: cmd=3 mid=8 state=4
[ 1815.786635] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[ 1815.786639] fs/cifs/connect.c: Tcon rc = 0 ipc_tid = 65
[ 1815.786642] fs/cifs/smb2ops.c: smb2_get_dfs_refer path <\nfsserv22\expsi>
[ 1815.786646] fs/cifs/smb2pdu.c: SMB2 IOCTL
[ 1815.786648] fs/cifs/smb2pdu.c: replacing tid 0x40 with IPC tid 0x41
[ 1815.786651] fs/cifs/transport.c: Sending smb: smb_len=156
[ 1815.787382] fs/cifs/connect.c: RFC1002 header 0x49
[ 1815.787388] fs/cifs/smb2misc.c: smb2_check_message length: 0x4d, smb_buf_length: 0x49
[ 1815.787390] fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[ 1815.787391] fs/cifs/smb2misc.c: SMB2 len 77
[ 1815.787427] fs/cifs/transport.c: cifs_sync_mid_result: cmd=11 mid=9 state=4
[ 1815.787434] fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc0000225 to POSIX err -2
[ 1815.787435] fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[ 1815.787439] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2
[ 1815.787447] fs/cifs/smb2pdu.c: create/open
[ 1815.788648] fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[ 1815.788651] fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 10
[ 1815.788669] fs/cifs/smb2pdu.c: Close
[ 1815.789451] fs/cifs/smb2pdu.c: create/open
[ 1815.790282] fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[ 1815.790285] fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 12
[ 1815.790324] fs/cifs/smb2pdu.c: Close
[ 1815.791316] fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 6) rc = 0
[ 1815.791394] fs/cifs/inode.c: CIFS VFS: in cifs_root_iget as Xid: 9 with uid: 0
[ 1815.791395] fs/cifs/inode.c: Getting info on 
[ 1815.791401] fs/cifs/smb2pdu.c: create/open
[ 1815.792086] fs/cifs/smb2misc.c: SMB2 data length 0 offset 0
[ 1815.792089] fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 14
[ 1815.792106] fs/cifs/smb2pdu.c: Query Info
[ 1815.792723] fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc00000bb to POSIX err -95
[ 1815.792727] fs/cifs/smb2pdu.c: Close
[ 1815.794352] fs/cifs/smb2pdu.c: create/open
[ 1815.795290] fs/cifs/smb2misc.c: Calculated size 157 length 156 mismatch mid 17
[ 1815.795321] fs/cifs/smb2pdu.c: Query Info
[ 1815.795974] fs/cifs/smb2maperror.c: Mapping SMB2 status code 0xc00000bb to POSIX err -95
[ 1815.795977] fs/cifs/smb2pdu.c: Close
[ 1815.797136] CIFS VFS: cifs_read_super: get root inode failed
[ 1815.816161] fs/cifs/connect.c: cifs_put_tcon: tc_count=1
[ 1815.816165] fs/cifs/connect.c: CIFS VFS: in cifs_put_tcon as Xid: 10 with uid: 0
[ 1815.816167] fs/cifs/smb2pdu.c: Tree Disconnect
[ 1815.816776] fs/cifs/fscache.c: cifs_fscache_release_super_cookie: (0xffff883b522efaf0)
[ 1815.816782] fs/cifs/connect.c: cifs_put_smb_ses: ses_count=1
[ 1815.816784] fs/cifs/connect.c: CIFS VFS: in cifs_put_smb_ses as Xid: 11 with uid: 0
[ 1815.816786] fs/cifs/smb2pdu.c: disconnect session ffff883b9abf1400
[ 1815.817500] fs/cifs/fscache.c: cifs_fscache_release_client_cookie: (0xffff883a2bbf8000/0xffff883b522ef960)
[ 1820.409323] device enp0s25 left promiscuous mode

[-- Attachment #3: trace.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 9650 bytes --]

Re: [PATCH] CIFS: do not send invalid input buffer on QUERY_INFO requests

[Aurélien Aptel]

Hadrien Grasland <grasland-dJj/bURytuEtnUBFBimtzg@public.gmane.org> writes:
> Just tried out this patch, and the CIFS module does indeed produce 
> well-formed GetInfo requests now (according to Wireshark's definition at 
> least, didn't check myself).
>
> However, the server will still reject the request with a 
> STATUS_NOT_SUPPORTED error, suggesting that Steve's interpretation was 
> the right one: this is likely a server-side bug.

Yes. As Steve suggested as a workaround, we could try to use a less
detailed information level if FullInfo fails. Is it worth doing for a
single old NetApp server?

As for the offset and extra byte in QUERY_INFO I guess having the length
set to 0 makes it ok... I've sent a couple of patches to Wireshark to
fix the packet parsing. It now accepts the empty filename in CREATE (no
more "[unknown]"), which enables the proper parsing of the unknown
field.

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [PATCH] CIFS: do not send invalid input buffer on QUERY_INFO requests

[Hadrien Grasland]

Le 18/10/2017 à 16:50, Aurélien Aptel a écrit :
> Hadrien Grasland <grasland-dJj/bURytuEtnUBFBimtzg@public.gmane.org> writes:
>> Just tried out this patch, and the CIFS module does indeed produce
>> well-formed GetInfo requests now (according to Wireshark's definition at
>> least, didn't check myself).
>>
>> However, the server will still reject the request with a
>> STATUS_NOT_SUPPORTED error, suggesting that Steve's interpretation was
>> the right one: this is likely a server-side bug.
> Yes. As Steve suggested as a workaround, we could try to use a less
> detailed information level if FullInfo fails. Is it worth doing for a
> single old NetApp server?

If it's only me that's having the issue, I would say don't bother. The 
same system issue that prevents my sysadmin colleagues from updating to 
a NetApp software version where the bug is fixed also prevents them from 
disabling SMBv1 support, and sticking with SMBv1 for now is fine by me.


> As for the offset and extra byte in QUERY_INFO I guess having the length
> set to 0 makes it ok... I've sent a couple of patches to Wireshark to
> fix the packet parsing. It now accepts the empty filename in CREATE (no
> more "[unknown]"), which enables the proper parsing of the unknown
> field.
Thanks for looking into this!
Hadrien

Re: [PATCH] CIFS: do not send invalid input buffer on QUERY_INFO requests

[Steve French]

rebased cifs-2.6.git for-next and pushed this patch

On Tue, Oct 17, 2017 at 7:47 AM, Aurelien Aptel <aaptel-IBi9RG/b67k@public.gmane.org> wrote:
> query_info() doesn't use the InputBuffer field of the QUERY_INFO
> request, therefore according to [MS-SMB2] it must:
>
> a) set the InputBufferOffset to 0
> b) send a zero-length InputBuffer
>
> Doing a) is trivial but b) is a bit more tricky.
>
> The packet is allocated according to it's StructureSize, which takes
> into account an extra 1 byte buffer which we don't need
> here. StructureSize fields must have constant values no matter the
> actual length of the whole packet so we can't just edit that constant.
>
> Both the NetBIOS-over-TCP message length ("rfc1002 length") L and the
> iovec length L' have to be updated. Since L' is computed from L we
> just update L by decrementing it by one.
>
> Signed-off-by: Aurelien Aptel <aaptel-IBi9RG/b67k@public.gmane.org>
> ---
>  fs/cifs/smb2pdu.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 6f0e6343c15e..b927e131f997 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -2191,9 +2191,13 @@ query_info(const unsigned int xid, struct cifs_tcon *tcon,
>         req->PersistentFileId = persistent_fid;
>         req->VolatileFileId = volatile_fid;
>         req->AdditionalInformation = cpu_to_le32(additional_info);
> -       /* 4 for rfc1002 length field and 1 for Buffer */
> -       req->InputBufferOffset =
> -               cpu_to_le16(sizeof(struct smb2_query_info_req) - 1 - 4);
> +
> +       /*
> +        * We do not use the input buffer (do not send extra byte)
> +        */
> +       req->InputBufferOffset = 0;
> +       inc_rfc1001_len(req, -1);
> +
>         req->OutputBufferLength = cpu_to_le32(output_len);
>
>         iov[0].iov_base = (char *)req;
> --
> 2.12.3
>



-- 
Thanks,

Steve

Re: [PATCH] CIFS: do not send invalid input buffer on QUERY_INFO requests

[Pavel Shilovsky]

2017-10-17 5:47 GMT-07:00 Aurelien Aptel <aaptel-IBi9RG/b67k@public.gmane.org>:
> query_info() doesn't use the InputBuffer field of the QUERY_INFO
> request, therefore according to [MS-SMB2] it must:
>
> a) set the InputBufferOffset to 0
> b) send a zero-length InputBuffer
>
> Doing a) is trivial but b) is a bit more tricky.
>
> The packet is allocated according to it's StructureSize, which takes
> into account an extra 1 byte buffer which we don't need
> here. StructureSize fields must have constant values no matter the
> actual length of the whole packet so we can't just edit that constant.
>
> Both the NetBIOS-over-TCP message length ("rfc1002 length") L and the
> iovec length L' have to be updated. Since L' is computed from L we
> just update L by decrementing it by one.
>
> Signed-off-by: Aurelien Aptel <aaptel-IBi9RG/b67k@public.gmane.org>
> ---
>  fs/cifs/smb2pdu.c | 10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index 6f0e6343c15e..b927e131f997 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -2191,9 +2191,13 @@ query_info(const unsigned int xid, struct cifs_tcon *tcon,
>         req->PersistentFileId = persistent_fid;
>         req->VolatileFileId = volatile_fid;
>         req->AdditionalInformation = cpu_to_le32(additional_info);
> -       /* 4 for rfc1002 length field and 1 for Buffer */
> -       req->InputBufferOffset =
> -               cpu_to_le16(sizeof(struct smb2_query_info_req) - 1 - 4);
> +
> +       /*
> +        * We do not use the input buffer (do not send extra byte)
> +        */
> +       req->InputBufferOffset = 0;
> +       inc_rfc1001_len(req, -1);
> +

I was looking at the code and noticed that build_qfs_info_req() uses
the same pattern of initializing InputBufferOffset field. Do we need
to fix it in the same way?

--
Best regards,
Pavel Shilovsky