I have a wireless network with three wireless access points using the same SSID and password combination [...] This works great, though I have two networks
Unrelated to your question, but I'd say there's one problem here already.
The SSID tells client devices what network they're joining – often they'll expect to seamlessly roam from AP to AP (with identical SSIDs) without needing to close any connections, and that only works when all APs provide access to the same subnet. So if there are several access points offering the same SSID, they really ought to offer access to the same network, not to two networks. (Or if networks are separate, then SSIDs should be different too.)
I mean, your setup will mostly work if devices always have strong signal and don't move around while transferring data... but it's still not great.
now I have an IoT device that's connected to Network A (based on physical location, and it's not moveable) that I want to be able to talk to while connected to Network B.
Direct connections should already just work. Any 192.168.x.x device should be able to make IP connections to any 10.0.0.x device without problems. Try ping 192.168.y.z from a computer and it should work.
Although if your IoT device uses broadcasts in its communication, the situation is different – these will (almost) never go through a router and will always remain limited to their own subnet.
I don't know that I could convince the app for the IoT device to use a specific IP/port combo
...Well, if the app only supports automatic device discovery and doesn't let you enter a specific IP address, that indeed sounds like it needs to send/receive broadcast packets.
I doubt that Google Home (the router in between) will have an option to forward broadcasts. It's a rarely seen feature.
I thought port forwarding was the way to go, but a long chat with Google tech support essentially told me that even if port forwarding is what I want, their app won't do it unless you've already connected the device to Network B
It is unnecessary when connecting from network B to network A, for the same reason that makes port forwarding unnecessary when connecting from network A to the Internet. Just by following the "default gateway" configuration, the packets already go where they need to.
Port forwarding is only useful in the opposite direction (inwards) – from WAN to network A, or from A to network B – because devices on the outer network normally don't know which way to reach addresses belonging to the inner network.
But either way, port forwarding would only help for direct connections, not broadcast-based "device discovery".
I've searched the web and haven't found what Comcast's "Bridge Mode" specifically does. Some folks say it allows the Wifi to work in a mesh-like configuration. (I don't see how that's possible without more configuration than turning a single toggle on the modem/router's web interface off. I would expect that you'd have to at least teach it what was authoritative for DHCP, etc)
You could say bridge mode is the opposite of router mode – it connects all ports (whether they're "WAN" or "LAN") to a single subnet.
If bridge mode is to be used on an "inside" device (e.g. your #2 Google Home), then yes, the resulting single network gives you what's sometimes called "mesh-like Wi-Fi", that is, being able to access the same network through several access points (though it's only something made popular by mesh Wi-Fi products and has nothing specifically to do with mesh otherwise).
On the other hand, if bridge mode is to be used on the "outermost" device (e.g. your Comcast modem), then that device should not provide Wi-Fi at all (since it'll be on the 'WAN' side now), and you'll have one access point less.
In both cases, the advantage is that all devices connected to all access points are part of the same IP subnet and can reach each other without worrying much about routing. That also means any packets that your app broadcasts to the whole "LAN" will also reach the IoT device, or vice versa.
You're right that something needs to be done to avoid DHCP duplication – in some models enabling the "bridge" toggle automatically turns off DHCP service on the device, but most often you have to turn it off by itself.
Ideally in your case the Comcast modem would continue acting as a router (due to being outermost) and the wired Google Home would act as a bridge... but unfortunately Google doesn't support that when you have additional mesh Wi-Fi nodes attached to it. (And various fancy features in the Home app would stop working, too.)
Other sources say it just turns off the Wifi radios and that is all.
No, but if bridge mode is to be used on the "outermost" device, that makes it somewhat necessary to turn off Wi-Fi on that device – because everything connected to it would be on the WAN side (would try to obtain public IP addresses from the ISP), and you generally don't want laptops and phones to do that.
Yes, unfortunately that means Google's recommendation to turn the Comcast modem into a bridge would result in the IoT device having no Wi-Fi in its physical location anymore.
if it appropriately solves the problem?
As long as your IoT device is physically located next to the Comcast modem, no – because there will still be a router (the Google Home) separating it from your app.
