Custom Query (8117 matches)
Results (442 - 444 of 8117)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#7837 | fixed | Problem Uploading via FTPS. | ||
Description |
I recently installed Fedora 16 onto my laptop. Since then I have been having trouble uploading over FTPS. This affects both FTPS and FTPES modes, and only affects uploads. What happens is that the upload proceeds for only a few Kilobytes, then the connection times out and the upload resumes (REST). For another few Kilobytes, then times out again. Et. Cetera. Trying an older version of FileZilla on Ubuntu works fine. However, an older version of FileZilla on Fedora still fails. My guess is that the problem might be due to the version of GnuTLS on Fedora, but this is only a guess. Below are the details of the versions of FileZilla I have tested. Fedora (not working): FileZilla Client Version: 3.5.1 Build information:
Linked against:
Operating system:
Ubuntu (working): FileZilla Client Version: 3.3.5.1 Build information:
Linked against:
Operating system:
I have two log files attached. ftp-log-working.txt shows the log from the Ubuntu client performing a successful upload. ftp-log-broken.txt shows the log from the Fedora client. In the broken log, you can see the problem spot: -- 12:25:35 Response: 150 File status okay. About to open data connection. 12:25:35 Trace: CFtpControlSocket::TransferParseResponse() 12:25:35 Trace: code = 1 12:25:35 Trace: state = 4 12:25:35 Trace: CFtpControlSocket::SendNextCommand() 12:25:35 Trace: CFtpControlSocket::TransferSend() 12:25:35 Trace: state = 5 12:25:35 Trace: CTlsSocket::OnRead() 12:25:35 Trace: CTlsSocket::ContinueHandshake() 12:25:35 Trace: Handshake successful 12:25:35 Trace: Session resumed 12:25:35 Trace: Cipher: AES-256-CBC, MAC: SHA1 12:25:35 Trace: CTransferSocket::OnConnect 12:25:35 Trace: First EAGAIN in CTransferSocket::OnSend() 12:26:15 Error: Connection timed out -- But in the working log you see: -- 07:24:55 Response: 150 File status okay. About to open data connection. 07:24:55 Trace: CFtpControlSocket::TransferParseResponse() 07:24:55 Trace: code = 1 07:24:55 Trace: state = 4 07:24:55 Trace: CFtpControlSocket::SendNextCommand() 07:24:55 Trace: CFtpControlSocket::TransferSend() 07:24:55 Trace: state = 5 07:24:55 Trace: CTlsSocket::OnRead() 07:24:55 Trace: CTlsSocket::ContinueHandshake() 07:24:55 Trace: Handshake successful 07:24:55 Trace: Session resumed 07:24:55 Trace: Cipher: AES-256-CBC, MAC: SHA1 07:24:55 Trace: CTransferSocket::OnConnect 07:24:55 Trace: First EAGAIN in CTransferSocket::OnSend() 07:24:55 Trace: CTlsSocket::OnSend() 07:24:55 Trace: Made progress in CTransferSocket::OnSend() 07:24:56 Trace: CTlsSocket::OnSend() 07:24:56 Trace: CTlsSocket::OnSend() ... -- CTlsSockt::OnSend() continues until I cancel the transfer. I am not sure why the broken log stops after the EAGAIN error. Please let me know if I can provide any other information that might be useful. |
|||
#7855 | fixed | Cannot Connect to Server | ||
Description |
This is my Server Information Platform Type Debian MySQL Version 5.0.91 Perl Version 5.8.8 PHP Version 5.2.2 Path to SendMail /usr/sbin/sendmail Path to Perl /usr/bin/perl Path to PHP /usr/local/bin/php This is the message I get on Filezilla Status: Resolving address of ftp.xxxxxxxxxxxxxxxxxx.net Status: Connecting to 000.000.000.00:00... Status: Connection attempt failed with "ETIMEDOUT - Connection attempt timed out". Error: Could not connect to server Status: Waiting to retry... Status: Resolving address of ftp.xxxxxxxxxxxxxxxxxx.net Status: Connecting to 000.000.000.00:00... Status: Connection attempt failed with "ETIMEDOUT - Connection attempt timed out". Error: Could not connect to server I took out my website name and the IP address. Am I having problems connecting because my host servers are Debian? I seen that mentioned on here Please let me know whatever the problem is. Maybe my web host, ISP, or my firewall, home network. I really don't have a clue. |
|||
#7864 | fixed | Signature Algorithms extension of ClientHello incomplete. | ||
Description |
FileZilla Client sends a TLSv1.2 (RFC 5246) ClientHello. TLSv1.2 requires servers to accept a Signature Algorithms extension on a ClientHello message, and gives the client the option to omit it if it desires the default (usually SHA1/RSA--see the RFC). FileZilla (using GnuTLS) is sending only one Signature Algorithms extension value--SHA512/RSA (6/1). This will cause a TLSV1.2 aware server to reject the ClientHello if it does not posses a SHA512/RSA signed certificate. Originally I thought this was a GnuTLS problem, so I sent this e-mail to them: "Hello, I have been working on the implementation of the TLS 1.2 protocol. TLS 1.2 requires servers to handle the Signature Algorithms extension to the ClientHello handshake message. My reading of RFC 5246 (7.4.1.4.1.) indicates that if client presents the extension (it can be omitted) it should include all hash/signature algorithm pairs the client is willing to process. While running the latest version of FileZilla, which uses GnuTLS 2.10.4, the only proposed Signature Algorithm is {SHA512,RSA}. If I stick with the RFC, the handshake will fail, as my {SHA1,RSA} signed certificate is not in the list. I’m not saying Microsoft is always right (in this case I think they are), but IE8/Win7 sends 7 Signature Algorithms in the extension: {SHA256,RSA},{SHA384,RSA},{SHA1,RSA},{SHA256,ECDSA},{SHA384,ECDSA},{SHA1,ECDSA},{SHA1,DSA}." The response I received from the GnuTLS developers was this: "Hello, This is a configuration issue. Filezilla for some reason unknown to me only enables 256-bit ciphersuites and signature algorithms. If you use gnutls-cli with your server you'll see that gnutls sends all options." |