Custom Query (8117 matches)
Results (220 - 222 of 8117)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #12426 | worksforme | FileZilla 3.53 kills my ubuntu 20.04 network-manager | ||
| Description |
This is an very awkward problem.It's been annoying me on my notebook for 5 months now and when it started on my local server as well I can now track it down to the install of Filezilla 3.53.1. First things first. My laptop started to fail to boot into network. After some log search I always dig the following error message from syslog: Apr 15 16:50:31 Quietearth2 NetworkManager[1244]: /usr/sbin/NetworkManager: symbol lookup error: /lib/x86_64-linux-gnu/libcurl-gnutls.so.4: undefined symbol: gnutls_srp_allocate_client_credentials, version GNUTLS_3_4 Removing /usr/local/lib/libgnutls.so.30 makes network manager start again. Now the same error ocurred on the reboot of my server after the recent first time installation of filezilla client. And the same workaround made Network-Manager start again. It is the lib that came with filezilla. My laptop is a Kubuntu 20.04.2 Thinkpad T460, my server is an Ubuntu 20.04.2 Dell Optiplex 7040 I downloaded the tarball of the client and copied the files from bin, lib und share in /usr/local respectively. If I can provide further system info and logs, feel free to ask. I suspect the libsqlite3.so.0 to have a similar problem but I can not provide the same clear evidence as above. |
|||
| #12424 | fixed | libfilezilla 0.27.1 - fails tring_test::test_conversion2 test (ppc64, Big Endian) | ||
| Description |
This is downstream Gentoo bug 760944 (https://bugs.gentoo.org/760944). string_test::test_conversion2 fails at least since libfilezilla 0.25.0 so I thought it would be a good idea to take this issue upstream. ===============================================
=============================================== # TOTAL: 2 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test ========== ...................F............. !!!FAILURES!!! Test Results: Run: 32 Failures: 1 Errors: 0 1) test: string_test::test_conversion2 (F) line: 66 string.cpp assertion failed
FAIL test (exit status: 1) ===============================================
=============================================== # TOTAL: 2 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test ========== ........................F.............. !!!FAILURES!!! Test Results: Run: 38 Failures: 1 Errors: 0 1) test: string_test::test_conversion2 (F) line: 66 string.cpp assertion failed
FAIL test (exit status: 1) |
|||
| #12421 | worksforme | Passive mode not honoring first connection IP when using proxy | ||
| Description |
Hello, I'd like to understand if this is a bug - it does very much look like one to me. Scenario: FTP server behind NAT Behavior without proxy: When using FTP passive mode, and the server replies with its real IP address, Filezilla ignores it, uses the original IP instead, and uses the port for data connection. This is absolutely correct. Behavior with proxy: When using FTP passive mode, and the server replies with its real IP address, Filezilla send a new request to the proxy but uses the server reply. The proxy tries to contact the server's real IP, and (in most scenarios) fails. I found this issue with FTPS, not plain FTP, but the implementation might be the same. It doesn't help that the traffic is encrypted, otherwise I could have found some workaround. But with encrypted traffic I have no chance to do so. BR, Miguel |
|||
