Vivaldi not syncing

LazyLama

@Pathduck I did the tcpdump before and after running the curl command. So, without syncing working (before the curl command) and with syncing working (after curl).

The only difference I can see is that when things don't work, the host used differs from when things work. So, somehow, running the curl command changes how my ISP (in fact, my institution) handles my internet traffic.

So, what is see is before curl
ucfsu.xxx.xxx.xxx.56938 > 31.209.137.10.https
and
windows-j5s3qlt.xxx.xxx.xxx.34758 > 31.209.137.10.https
after curl.

(I have replaced some identifying parts of the strings with x's).

Maybe I should just write an sh script that runs the curl command before starting Vivaldi.

Pathduck

@LazyLama said in Vivaldi only syncing when on VPN:

in fact, my institution

So there's a clue, and a good one. You're on an enterprise network, probably proxied, firewalled and NAT'ed to hell and back.

Why it would change your client hostname I have no idea, you'd have to ask your IT people.
But the target IP and port is the same so should work no matter.
But if the client host is changed then the return packets have no way of making it back to the client over the NAT'ed firewall/proxy, and you'd get a timeout.

Talk to your IT people. If Vivaldi is at all supported by your company/institution. Knowing most IT depts. they will just say they don't support it and that's that. "We only support major browsers."

Still a capture from net-export would be interesting to see, but then again you X'd out your hostname so such a log would probably contain more than you're willing/allowed to share. So you'll need to analyze it yourself I guess

LazyLama

@Pathduck said in Vivaldi only syncing when on VPN:

Still a capture from net-export would be interesting to see, but then again you X'd out your hostname so such a log would probably contain more than you're willing/allowed to share. So you'll need to analyze it yourself I guess

I appreciate your offer. However, I am not sure whether my institute would appreciate me sharing these logs

irz

I have tried launching Vivaldi with the command:

vivaldi --host-resolver-rules="MAP bifrost.vivaldi.com 31.209.137.10"

but I still can't sync

In the same network environment, Vivaldi sync works fine on Windows OS

DoctorG

Could be a hardware firewall appliance which checks behavior of requesting connections by rules. Who knows.

irz

I compared the logs captured via chrome://net-export on Debian 12 and Windows under the same network environment.

After opening the log files on https://netlog-viewer.appspot.com, I noticed that in the DNS section, Debian 12 doesn't have any entries for bifrost.vivaldi.com, regardless of whether sync works properly.

On Windows, however, the DNS logs do include bifrost.vivaldi.com.

The records that are present in both logs include login.vivaldi.net, mimir2.vivaldi.com, and downloads.vivaldi.com.

DoctorG

Perhaps some settings for DNS are managed in your LAN?
Check internal pages

vivaldi://policy
vivaldi://management

irz

I searched through previous forum posts and found that this issue indeed started from version 6.7. The last version of 6.6, which is 6.6.3271.61 (Stable channel), was able to sync without any problems. However, starting from the first version of 6.7, which is 6.7.3329.17 (Stable channel), syncing no longer works.

From these two forum posts https://forum.vivaldi.net/topic/97615/vivaldi-on-linux-sync-broken https://forum.vivaldi.net/topic/97482/initializing-sync-stalled-new-version, it appears that the sync error started around May of this year, corresponding to the update from Chromium v122 to Chromium v124. I am certain that this sync issue is caused by the Chromium update.

Therefore, I downloaded several Chromium-based browsers for testing. The test focused on whether I could directly open https://bifrost.vivaldi.com/vivid-sync. Here are the test results:

The last version of google-chrome-unstable that could open the webpage directly is 124.0.6342.3-1. Information from chrome://version

Google Chrome: 124.0.6342.3 (Official Build) dev (64-bit)
Revision: 144c1c9bfe50c83a7304a43491a071f2befefdeb-refs/branch-heads/6342@{#7}
OS: Linux
JavaScript: V8 12.4.148
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
Command Line: /usr/bin/google-chrome-unstable --flag-switches-begin --flag-switches-end
Executable Path: /opt/google/chrome-unstable/google-chrome-unstable
Profile Path: /home/username/.config/google-chrome-unstable/Default
Active Variations: f38ef081-ca7d8d80

The last version of Brave Browser Release Channel that could open the webpage directly is v1.64.122 based on Chromium 123.0.6312.122. Information from version

Brave: 1.64.122 Chromium: 123.0.6312.122 (Official Build) (64-bit)
Revision: a5b964f45dca7b87fc0f2adf2660d6fd6a6608b8
OS: Linux
JavaScript: V8 12.3.219.16
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
Command Line: /opt/brave.com/brave/brave --disable-domain-reliability --enable-dom-distiller --enable-distillability-service --origin-trial-public-key=bYUKPJoPnCxeNvu72j4EmPuK7tr1PAC7SHh8ld9Mw3E=,fMS4mpO6buLQ/QMd+zJmxzty/VQ6B1EUZqoCU04zoRU= --sync-url=https://sync-v2.brave.com/v2 --lso-url=https://no-thanks.invalid --variations-server-url=https://variations.brave.com/seed --variations-insecure-server-url=https://variations.brave.com/seed --flag-switches-begin --flag-switches-end --component-updater=url-source=https://go-updater.brave.com/extensions
Executable Path: /opt/brave.com/brave/brave

The last version of Microsoft Edge Beta that was able to open the webpage directly is v123.0.2420.65-1 based on Chromium 123.0.6312.87. Information from version

Microsoft Edge: 123.0.2420.65 (Official build) beta (64-bit)
Revision: 49b6a5859239c32604bcefee0b98e103c0a9bdae
Chromium version: 123.0.6312.87
Operating system: Linux
JavaScript: V8 12.3.23.7
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 Edg/123.0.0.0
Command-line: /usr/bin/microsoft-edge-beta --flag-switches-begin --flag-switches-end
Executable path: /opt/microsoft/msedge-beta/microsoft-edge-beta

It can be concluded that Chromium versions prior to v123 are able to sync normally. However, starting from v124, sync no longer works. It is unclear what new feature Chromium added that prevents the resolution of bifrost.vivaldi.com, although other subdomains of vivaldi.com can still be resolved correctly.

This is definitely unrelated to the network being used, as version 6.6 and earlier versions can sync normally.

Therefore, if you wish to sync directly without using a proxy or VPN, it is recommended to install version 6.6.3271.61 (Stable channel) and avoid upgrading until the issue is resolved.

I hope this issue can be fixed by the Vivaldi team soon.

DoctorG

@irz said in Vivaldi only syncing when on VPN:

I hope this issue can be fixed by the Vivaldi team soon.

Issues can only be fixed when reproducible on Operating Systems by the internal tester and developer team.

Currently i have no idea whats is wrong on your side.

May i ask in which country you live and how you are connected to Internet?

@irz Do you have special commandline for starting Vivaldi?

I can not reproduce your Sync issue on Mint 21.3 Cinnamon "Virginia".

We do not know how your Mint is caching and resolving DNS.

irz

@DoctorG It is indeed difficult to reproduce, although the network environment is not very special. 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.

I found that this issue doesn't seem related to DNS resolution; it might be that Chromium has updated its restrictions on Private Network Access, leading to the ERR_TIMED_OUT error.

However, in the same network environment, I can sync normally on the Windows OS.

On Debian 12, 6.6.3271.61-1 and earlier versions can sync normally, while the problem only started appearing from 6.7.3329.17-1 onwards.

I’ve uploaded five netlog files (available for download here) and will explain the process for obtaining each of them below:

chrome-net-export-log-6.6.3271.61-1.json

Completely fresh installation of 6.6.3271.61-1, without any previous configuration files, and can open Bifrost directly.

chrome-net-export-log-6.7.3329.17-1.json

Completely fresh installation of 6.7.3329.17-1, without any previous configuration files, and cannot open Bifrost directly.

chrome-net-export-log-6.7.3329.17-1-with-proxy.json

Completely fresh installation of 6.7.3329.17-1, without any previous configuration files, and opening Bifrost through a proxy.

chrome-net-export-log-6.7.3329.17-1-with-curl.json

Completely fresh installation of 6.7.3329.17-1, without any previous configuration files. Initially, opening Bifrost returns ERR_TIMED_OUT. Running curl https://bifrost.vivaldi.com/vivid-sync in the terminal returns a response, and then Bifrost can be opened.

chrome-net-export-log-6.7.3329.17-1-after-curl.json

Completely fresh installation of 6.7.3329.17-1, without any previous configuration files. The difference from the with-curl file is that network requests before running curl are not logged.

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.

I believe others have also encountered this issue, mainly on devices using internal addresses. So I hope these netlog files can help in resolving this issue.

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.