Vivaldi not syncing
-
@LazyLama said in Vivaldi only syncing when on VPN:
Would this show how Vivaldi resolves the IP address?
It wouldn't show how it resolves the IP. To do that you could capture DNS requests:
λ tshark -i4 port 53 Capturing on 'Ethernet' 1 0.000000 192.168.0.10 49891 router.asus.com 53 DNS 79 Standard query 0x9b75 A bifrost.vivaldi.com 2 0.000212 192.168.0.10 64669 router.asus.com 53 DNS 79 Standard query 0x74ec HTTPS bifrost.vivaldi.com 3 0.002631 router.asus.com 53 192.168.0.10 49891 DNS 95 Standard query response 0x9b75 A bifrost.vivaldi.com A 31.209.137.10 4 0.003298 router.asus.com 53 192.168.0.10 64669 DNS 138 Standard query response 0x74ec HTTPS bifrost.vivaldi.com SOA carl.ns.cloudflare.com
In this capture my PC asks my router for the IP of Bifrost, the router replies with the correct IP.
But it would show at least the request timing out, and to what IP it goes. But come to think of it, since the OS obviously resolves the IP correctly, it wouldn't actually capture any traffic going to the wrong IP.
Unless of course you capture all HTTPS traffic. But you'd get a lot of data. So close all browser tabs, close all other networked programs and restart the browser then run a
tcpdump dst port 443
and trigger the sync issue fromchrome://sync-internals
Above, you mentioned using vivaldi://net-internals/#dns. Wouldn't that work as well?
Yes, and you did that and it resolved correctly. I don't know why it did.
Another thing to do:
- Close all tabs
- Open
chrome://net-export
- Click Start Logging...
- Trigger the Sync issue and wait for the timeout
- Stop the logging
- Share the network capture (zip it first) or analyze it yourself
-
I have done the following to test your hypothesis:
- Restart the computer
- Open Vivaldi and check whether I can sync. I could not.
- Open
vivaldi://net-internals/#dns
. This resulted inResolved IP addresses of "bifrost.vivaldi.com": ["31.209.137.10"]. No alternative endpoints
- Run
curl https://bifrost.vivaldi.com/vivid-sync
. - Sign out of sync and sign back in to trigger syncing.
- Syncing succeeds.
So, you seem correct.
-
@LazyLama said in Vivaldi only syncing when on VPN:
So, you seem correct.
Nope - because the resolved IP is the correct one. That works against my theory. It should be wrong. So maybe it's not DNS but something else on your system blocking the browser. Only you can know.
Or, at least I'm partly correct on the caching bit, as the act of running curl will resolve the correct IP, at least for a time. Or possibly just "open" something that was blocked.
It's also quite possible that the net-internals page does things differently and I don't know why.
Do a network capture from net-export and share it.
-
@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.
-
@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
-
@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
-
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
-
Could be a hardware firewall appliance which checks behavior of requesting connections by rules. Who knows.
-
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 forbifrost.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
, anddownloads.vivaldi.com
. -
Perhaps some settings for DNS are managed in your LAN?
Check internal pages- vivaldi://policy
- vivaldi://management
-
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 is6.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 Chromiumv124
. 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://versionGoogle 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 versionBrave: 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 versionMicrosoft 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 fromv124
, sync no longer works. It is unclear what new feature Chromium added that prevents the resolution ofbifrost.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.
-
@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.
-
@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 theERR_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 from6.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.
-
@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.
-
@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!
-
@DoctorG
I face the same issue: Vivaldi Sync works only through VPN.
Myip 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
-
about:sync
Trigger GetUpdates() -
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.
-
@kaleh I am not able to tell why your Networkmanager is acting like this and not letting Vivaldi connect.
-
@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.