#StackBounty: #dns #email #sendmail How to configure an email-forwarding system, usable as "MX" record in DNS

Bounty: 150

Context: let’s say I have the domain example.com, but the registrar doesn’t provide an "email forward" system.

How can I configure postfix (or even a simple Python script would be better, because I could customize certain forwarding rules) to use my server of IP 1.2.3.4 as a server that only redirects every mail incoming to *@example.com ("catch-all") to myadress@gmail.com ?

The DNS record would probably be something like:

mx.example.com                   MX     mailforwarder.example.com
mailforwarder.example.com        A      1.2.3.4


Get this bounty!!!

#StackBounty: #networking #dns #proxy #docker #wsl2 TimeOut when connectinc to webserver behind reverse proxy from browser

Bounty: 100

i’ve got home server running various docker containers, amongst them i’ve got a few web servers. The thing is, i can acces them from within the LAN vía local DNS resolution, and apparently they’re accesible from the internet, since Let’sEncrypt could actually connect and verify the certificates vía ACME.

However i cannot seem to access the websites from the internet. For example https://coralt.ml gives me a timeout, and i’ve tried with diferent phones connected to the internet vía 4G.

Is there any reason why this might be happening?

This are my current containers: enter image description here

As for my current docker-compose file, it’s like this:

version: '3'
services:
  reverse-proxy:
    image: jwilder/nginx-proxy
    ports:
      - '80:80'
      - '443:443'
    container_name: reverse-proxy
    networks:
      service_network: null
    volumes:
      - '/var/run/docker.sock:/tmp/docker.sock:ro'
      - '.nginxcerts:/etc/nginx/certs'
      - '.nginxvhosts:/etc/nginx/vhost.d'
      - '.nginxhtml:/usr/share/nginx/html'
  ACME-SSL:
    image: jrcs/letsencrypt-nginx-proxy-companion
    depends_on:
      - reverse-proxy
    environment:
      NGINX_PROXY_CONTAINER: reverse-proxy
    networks:
      service_network: null
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock:ro'
      - '.nginxcerts:/etc/nginx/certs'
      - '.nginxvhosts:/etc/nginx/vhost.d'
      - '.nginxhtml:/usr/share/nginx/html'
  nginx:
    image: nginx
    depends_on:
      - reverse-proxy
    ports:
      - '8080:80'
    expose:
      - 8080
    environment:
      - NGINX_HOST=<DOMAIN>
      - NGINX_PORT=80
      - HTTP_PORT=8080
      - VIRTUAL_HOST=<DOMAIN>
      - LETSENCRYPT_HOST=<DOMAIN>
      - LETSENCRYPT_EMAIL=<EMAIL>
    networks:
      service_network: null
    volumes:
      - '.<DIRECTORY>:/usr/share/nginx/html'
  koel:
    image: hyzual/koel
    depends_on:
      - reverse-proxy
      - database
    ports:
      - '8000:80'
    expose:
      - 8000
    environment:
      - HTTP_PORT=8000
      - VIRTUAL_HOST=<SUBDOMAIN>.<DOMAIN>
      - LETSENCRYPT_HOST=<SUBDOMAIN>.<DOMAIN>
      - LETSENCRYPT_EMAIL=<EMAIL>
      - DB_CONNECTION=mysql
      - DB_HOST=database
      - DB_USERNAME=koel
      - DB_PASSWORD=<PASS>
      - DB_DATABASE=koel
      - FORCE_HTTPS=true
      - LASTFM_API_KEY=<API_SECRET>
      - LASTFM_API_SECRET=<API_KEY>
    networks:
      service_network: null
      db_network: null
    volumes:
      - '/e/musica:/music'
      - '.koelcovers:/var/www/html/public/img/covers'
      - '.koelsearch_index:/var/www/html/storage/search-indexes'
  database:
    image: 'mysql/mysql-server:5.7'
    volumes:
      - '.mysql:/var/lib/mysql'
    environment:
      - MYSQL_ROOT_PASSWORD=<PASS>
      - MYSQL_DATABASE=koel
      - MYSQL_USER=koel
      - MYSQL_PASSWORD=<PASS>
    networks:
      db_network: null
networks:
  service_network:
    driver: bridge
  db_network:
    driver: bridge
 

*I’ve changed some values to descriptions between < > as they contain private information.


Get this bounty!!!

#StackBounty: #networking #dns DNS resolution failing after a few hours

Bounty: 100

I am using Ubuntu Server 20.04.2 LTS on a raspberry pi 4 8gb. DNS resolution stops working after a few hours after reboot. A reboot solves the issue but it’s just a band-aid. My DNS is set to 8.8.8.8 and 8.8.4.4.

I have tried running tcpdump -n -i eth0 host 8.8.8.8 and dig @8.8.8.8 www.google.com simultaneously and the output is

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:06:51.643074 IP 192.168.0.2.57220 > 8.8.8.8.53: 6359+ [1au] A? www.google.com. (55)
22:06:51.651180 IP 8.8.8.8.53 > 192.168.0.2.57220: 6359 1/0/1 A 142.250.200.4 (59)

(The IP of the device is 192.168.0.02)

NSLookup also fails, running the following: nslookup www.google.com returns

;; connection timed out; no servers could be reached

I would like the DNS to not break every 6 hours or so and rebooting it every time it breaks is a little inconvenient.

Edit:

Running telnet returns this:

root@najemi:~# telnet to 8.8.8.8:53
telnet: could not resolve to/8.8.8.8:53: Servname not supported for ai_socktype

Running tcpdump without any arguments returns this

Date looks about right:

root@najemi:~# date
Sat Jul  3 05:14:10 UTC 2021

sudo tcpdump -n -i eth0 host 8.8.8.8 while running dig +cdflag @8.8.8.8 www.google.com returns:

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
05:18:07.377351 IP 192.168.0.2.43923 > 8.8.8.8.53: 37809+% [1au] A? www.google.com. (55)
05:18:07.422270 IP 8.8.8.8.53 > 192.168.0.2.43923: 37809 1/0/1 A 142.250.180.4 (59)

IP is static.

Also thought I’d mention that these problems started arising after installing pihole. It has since been uninstalled yet the problems remain.

Edit 2:

Contents of /etc/resolv.conf are:

# Generated by dhcpcd from eth0.dhcp
# /etc/resolv.conf.head can replace this line
nameserver 8.8.8.8
nameserver 8.8.4.4
# /etc/resolv.conf.tail can replace this line


Get this bounty!!!

#StackBounty: #networking #dns #dhcp Dynamic DNS updates via DHCP on CentOS

Bounty: 50

I’m running mostly Ubuntu VMs in an vSphere cluster where a VLAN is managed by a DHCP and a Windows DNS. From the Ubuntu VMs I can update the DNS records in the Windows DNS to point the dynamic IP to its hostname (set in /etc/hostname) with dhcp-identifier: mac addition in /etc/netplan/00-installer-config.yaml:

cat /etc/netplan/00-installer-config.yaml
# This is the network config written by 'subiquity'
network:
  ethernets:
    ens160:
      dhcp4: true
      dhcp-identifier: mac
  version: 2

But now I want to achieve the same DNS update functionality in a CentOS 7 VM, but can’t get it to work. Is it even possible?


Get this bounty!!!

#StackBounty: #windows-10 #networking #google-chrome #dns Chrome and Spotify app can't connect

Bounty: 300

I’m having this really weird problem on my computer that I can’t seem to wrap my head around. Occasionally (and almost always after a reboot), the spotify app can’t seem to connect to it’s servers. When this happens, Chrome is also affected, and it affects all known websites related to Spotify (their web page, web player, their community etc, basically all of *.spotify.com).

This is what it looks like, note the empty remote address column, which makes me suspect a DNS problem.

network tab of Chrome

Now, after a while, this seems to "fix" itself, but it takes like 5-10 minutes or so. Meanwhile, Brave browser (which is basically chrome in disguise) works fine, so does Invoke-WebRequest from powershell. Running ipconfig /flushdns and restarting Chrome does nothing.

I do know that the Spotify app does use the Chrome engine under the hood, but I would expect it to run it’s own bundled engine, and not my installed Chrome? So why do they affect each other? Also, when this problem stops, it seems to stop simultaneously for both apps.

One suspicion I had, was that it is IPv6 that is buggering me. Spotify actually resolves IPv6 addresses, and I don’t have IPv6. However, I did disable IPv6 on my Wi-Fi adapter, but to no avail.

I’ve also verified that Chrome and Spotify are both allowed through windows firewall.

I’m kind of stuck in my troubleshooting, and some new ideas would be welcome. Also, Spotify is the only known service that seems to have this problem, which is also strange.

EDIT: I’ve noticed that this affects some more sites. plex.tv, as well as the Netflix app, suffer from the same problem. When I can’t visit these sites, other sites are fine, like github.com, google.com, AWS console etc.

I’m stumped. I’ve managed to start the debug logger in Chrome, and when requesting a url that fails, I get this:

[15564:26264:0704/214452.685:VERBOSE1:network_delegate.cc(32)] NetworkDelegate::NotifyBeforeURLRequest: https://plex.tv/
[33512:27416:0704/214452.735:INFO:cpu_info.cc(53)] Available number of cores: 8
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.622:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.626:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.627:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING

The 192.168.0.148 is a Chromecast on my network, and those errors might be irrelevant, but the error line is interesting:

[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101

I don’t understand why I would get SSL error in multiple applications, which after awhile just goes away. Also, why does it only affect some applications, and not all? (Brave, for instance)


Get this bounty!!!

#StackBounty: #windows-10 #networking #google-chrome #dns Chrome and Spotify app can't connect

Bounty: 300

I’m having this really weird problem on my computer that I can’t seem to wrap my head around. Occasionally (and almost always after a reboot), the spotify app can’t seem to connect to it’s servers. When this happens, Chrome is also affected, and it affects all known websites related to Spotify (their web page, web player, their community etc, basically all of *.spotify.com).

This is what it looks like, note the empty remote address column, which makes me suspect a DNS problem.

network tab of Chrome

Now, after a while, this seems to "fix" itself, but it takes like 5-10 minutes or so. Meanwhile, Brave browser (which is basically chrome in disguise) works fine, so does Invoke-WebRequest from powershell. Running ipconfig /flushdns and restarting Chrome does nothing.

I do know that the Spotify app does use the Chrome engine udner the hood, but I would expect it to run it’s own bundled engine, and not my installed Chrome? So why do they affect eachother? Also, when this problem stops, it seems to stop simultaneously for both apps.

One suspicion I had, was that it is IPv6 that is buggering me. Spotify actually resolves IPv6 addresses, and I don’t have IPv6. However, I did disable IPv6 on my wifi adapter, but to no avail.

I’ve also verified that Chrome and spotify are both allowed through windows firewall.

I’m kind of stuck in my troubleshooting, and some new ideas would be welcome. Also, Spotify is the only known service that seems to have this problem, which is also strange.

EDIT: I’ve noticed that this affects some more sites. plex.tv, as well as the Netflix app, suffer from the same problem. When I can’t visit these sites, other sites are fine, like github.com, google.com, AWS console etc.

I’m stumped. I’ve managed to start the debug logger in Chrome, and when requesting a url that fails, I get this:

[15564:26264:0704/214452.685:VERBOSE1:network_delegate.cc(32)] NetworkDelegate::NotifyBeforeURLRequest: https://plex.tv/
[33512:27416:0704/214452.735:INFO:cpu_info.cc(53)] Available number of cores: 8
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.622:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.626:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.627:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING

The 192.168.0.148 is a Chromecast on my network, and those errors might be unrelevant, but the error line is interesting:

[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101

I don’t understand why I would get SSL error in multiple applications, which after a while just goes away. Also, why does it only affect some applications, and not all? (Brave, for instance)


Get this bounty!!!

#StackBounty: #windows-10 #networking #google-chrome #dns Chrome and Spotify app can't connect

Bounty: 300

I’m having this really weird problem on my computer that I can’t seem to wrap my head around. Occasionally (and almost always after a reboot), the spotify app can’t seem to connect to it’s servers. When this happens, Chrome is also affected, and it affects all known websites related to Spotify (their web page, web player, their community etc, basically all of *.spotify.com).

This is what it looks like, note the empty remote address column, which makes me suspect a DNS problem.

network tab of Chrome

Now, after a while, this seems to "fix" itself, but it takes like 5-10 minutes or so. Meanwhile, Brave browser (which is basically chrome in disguise) works fine, so does Invoke-WebRequest from powershell. Running ipconfig /flushdns and restarting Chrome does nothing.

I do know that the Spotify app does use the Chrome engine udner the hood, but I would expect it to run it’s own bundled engine, and not my installed Chrome? So why do they affect eachother? Also, when this problem stops, it seems to stop simultaneously for both apps.

One suspicion I had, was that it is IPv6 that is buggering me. Spotify actually resolves IPv6 addresses, and I don’t have IPv6. However, I did disable IPv6 on my wifi adapter, but to no avail.

I’ve also verified that Chrome and spotify are both allowed through windows firewall.

I’m kind of stuck in my troubleshooting, and some new ideas would be welcome. Also, Spotify is the only known service that seems to have this problem, which is also strange.

EDIT: I’ve noticed that this affects some more sites. plex.tv, as well as the Netflix app, suffer from the same problem. When I can’t visit these sites, other sites are fine, like github.com, google.com, AWS console etc.

I’m stumped. I’ve managed to start the debug logger in Chrome, and when requesting a url that fails, I get this:

[15564:26264:0704/214452.685:VERBOSE1:network_delegate.cc(32)] NetworkDelegate::NotifyBeforeURLRequest: https://plex.tv/
[33512:27416:0704/214452.735:INFO:cpu_info.cc(53)] Available number of cores: 8
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.622:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.626:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.627:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING

The 192.168.0.148 is a Chromecast on my network, and those errors might be unrelevant, but the error line is interesting:

[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101

I don’t understand why I would get SSL error in multiple applications, which after a while just goes away. Also, why does it only affect some applications, and not all? (Brave, for instance)


Get this bounty!!!

#StackBounty: #windows-10 #networking #google-chrome #dns Chrome and Spotify app can't connect

Bounty: 300

I’m having this really weird problem on my computer that I can’t seem to wrap my head around. Occasionally (and almost always after a reboot), the spotify app can’t seem to connect to it’s servers. When this happens, Chrome is also affected, and it affects all known websites related to Spotify (their web page, web player, their community etc, basically all of *.spotify.com).

This is what it looks like, note the empty remote address column, which makes me suspect a DNS problem.

network tab of Chrome

Now, after a while, this seems to "fix" itself, but it takes like 5-10 minutes or so. Meanwhile, Brave browser (which is basically chrome in disguise) works fine, so does Invoke-WebRequest from powershell. Running ipconfig /flushdns and restarting Chrome does nothing.

I do know that the Spotify app does use the Chrome engine udner the hood, but I would expect it to run it’s own bundled engine, and not my installed Chrome? So why do they affect eachother? Also, when this problem stops, it seems to stop simultaneously for both apps.

One suspicion I had, was that it is IPv6 that is buggering me. Spotify actually resolves IPv6 addresses, and I don’t have IPv6. However, I did disable IPv6 on my wifi adapter, but to no avail.

I’ve also verified that Chrome and spotify are both allowed through windows firewall.

I’m kind of stuck in my troubleshooting, and some new ideas would be welcome. Also, Spotify is the only known service that seems to have this problem, which is also strange.

EDIT: I’ve noticed that this affects some more sites. plex.tv, as well as the Netflix app, suffer from the same problem. When I can’t visit these sites, other sites are fine, like github.com, google.com, AWS console etc.

I’m stumped. I’ve managed to start the debug logger in Chrome, and when requesting a url that fails, I get this:

[15564:26264:0704/214452.685:VERBOSE1:network_delegate.cc(32)] NetworkDelegate::NotifyBeforeURLRequest: https://plex.tv/
[33512:27416:0704/214452.735:INFO:cpu_info.cc(53)] Available number of cores: 8
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.622:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.626:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.627:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING

The 192.168.0.148 is a Chromecast on my network, and those errors might be unrelevant, but the error line is interesting:

[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101

I don’t understand why I would get SSL error in multiple applications, which after a while just goes away. Also, why does it only affect some applications, and not all? (Brave, for instance)


Get this bounty!!!

#StackBounty: #windows-10 #networking #google-chrome #dns Chrome and Spotify app can't connect

Bounty: 300

I’m having this really weird problem on my computer that I can’t seem to wrap my head around. Occasionally (and almost always after a reboot), the spotify app can’t seem to connect to it’s servers. When this happens, Chrome is also affected, and it affects all known websites related to Spotify (their web page, web player, their community etc, basically all of *.spotify.com).

This is what it looks like, note the empty remote address column, which makes me suspect a DNS problem.

network tab of Chrome

Now, after a while, this seems to "fix" itself, but it takes like 5-10 minutes or so. Meanwhile, Brave browser (which is basically chrome in disguise) works fine, so does Invoke-WebRequest from powershell. Running ipconfig /flushdns and restarting Chrome does nothing.

I do know that the Spotify app does use the Chrome engine udner the hood, but I would expect it to run it’s own bundled engine, and not my installed Chrome? So why do they affect eachother? Also, when this problem stops, it seems to stop simultaneously for both apps.

One suspicion I had, was that it is IPv6 that is buggering me. Spotify actually resolves IPv6 addresses, and I don’t have IPv6. However, I did disable IPv6 on my wifi adapter, but to no avail.

I’ve also verified that Chrome and spotify are both allowed through windows firewall.

I’m kind of stuck in my troubleshooting, and some new ideas would be welcome. Also, Spotify is the only known service that seems to have this problem, which is also strange.

EDIT: I’ve noticed that this affects some more sites. plex.tv, as well as the Netflix app, suffer from the same problem. When I can’t visit these sites, other sites are fine, like github.com, google.com, AWS console etc.

I’m stumped. I’ve managed to start the debug logger in Chrome, and when requesting a url that fails, I get this:

[15564:26264:0704/214452.685:VERBOSE1:network_delegate.cc(32)] NetworkDelegate::NotifyBeforeURLRequest: https://plex.tv/
[33512:27416:0704/214452.735:INFO:cpu_info.cc(53)] Available number of cores: 8
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.622:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.626:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.627:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING

The 192.168.0.148 is a Chromecast on my network, and those errors might be unrelevant, but the error line is interesting:

[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101

I don’t understand why I would get SSL error in multiple applications, which after a while just goes away. Also, why does it only affect some applications, and not all? (Brave, for instance)


Get this bounty!!!

#StackBounty: #windows-10 #networking #google-chrome #dns Chrome and Spotify app can't connect

Bounty: 300

I’m having this really weird problem on my computer that I can’t seem to wrap my head around. Occasionally (and almost always after a reboot), the spotify app can’t seem to connect to it’s servers. When this happens, Chrome is also affected, and it affects all known websites related to Spotify (their web page, web player, their community etc, basically all of *.spotify.com).

This is what it looks like, note the empty remote address column, which makes me suspect a DNS problem.

network tab of Chrome

Now, after a while, this seems to "fix" itself, but it takes like 5-10 minutes or so. Meanwhile, Brave browser (which is basically chrome in disguise) works fine, so does Invoke-WebRequest from powershell. Running ipconfig /flushdns and restarting Chrome does nothing.

I do know that the Spotify app does use the Chrome engine udner the hood, but I would expect it to run it’s own bundled engine, and not my installed Chrome? So why do they affect eachother? Also, when this problem stops, it seems to stop simultaneously for both apps.

One suspicion I had, was that it is IPv6 that is buggering me. Spotify actually resolves IPv6 addresses, and I don’t have IPv6. However, I did disable IPv6 on my wifi adapter, but to no avail.

I’ve also verified that Chrome and spotify are both allowed through windows firewall.

I’m kind of stuck in my troubleshooting, and some new ideas would be welcome. Also, Spotify is the only known service that seems to have this problem, which is also strange.

EDIT: I’ve noticed that this affects some more sites. plex.tv, as well as the Netflix app, suffer from the same problem. When I can’t visit these sites, other sites are fine, like github.com, google.com, AWS console etc.

I’m stumped. I’ve managed to start the debug logger in Chrome, and when requesting a url that fails, I get this:

[15564:26264:0704/214452.685:VERBOSE1:network_delegate.cc(32)] NetworkDelegate::NotifyBeforeURLRequest: https://plex.tv/
[33512:27416:0704/214452.735:INFO:cpu_info.cc(53)] Available number of cores: 8
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.563:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.607:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.622:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(220)] [192.168.0.148:8009, auth=SSL_VERIFIED] Connect readyState = ReadyState::NONE
[9692:25292:0704/214454.622:VERBOSE1:cast_socket.cc(379)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnect
[9692:25292:0704/214454.626:VERBOSE1:cast_socket.cc(393)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoTcpConnectComplete: 0
[9692:25292:0704/214454.627:VERBOSE1:cast_socket.cc(410)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnect
[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(433)] [192.168.0.148:8009, auth=SSL_VERIFIED] DoSslConnectComplete: -101
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(653)] [192.168.0.148:8009, auth=SSL_VERIFIED] SetErrorState ChannelError::AUTHENTICATION_ERROR
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(575)] DoConnectCallback (error_state = ChannelError::AUTHENTICATION_ERROR)
[9692:25292:0704/214454.633:VERBOSE1:cast_socket.cc(615)] [192.168.0.148:8009, auth=SSL_VERIFIED] Close ReadyState = ReadyState::CONNECTING

The 192.168.0.148 is a Chromecast on my network, and those errors might be unrelevant, but the error line is interesting:

[15564:26264:0704/214454.632:ERROR:ssl_client_socket_impl.cc(980)] handshake failed; returned -1, SSL error code 1, net_error -101

I don’t understand why I would get SSL error in multiple applications, which after a while just goes away. Also, why does it only affect some applications, and not all? (Brave, for instance)


Get this bounty!!!