Custom Query (8164 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (442 - 444 of 8164)

Ticket Resolution Summary Owner Reporter
#7837 fixed Problem Uploading via FTPS. Ben Timby
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:

Compiled for: x86_64-redhat-linux-gnu Compiled on: x86_64-redhat-linux-gnu Build date: 2011-08-31 Compiled with: gcc (GCC) 4.6.1 20110804 (Red Hat 4.6.1-7) Compiler flags: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -g -fexceptions -std=gnu++0x

Linked against:

wxWidgets: 2.8.12 GnuTLS: 2.12.7

Operating system:

Name: Linux 3.1.1-1.fc16.x86_64 x86_64 Version: 3.1

  • Note, I also tried version 3.3.3 on Fedora 16 with the same result.

Ubuntu (working):

FileZilla Client


Version: 3.3.5.1

Build information:

Compiled for: x86_64-pc-linux-gnu Compiled on: x86_64-pc-linux-gnu Build date: 2010-12-12 Compiled with: gcc (Ubuntu/Linaro 4.5.1-12ubuntu1) 4.5.2 Compiler flags: -g -O2 -Wall -g -fexceptions

Linked against:

wxWidgets: 2.8.11 GnuTLS: 2.8.6

Operating system:

Name: Linux 2.6.38-12-generic x86_64 Version: 2.6

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 NaviPrince
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. Jim Heit
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."

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.