Created attachment 16611 [details] Wireshark of failure We have found that in one case we are getting: GetInfo Response (0x10) ... StructureSize: 0x0009 0000 0000 0000 1000. = Fixed Part Length: 4 .... .... .... ...1 = Dynamic Part: True Blob Offset: 0x00000048 Blob Length: 65535 In samba-4.7.5/source3/libsmb/cli_smb2_fnum.c, function: cli_smb2_dskattr() we see: 1943 /* getinfo on the returned handle with info_type SMB2_GETINFO_FS (2), 1944 level 3 (SMB_FS_SIZE_INFORMATION). */ 1945 1946 status = smb2cli_query_info(cli->conn, 1947 cli->timeout, 1948 cli->smb2.session, 1949 cli->smb2.tcon, 1950 2, /* in_info_type */ 1951 3, /* in_file_info_class */ 1952 0xFFFF, /* in_max_output_length */ 1953 NULL, /* in_input_buffer */ 1954 0, /* in_additional_info */ 1955 0, /* in_flags */ 1956 ph->fid_persistent, 1957 ph->fid_volatile, 1958 frame, 1959 &outbuf); 1960 if (!NT_STATUS_IS_OK(status)) { 1961 goto fail; 1962 } 1963 1964 /* Parse the reply. */ 1965 if (outbuf.length != 24) { 1966 status = NT_STATUS_INVALID_NETWORK_RESPONSE; 1967 goto fail; 1968 } 1969 So we decided to try change it to: + if (outbuf.length < 24) { + status = NT_STATUS_INVALID_NETWORK_RESPONSE; + goto fail; + } And the transfer passed. This was in 4.7.5 but we see the same logic exists in 4.12.x ... So do you think this is a valid change ? Is 65535 an expected valid return ? Is it indicating something ? Have you seen other cases where the blob length may not be 24 ? Your feedback would be great appreciated. Windows 2019 Windows Server. ( Moved from a Linux based NAS Server (working okay) to a Windows 2019 Cluster Server) Mike
Created attachment 16612 [details] Diagram of Cluster configuration
OK, took a look at the wireshark respons. The bad packet is 1704. It's returning a size of 65607 and wireshark is flagging it as a malformed packet. In our request, we send a "max response size" of 65536, and I wonder if the errant server is taking that, allocating that plus a response and returning the whole thing. You could try changing the "max response size" we send to see if it changes the server behavior. But this is pathalogical server behavior. I wouldn't be at all surprised if you could trigger a buffer overrun on this thing given the way it behaves.