Vivaldi not syncing

DoctorG

@irz said in Vivaldi only syncing when on VPN:

It might be possible to reproduce the issue in a virtual machine using VirtualBox or VMware by assigning an internal address, like 10.0.0.x.

My Mint gets its IP by DHCP from router in IP range 192.168.0.x.

You mean, if i should give the VM guest the IP 10.0.2.xx?

est@minze:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:74:90:93 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute enp0s3
       valid_lft 86301sec preferred_lft 86301sec
    inet6 fe80::a3c3:4ef6:1992:8166/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever


est@minze:~$ ip route
default via 10.0.2.2 dev enp0s3 proto dhcp metric 100 
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100 
169.254.0.0/16 dev enp0s3 scope link metric 1000

And which gateway?
And which /etc/resolv.conf?

I will try if Vivaldi will not work with Sync.

irz

@DoctorG Here is my output:

irz@deb:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:22:48:19:38:2d brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.4/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::222:48ff:fe19:382d/64 scope link 
       valid_lft forever preferred_lft forever

irz@deb:~$ ip route
default via 10.0.0.1 dev eth0 
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.4 
169.254.169.254 via 10.0.0.1 dev eth0

irz@deb:~$ cat /etc/resolv.conf 
nameserver 1.1.1.1
nameserver 8.8.8.8

I'm sorry that I can't provide a complete solution that can be guaranteed to be perfectly reproduced. If you can't reproduce it, I will try to find other ways. Thank you for your help!

kaleh

@DoctorG
I face the same issue: Vivaldi Sync works only through VPN.
My ip a output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp8s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether b4:2e:99:3b:d8:11 brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether a2:ff:0c:84:96:69 brd ff:ff:ff:ff:ff:ff permaddr 3c:f0:11:b2:cb:c2
4: enp6s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether a0:36:9f:b3:28:ec brd ff:ff:ff:ff:ff:ff
    inet <myIP>/24 brd xxx.xxx.xxx.255 scope global noprefixroute enp6s0f0
       valid_lft forever preferred_lft forever
    inet6 <myIP>/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: enp6s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether a0:36:9f:b3:28:ed brd ff:ff:ff:ff:ff:ff
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:01:84:35 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever

My ip route output:

default via xxx.xxx.xxx.1 dev enp6s0f0 proto static metric 100 
xxx.xxx.xxx.0/24 dev enp6s0f0 proto kernel scope link src xxx.xxx.xxx.xxx metric 100 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

My cat /etc/resolv.conf output:

# Generated by NetworkManager
nameserver xxx.xxx.2.5
nameserver xxx.xxx.2.3

nataliya57s

about:sync
Trigger GetUpdates()

DoctorG

I could not match a network setting on Mint 21.3 where Vivaldi Sync failed.

All my Ubuntu-alike Linux installations work without a VPN and Vivaldi syncs.

DoctorG

@kaleh I am not able to tell why your Networkmanager is acting like this and not letting Vivaldi connect.

DoctorG

@irz said in Vivaldi only syncing when on VPN:

Please let me emphasize again: I can sync normally on Windows. And on Debian 12, 6.6.3271.61-1 and earlier versions can also sync normally, so it’s impossible that my network is blocking the sync.

Debian 12 and Windows are not comparable in network management.

If it works on Debian 12 and Windows your network configuration/Netwrok Manager is acting strange.
Had you tried to ask in a Mint forum how to debug this?
I can not give support for Mint.

kaleh

Thank you for looking into it. Would there be an option within Vivaldi to use a proxy or something for syncing?

DoctorG

@kaleh said in Vivaldi only syncing when on VPN:

Would there be an option within Vivaldi to use a proxy or something for syncing?

Vivaldi uses the global system proxy for http&https which is set in Linux.

irz

Good news!

I have figured out the cause of this issue and how to resolve it.

First of all, the ERR_TIMED_OUT error indicates that the browser successfully sent a request to Bifrost, but Bifrost did not respond to the request.

However, I can get a correct response by using curl https://bifrost.vivaldi.com/vivid-sync, which allows me to maintain a connection to Bifrost for a while and successfully sync. However, after the connection validity (lasting about 5 to 10 minutes) expires, syncing fails.

Using curl -v https://bifrost.vivaldi.com/vivid-sync to check the connection debug info

*   Trying 31.209.137.10:443...
* Connected to bifrost.vivaldi.com (31.209.137.10) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=bifrost.vivaldi.com
*  start date: Aug 25 05:40:37 2024 GMT
*  expire date: Nov 23 05:40:36 2024 GMT
*  subjectAltName: host "bifrost.vivaldi.com" matched cert's "bifrost.vivaldi.com"
*  issuer: C=US; O=Let's Encrypt; CN=R10
*  SSL certificate verify ok.
* using HTTP/1.x
> GET /vivid-sync HTTP/1.1
> Host: bifrost.vivaldi.com
> User-Agent: curl/7.88.1
> Accept: */*

I found that Bifrost does not support TLSv1.3 and only supports TLSv1.2. This can be verified by forcing TLSv1.3 with curl -v --tlsv1.3 https://bifrost.vivaldi.com/vivid-sync

*   Trying 31.209.137.10:443...
* Connected to bifrost.vivaldi.com (31.209.137.10) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS alert, handshake failure (552):
* OpenSSL/3.0.14: error:0A000410:SSL routines::sslv3 alert handshake failure
* Closing connection 0
curl: (35) OpenSSL/3.0.14: error:0A000410:SSL routines::sslv3 alert handshake failure

However, other Vivaldi services such as downloads.vivaldi.com and mimir.vivaldi.com can be connected using TLSv1.3.

So I suspect that Chromium-based browsers on my devices (Debian 12) are forcing TLSv1.3 for any connection and are unable to connect to sites that only using TLSv1.2.

To verify this, I launched Vivaldi with vivaldi --ssl-version-max=tls1.2, which disables TLSv1.3 and forces TLSv1.2. After doing this, I was able to sync normally, just like on my other devices, confirming my suspicion! (@kaleh please try this!)

As for why Chromium-based browsers on my devices (Debian 12) are unable to use TLSv1.2, I'm still trying to find the cause. Since I can still get a proper response from Bifrost using the curl command, the issue definitely isn't with the OS itself. At the very least, this is caused by the interaction between the Chromium-based browser and the OS, because in versions prior to v124, I was able to connect using TLSv1.2 directly.

This issue has been bothering me for a long time. While using a proxy to sync isn’t too much of a hassle, I still prefer syncing directly. I happened to come across this topic and hope it can lead to a proper fix.

For now, I can sync normally by disabling TLSv1.3, but this also means I can't access sites that only support TLSv1.3.

It would be great if Vivaldi's sync service could enable TLSv1.3 support, and it would be even better if I could find out why the Chromium-based browser on my devices (Debian 12) is forcing the use of TLSv1.3.

Thank you for your help! If no one replies to me, I might not have been willing to persist in finding a solution to this issue. I have already spent a lot of time on this issue, and I’m really exhausted.

irz

@DoctorG sorry I forgot to click the reply button, please see my last post.

DoctorG

@irz said in Vivaldi only syncing when on VPN:

So I suspect that Chromium-based browsers on my devices (Debian 12) are forcing TLSv1.3 for any connection

I do not know that Debian 12 forces TLSv1.3.
And i do not know that Vivaldi forces TLSv1.3 for Sync connects.

DoctorG

@irz @kaleh @LazyLama How have you installed Vivaldi?
Snap-, Deb- or Flatpak-package?

irz

@DoctorG It's not about Vivaldi. It's about Chromium-based
I install and upgrade Vivaldi via .deb and apt upgrade

LazyLama

@DoctorG said in Vivaldi only syncing when on VPN:

@irz said in Vivaldi only syncing when on VPN:

So I suspect that Chromium-based browsers on my devices (Debian 12) are forcing TLSv1.3 for any connection

I do not know that Debian 12 forces TLSv1.3.
And i do not know that Vivaldi forces TLSv1.3 for Sync connects.

I installed Vivaldi from a deb package downloaded from the Vivaldi website.

@irz, great detective work. For now, I have an sh script on my computer that runs the curl command before running Vivaldi. I could update the script to call Vivaldi using the command-line options you suggested. Or can TLSv1.3 be disabled somewhere in the settings?

DoctorG

@LazyLama said in Vivaldi only syncing when on VPN:

Or can TLSv1.3 be disabled somewhere in the settings?

Not in Vivaldis normal settings.

Have you changed something in vivaldi://flags ?

LazyLama

@DoctorG said in Vivaldi only syncing when on VPN:

Have you changed something in vivaldi://flags ?

No. I didn't even know that existed

DoctorG

@LazyLama OK, nothing changed. Fine.

Why i asked? Some users change there and forget after a while they did a change.

DoctorG

@irz said in Vivaldi only syncing when on VPN:

It's not about Vivaldi. It's about Chromium-based

Then there is a startup setting made by a program (not Vivaldi!) in folder /etc/chromium which could causes the forced TLS 1.3.

irz

@LazyLama Or you could add the curl command as a crontab running per 5 mins or 10 mins or more longer, so that you don't need any scripts