Transmission 'Could not connect to tracker' ONLY HTTP tracker (UDP are ok)

Installing and Using OpenWrt
1

Hi guys.

For years in my home I used a Linksys WRT1900ACS with Openwrt build by community (user davidc502).
Transmission-daemon run into router worked perfectly since last Davidc502 build (about r12800 ,May 2020, davidc502 stopped his developement).

From that release and newer, Transmission has problem to connect to http (and https) trackers. Log shows always "Could not connect to tracker (announcer.c:1085)".

On the contrary UDP trackers work very fine. It looks that only http/https are not working. I've tried many many trackers with the same results: http not working, udp yes.

From the router console if I try to connect the tracker http url using wget or curl (i.e. curl -v http://tracker.example.org/a/401111111111111111430e6c4d/announce ), the connection is fine even if the tracker is on tcp port 80 or something different tcp port. It's looks not a firewall problem.

If I run Transmission in a PC inside my LAN, http/https tracker are working fine.

During these days I build myself from scratch a new OpenWRT image and now I'm running r15880 with transmission 3.00. All works fine but the Transmission problem is the same. I've reconfigured all new image parameters by hand from a fresh and clean installation (I've not use my previous config).

So I'm very confused: only trasmission-daemon running into router cannot connect http.

Any idea ?

Thanks in advance for any suggestion :innocent:

2

I see this error in transmission logs:
[2021-02-24 20:44:15.952] web will verify tracker certs using envvar CURL_CA_BUNDLE: none (web.c:456)
[2021-02-24 20:44:15.952] web NB: this only works if you built against libcurl with openssl or gnutls, NOT nss (web.c:457)
[2021-02-24 20:44:15.952] web NB: invalid certs will show up as 'Could not connect to tracker' like many other errors (web.c:458)

It's possible that incorrect CERTS can block https AND also http ??

3

You don't have any certs installed, therefore it cannot verify them. No public certs can be verified, no matter where they're presented.

1 Like
4

Dear @lleachii

  1. I've problem with HTTP (and HTTPS). Forget HTTPS. I suppose that HTTP doesn't use ssl certs. Right or wrong ?

  2. If I set CURL_CA_BUNDLE = /etc/ssl/certs nothing change: always the same problem.

  3. My /etc/ssl/certs/*
    ACCVRAIZ1.crt
    AC_RAIZ_FNMT-RCM.crt
    Actalis_Authentication_Root_CA.crt
    AffirmTrust_Commercial.crt
    AffirmTrust_Networking.crt
    AffirmTrust_Premium.crt
    AffirmTrust_Premium_ECC.crt
    Amazon_Root_CA_1.crt
    Amazon_Root_CA_2.crt
    Amazon_Root_CA_3.crt
    Amazon_Root_CA_4.crt
    Atos_TrustedRoot_2011.crt
    Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt
    Baltimore_CyberTrust_Root.crt
    Buypass_Class_2_Root_CA.crt
    Buypass_Class_3_Root_CA.crt
    CA_Disig_Root_R2.crt
    CFCA_EV_ROOT.crt
    COMODO_Certification_Authority.crt
    COMODO_ECC_Certification_Authority.crt
    COMODO_RSA_Certification_Authority.crt
    Certigna.crt
    Certigna_Root_CA.crt
    Certum_Trusted_Network_CA.crt
    Certum_Trusted_Network_CA_2.crt
    Chambers_of_Commerce_Root_-2008.crt
    Comodo_AAA_Services_root.crt
    Cybertrust_Global_Root.crt
    D-TRUST_Root_Class_3_CA_2_2009.crt
    D-TRUST_Root_Class_3_CA_2_EV_2009.crt
    DST_Root_CA_X3.crt
    DigiCert_Assured_ID_Root_CA.crt
    DigiCert_Assured_ID_Root_G2.crt
    DigiCert_Assured_ID_Root_G3.crt
    DigiCert_Global_Root_CA.crt
    DigiCert_Global_Root_G2.crt
    DigiCert_Global_Root_G3.crt
    DigiCert_High_Assurance_EV_Root_CA.crt
    DigiCert_Trusted_Root_G4.crt
    E-Tugra_Certification_Authority.crt
    EC-ACC.crt
    Entrust.net_Premium_2048_Secure_Server_CA.crt
    Entrust_Root_Certification_Authority.crt
    Entrust_Root_Certification_Authority    -EC1.crt
    Entrust_Root_Certification_Authority    -G2.crt
    Entrust_Root_Certification_Authority    -G4.crt
    GDCA_TrustAUTH_R5_ROOT.crt
    GTS_Root_R1.crt
    GTS_Root_R2.crt
    GTS_Root_R3.crt
    GTS_Root_R4.crt
    GeoTrust_Primary_Certification_Authority    -G2.crt
    GlobalSign_ECC_Root_CA    -R4.crt
    GlobalSign_ECC_Root_CA    -R5.crt
    GlobalSign_Root_CA.crt
    GlobalSign_Root_CA    -R2.crt
    GlobalSign_Root_CA    -R3.crt
    GlobalSign_Root_CA    -R6.crt
    Global_Chambersign_Root    -2008.crt
    Go_Daddy_Class_2_CA.crt
    Go_Daddy_Root_Certificate_Authority    -G2.crt
    Hellenic_Academic_and_Research_Institutions_ECC_RootCA_2015.crt
    Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt
    Hellenic_Academic_and_Research_Institutions_RootCA_2015.crt
    Hongkong_Post_Root_CA_1.crt
    Hongkong_Post_Root_CA_3.crt
    ISRG_Root_X1.crt
    IdenTrust_Commercial_Root_CA_1.crt
    IdenTrust_Public_Sector_Root_CA_1.crt
    Izenpe.com.crt
    Microsec_e-Szigno_Root_CA_2009.crt
    Microsoft_ECC_Root_Certificate_Authority_2017.crt
    Microsoft_RSA_Root_Certificate_Authority_2017.crt
    NAVER_Global_Root_Certification_Authority.crt
    NetLock_Arany    =Class_Gold=Főtanúsítvány.crt
    Network_Solutions_Certificate_Authority.crt
    OISTE_WISeKey_Global_Root_GB_CA.crt
    OISTE_WISeKey_Global_Root_GC_CA.crt
    QuoVadis_Root_CA.crt
    QuoVadis_Root_CA_1_G3.crt
    QuoVadis_Root_CA_2.crt
    QuoVadis_Root_CA_2_G3.crt
    QuoVadis_Root_CA_3.crt
    QuoVadis_Root_CA_3_G3.crt
    SSL.com_EV_Root_Certification_Authority_ECC.crt
    SSL.com_EV_Root_Certification_Authority_RSA_R2.crt
    SSL.com_Root_Certification_Authority_ECC.crt
    SSL.com_Root_Certification_Authority_RSA.crt
    SZAFIR_ROOT_CA2.crt
    SecureSign_RootCA11.crt
    SecureTrust_CA.crt
    Secure_Global_CA.crt
    Security_Communication_RootCA2.crt
    Security_Communication_Root_CA.crt
    Sonera_Class_2_Root_CA.crt
    Staat_der_Nederlanden_EV_Root_CA.crt
    Staat_der_Nederlanden_Root_CA    -G3.crt
    Starfield_Class_2_CA.crt
    Starfield_Root_Certificate_Authority    -G2.crt
    Starfield_Services_Root_Certificate_Authority    -G2.crt
    SwissSign_Gold_CA    -G2.crt
    SwissSign_Silver_CA    -G2.crt
    T-TeleSec_GlobalRoot_Class_2.crt
    T-TeleSec_GlobalRoot_Class_3.crt
    TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi    -_Surum_1.crt
    TWCA_Global_Root_CA.crt
    TWCA_Root_Certification_Authority.crt
    TeliaSonera_Root_CA_v1.crt
    TrustCor_ECA-1.crt
    TrustCor_RootCert_CA-1.crt
    TrustCor_RootCert_CA-2.crt
    Trustis_FPS_Root_CA.crt
    Trustwave_Global_Certification_Authority.crt
    Trustwave_Global_ECC_P256_Certification_Authority.crt
    Trustwave_Global_ECC_P384_Certification_Authority.crt
    UCA_Extended_Validation_Root.crt
    UCA_Global_G2_Root.crt
    USERTrust_ECC_Certification_Authority.crt
    USERTrust_RSA_Certification_Authority.crt
    VeriSign_Universal_Root_Certification_Authority.crt
    XRamp_Global_CA_Root.crt

5

SOLVED !!!
It was a simple (and stupid) configuration issue.

My settings.json has:
"bind-address-ipv4": "0.0.0.0"
"rpc-bind-address": "0.0.0.0" (but rpc was working correctly. Mumble mumble).

Well if I change with router LAN IP:
"bind-address-ipv4": "192.168.1.1"
"rpc-bind-address": "192.168.1.1"

HTTP/HTTPS connection to trackers works fine !

I've discovered this enabling TR_CURL_VERBOSE:
export TR_CURL_VERBOSE =1 ; transmission-daemon -f -g --log-debug /my/p2p/dir
and I see some "cannot bind 0.0.0.0" messages.
So I change 0.0.0.0 with 192.168.1.1 and BINGO ! All works.

6
7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.