go-chromecast ls fails when trying to bind to a nonexistent IPv6 interface

[utrack]

Hey team :)

Piggybacking off an another issue: https://github.com/gabe565/CastSponsorSkip/issues/54

I get an error when running go-chromecast ls:

» go-chromecast ls
error: unable to discover chromecast devices: unable to create new zeroconf resolver: listen udp6 [ff02::]:5353: socket: address family not supported by protocol

Version: go-chromecast dev (master) 2024-02-09T15:51:33Z, Arch Linux.

ip a output (IPv6 interface is not active):

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
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 04:7b:cb:b3:4a:e0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.50.123/24 brd 192.168.50.255 scope global dynamic noprefixroute wlan0
       valid_lft 85727sec preferred_lft 85727sec
4: br-791da0daa1ae: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:c2:08:e1:38 brd ff:ff:ff:ff:ff:ff
    inet 172.4.1.1/24 brd 172.4.1.255 scope global br-791da0daa1ae
       valid_lft forever preferred_lft forever
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:26:c5:4d:99 brd ff:ff:ff:ff:ff:ff
    inet 172.4.0.1/24 brd 172.4.0.255 scope global docker0
       valid_lft forever preferred_lft forever
8: vethe5ede18@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-791da0daa1ae state UP group default
    link/ether 16:6a:a6:16:fc:e7 brd ff:ff:ff:ff:ff:ff link-netnsid 0

ip l output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 04:7b:cb:b3:4a:e0 brd ff:ff:ff:ff:ff:ff
4: br-791da0daa1ae: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:c2:08:e1:38 brd ff:ff:ff:ff:ff:ff
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
    link/ether 02:42:26:c5:4d:99 brd ff:ff:ff:ff:ff:ff
8: vethe5ede18@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-791da0daa1ae state UP mode DEFAULT group default
    link/ether 16:6a:a6:16:fc:e7 brd ff:ff:ff:ff:ff:ff link-netnsid 0

[vishen]

Hmm, this is odd. Can you try specifying the network interfacce argument and seeing if that works: go-chromecast ls --iface=<network_interface>?

We piggyback on https://github.com/grandcat/zeroconf for mDNS and I see a similar issue here https://github.com/grandcat/zeroconf/issues/3 although it was a while ago and I suspect it has been fixed already.

[thoughtsunificator]

I managed to get through it by adding opts = append(opts, zeroconf.SelectIPTraffic(0x01)) to DiscoverCastDNSEntries.

[vishen]

Thanks @thoughtsunificator! What OS are you on?

I am a bit confused about why this is happening. Looking at the zeroconf library, it tries to bind to a [ff02::]:5353: (https://github.com/grandcat/zeroconf/blob/master/connection.go#L21-L25 https://github.com/grandcat/zeroconf/blob/master/connection.go#L39. This works fine on my m1 mac, but unsure why it isn't working on other OS and whether this is a Go issue or an OS issue.

I've upgraded the Go version and the golang.org/x/net/ipv{4,6} versions. If someone is able to try what's currently in master that is having this issue, that would be very helpful.

Otherwise, I think we can add a new flag to be able to force select ipv4 for mDNS.

[utrack]

Hey :) I just checked - it seems like something's changed in my system, but I don't receive this error anymore, both on master and v0.3.1... Could a kernel upgrade fix things?

[vishen]

Ahh, that's interesting, thanks for that @utrack. I suspect a Kernel upgrade could have fixed things. It seemed like it was either an Kernel/OS thing, or the way Go was interacting with the Kernal/OS that was causing this.

[vishen]

I might close this issue since it might be a issue we can't fix. Please feel free to reopen if needed.

[diadeluz]

Hi, I have this issue on Ubuntu 22.04. Should we reopen the issue? Or would anyone have any advice?