MalformedReplyException connecting to Tumbleweed Server

Question

I'm trying out the edtFTPPro .net client trying to connect to a Tumbleweed Secure Transport server and I'm getting the subject exception. My Log files are:

Command Log

Reply: 220-Hello, Welcome to AF SecureTransport!
Reply: 220-
Reply: 220 Secure FTP Server
Command: ---> AUTH TLS
Reply: ready.
Command: ---> QUIT
Reply: 234 SSLv23/TLSv1


Debug Log


INFO : Connection Properties:
INFO : ServerPort = 21
INFO : Protocol = FTPSExplicit
INFO : SocksProxySettings =
INFO : ProxySettings = NoProxy
INFO : ServerCompatibility = Standard
INFO : ServerValidation = None
INFO : AutoSecure = True
INFO : SecureFTPType =
INFO : SSLVersion = SSL3
INFO : CipherSuites = SECURE_CIPHERS
INFO : ServerCommonName = sftp01.af-group.com
INFO : UseUnencryptedCommands = False
INFO : ClientCertificate = CN=[afalrjr]
INFO : ServerCertificate =
INFO : UMask = 0022
INFO : DefaultPermissions = 0777
INFO : AuthenticationMethod = PublicKey
INFO : ClientPrivateKeyFile = C:\mysftpkey.pfx
INFO : ClientPrivateKeyPassphrase = w1ntermute
INFO : KBIPrompts = null
INFO : KnownHosts =
INFO : PreferredHostKeyAlgorithms = ALL
INFO : PreferredCipherAlgorithms = All
INFO : PreferredCompressionAlgorithms = All
INFO : PreferredMACAlgorithms = All
INFO : SSHWindowSize = 131071
INFO : SSHMaxPacketSize = 65535
INFO : CloseStreamsAfterTransfer = True
INFO : DeleteOnFailure = True
INFO : Timeout = 120000
INFO : ShowHiddenFiles = False
INFO : TransferBufferSize = 4096
INFO : TransferNotifyInterval = 4096
INFO : LicenseOwner = trialuser
INFO : LicenseKey = 700-8306-8962-3986
INFO : DataEncoding = null
INFO : IsTransferring =
INFO : CommandEncoding = null
INFO : MultiTransferSleepEnabled = False
INFO : MultiTransferCountBeforeSleep = 100
INFO : MultiTransferSleepTime = 60
INFO : DetectTransferMode = True
INFO : KeepAliveTransfer = False
INFO : KeepAliveIdle = True
INFO : KeepAlivePeriodSecs = 30
INFO : DefaultSyncRules = EnterpriseDT.Net.Ftp.FTPSyncRules
INFO : RetryCount = 3
INFO : RetryDelay = 5000
INFO : Site =
INFO : ParentControl =
INFO : Version = 5.1.0
INFO : BuildTimestamp = 18-Sep-2008 18:24:50 EST
INFO : StrictReturnCodes = False
INFO : PublicIPAddress =
INFO : AutoPassiveIPSubstitution = True
INFO : ActivePortRange = 1024 -> 5000
INFO : FileNotFoundMessages = EnterpriseDT.Net.Ftp.FileNotFoundStrings
INFO : TransferCompleteMessages = EnterpriseDT.Net.Ftp.TransferCompleteStrings
INFO : DirectoryEmptyMessages = EnterpriseDT.Net.Ftp.DirectoryEmptyStrings
INFO : ConnectMode = PASV
INFO : IsConnected =
INFO : WorkingDirectory =
INFO : ServerDirectory = null
INFO : LocalDirectory = C:\
INFO : SynchronizePassiveConnections = False
INFO : FilePathEncoding =
INFO : ParsingCulture =
INFO : FileInfoParser =
INFO : TimeDifference = 00:00:00
INFO : TimeIncludesSeconds =
INFO : LastValidReply =
INFO : TransferType = BINARY
INFO : AccountInfo = null
INFO : AutoLogin = True
INFO : EventsEnabled =
INFO : UseGuiThreadIfAvailable =
INFO : LastTransferCancelled =
INFO : Container =
DEBUG : Queuing FTP task Connect()
DEBUG : Starting FTP task processor
DEBUG : Running FTP task Connect()
DEBUG : Running task: Connect()
INFO : Licence expiry date: 11/6/2008
INFO : Trial license
ALL : Invoking delegate EnterpriseDT.Net.Ftp.FTPConnectionEventHandler -> InuGeReBZBqiHJsKatt.M7N1Bxe2ZcHbKcfYMwx.FwtxKcqwP
ALL : Have GUI control
ALL : GUI control invocation required
ALL : Invoking delegate asynchronously using GUI control
INFO : Licence expiry date: 11/6/2008
INFO : Trial license
DEBUG : Connecting to sftp01.af-group.com:21
DEBUG : sftp01.af-group.com resolved to 24.249.236.140
DEBUG : waitOnShutdownSSL=True
DEBUG : Connecting directly to ftp-server 24.249.236.140:21
DEBUG : Setting socket timeout=120000
DEBUG : Set timeout=120000
DEBUG : Set timeout=120000
DEBUG : Command encoding=System.Text.ASCIIEncoding
DEBUG : Created control-socket: SocksContext=, ProxySettings=NoProxy, RemoteHost=24.249.236.140, controlPort=21, timeout=120000
DEBUG : StrictReturnCodes=False
DEBUG : 220-Hello, Welcome to AF SecureTransport!
DEBUG : 220-
DEBUG : 220 Secure FTP Server
DEBUG : Changing local working directory to C:\
DEBUG : ---> AUTH TLS
DEBUG : ready.
ERROR : Exception in SendCommand : EnterpriseDT.Net.Ftp.MalformedReplyException: Malformed FTP reply: re
EnterpriseDT.Net.Ftp.MalformedReplyException: Malformed FTP reply: re
at EnterpriseDT.Net.Ftp.FTPReply..ctor(String replyCode, String replyText, String[] data)
at EnterpriseDT.Net.Ftp.FTPControlSocket.63qILu0ZS0()
at EnterpriseDT.Net.Ftp.FTPControlSocket.SendCommand(String command)
DEBUG : Stopping FTP task processor.
DEBUG : FTP task processor stopped.
DEBUG : Defaulting to Unix parsing
DEBUG : ---> QUIT
DEBUG : 234 SSLv23/TLSv1
DEBUG : Shutdown(Both)
ALL : Invoking delegate EnterpriseDT.Net.Ftp.FTPConnectionEventHandler -> ANNiyI1WB8nPQG8G8k.hkKSCfAXCcVOE7Qclj.o2h6T1ap7
ALL : Have GUI control
ALL : GUI control invocation required
ALL : Invoking delegate asynchronously using GUI control
ALL : Invoking delegate EnterpriseDT.Net.Ftp.FTPConnectionEventHandler -> ANNiyI1WB8nPQG8G8k.hkKSCfAXCcVOE7Qclj.oLkEUFunh
ALL : Have GUI control
ALL : GUI control invocation required
ALL : Invoking delegate asynchronously using GUI control
ERROR : Error event while executing Connect - notifying Error event-handlers
ALL : Invoking delegate EnterpriseDT.Net.Ftp.FTPErrorEventHandler -> ANNiyI1WB8nPQG8G8k.hkKSCfAXCcVOE7Qclj.0sggA0JIB
ALL : Have GUI control
ALL : GUI control invocation required
ALL : Invoking delegate asynchronously using GUI control
ERROR : Event-handlers notified successfully
DEBUG : FTP task completed Connect()
ERROR : Connection Error : EnterpriseDT.Net.Ftp.MalformedReplyException: Malformed FTP reply: re
EnterpriseDT.Net.Ftp.MalformedReplyException: Malformed FTP reply: re
at EnterpriseDT.Net.Ftp.FTPReply..ctor(String replyCode, String replyText, String[] data)
at EnterpriseDT.Net.Ftp.FTPControlSocket.63qILu0ZS0()
at EnterpriseDT.Net.Ftp.FTPControlSocket.SendCommand(String command)
at EnterpriseDT.Net.Ftp.Ssl.SSLFTPClient.Auth(SSLFTPSSLVersion sslVersion, Boolean secureDataChannels)
at EnterpriseDT.Net.Ftp.SecureFTPConnection.SecureConnection()
at EnterpriseDT.Net.Ftp.SecureFTPConnection.Connect()
ERROR : Connection Error : EnterpriseDT.Net.Ftp.MalformedReplyException: Malformed FTP reply: re
EnterpriseDT.Net.Ftp.MalformedReplyException: Malformed FTP reply: re
at EnterpriseDT.Net.Ftp.FTPReply..ctor(String replyCode, String replyText, String[] data)
at EnterpriseDT.Net.Ftp.FTPControlSocket.63qILu0ZS0()
at EnterpriseDT.Net.Ftp.FTPControlSocket.SendCommand(String command)
at EnterpriseDT.Net.Ftp.Ssl.SSLFTPClient.Auth(SSLFTPSSLVersion sslVersion, Boolean secureDataChannels)
at EnterpriseDT.Net.Ftp.SecureFTPConnection.SecureConnection()
at EnterpriseDT.Net.Ftp.SecureFTPConnection.Connect()
ERROR : Connection Error : EnterpriseDT.Net.Ftp.MalformedReplyException: Malformed FTP reply: re
EnterpriseDT.Net

Answer 1

This looks a lot like a problem that our users have encountered a couple of times before. Some routers have a fault in the software that handles FTP, which causes the beginning of some replies to be chopped off. In particular we know that the Netgear VPN router FVS114 has this problem, but quite possibly other routers also have this problem.

One way to try to confirm this is to use WireShark (it's free) to inspect the raw data that your client computer is receiving. If the reply is also chopped then you know that it's not the client software that's at fault. If you can run it on the server as well and you find that the reply is not chopped at that end then you'll know that the problem is in between the server and the client as I suggested.

- Hans (EnterpriseDT)

Answer 2

This looks a lot like a problem that our users have encountered a couple of times before. Some routers have a fault in the software that handles FTP, which causes the beginning of some replies to be chopped off. In particular we know that the Netgear VPN router FVS114 has this problem, but quite possibly other routers also have this problem.

I'm running through a linksys WRT54G version 5 with the latest firmware (jan 08), into a Westell A90-74010-06 DSL Modem/4 port router. I've tested with Firewall's on both disabled and enabled with no difference in results.

One way to try to confirm this is to use WireShark (it's free) to inspect the raw data that your client computer is receiving. If the reply is also chopped then you know that it's not the client software that's at fault. If you can run it on the server as well and you find that the reply is not chopped at that end then you'll know that the problem is in between the server and the client as I suggested.

- Hans (EnterpriseDT)

I'm not very familiar with reading the raw data, so here's the captured converstaion if you can read anything from it. I made it as short as possible. Also, I don't have access to the server to capture from that end.

No. Time Source Destination Protocol Info
1 0.000000 192.168.0.106 24.249.236.140 TCP 10138 > ftp [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2

Frame 1 (66 bytes on wire, 66 bytes captured)
Arrival Time: Oct 28, 2008 16:12:24.075915000
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 66 bytes
Capture Length: 66 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: TCP SYN/FIN]
[Coloring Rule String: tcp.flags & 0x02 || tcp.flags.fin == 1]
Ethernet II, Src: CompalIn_bb:b2:38 (00:1b:38:bb:b2:38), Dst: Cisco-Li_f7:53:bf (00:14:bf:f7:53:bf)
Destination: Cisco-Li_f7:53:bf (00:14:bf:f7:53:bf)
Address: Cisco-Li_f7:53:bf (00:14:bf:f7:53:bf)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: CompalIn_bb:b2:38 (00:1b:38:bb:b2:38)
Address: CompalIn_bb:b2:38 (00:1b:38:bb:b2:38)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.106 (192.168.0.106), Dst: 24.249.236.140 (24.249.236.140)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 52
Identification: 0xc513 (50451)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0xaf18 [correct]
[Good: True]
[Bad : False]
Source: 192.168.0.106 (192.168.0.106)
Destination: 24.249.236.140 (24.249.236.140)
Transmission Control Protocol, Src Port: 10138 (10138), Dst Port: ftp (21), Seq: 0, Len: 0
Source port: 10138 (10138)
Destination port: ftp (21)
Sequence number: 0 (relative sequence number)
Header length: 32 bytes
Flags: 0x02 (SYN)
Window size: 65535
Checksum: 0x7cf0 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (12 bytes)

0000 00 14 bf f7 53 bf 00 1b 38 bb b2 38 08 00 45 00 ....S...8..8..E.
0010 00 34 c5 13 40 00 40 06 af 18 c0 a8 00 6a 18 f9 .4..@.@......j..
0020 ec 8c 27 9a 00 15 6b 55 98 89 00 00 00 00 80 02 ..'...kU........
0030 ff ff 7c f0 00 00 02 04 05 b4 01 03 03 02 01 01 ..|.............
0040 04 02 ..

No. Time Source Destination Protocol Info
2 0.088550 24.249.236.140 192.168.0.106 TCP ftp > 10138 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 WS=0

Frame 2 (66 bytes on wire, 66 bytes captured)
Arrival Time: Oct 28, 2008 16:12:24.164465000
[Time delta from previous captured frame: 0.088550000 seconds]
[Time delta from previous displayed frame: 0.088550000 seconds]
[Time since reference or first frame: 0.088550000 seconds]
Frame Number: 2
Frame Length: 66 bytes
Capture Length: 66 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp]
[Coloring Rule Name: TCP SYN/FIN]
[Coloring Rule String: tcp.flags & 0x02 || tcp.flags.fin == 1]
Ethernet II, Src: Cisco-Li_f7:53:bf (00:14:bf:f7:53:bf), Dst: CompalIn_bb:b2:38 (00:1b:38:bb:b2:38)
Destination: CompalIn_bb:b2:38 (00:1b:38:bb:b2:38)
Address: CompalIn_bb:b2:38 (00:1b:38:bb:b2:38)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Cisco-Li_f7:53:bf (00:14:bf:f7:53:bf)
Address: Cisco-Li_f7:53:bf (00:14:bf:f7:53:bf)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 24.249.236.140 (24.249.236.140), Dst: 192.168.0.106 (192.168.0.106)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 52
Identification: 0x137a (4986)
Flags: 0x00
Fragment offset: 0
Time to live: 113
Protocol: TCP (0x06)
Header checksum: 0x6fb2 [correct]
[Good: True]
[Bad : False]
Source: 24.249.236.140 (24.249.236.140)
Destination: 192.168.0.106 (192.168.0.106)
Transmission Control Protocol, Src Port: ftp (21), Dst Port: 10138 (10138), Seq: 0, Ack: 1, Len: 0
Source port: ftp (21)
Destination port: 10138 (10138)
Sequence number: 0 (relative sequence number)
Acknowledgement number: 1 (relative ack number)
Header length: 32 bytes
Flags: 0x12 (SYN, ACK)
Window size: 64240
Checksum: 0xa4b3 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (12 bytes)
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 1]
[The RTT to ACK the segment was: 0.088550000 seconds]

0000 00 1b 38 bb b2 38 00 14 bf f7 53 bf 08 00 45 00 ..8..8....S...E.
0010 00 34 13 7a 00 00 71 06 6f b2 18 f9 ec 8c c0 a8 .4.z..q.o.......
0020 00 6a 00 15 27 9a 57 f7 85 45 6b 55 98 8a 80 12 .j..'.W..EkU....
0030 fa f0 a4 b3 00 00 02 04 05 b4 01 03 03 00 01 01 ................
0040 04 02 ..

No. Time Source Destination Protocol I

Answer 3

I turned off tcp and ip checksum offloading on my NIC and it cleared up the checksum errors from the previous capture, but I got the same malformed response error trying to connect.

Answer 4

The malformed response is unrelated to routers I think. The key is here:

Reply: 220-Hello, Welcome to AF SecureTransport!
Reply: 220-
Reply: 220 Secure FTP Server
Command: ---> AUTH TLS
Reply: ready.
Command: ---> QUIT
Reply: 234 SSLv23/TLSv1

There's an erroneous "ready" being returned. The reply "234 SSLv23/TLSv1" is what should be returned in response to "AUTH TLS".

And the wireshark log tells me why:

220 Secure FTP Server\r
ready.\r\n

There's a carriage return after "Server", and edtFTPnet/PRO is reading that as the end of the response. I'll take a look at our code ...

Answer 5

Ok we've got a fix ... can you please email us & we'll send you a patched DLL.