Custom Query (7871 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (166 - 168 of 7871)

Ticket Resolution Summary Owner Reporter
#4204 rejected FileZilla Client (Windows) uses IPv6 in preference to IPv4 Chris Jenkins
Description

I have several Windows clients running Windows XP Pro SP3 and Windows Vista SP1. I have FileZilla client 3.2.0 installed. All these machines have a dual IPv4 and IPv6 configuration as I am currently testing IPv6. My DNS server (Windows 2003 Server SP2) returns both IPv4 and IPv6 addresses for my servers when queried.

My FileZilla sever (0.9.30) is running on a Windows XP SP3 machine, also with a valid IPv6 configuration.

When I use the FileZilla client to try and connect to a server for which my DNS server can return both an IPv6 address and an IPv4 address, the FileZilla client always tries to use the IPv6 address in preference to the IPv4 address. This might not be an issue except that the FileZilla server does not seem to listen to/accept connections on its host's IPv6 address. As a result the client is not able to connect. I have tried changing the binding order on the client machines to make IPv4 come before IPv6 but it does not help.

This seems like a bug to me. Surely use of IPv6 should at a minimum only be by explicit request? Ideally one could specify which to use as a default at the client level and maybe also with a host specific override. I imagine mixed environments are becoming quite common and this could become a big problem.

#11686 duplicate Command-line argument (-c, --site=<string>) not working since upgrade to 3.35.0 ChrisL
Description

Command-line argument (-c, --site=<string>) not working since upgrade to 3.35.0. Client does not Connect to specified Site Manager site, it just opens as if no arguments were specified. All works as it used to when I downgrade to 3.34.0

#7788 outdated Enabling TLS 1.2 causes a GnuTLS error -9 ChrisTX
Description

I'm hosting a FTP server with explicit TLS and recently enabled TLS 1.1/1.2 on it. Now a few users reported to me (and I could reproduce this) that they couldn't connect to the server due to a GnuTLS error being displayed. Other clients using GnuTLS (but those are using newer version from what they've told me) or Windows CryptoAPI/CNG (ie SmartFTP) can still connect flawlessy.

Server: IIS 7.5, SSL 3.0, TLS 1.0,1.1,1.2 enabled, explicit mode. (with 1.1/1.2 disabled, it works)

Logs:

Status: Resolving address of rev-crew.info Status: Connecting to x.x.x.x:21... Status: Connection established, waiting for welcome message... Trace: CFtpControlSocket::OnReceive() Response: 220 Microsoft FTP Service Trace: CFtpControlSocket::SendNextCommand() Command: AUTH TLS Trace: CFtpControlSocket::OnReceive() Response: 234 AUTH command ok. Expecting TLS Negotiation. Status: Initializing TLS... Trace: CTlsSocket::Handshake() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnSend() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::Failure(-9, 10053) Error: GnuTLS error -9: A TLS packet with unexpected length was received. Status: Server did not properly shut down TLS connection Trace: CTlsSocket::OnSocketEvent(): close event received Trace: CRealControlSocket::OnClose(10053) Trace: CControlSocket::DoClose(64) Trace: CFtpControlSocket::ResetOperation(66) Trace: CControlSocket::ResetOperation(66) Error: Could not connect to server Trace: CFileZillaEnginePrivate::ResetOperation(66) Status: Waiting to retry... Trace: CControlSocket::DoClose(64) Trace: CControlSocket::DoClose(64)

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