Using Wireshark to Debug FTPES through vsFTP
While vsFTP is lightweight and has a relatively good track record, the verbosity of its logs is lacking. Without having an error logged, it can be considerably more difficult to find and resolve the problem. This issue is compounded when using an encrypted connection.
After recently enabling FTP over SSL on vsFTP, I noticed that I would periodically get the following error in FileZilla:
Error: GnuTLS error -8: A record packet with illegal version was received.
Error: Disconnected from server: ECONNABORTED – Connection aborted
Typically, this would occur after a period of inactivity, and it rarely had any impact my use of FTP, however, it is always nice to know the cause. On initial observation, it appeared that the cause was an unencrypted packet being sent from vsFTP. Of course, nothing was logged on the system.
To determine the content, and hopefully the cause, of the error, Wireshark (a packet analyzer) was used to capture packets on the interface. This program is easily setup, and will listen on the selected interface, furthermore, it will filter the incoming packets based on a specified expression, and was thus set to only show packets whose protocol was FTP.
If the NPF driver isn’t running, it can be started by launching an administrative command prompt, and running:
net start npf
On observing the packets, received, one can see that following the SSL handshake, the content stream is encrypted, until an error (500) is thrown. The packet containing the error is sent in clear text, and is unexpected by the client (FileZilla), which returns an error.
The first error-containing packet is followed by several more, until the connection is broken.
- 500 OOPS :
- vsf_sysutil_recv_peek: no data
- 500 OOPS : priv_sock_get_int
- 500 OOPS: child died
Having at least an error to work with, provides a starting point in debugging, and greatly helps to narrow the search for the culprit My understanding is that all 500 errors encountered by vsFTP are sent unencrypted and therefore disrupt the encrypted connection and do not appear in the client program. It is therefore quite likely that the same error reported by the FTP client, will be the result of a different error generated by vsFTP.
