Used to work, now only sees some of my google-home devices

[jbrown123]

I've been using this node for quite some time and it's worked well (thanks for making it available!). I was using 4.1.1 and started having random problems with it not connecting to devices. I updated to 4.1.2 and the problem persists.

As far as I know, nothing has changed in my node or speaker configurations. I have 2 google homes and 4 google minis on my network. The module can only see 2 of my devices and one of my groups. It can see one google home, one google mini, and one of my user-defined speaker groups. It's always consistent about which two speakers and which group it sees. None of the rest work, even using existing nodes that were connected to them previously.

All the speakers work just fine and all are accessible from the android app (google home app). I can stream to them just fine from there as well. I can see them all on the network using angry IP scanner.

For nodes that don't work I get a continuous cycle of connecting ... disconnected ... connecting ... disconnected status on the node. I'm not seeing any error messages.

How can I help debug this issue?

[i8beef]

I assume you are using the mDNS discovery stuff to connect. Have you changed anything on your setup recently, specifically anything that would put your node-red instance on a different network from the missing cast targets (network repartitioning / vlaning, switching to Docker, etc.)?

The only way for you to really troubleshoot that is to find an mDNS / bonjour browser and see what you can see advertised on the network. There aren't a lot of options to the mdns library I'm using, so its basically just what it can see is what it can see. If there was something weird going on with it, restarting node-red completely might fix it. If it does, that might mean there's some sort of issue in that library.

[jbrown123]

Yes, I'm using the mDNS discovery. I haven't changed anything but I did find that the devices I could not see were attached to a particular access point. I moved them to a different one and they work now.

My only guess is that the AP received a firmware update that causes it to not pass mDNS multicast. I can't find any settings on the AP that allow / disallow mDNS or multicast generally.

I was able to debug this by using a service browser on my android device. Indeed, I was only seeing the devices that showed up in the list.

Interestingly though, I could cast to all the devices from my phone even though some were on the AP that wasn't passing mDNS traffic. Android must be using some other discovery mechanism to find the cast devices.

Another interesting thing though. At one point in all of this I looked up the IP address of one of my speakers and put that in rather than searching. It still didn't work. Shouldn't that have worked?

I'm going to mark this as closed since changes to my network resolved the issue.

Thanks for a great node / tool, for helping me debug my setup, and for all you are doing!!!

[i8beef]

Phew glad to hear the node is doing what its supposed to!

Probably an obvious question, but I'm assuming the AP is not on a different subnet / network / vlan / guest network, etc.?

[jbrown123]

Several odd things. Nothing in the network config has changed (at least I didn't change anything). None of the configuration of the various homes has changed either (which network they hooked to, etc.)

The AP in question (call it AP1) is my "gateway" to the internet. It has a WAN port hooked to my ISP, several LAN ports hooked to various devices, and both 5 and 2.4 WiFi on a shared SSID (call it SSID1). It's also my only DHCP server. One of AP1s LAN ports hooks to a gig switch which, in turn, has another port hooked to the LAN port of another AP (call it AP2) that serves 5 and 2.4 on two other SSIDs (call them SSID5 and SSID2). My Node-Red server (an RPi clone) is also hardwired to another port on the same switch. All of my devices share the same IP subnet (10.0.1.x/24).

Originally the (now) failing google home devices were connected to AP1 via WiFi (obviously) and worked just fine in that configuration for months. Recently, all the homes hooked to AP1 were no longer reachable by node but still worked just fine from apps on my phone and tablet. Meaning, I could cast to them, broadcast between them, see them in the home app, they could see each other (detecting multiple devices hearing the same wake word), etc. Nothing seemed amiss other than node could no longer see them or connect to them. Apparently the google home app and the devices themselves use some other protocol to find each other.

I used angry IP scanner to scan my network and I could see all of the home devices. They all had reasonable IP addresses handed out by the DHCP server on AP1.

I tried putting the IP address of one of the failing homes in the IP field of the castv2 node. This also didn't work which I found surprising.

I had no reason to do a bonjour scan prior to this incident but I have to assume they were visible prior to whatever caused them to fail. A recent bonjour scan (from my android phone) prior to moving them to SSID5 showed only the ones that node saw (as expected). A bonjour scan now that everything is fixed shows all of them (again, as expected).

Moving a failing home from SSID1 to SSID5 fixed the issue.

I have no idea why mDNS traffic isn't being routed from the LAN ports to the WiFi networks on AP1 but apparently it is not. I looked through all the settings on AP1 and could find nothing about mDNS, bonjour, apple, etc. Nothing that would allow / disallow such traffic to pass between LAN and WiFi.

Again, thanks so much for your help. I never would have figured out what the issue was without your suggestion of doing an mDNS scan.

[i8beef]

I tried putting the IP address of one of the failing homes in the IP field of the castv2 node. This also didn't work which I found surprising.

Did you REMOVE the mDNS name first? If I remember correctly, if you still have BOTH, it'll preferentially use the mDNS lookup first, as that's basically just an optional lookup for the core behavior of connecting by IP (i.e. the IP field is ignored if the mDNS name field is present I think, I'd have to go look to make sure but thats what my memory says).

What brand is the gateway router out of curiosity? Is it a real router or an ISP supplied router (They might have it setup to drop multicast or something as a firewall rule maybe intentionally, or accidentally with a generic drop rule?).

[jbrown123]

I did not remove the mDNS name. Indeed, if I remove the name it works with an IP address. And if I put the name in and put a bogus IP address (not for the target device) it still speaks to the target device. So it appears your memory is correct. The mDNS name overrides the IP address.

The gateway is a C4000LG CenturyLink Modem by GreenWave. It supports both a DSL connection or an ethernet WAN connection. I'm using it with the WAN connection, not with CenturyLink DSL. It was my old modem/router/gateway before I upgraded from CenturyLink to a fiber provider.

I purchased the modem (rather than leasing) and I no longer have a CL account. I don't see how CL could have upgraded it remotely. It is possible, however, that the modem did a firmware upgrade on it's own (pull request rather than push).

https://smile.amazon.com/C4000LG-CenturyLink-DSL-Modem-GreenWave/dp/B08HWMXWT7?sa-no-redirect=1

Another interesting factoid - If I connect my phone to the CL WiFi (AP1) and do an mDNS query, I don't see any of the devices that are hooked to AP2. So it's clearly not connecting WiFi to the LAN network for mDNS traffic and it obviously used to do that since my google devices used to work with node.

[i8beef]

Huh, odd that it changed on you, but I've seen stranger things I guess. I'm assuming you tried the good old "turn it off and on again" fix just in case. I am less surprised by an edge router like that making a decision about mDNS rejection though than a standard router / switch / ap... they can probably afford to be a little more exclusionary in what they support.

[jbrown123]

Very odd. I can only guess that it did a firmware update and that's what changed.

I didn't try the "big red switch" fix because I was focused on testing whether moving them fixed it and such. I can give that a go and see what happens the other direction (being able to see "into" the LAN from the WiFi).

I agree about edge router rejection but I'm surprised it did it between the LAN and WiFi "ports".