# Wireshark shows SMB path and File name in 8.3 file format, but only from time to time?

Has any one seen in an SMB capture that the client will send what seems to be file path and name in 8.3 file format, even though both SMB2 is used and the Client is a Win10? Most of the times it does use the normal file format to send its requests . I wonder if this is a Client issue or the Wireshark just not showing it properly?

Here is a good example from the SMB2 Create Request: Filename: Energie_GmbH\04_WET\03_Angebote\140220_4601000136_Bachert.pdf

And Here is a not so good one: Filename: ENERGI~1\04_wet\03_ANG~1\140220~1.PDF

I wanted to upload a screenshot, but the system would not allow me to. Both of the above are sent from the same Clients within a few packets of each other and I strongly suspect that it is the same file. I am not sure if that is a problem or not, but jumps out when I look at the captures.

And some background of the problem. User connects to the shared drive and tries to open some PDF files. They could not open any files for a few minutes and then the problem disappears for a few hours. After that all repeats. User is Win10 and Share is NetApp.

edit retag close merge delete

Sort by » oldest newest most voted

Hello kalintri

Wireshark is showing the real data (and real filenames) as they go over the network and SMB2 is working as designed.

To get to the root of the 8.3 filenames in your trace file we have to leave the network arena and take a detour into Windows internals.

You are (or were) most likely running a legacy application that does not support long file names or explicitly demands 8.3 file names.

Creation of 8.3 filenames

The 8.3 filenames go back to old days of MS-DOS and 640kBytes of Memory. You can control the creation of 8.3 filenames with the command line utility fsutil or through a GPO (Administrative templates -> System -> Filesystem -> NTFS -> Short Name creation Options). By default Windows will create 8.3 file names together with the long name. The Explorer will only show the long names.

8.3 filenames = old stuff

Windows will start using 8.3 file names, when an application is running in compatiblity mode. This can happen due to information in the PE Header or because of the properties of the program.

The PE header is at the beginning of any executable file (.EXE, .DLL, .SYS …) It starts with the letters MZ. The following bytes can give a hint to Windows to present only 8.3 filenames to this application. More precisely and completly off topic for this forum: The PE header includes a datastructure called "optional header" (which is usually present despite its name). That header lists a "subsystem", for example Windows GUI or Command Line or OS/2 console.

Right-click on the program, select properties and go to the tab "Compatibility" to launch old Windows 95 applications. (Note: Windows 95 did support long filenames, but not all applications form the 90ies were Ready for long file names)

8.3 filenames in SMB

Time to go back to the network layer. When a file is opened the client will send a Create Request to the server. This request has a 32-bit field for "Create Options". Here the client can ask the server to use an 8.3 filename for this Operation.

To continue your analysis I recommend a good look at the Create Options.

Good luck

more

The PE header is at the beginning of any executable file (.EXE, .DLL, .SYS …) It starts with the letters MZ.

That's actually the DOS executable header. That's the header of DOS .EXE files. (There are also DOS .COM files, which don't have a header.)

Some other executable file formats for Windows, such as the New Executable format, and the Portable Executable (PE) format, start with an MZ header, followed by a DOS executable program. The DOS executable program is usually a stub that just says "this isn't a DOS executable, it's a Windows executable", although some of those files are fat binary files, with the DOS executable being a real program.

If the file is a DOS or New Executable file, it's presumably 16-bit code, which can't handle long file names, and if it's doing file system accesses to an SMB server ...(more)

( 2018-05-24 21:39:50 +0000 )edit

Thanks for the explanations guys. In my case in the example I have given above the file is a PDF and the client, which is a Windows 10 was trying to open the file through Windows Explorer. The file itself is stored on a NetApp storage. Both the client and the Storage are running pretty new OS, so I am not sure why would it run in compatibility mode or even use the 8.3 format. I just found it strange. What is also strange that this was only happening from time to time as you can see both 8.3 and the long file name format from the example I gave were for the same file within a few packets of each other. Same client, same server, same file. That is what puzzled me.

( 2018-05-24 21:47:08 +0000 )edit

the file is a PDF

So what is the PDF reader on your machine? That's the program that'll be trying to open the file.

( 2018-05-25 18:56:02 +0000 )edit

I will ask the person who sent me that file. I assume standard Adobe reader. What was interesting to me is that it does not happen every time, but I will look further. I am not even sure that it is a problem, I was just curious.

( 2018-05-25 19:02:23 +0000 )edit