This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

CIFS vs NETBIOS & network performance

0

Testing file open performance across a WAN vs LAN. I open a 1MB .rtf file. When opening on the LAN, the traffic is on port 445 (CIFS). When opening the same file from the same server across the WAN, the traffic is on port 139 (NETBIOS).

My question for all of you protocol gurus:

Is there really any difference in the traffic when using a different port to do the same activity? If so, what are those differences & how does it contribute to end-user experience?

Some other information you might be interested in:

Number of packets LAN – 1,544 WAN – 1,864 Size of data packets LAN – 1,474 bytes WAN – 1,354 bytes Time to open (first packet to last packet) LAN – 3 secs WAN – 19 secs

asked 02 Jun '11, 11:42

Labnuke's gravatar image

Labnuke
61449
accept rate: 0%


2 Answers:

4

Your time differences are most certainly related to the "chattiness" of SMB. Both ports work - for your simple file transfer - nearly the same way.

Your long response times are most certainly a result of the SMB protocol design and not of the different ports.

Understanding the differences between 139 and 445 is a lot easier with a bit of protocol history. So ...

1. Protocol History

TCP port 139 is used for "NetBIOS over TCP", sometimes called NBT. This protocol was created to make the "NetBIOS over Ethernet" (NetBEUI) protocol routable. This rather old NetBIOS protocol was never designed to connect two computer with anything else but a LAN.

NetBIOS has several characteristics of TCP, for example you have to establish a session or keep-alives. After starting the NetBIOS session the client negotiates a protocol version, authenticates, mounts a share and accesses files and services on the server. This last part would be SMB.

With Windows 2000 Microsoft felt that this can be improved. They added the port 445 for the same service. On port 445 SMB runs directly over TCP. The only difference is that the client skips the NetBIOS session (saves one round trip) then negotiates, authenticates, mounts etc.

Check the properties of your network card. Somewhere in the Advanced IP Settings is a checkbox "Enable NetBIOS over TCP". Activate it and your computer uses port 139. Deactivate the option and the system wants to use 445.

So the protocol layers are:

port 139: SMB -> NetBIOS -> TCP port 445: SMB -> .... -> TCP

The 4 dots are not exactly random. Microsoft leaves 4 empty bytes in place so the same source code can process the message, regardless of 139 or 445.

I remember pulling my hair out when I tried to connect a shiny Windows 2000 system to an NT server for the first time ....

So far the protocol history.

2. System behaviour

Most traces that I have seen lately show that workstations try to connect to 139 and 445 at the same time. Whatever ports gets the first response will be used for communications.

With the latest versions of Windows you want to use port 445.

With NetBIOS out of the picture you have less broadcast traffic, can use FQDNs to mount shares, and you can use larger buffers.

answered 03 Jun '11, 08:47

packethunter's gravatar image

packethunter
2.1k71548
accept rate: 8%

Thanks for the rsponse. Good information.

(07 Jun '11, 11:11) Labnuke

1

I have no idea about the differences between the way services are offered on port 139 and 445. However, I do know that the SMB protocol is not very WAN friendly as data is transferred one block at a time (instead of streaming). Which means, for each blocksize of data you get 1 round-trip-time for free as an additional bonus. If your blocksize is 4KB (not uncommon) and your RTT is 40ms, you get an additional delay of 1MB/4KB * 60 ms = ~15sec.

Have a look at your packet capture and check whether that is indeed what is causing the extra delay. Comparing traces can also give you some insight in whether the protocols used are the same on each port.

answered 02 Jun '11, 13:13

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%