16.2 SMB Echo

Here's a toy we can play with.

ECHO is really as simple as it sounds. It's sort of the SMB equivalent of ping . The client sends a packet with a data block full of bytes, and the server echoes the block back. Simple.

...but this is CIFS we're talking about.

Although the ECHO itself is simple, there are many quirks to be found in existing implementations . We will dig into this just a tiny bit to give you a taste of the kinds of problems you are likely to encounter. Let's start with a quick look at the ECHO REQUEST structure:

 SMB_PARAMETERS   {   WordCount  = 1   EchoCount  = <In theory, anything from 0 to 65535>   } SMB_DATA   {   ByteCount  = <Number of data bytes to follow>   Bytes      = <Your favorite soup recipe?>   } 

The EchoCount field is a multiplier . It tells the server to respond EchoCount times. If EchoCount is zero, you shouldn't get any reply at all. If EchoCount is 9,999, then you are likely to get nine thousand, nine hundred, and ninety-nine replies. We say likely because of the wide variety of weirdity that can be seen in testing.

One bit of weirdation is that all of the systems that were tested would respond to an ECHO REQUEST even if no SESSION SETUP had been sent and no authentication performed. This behavior is, in fact, per design, but it means that any client that can talk to your server from anywhere can ask for EchoCount replies to a single request. (It would probably be safer for the server to send a ERRSRV/ERRnosupport error message in response to an un-authenticated ECHO REQUEST .)

Other strangisms of note:

• In testing, Windows 9x systems returned an "Invalid TID" error unless the TID was set to 0xFFFF. Also, these systems sent back at most a single reply, handling EchoCount as if it were a boolean.

• Windows NT 4.0 and Windows 2000 would try to send as many replies as specified in EchoCount . If the data block ( SMB_DATA.Bytes ) was very large (4K was tested) and the EchoCount very high (e.g., 20,000), the server would eventually give up and reset the connection.

• Samba has an upper limit of 100 repetitions. Also, Samba sends the replies fast enough that multiple replies will be batched together in a single TCP packet. (That's normal behavior for a TCP stream.)

• The Windows NT 4.0 (Service Pack 6) system used in testing failed to respond if the payload was greater than 4323 bytes. Windows 2000 seems to have an upper limit of 16611 bytes, above which it resets the TCP connection.

Email

 From: Conrad Minshall, Apple Computer      To: Chris Hertel      Cc: Samba Technical Mailing List Subject: Re: Bizarre limit alert. I saw the same "packet drop" with an overlong WRITE_ANDX.  The maximum buffer size an NT SP6 claims on the NEGOTIATE response is 0x1104 (4356). This limit is not on the data, the limit includes the SMB header (32 bytes) and the SMB command. Based upon the size of an ECHO command I'd expect you could send 4319 bytes, not 4323, so on this topic you'll have to have the last word... sorry. 

No apologies. This is CIFS we're talking about.

The ECHO SMB may be one of those things that get coded up just because they're in the documentation and they seem easy. It also appears as though ECHO hasn't been tested much. Certainly, the more it is stressed, the more variation can be seen. There is, however, something to note in the last example in the above list and in the message from Conrad: Once you know what you're looking at, you will find common themes that appear and reappear across a given implementation. These common themes are derived from common internals, and they can provide many clues about the inner workings of the implementation.

Another fine point highlighted by our quick look at the ECHO SMB is that TCP is designed to carry streams of data not discrete packets. This can be seen in the results of the tests against Samba, in which multiple replies were contained in a single TCP packet. At the other extreme, several TCP packets are needed to transfer a single ECHO if it has a very large data payload. As a result, a single read operation may or may not return one and only one complete SMB message.

Oversimplification Alert

The RecvTimeout() function (provided way back in Listing 10.1) makes the assumption that one complete SMB message will be returned per call to the recv() function. That's a weak assumption. It works well enough for the simple testing we have done so far, but it is not sufficient for a real SMB implementation.

A better version of RecvTimeout() would verify the received data length against the NBT SESSION_MESSAGE.LENGTH field value to ensure that only one message is read at a time, and that the complete message is read before it is returned.