[GH-ISSUE #535] Connectivity issue with IPv6 enabled

kerem commented

2026-02-27 19:30:07 +03:00

Owner

Originally created by @utomsig on GitHub (Nov 1, 2020).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/535

Not sure if this is a bug or some problem with my computer/ISP/router.
When “IPv6 Method” is set to “Automatic”, librespot takes about 3 min to authenticate. I’m running Ubuntu desktop 20.04 and the IPv6 setting is in the usual gui settings app. If I use “Automatic, DHCP only” it works without problems, but then I only got a local ipv6 address.
According to http://test-ipv6.com/ I can reach ipv6 sites (with the “Automatic” setting).

Thanks for a great app!
/Simon
librespot_bug.txt

Originally created by @utomsig on GitHub (Nov 1, 2020). Original GitHub issue: https://github.com/librespot-org/librespot/issues/535 Not sure if this is a bug or some problem with my computer/ISP/router. When “IPv6 Method” is set to “Automatic”, librespot takes about 3 min to authenticate. I’m running Ubuntu desktop 20.04 and the IPv6 setting is in the usual gui settings app. If I use “Automatic, DHCP only” it works without problems, but then I only got a local ipv6 address. According to http://test-ipv6.com/ I can reach ipv6 sites (with the “Automatic” setting). Thanks for a great app! /Simon [librespot_bug.txt](https://github.com/librespot-org/librespot/files/5471794/librespot_bug.txt)

kerem

2026-02-27 19:30:07 +03:00

closed this issue
added the
can't reproduce
label

kerem commented

2026-02-27 19:30:07 +03:00

Author

Owner

@kescherCode commented on GitHub (Dec 28, 2020):

I use IPv6, and I don't have such an issue. Are you testing the dev branch?

@kescherCode commented on GitHub (Dec 28, 2020): I use IPv6, and I don't have such an issue. Are you testing the dev branch?

kerem commented

2026-02-27 19:30:07 +03:00

Author

Owner

@Malvineous commented on GitHub (Feb 27, 2021):

See the line in the log that says:

Connecting to AP "gew1-accesspoint-b-3ml0.ap.spotify.com:4070"

Try to connect to this manually, e.g. telnet gew1-accesspoint-b-3ml0.ap.spotify.com 4070 and see how long it takes to connect. If you get the same delay, the problem is not with librespot but with your IPv6 setup.

@Malvineous commented on GitHub (Feb 27, 2021): See the line in the log that says: ``` Connecting to AP "gew1-accesspoint-b-3ml0.ap.spotify.com:4070" ``` Try to connect to this manually, e.g. `telnet gew1-accesspoint-b-3ml0.ap.spotify.com 4070` and see how long it takes to connect. If you get the same delay, the problem is not with librespot but with your IPv6 setup.

kerem commented

2026-02-27 19:30:07 +03:00

Author

Owner

@roderickvd commented on GitHub (Jun 14, 2021):

Same here. I also have no connectivity issues on an IPv6-enabled LAN (but without IPv6 connectivity to the Internet). I'm closing this because multiple users cannot reproduce it and there are no further replies. But feel free to reopen if this is a different issue.

@roderickvd commented on GitHub (Jun 14, 2021): Same here. I also have no connectivity issues on an IPv6-enabled LAN (but without IPv6 connectivity to the Internet). I'm closing this because multiple users cannot reproduce it and there are no further replies. But feel free to reopen if this is a different issue.

kerem commented

2026-02-27 19:30:07 +03:00

Author

Owner

@klemensn commented on GitHub (Dec 31, 2023):

Dual-stack networks, i.e. clients with both IPv4 and IPv6 connectivity, ought to work.

However, In IPv6-only networks without migration features such as DNS64/NAT64 or the like, Spotify yields APs without AAAA DNS records, so there's no IPv6 address to connect to:

$ spotifyd --no-daemon --verbose
[...]
No proxy specified
registering event source with poller: token=Token(2147483649), interests=READABLE
Using software volume controller.
registering event source with poller: token=Token(0), interests=READABLE | WRITABLE
signal: Want
signal found waiting giver, notifying
poll_want: taker wants!
signal: Want
signal: Want
deregistering event source from poller
Ignoring blacklisted access point ap-gew4.spotify.com:4070
signal: Closed
Ignoring blacklisted access point ap-gew4.spotify.com:443
Ignoring blacklisted access point ap-gew4.spotify.com:80
Ignoring blacklisted access point ap-gue1.spotify.com:4070
Connecting to AP "ap-gae2.spotify.com:443"
failed to connect to spotify: Cannot create session: Can't assign requested address (os error 49)

Asking one of Spotify's nameservers directly:

$ dig +short spotify.com. NS  
ns-cloud-a1.googledomains.com.
ns-cloud-a4.googledomains.com.
ns-cloud-a3.googledomains.com.
dns3.p07.nsone.net.
dns1.p07.nsone.net.
dns4.p07.nsone.net.
ns-cloud-a2.googledomains.com.
dns2.p07.nsone.net.

There is indeed only an A record:

$ dig @dns2.p07.nsone.net. ap-gae2.spotify.com. AAAA

; <<>> dig 9.10.8-P1 <<>> @dns2.p07.nsone.net. ap-gae2.spotify.com. AAAA
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63127
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ap-gae2.spotify.com.		IN	AAAA

;; AUTHORITY SECTION:
spotify.com.		3600	IN	SOA	dns1.p07.nsone.net. hostmaster.nsone.net. 1655911284 43200 7200 1209600 3600

;; Query time: 78 msec
;; SERVER: 2a00:edc0:6259:7:7::2#53(2a00:edc0:6259:7:7::2)
;; WHEN: Sun Dec 31 18:30:10 CET 2023
;; MSG SIZE  rcvd: 113

Same with other APs spotifyd ends up connecting to, e.g.

ap-guc3.spotify.com:443
ap.spotify.com:443
ap-gew1.spotify.com:443

I remember Spotify's official desktop client failing to connect on Linux in an IPv6-only network, although that was years ago and DNS64/NAT64 was probably deployed.
There some command line flag or environment variable made the proprietary, electron-based app work, but that's all I remember.
https://community.spotify.com/t5/Live-Ideas/Desktop-IPv6-support-for-the-desktop-client/idc-p/5475568/highlight/true#M249926 mentioning --experimental-network seems to support that.

@klemensn commented on GitHub (Dec 31, 2023): Dual-stack networks, i.e. clients with both IPv4 and IPv6 connectivity, ought to work. However, In IPv6-only networks without migration features such as DNS64/NAT64 or the like, Spotify yields APs without `AAAA` DNS records, so there's no IPv6 address to connect to: ``` $ spotifyd --no-daemon --verbose [...] No proxy specified registering event source with poller: token=Token(2147483649), interests=READABLE Using software volume controller. registering event source with poller: token=Token(0), interests=READABLE | WRITABLE signal: Want signal found waiting giver, notifying poll_want: taker wants! signal: Want signal: Want deregistering event source from poller Ignoring blacklisted access point ap-gew4.spotify.com:4070 signal: Closed Ignoring blacklisted access point ap-gew4.spotify.com:443 Ignoring blacklisted access point ap-gew4.spotify.com:80 Ignoring blacklisted access point ap-gue1.spotify.com:4070 Connecting to AP "ap-gae2.spotify.com:443" failed to connect to spotify: Cannot create session: Can't assign requested address (os error 49) ``` Asking one of Spotify's nameservers directly: ``` $ dig +short spotify.com. NS ns-cloud-a1.googledomains.com. ns-cloud-a4.googledomains.com. ns-cloud-a3.googledomains.com. dns3.p07.nsone.net. dns1.p07.nsone.net. dns4.p07.nsone.net. ns-cloud-a2.googledomains.com. dns2.p07.nsone.net. ``` There is indeed only an `A` record: ``` $ dig @dns2.p07.nsone.net. ap-gae2.spotify.com. AAAA ; <<>> dig 9.10.8-P1 <<>> @dns2.p07.nsone.net. ap-gae2.spotify.com. AAAA ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63127 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;ap-gae2.spotify.com. IN AAAA ;; AUTHORITY SECTION: spotify.com. 3600 IN SOA dns1.p07.nsone.net. hostmaster.nsone.net. 1655911284 43200 7200 1209600 3600 ;; Query time: 78 msec ;; SERVER: 2a00:edc0:6259:7:7::2#53(2a00:edc0:6259:7:7::2) ;; WHEN: Sun Dec 31 18:30:10 CET 2023 ;; MSG SIZE rcvd: 113 ``` Same with other APs `spotifyd` ends up connecting to, e.g. - `ap-guc3.spotify.com:443` - `ap.spotify.com:443` - `ap-gew1.spotify.com:443` I remember Spotify's official desktop client failing to connect on Linux in an IPv6-only network, although that was years ago and DNS64/NAT64 was probably deployed. There some command line flag or environment variable made the proprietary, electron-based app work, but that's all I remember. https://community.spotify.com/t5/Live-Ideas/Desktop-IPv6-support-for-the-desktop-client/idc-p/5475568/highlight/true#M249926 mentioning `--experimental-network` seems to support that.

Rows
Columns

[GH-ISSUE #535] Connectivity issue with IPv6 enabled #342