jamesmcm / vopono

Run applications through VPN tunnels with temporary network namespaces
GNU General Public License v3.0
888 stars 46 forks source link

Mullvad sync fails (error decoding response body) #180

Closed hashworks closed 2 years ago

hashworks commented 2 years ago

Trying to sync Mullvad results in a failure to decode the response body.

$ vopono -v sync
Which VPN providers do you wish to synchronise? Press Space to select and Enter to continue: Mullvad
 2022-08-18T16:43:05.210Z INFO  vopono::sync > Starting Wireguard configuration...
 2022-08-18T16:43:05.210Z DEBUG vopono_core::util > Using config dir from $HOME config: /home/hashworks/.config
 2022-08-18T16:43:05.210Z DEBUG reqwest::connect  > starting new connection: https://api.mullvad.net/
 2022-08-18T16:43:05.244Z DEBUG rustls::client::hs > No cached session for DnsName(DnsName(DnsName("api.mullvad.net")))
 2022-08-18T16:43:05.244Z DEBUG rustls::client::hs > Not resuming any session
 2022-08-18T16:43:05.280Z DEBUG rustls::client::hs > Using ciphersuite TLS13_AES_256_GCM_SHA384
 2022-08-18T16:43:05.280Z DEBUG rustls::client::tls13 > Not resuming
 2022-08-18T16:43:05.280Z DEBUG rustls::client::tls13 > TLS1.3 encrypted extensions: [ServerNameAck, Protocols([6832])]
 2022-08-18T16:43:05.280Z DEBUG rustls::client::hs    > ALPN protocol is Some(b"h2")
 2022-08-18T16:43:05.280Z DEBUG rustls::client::tls13 > Got CertificateRequest CertificateRequestPayloadTLS13 { context: , extensions: [SignatureAlgorithms([ECDSA_NISTP256_SHA256, ECDSA_NISTP384_SHA384, ECDSA_NISTP521_SHA512, ED25519, ED448, Unknown(2057), Unknown(2058), Unknown(2059), RSA_PSS_SHA256, RSA_PSS_SHA384, RSA_PSS_SHA512, RSA_PKCS1_SHA256, RSA_PKCS1_SHA384, RSA_PKCS1_SHA512, Unknown(771), Unknown(769)]), AuthorityNames([30523110300e060355040a0c074d756c6c766164311d301b06035504030c1473652d6d6d612d6170692d6e67696e782d303031311f301d06092a864886f70d0109010c10696e666f406d756c6c7661642e6e6574])] }
 2022-08-18T16:43:05.280Z DEBUG rustls::client::common > Client auth requested but no cert/sigscheme available
 2022-08-18T16:43:05.340Z DEBUG rustls::client::tls13  > Ticket saved
 2022-08-18T16:43:05.340Z DEBUG rustls::client::tls13  > Ticket saved
 2022-08-18T16:43:05.448Z DEBUG reqwest::async_impl::client > response '200 OK' for https://api.mullvad.net/www/relays/wireguard/
Error: error decoding response body: invalid type: null, expected a string at line 1 column 35628

Caused by:
    invalid type: null, expected a string at line 1 column 35628

Might be the "socks_name":null?

jamesmcm commented 2 years ago

This is strange, as I just tried it myself and it worked fine. But I also have no nulls in the response :thinking:

Can you provide the full response maybe? I wonder if it is account or location specific?

hashworks commented 2 years ago

Yeah, looks like it's fixed now. Could've just been a hickup on mullvads side?

I guess we could close this, or keep it open for a PR that implements null-checks just to be sure.

jamesmcm commented 2 years ago

Yeah, the issue it seems the relay data was actually bad too though, so I'd rather it just throw an irrecoverable error in this case.

I'll look at adding a better error message if it fails to parse though!