Trying to understand Guest Network Pro limitations

[bennor]

For what ever reason the Guest Network Pro on my RT-AX86U Pro gets wonky if I've added and removed a bunch of Guest Network Pro Profiles. Sometimes it doesn't show all the available settings or options in newly added Profiles. Typically what I've had to do is remove all the Profiles, reboot the router, then add each one back one at a time.

In any case here is brctl show for my setup. Redacted the bridge id device MAC address.

/jffs/scripts$ brctl show
bridge name    bridge id        STP enabled    interfaces
br0        8000.xxxxxxxxxxc0    no        eth1
                            eth2
                            eth3
                            eth4
                            eth5
                            eth6
                            eth7
br52        8000.xxxxxxxxxxc1    no        eth1.52
                            eth2.52
                            eth3.52
                            eth4.52
                            eth5.52
                            eth6.52
                            eth7.52
                            wl0.1
br53        8000.xxxxxxxxxxc5    no        eth1.53
                            eth2.53
                            eth3.53
                            eth4.53
                            eth5.53
                            eth6.53
                            eth7.53
                            wl1.1

@visortgw, Just did a quick test and can successfully print to a HP Officejet printer connected to 2.4 GHz main LAN WiFi from a smartphone connected to a Guest Network IoT Profile (br53) 5 GHz network. Can ping and access the HP Officejet printer's administration GUI page as well from the Guest Network Pro IoT Profile (br53) 5 GHz network connected smartphone. I did have to access HP Printer app (on the smartphone) settings and toggle a WiFi 5 GHz option before the HP printer app would see the main LAN WiFi 2.4 GHz connected HP Officejet printer. Here are the firewall-start script I used. 192.168.2.163 is the IP address for the HP Officejet printer, br53 192.168.53.0/24 is the Guest Network Pro IoT Profile (5 GHz).

#!/bin/sh
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.2.163 -j ACCEPT
iptables -I FORWARD -i br0 -s 192.168.2.163 -d 192.168.53.0/24 -j ACCEPT

You may want to dump your IPTables to see if the firewall-start entries are getting input into the firewall's IPTables list.
Example on my system showing the above script has input the two IPTables entries:

/jffs/scripts$ iptables -nL | grep 192.168.2.163
ACCEPT     all  --  192.168.2.163        192.168.53.0/24 
ACCEPT     all  --  192.168.53.0/24      192.168.2.163

If the script isn't being injected into the IPTables then double check you have the firewall-start in the /jffs/scripts/ folder on the router and that it has the correct permissions (0755) so it can be executed. Then check the script itself for any errors or typo's.

 

[bennor]

Another way of showing the correct entries for my code in my router's IPTables:

/jffs/scripts$ iptables -S | grep 192.168.2.163
-A FORWARD -s 192.168.2.163/32 -d 192.168.53.0/24 -i br0 -j ACCEPT
-A FORWARD -s 192.168.53.0/24 -d 192.168.2.163/32 -i br53 -j ACCEPT

 

[visortgw]

My printer is connected via Ethernet cable to the primary network with a fixed IP address of 192.168.222.10.

# iptables -S | grep 192.168.222.10
-A FORWARD -s 192.168.222.10/32 -d 192.168.54.0/24 -i br0 -j ACCEPT
-A FORWARD -s 192.168.222.10/32 -d 192.168.52.0/24 -i br0 -j ACCEPT
-A FORWARD -s 192.168.54.0/24 -d 192.168.222.10/32 -i br52 -j ACCEPT
-A FORWARD -s 192.168.52.0/24 -d 192.168.222.10/32 -i br53 -j ACCEPT

# iptables -nL | grep 192.168.222.10
ACCEPT     all  --  192.168.222.10       192.168.54.0/24     
ACCEPT     all  --  192.168.222.10       192.168.52.0/24     
ACCEPT     all  --  192.168.54.0/24      192.168.222.10     
ACCEPT     all  --  192.168.52.0/24      192.168.222.10

 

[bennor]

My printer is connected via Ethernet cable to the primary network with a fixed IP address of 192.168.222.10.

I may have missed it, but have you tried a different device on the main LAN as a troubleshooting step? Could be a specific issue with the printer, like maybe it doesn't respond to IP addresses outside it's own IP address subnet.

I tested yesterday with a NAS connected via Ethernet to the router (on main LAN) and didn't have an issue. My br53 Guest Network Pro IoT Profile clients could contact that NAS via SMB and HTTP and ping.

PS: Or perhaps the issue is with the Guest Network Pro Profiles themselves due the br numbers and IP address numbers not matching like they should when initially created.
PPS: If you have a VPN assigned to the Guest Network Pro Profiles maybe try disabling or unselecting that VPN and applying the changes.

 

[jksmurf]

This is a really interesting discussion with well presented solutions, thank you. I checked my LANs using brtcl show and I’m pleased to see they still follow the bridge / LAN numbering, I prefer it when they are in sync.

Would this work with a Google Chromecast e.g. if I have the Chromecast on my IoT network (say), could I assign guest users access to that device so they could cast any media (streaming or otherwise) from their phone to the Chromecast and it would play on the TV in the Guest Bedroom?

While I’d be comfortable making these specific rules, following these guidelines, for average users (me), wouldn’t it be nice if this IPTables forwarding rule (if that is what it is called) could be incorporated into Merlin Firmware or an Addon? It just makes it easier to add, amend and delete.

There must be other folks that would like to assign e.g. Guest users, access to a single device on the primary network, like a printer.

 

[bennor]

Would this work with a Google Chromecast e.g. if I have the Chromecast on my IoT network (say), could I assign guest users access to that device so they could cast any media (streaming or otherwise) from their phone to the Chromecast and it would play on the TV in the Guest Bedroom?

If you have a Chromecast; try it and find out. Add the scripting and report back if it worked for you.

While I’d be comfortable making these specific rules, following these guidelines, for average users (me), wouldn’t it be nice if this IPTables forwarding rule (if that is what it is called) could be incorporated into Merlin Firmware or an Addon? It just makes it easier to add, amend and delete.

The problem is the mess that Guest Network Pro is at the moment. The entire Guest Network Pro portion feels like beta as users use it here. Certain things just don't work properly with it as many of us have discovered.

Much of what is being discussed both here and in certain other threads about using scripting to accomplish certain things with Guest Network Pro is simply users trying to emulate what YazFi did behind the scenes with Guest Network on Asus-Merlin 3004.x firmware. YazFi is no longer being actively developed by it's developer (@Jack Yaz) and @Martinski has made some modifications to YazFi in recent years. Due to the complexity of Guest Network Pro it would likely take a significant and major rewrite YazFi to work Guest Network Pro. Asus has indicated that starting from firmware version 3.0.0.6.102_35404, the name will change from [Guest Network Pro] to [Network] which will likely further complicate trying to create a addon script.

As always anyone is free to take their own stab at writing a addon script for Guest Network Pro.

In the mean time the firewall-start scripting is what it is to try and accomplish certain things around the mess that is Guest Network Pro. As we see above, what works for one person may not work with another quite possibly due to the variation of Guest Network Pro Profile configurations.

 

[jksmurf]

If you have a Chromecast; try it and find out. Add the scripting and report back if it worked for you.

I do indeed have a Chromecast with Google TV.

Before I start on that I wanted to provide some feedback on another Inter-VLAN issue I had been having and how your suggestion fixed it.

A. Home Assistant (HA):

1. All my IoT devices, particularly those supported by and supporting Home Assistant, are on the IoT VLAN, VLAN 53.

• My HA Server is 192.168.53.13; my Primary VLAN is 192.168.9.0/24.
• When I first set up GNP I tried to isolate the IoT from Primary (and indeed my other VLANs), by leaving "Access Intranet" unchecked. See Pic.
• However in doing so I could not get the HA server to be accessed from the primary VLAN unless I selected "Main Network" in the GNP General screen for my IoT Network, which I did.
• I left it like that so I could use it; and I had concerns that the various Apps I sometimes use to enable/disable IoT devices from my iPhone, which is connectd to the primary VLAN would also not work without “Main Network” being checked.
• To test again I unchecked "Access Intranet" for the Main Network and tried all the Apps; Tapo, Alexa, Kasa, Sensibo, Mii, LGThinQ and EzViz, from my iPhone (connected to the Primary Network). They all worked, but I believe this is due to them doing so over the Internet.
• What did not work, as expected, was the HA Server.
• So, I tried the IP Tables suggested above, adding these lines to firewall-start, located in /jffs/scripts

# Added by KM to allow access to the Home Assistant Server from any client on the Primary Network
iptables -I FORWARD -i br0 -s 192.168.9.0/24 -d 192.168.53.13 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.13 -d 192.168.9.0/24 -j ACCEPT

Saved, then restarted the firewall with service restart_firewall, refreshed the Browser and ..................................................................... Success!

B. Google Chromecast with TV:

So, flushed with success from the trial above, I thought I would tackle the Google Chromecast TV.

This is a very different beast; it feels like folks have tried a hundred ways (see attachments) to get past the requirement to have the Chromecast on the same VLAN as the casting device.

• So, my Chromecast is on the IoT VLAN, address 192.168.53.239.
• My Guest Network, that I want to cast from, is 192.168.52.0/24.

# Added by KM to allow Guest access to Chromecast with Google TV from any client on the Guest Network. I added a two-way rule like this:
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.53.239 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.239 -d 192.168.52.0/24 -j ACCEPT

I baseline-tested by casting YouTube while on the same IoT VLAN; all fine.
Unfortunately when the Client Device is on the Guest VLAN, this does not work. So to answer my and your question, no, iptables alone do not work.

There appear to be a myriad of solutions from checking mDNS, IGMPv3, TCP/UDP Ports and iptable forwards like these, none of which I really undertsand.

As regards multicast/mDNS I might try looking at my post here again as it helped someone else recently, but I don't really know what I am doing TBH, nor the security implications.

Happy for any (simple) advice, as always. These links are to various posts about getting Chromecast to work across VLANs.

• Link1
• Link2
• Link3
• Link4
• Link5

 

[bennor]

# Added by KM to allow Guest access to Chromecast with Google TV from any client on the Guest Network. I added a two-way rule like this:
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.53.239 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.239 -d 192.168.52.0/24 -j ACCEPT

If you haven't done so already as a troubleshooting step. Take the Chromecast out of the mix and just try to see if the two Guest Network Pro Profile networks (br52 and br53) can communicate with each other by using something like the following. If the two VLAN/SDN's clients can communicate with each other than it's likely an issue specific to Chromecast.

iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.53.0/24 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.52.0/24 -j ACCEPT

Also ensure you don't have Set AP Isolated enabled on either of the Guest Network Profiles advanced settings.

 

[jksmurf]

If you haven't done so already as a troubleshooting step. Take the Chromecast out of the mix and just try to see if the two Guest Network Pro Profile networks (br52 and br53) can communicate with each other by using something like the following. If the two VLAN/SDN's clients can communicate with each other than it's likely an issue specific to Chromecast.

Ok thank you, will need to try tomorrow, getting a wee bit late.

iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.53.0/24 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.52.0/24 -j ACCEPT

What’s the best way to check there’s information going both ways unobstructed? Ping?

Also ensure you don't have Set AP Isolated enabled on either of the Guest Network Profiles advanced settings.

lol I do actually have that enabled for br52, the Guest Network. Will try turning it off later.

Thanks again, k.

 

[bennor]

What’s the best way to check there’s information going both ways unobstructed? Ping?

Ping is one way assuming the targeted device responds to pings. Other methods are SMB or the like if a computer or NAS with file sharing enabled. Or via HTTP if the target device has a web GUI (like a printer).

 

[jksmurf]

If you haven't done so already as a troubleshooting step. Take the Chromecast out of the mix and just try to see if the two Guest Network Pro Profile networks (br52 and br53) can communicate with each other by using something like the following. If the two VLAN/SDN's clients can communicate with each other than it's likely an issue specific to Chromecast.

Thank you, I did not need to do this in the end, see below.

Also ensure you don't have Set AP Isolated enabled on either of the Guest Network Profiles advanced settings.

Did not need to turn that off either. So, just an update with my developments so far:

B. Google Chromecast with TV [Client on Guest Network to TV on IoT Network]

As noted above "As regards multicast/mDNS I might try looking at my post here again as it helped someone else recently...", well I just tried it and my goodness me, I helped myself . Success! I tried both Youtube and Vimeo casting.

Note that I did not even need AP Isolation to be switched off; it just worked. No TCP/UDP Ports, no million other tweaks, just the two requirements below.

Chromecast is on the IoT VLAN, address 192.168.53.239.
Guest Network, that I want to cast from, is 192.168.52.0/24.

Summary:

[Requirement 1] Amend the firewall-start file in /jffs/scripts

# Added by KM to allow Guest access to Chromecast with Google TV from any client on the Guest Network. I added a two-way rule like this:
iptables -I FORWARD -i br52 -s 192.168.52.0/24 -d 192.168.53.239 -j ACCEPT
# iptables -I FORWARD -i br53 -s 192.168.53.239 -d 192.168.52.0/24 -j ACCEPT

Restart the firewall service by issuing

service restart_firewall

AND

[Requirement 2] Add and amend the avahi-daemon.conf.add file in /jffs/configs

Add the file avahi-daemon.conf.add to /jffs/configs/ [if it does not already exist]
Add this line into it, under the [bracketed] heading shown

[reflector]
enable-reflector=yes

Restart the daemon by issuing

service restart_mdns

check the same lines as above are in the avahi-damon.conf file in /tmp/avahi/avahi-daemon.conf

So a huge thank you to you for Requirement 1 and I have @ColinTaylor to thank for Requirement 2. Success!

[EDIT] The first time I ran it, I only used the first line in requirement 1 (i.e. casting from Client on the Guest Wifi TO the Google TV) and it worked, so may be enough (and more secure). I only added the second line when I was troubleshooting.

C. Google Chromecast with TV [Client on Primary Network to TV on IoT Network]

Never satisfied, I thought I would extend this capability to Clients on the Primary Network Wifi to the TV (on the IoT Network Wifi), thinking this will be easy-peasy-lemon-squeezy, two more lines in firewall-start, restart the daemon and I am done.

Nope; this does not work. Very odd.

# Added by KM to allow User access to Chromecast with Google TV from any client on the Primary Network
iptables -I FORWARD -i br0 -s 192.168.9.0/24 -d 192.168.53.239 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.239 -d 192.168.9.0/24 -j ACCEPT

Why would this not work? I checked IoT-IoT still worked (Yup, Chromecast Default), Guest-IoT as in B above still worked (Yup) but the Primary-IoT connectivity (Nope, it hates me). Did I type in something wrong, is there something about the Primary Network having even tighter security?

xxxxxxxxx@RT-AX88U-Pro:/tmp/home/root#  iptables -S | grep 192.168.9.0
-A FORWARD -s 192.168.53.239/32 -d 192.168.9.0/24 -i br53 -j ACCEPT
-A FORWARD -s 192.168.9.0/24 -d 192.168.53.239/32 -i br0 -j ACCEPT
-A FORWARD -s 192.168.9.0/24 -d 192.168.53.13/32 -i br0 -j ACCEPT
xxxxxxxxx@RT-AX88U-Pro:/tmp/home/root#  iptables -S | grep 192.168.53.0
xxxxxxxxx@RT-AX88U-Pro:/tmp/home/root#  iptables -S | grep 192.168.52.0
-A FORWARD -s 192.168.53.239/32 -d 192.168.52.0/24 -i br53 -j ACCEPT
-A FORWARD -s 192.168.52.0/24 -d 192.168.53.239/32 -i br52 -j ACCEPT

 

[jksmurf]

C. Google Chromecast with TV [Client on Primary Network to TV on IoT Network]
....

Nope; this does not work. Very odd.

So for this one I followed @bennor suggestion for seeing if any client can ping either way (Primary to IoT).

# Added by KM as Trial for Primary to IoT (and vv if needed, 2nd line)
iptables -I FORWARD -i br0 -s 192.168.9.0/24 -d 192.168.53.0/24 -j ACCEPT
iptables -I FORWARD -i br53 -s 192.168.53.0/24 -d 192.168.9.0/24 -j ACCEPT

I then put my Notebook on the IoT Wifi and with my PC on the Primary Wifi I

I: Ran a ping from my PC (Primary) to my Notebook (IoT); from the Router via SSH

xxxxxxx@RT-AX88U-Pro:/tmp/home/root# ping -c4 192.168.53.39
PING 192.168.53.39 (192.168.53.39): 56 data bytes
64 bytes from 192.168.53.39: seq=0 ttl=128 time=18.353 ms
64 bytes from 192.168.53.39: seq=1 ttl=128 time=4.166 ms
64 bytes from 192.168.53.39: seq=2 ttl=128 time=5.175 ms
64 bytes from 192.168.53.39: seq=3 ttl=128 time=3.193 ms

--- 192.168.53.39 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 3.193/7.721/18.353 ms
xxxxxxx@RT-AX88U-Pro:/tmp/home/root#

II: Ran a ping from my Notebook (IoT) to my PC (Primary); from a CMD Window

C:\WINDOWS\system32>ping 192.168.9.10

Pinging 192.168.9.10 with 32 bytes of data:
Reply from 192.168.9.10: bytes=32 time=3ms TTL=127
Reply from 192.168.9.10: bytes=32 time=5ms TTL=127
Reply from 192.168.9.10: bytes=32 time=4ms TTL=127
Reply from 192.168.9.10: bytes=32 time=5ms TTL=127

Ping statistics for 192.168.9.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 5ms, Average = 4ms

C:\WINDOWS\system32>

III: Ran a ping from my PC (Primary) to my Google TV (IoT); from the Router via SSH

xxxxxxxxx@RT-AX88U-Pro:/tmp/home/root# ping -c4 192.168.53.239
PING 192.168.53.239 (192.168.53.239): 56 data bytes
64 bytes from 192.168.53.239: seq=0 ttl=64 time=1312.368 ms
64 bytes from 192.168.53.239: seq=1 ttl=64 time=312.239 ms
64 bytes from 192.168.53.239: seq=2 ttl=64 time=613.695 ms
64 bytes from 192.168.53.239: seq=3 ttl=64 time=13.943 ms

--- 192.168.53.239 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 13.943/563.061/1312.368 ms
xxxxxxxxx@RT-AX88U-Pro:/tmp/home/root#

I then set log debug level to debug/debug to attempt to capture the events when I :

• From my iPhone, on the Guest Wifi, successfully played a Youtube Video on the Google Chromecast TV on the IoT Wifi. Here, the prompt came up to 'Play on SmurfCastTV'.
• From my iPhone, on the Primary Wifi, was not successful in playing a Youtube Video on the Google Chromecast TV on the IoT Wifi. Here, 'Play on SmurfCastTV' was not offered.

Apr 25 13:07:10 kernel: 2E:F2:07:B7:30:6F not mesh client, can't delete it
Apr 25 13:07:22 syslogd exiting
Apr 25 13:07:22 syslogd started: BusyBox v1.25.1
Apr 25 13:07:22 kernel: klogd started: BusyBox v1.25.1 (2025-04-19 12:20:11 EDT)
Apr 25 13:07:44 wlceventd: wlceventd_proc_event(662): eth7: Disassoc 98:50:2E:5B:F0:88, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr 25 13:07:44 wlceventd: wlceventd_proc_event(645): eth7: Deauth_ind 98:50:2E:5B:F0:88, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Apr 25 13:07:44 hostapd: eth7: STA 98:50:2e:5b:f0:88 IEEE 802.11: disassociated
Apr 25 13:07:44 hostapd: eth7: STA 98:50:2e:5b:f0:88 IEEE 802.11: disassociated
Apr 25 13:07:44 hostapd: wl1.1: STA 2e:f2:07:b7:30:6f IEEE 802.11: associated (aid 1)
Apr 25 13:07:44 wlceventd: wlceventd_proc_event(722): wl1.1: Assoc 2E:F2:07:B7:30:6F, status: Successful (0), rssi:-40
Apr 25 13:07:44 hostapd: wl1.1: STA 2e:f2:07:b7:30:6f RADIUS: starting accounting session 5A30A29A89B82A78
Apr 25 13:07:44 hostapd: wl1.1: STA 2e:f2:07:b7:30:6f WPA: pairwise key handshake completed (RSN)
Apr 25 13:07:44 dnsmasq-dhcp[17010]: DHCPREQUEST(br52) 192.168.52.83 2e:f2:07:b7:30:6f
Apr 25 13:07:44 dnsmasq-dhcp[17010]: DHCPACK(br52) 192.168.52.83 2e:f2:07:b7:30:6f iPhone
Apr 25 13:07:45 kernel: 74:13:EA:BD:45:9D not mesh client, can't update it's ip
Apr 25 13:08:39 kernel: 98:50:2E:5B:F0:88 not mesh client, can't delete it
Apr 25 13:08:42 kernel: 98:50:2E:5B:F0:88 not mesh client, can't delete it
Apr 25 13:09:01 hostapd: wl1.1: STA 2e:f2:07:b7:30:6f IEEE 802.11: disassociated
Apr 25 13:09:01 wlceventd: wlceventd_proc_event(662): wl1.1: Disassoc 2E:F2:07:B7:30:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Apr 25 13:09:01 wlceventd: wlceventd_proc_event(645): wl1.1: Deauth_ind 2E:F2:07:B7:30:6F, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
Apr 25 13:09:01 hostapd: wl1.1: STA 2e:f2:07:b7:30:6f IEEE 802.11: disassociated
Apr 25 13:09:02 hostapd: eth7: STA 98:50:2e:5b:f0:88 IEEE 802.11: associated (aid 3)
Apr 25 13:09:02 wlceventd: wlceventd_proc_event(722): eth7: Assoc 98:50:2E:5B:F0:88, status: Successful (0), rssi:-41
Apr 25 13:09:02 hostapd: eth7: STA 98:50:2e:5b:f0:88 RADIUS: starting accounting session B2C71CC686B3F9E6
Apr 25 13:09:02 hostapd: eth7: STA 98:50:2e:5b:f0:88 WPA: pairwise key handshake completed (RSN)
Apr 25 13:09:02 dnsmasq-dhcp[17006]: DHCPREQUEST(br0) 192.168.9.202 98:50:2e:5b:f0:88
Apr 25 13:09:02 dnsmasq-dhcp[17006]: DHCPACK(br0) 192.168.9.202 98:50:2e:5b:f0:88 KristiansIP13
Apr 25 13:09:02 kernel: 98:50:2E:5B:F0:88 not mesh client, can't update it's ip
Apr 25 13:09:02 kernel: 74:13:EA:BD:45:9D not mesh client, can't update it's ip
Apr 25 13:09:10 kernel: 74:13:EA:BD:45:9D not mesh client, can't update it's ip
Apr 25 13:09:13 kernel: 74:13:EA:BD:45:9D not mesh client, can't update it's ip
Apr 25 13:09:47 kernel: 2E:F2:07:B7:30:6F not mesh client, can't delete it
Apr 25 13:10:15 kernel: 2E:F2:07:B7:30:6F not mesh client, can't delete it
Apr 25 13:10:45 kernel: 74:13:EA:BD:45:9D not mesh client, can't update it's ip
Apr 25 13:10:47 kernel: 2E:F2:07:B7:30:6F not mesh client, can't delete it
Apr 25 13:11:17 kernel: 74:13:EA:BD:45:9D not mesh client, can't update it's ip
Apr 25 13:11:34 rc_service: httpd 23442:notify_rc restart_logger
Apr 25 13:11:34 custom_script: Running /jffs/scripts/service-event (args: restart logger)
Apr 25 13:11:34 syslogd exiting
Apr 25 13:11:34 syslogd started: BusyBox v1.25.1
Apr 25 13:11:34 kernel: klogd started: BusyBox v1.25.1 (2025-04-19 12:20:11 EDT)

One thing I noticed that when I was on the Guest Wifi my phone got a DHCP-assigned IP Address for that Wifi (as expected); and could cast to the Google TV OK.

However when I was on the Primary Wifi with my phone, of course it was given its manually assigned 192.168.9.202 address; but I could not cast to the Google TV. It is like the TV said, aha, I know you, I am not letting you in, whereas it seems to be much kinder to strangers on the Guest Wifi.

My Addons as per attachment, in case one of them that makes a difference.

k.

 

[bennor]

No idea if relevant but see the following post that might have some pointers:

Chromecast across two subnets

I ran my network this way for a while, and it worked for the most part. Essentially, what I had was an IoT VLAN into which all chromecast, roku and similar devices were placed. I'll say up front that while the end result allowed clients in LAN to cast to devices in IoT, certain things like...

forum.openwrt.org

Just throwing stuff against the wall but one thing I notice in that post is the person in that link has a allow-interfaces entry in their avahi-daemon conf file in the [server] section. Maybe something like that needs to be added to the avahi-daemon.conf.add file with the network interfaces you want to include.

https://linux.die.net/man/5/avahi-daemon.conf

allow-interfaces= Set a comma seperated list of allowed network interfaces that should be used by the avahi-daemon. Other interfaces will be ignored. If set to the empty list all local interfaces except loopback and point-to-point will be used.

 

[jksmurf]

Just a redirect post to an avahi thread and then an mDNS thread as while I believe my original post was on-topic, it veered off a little bit into mDNS usage for Chromecast which while it does use the IPTABLES recommendation from bennor (thank you again) has now veered OT into the avahi domain.

Having researched this issue a bit more it seems to have been a very difficult problem for at least 10 years, so I will continue to jot down any details I have on what is working (or not) in the separate threads. Thanks again to bennor for the guidance.