NULL on the command channel?

[James Noyes]

I considered sending this to the dev list, but I guess the developers
probably read this list and there may be non-developers that can provide
insights.

I'm troubleshooting a problem in transferring a file into our server. The
server is running WU-FTPd 2.6.2, date stamp of 2001/11/29. The OS is
Solaris 8 Sparc, current vendor-provided patch cluster.

The client making the transfer is a somewhat unknown "black box", being run
by non-tech-savvy people from a mainframe platform. Not sure how relevant
that is.

Basically, we have a particular file that always halts its transfer before
it is completely sent. The log on the server side (our side) records a
message of "Lost connection to client.host.name [CLI.ENT.IP.ADDR]".
Up to the point this message appears, everything seems to be going normally.

Where things look a little unusual is when I capture packets on the wire as
the transfer progresses. Everything looks fine initially. The command
channel is opened, credentials are presented and accepted, a TYPE command is
issued, a PORT is issued, a STOR is issued, and the 150 response is given.
Data begins flowing on the data channel at this point, inbound from the
client. But then...

Almost *exactly* 30 seconds after the "150" response is issued and ACK'ed at
the TCP level, an outbound packet is issued from our FTPd on the command
channel, containing exactly ONE byte - a NULL (0x00) byte. The client end
appears to respond to this byte with an immediate 0-length TCP RST packet on
the command channel, effectively forcing a hard close of the command
channel. It does not issue a "QUIT" or go through any graceful shutdown
steps. Only two further packets are exchanged - another 1-byte (also NULL)
packet is sent on the data channel, and the client responds to this with
another 0-length TCP RST for the data channel. On some level, this exchange
seems - wrong? broken? - to me.

Now, I'm pretty familiar with the FTP protocol, and I understand that the
communication on the command channel is loosely based on telnet. I've never
seen a NULL appear on the command channel, but I admit I don't look at the
protocol at this level very often - only when troubleshooting. So I have a
series of questions, some of which may be "duh" questions, but I honestly
don't know and would truly appreciate any answers I can get. I'm really
stumped.

- Is a NULL (0x00) byte from the server on the command channel valid in the
FTP protocol?
- If it's not, what conditions in the WU-FTPd code could possibly cause it
to generate such a byte on the command channel? Could it be in response
to anything on the data channel, even if triggered by some sort of bug?
- If it's valid, what is its purpose? Is it a keepalive/heartbeat of some
kind? Does it indicate an error of some kind? Is there any significance
to the fact that this NULL is sent almost *exactly* 30 seconds after the
prior packet on the command channel?
- If the NULL is valid, what is the proper expected response from the
client, if any? Would a hard TCP RST in response be consider a faulty
behavior of the client in this case?
- Is there any significance to the single-byte NULL being sent by the server
on the data channel after the command channel is abruptly shut down?
- Is the TCP RST on the data channel a proper client response to a NULL from
the server on the data channel?

I'm of the opinion that there is likely nothing wrong on the server side of
our setup, because no other transfers are experiencing these problems. but
until I have real answers I can't say that for sure. Google has come up
with essentially nothing regarding the presence of NULL bytes in the FTP
protocol stream. I'm hoping that the good folks here have enough knowledge
of how FTP works at this low of a level to clarify things for me. Input is
truly appreciated and will help me retain what little sanity I may have
left. :)