none
Strange behavior reading data from PCNET1 SMB server RRS feed

  • General discussion

  • Reading data from an SMB server using the PCNET1 SMB dialect is extremely inefficient from a WinXP with SP3 client. The trace summary below shows the traffic required to copy the 199 byte \CONFIG.SYS from the PCNET1 server named INST to the WinXP client named GLEB.

    When WINXP SP2 is used, there are also some anomalies, but from Windows Vista Business with SP1 it works in a predictable way. Complete traces of all three scenarios can be downloaded from:
    http://www.gpvno.co.za/temp/smb-read.zip

    Comments and a solution will be appreciated.

    NBSS     Session request, to INST<20> from GLEB<00>

    NBSS     Positive session response

    SMB      Negotiate Protocol Request

    SMB      Negotiate Protocol Response

    SMB      Tree Connect Request, Path: \\INST\C

    SMB      Tree Connect Response

    SMB      Query Information Request, Path: \CONFIG.SYS

    SMB      Query Information Response

    SMB      Search Request, File: \CONFIG.SYS

    SMB      Search Response

    SMB      Open Request, Path: \CONFIG.SYS

    SMB      Open Response, FID: 0x0000

    SMB      Search Request, File: \CONFIG.SYS

    SMB      Search Response

    SMB      Read Request, FID: 0x0000, 256 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 57 bytes at offset 199

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 512 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 313 bytes at offset 199

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 512 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 313 bytes at offset 199

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 2 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 512 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 313 bytes at offset 199

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 199 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 4096 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 3897 bytes at offset 199

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 512 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 313 bytes at offset 199

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 64 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 512 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 313 bytes at offset 199

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 199 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 4 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 512 bytes at offset 0

    SMB      Read Response

    SMB      Read Request, FID: 0x0000, 313 bytes at offset 199

    SMB      Read Response

    SMB      Open Request, FID: 0x0001, Path: \CONFIG.SYS

    SMB      Open Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 256 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 57 bytes at offset 199

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 512 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 313 bytes at offset 199

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 512 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 313 bytes at offset 199

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 2 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 512 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 313 bytes at offset 199

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 199 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 4096 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 3897 bytes at offset 199

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 512 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 313 bytes at offset 199

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 64 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 512 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 313 bytes at offset 199

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 199 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 4 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 4096 bytes at offset 0

    SMB      Read Response, FID: 0x0001

    SMB      Read Request, FID: 0x0001, 3897 bytes at offset 199

    SMB      Read Response, FID: 0x0001

    SMB      Close Request, FID: 0x0001

    SMB      Close Response, FID: 0x0001

    SMB      Close Request, FID: 0x0000

    SMB      Close Response


    Tuesday, November 11, 2008 2:11 PM

All replies

  •  Gerritvn,

       Thanks for your questions.  We will look at this issue.  We will post our finding when we complete our investigation.

    Thanks !

     
    Hongwei Sun -MSFT
    Tuesday, November 11, 2008 3:26 PM
  •  

    Gerritvn,

     

    Thank you for the traces.  I have downloaded them and will begin investigating your issue.  Before I go too far though, I want to ensure that I understand your issue.  Please confirm the following:

     

    You see a difference in behavior between a Windows XP with SP2, Windows XP with SP3 and Windows Vista with SP1 when trying to access and read a file over the network.  Have I understood your problem correctly?  Can you provide a section of the MS-SMB documentation that is causing the confusion?

     

    Thank you for taking the time to report your issue.

    Richard Guthrie
    Escalation Engineer

    Wednesday, November 12, 2008 4:56 PM
  • Richard,

    Yes, you do understand the issue correctly.

    As for the MS-SMB documentation: It is not causing any confusion. The confusion is in the behavior of the implementation in Windows XP with SP3 as is clearly shown in the summary trace. The behavior of the implementation in WinVista is according to the specification.

    Gerrit

    Wednesday, November 12, 2008 6:48 PM
  •  Gerritvn,

    Thank you for the confirmation.  Can you also provide some repro steps for how you are performing the file copy.  Are you doing this through Explorer, or using a Windows API on the client to perform the copy.  Any details you can provide would be appreciated.

    Richard Guthrie
    Escalation Engineer
    Wednesday, November 12, 2008 6:57 PM
  • Richard,

    I worked in a Windows console. To map to the server I used:

    net use e: \\inst\c

    I then did a simple copy in the Windows console:

    copy e:\config.sys

    Using Windows Explorer to do the copy, gives the same result.

    I also wrote a 32 bit Console mode program in C doing a simple fopen(), fread(), fclose() sequence to prove that it was indeed the protocol that caused the problem and not the utilities CMD.EXE and EXPLORER.EXE.

    Gerrit

    Wednesday, November 12, 2008 7:26 PM
  • Gerrit,

    Is there a virus scanner running on the Windows clients?  If so you might try disabling it to see if you get different behavior.

    Richard Guthrie
    Escalation Engineer
    Thursday, November 20, 2008 3:19 PM
  • Hello Richard,

    That was it! Norton Antivirus was running when I encountered the strange behavior. I have now replaced it with Microsoft Forefront and the problem is gone.

    There is still the somewhat strange behavior that the transfer is done twice (with virus real-time protection enabled or disabled), but not 26 times as before. I'll investigate that further with bigger files.

    Thank you for the support, both on- and off-forum. I am really impressed and appreciate it!

    Gerrit

    Friday, November 21, 2008 7:17 AM
  • I have investigated further with anti-virus real-time protection disabled and a simple C program doing unbuffered reads. The only slightly strange behavior is that at the end of a transfer two read requests starting at the end of file position, are attempted; obviously getting 0 bytes read responses. This is true for long as well as short files. I'll just accept this as an implementation detail.

    With Forefront real-time protection enabled, the file is actually read twice over the network. This is still a lot better than the behavior when Norton Antivirus is run. That goes a long way to explain why network access can become so painfully slow!


    Friday, November 21, 2008 3:25 PM
  • Gerrit,

    If possible can you post a trace of the behavior you are seeing?  We would like to make sure that it is covered in the documentation, possibly as a behavior note, so that the next person that might encounter this issue is able to understand what is happening.  Thanks for following up.

     

    Thanks,

    Richard Guthrie
    Escalation Engineer

    Tuesday, January 20, 2009 2:35 PM
  • I have posted a trace of the behavior I had seen before removing Norton Antivirus to dochelp.

    Tuesday, January 20, 2009 3:51 PM
  •  

    Hi Gerrit,

     

    Thanks for raising this issue. I have taken ownership of the case and will be investigating the SMB trace.

    I will keep you updated as soon as I have news or clarification questions.

     

    Best regards,

     

    Edgar
    Tuesday, January 20, 2009 10:02 PM
    Moderator
  •  

    Hi Gerrit,

     

    This is to confirm the scenario of an additional read as you experienced with PCNET SMB from a Windows XP SP3 client. We will update you with the answer as soon as we complete our investigation.

     

    Regards,

    Edgar

    Friday, February 6, 2009 4:32 PM
    Moderator
  • Hi Gerrit,

     

    We have completed investigation regarding the issue of reading data from a PCNET1 SMB server when the client is running Windows XP SP3 or Windows Vista.

    A Windows behavior will be added to the [MS-SMB] document and will reflect like this.

     

    3.2.4.4   Application Requests Reading from a File

    An exception case will reference to the <WB>

    6 Appendix A: Windows Behavior

    <WB> Windows-based clients send read request until it receives STATUS_END_OF_FILE, or DataLength is 0 (i.e. a zero length response).

    Note that this <WB> applies to both SMB_COM_READ and SMB_COM_READ_ANDX.


    The changes will appear in a future release of the [MS-SMB] specification.
     

    Best regards,

    Edgar

    Tuesday, February 10, 2009 12:05 AM
    Moderator