What's new

RT-AC68U Chromecast doesn't work on guest network

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

pythag0rus

New Around Here
Hello,

I upgraded my ASUS router RT-AC68U firmware (standard not merlin) recently to 3.0.0.4.386_40558-gc48f410 (from a 2018 firmware) and then suddenly my Chromecast was not visible anymore. So I reset my Chromecast and then it tells me:
Your Chromecast is connected by cannot be reached.

I then factory reset my router to make sure I start from a clean state and settings. Redo the operation, same thing.

I see my Chromecast connected in the network devices list, with a different VLAN (.102 instead of .1) than my normal network (fine). My cellphone is connected to that guest network.

I disabled airtime fairness (wireless -> professional -> airtime fairness) but no cigar.
AP Isolated is disabled (set to no)

If I connect my Chromecast to my regular network (not the guest), it works.

It used to work flawlessly before upgrade the firmware.

Would like to keep the Chromecast on the guest network.

Any thing else I should try?

Thank you!
 
Last edited:
That's because Chromecast depends on network discovery to work, but whenever you have multiple IP networks on different ethernet segments, network discovery will NOT cross network boundaries. IOW, this is normal, expected behavoir. When using third-party firmware, this can be mitigated by using an mDNS repeater (aka reflector), which propagates the network discovery protocol across those network boundaries. But when using OEM/stock firmware, in my experience, this is rarely an option.

FWIW, I'm running FT (FreshTomato) third-party firmware on my ASUS RT-AC68U and like you have my Chromecast devices on a separate network (IOT) from my private network. And I use Avahi (an mDNS repeater) to make network discovery work.

 
Hi @eibgrad thanks for replying.

I get what you are saying, but from what I understand, my cellphone and the Chromecast are on the same network (.102) so how come they cannot see each other?

Why when I join the Chromecast to the regular network, I can properly join it. That's what I'm trying to understand. Why does it work on the regular segment, but not on the guest segment
 
Hi @eibgrad thanks for replying.

I get what you are saying, but from what I understand, my cellphone and the Chromecast are on the same network (.102) so how come they cannot see each other?

Why when I join the Chromecast to the regular network, I can properly join it. That's what I'm trying to understand. Why does it work on the regular segment, but not on the guest segment

Try using an index2 guest WLAN that will broadcast from the router/root node only and use IPs from the router DHCP server IP Pool. I believe it will then work/route as it did before index1 guest WLANs were made to work across all AiMesh nodes, and where now the default appears to be that all guests are isolated from each other.

OE
 
Last edited:
I had read that ASUS made some changes in the config of Guest network 1 in 386....I don't think anyone knows exactly the extent of the changes. It was reported that Guest 2 and 3 still work as before, so you may want to try moving to using one of those.
 
I had read that ASUS made some changes in the config of Guest network 1 in 386....I don't think anyone knows exactly the extent of the changes. It was reported that Guest 2 and 3 still work as before, so you may want to try moving to using one of those.

No dice using #3 index, see pictures

asus-guest-settings.png

Screenshot_20201115-193942__01.jpg
 
No dice using #3 index, see pictures

View attachment 27691

I added a 5.0 index2 guest WLAN, setup Chromecast on it, and got the same error with both Chromecast and my Google Home app/tablet connected to the same guest WLAN. I then enabled Intranet access for that guest WLAN and it then worked.

This suggests you should not try to use Chromecast on a guest WLAN.

OE
 
Hi

I have run in to the same issue after upgrading to the latest release. The guest wifi now isolates clients from each other and that broke my Sonos system. Having down graded to the previous release its all working again. I was wondering if the behaviour could be changes by tweaking the iptables firewall through the CLI but I don't think that would change the flow of traffic within the same subnet.

Its very frustrating as I want to keep the IOT devices off the main network but I want the AiMesh 2 ability to extend the guest network to other nodes.
 
What is the output if you ssh to the router and run

nvram show | grep isolate

wl0.2_ap_isolate=0
size: 49226 bytes (16310 left)
wl0_ap_isolate=0
wl1.3_ap_isolate=1
wl0.3_ap_isolate=0
wl1.1_ap_isolate=1
wl1_ap_isolate=0
wl1.4_ap_isolate=0
wl0.1_ap_isolate=0
wl0.4_ap_isolate=0
wl1.2_ap_isolate=0
wl_ap_isolate=1
 
When I changed it to 2, it automatically applied isolation
wl1.2_ap_isolate=1

I think the problem comes there. The guests networks are isolated by default and that cannot be changed.
Thanks for the feedback....looks like we're out of luck. Asus moved the code that manages ap_isolate to closed source.
In the past I had written a patch for Merlin that allowed the user to independently set guest isolation but can't anymore.
 
Thanks for the feedback....looks like we're out of luck. Asus moved the code that manages ap_isolate to closed source.
In the past I had written a patch for Merlin that allowed the user to independently set guest isolation but can't anymore.

Thank you for your feedback and help @john9527. This is super unfortunate. Will have to add the chromecast to private network for now, until I see what I do with my network strategy. Thank you!
 
@pythag0rus
Had one more thought....what's the output of

ebtables -L
ebtables -t broute -L

ebtables -L:

Code:
Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

ebtables -t broute -L
Code:
Bridge table: broute

Bridge chain: BROUTING, entries: 3, policy: ACCEPT
-p IPv4 -i wl1.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl1.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl1.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
 
@pythag0rus
I'm assuming you still have 5GHz guest 2 active...

This will be like using a sledge hammer to kill a fly, but it will tell us if they did anything else in the close source. try running

ebtables -t broute -F

Then don't reboot or change any other settings, and try connecting the Chromecast to guest 2....
 
@pythag0rus
I'm assuming you still have 5GHz guest 2 active...

This will be like using a sledge hammer to kill a fly, but it will tell us if they did anything else in the close source. try running

ebtables -t broute -F

Then don't reboot or change any other settings, and try connecting the Chromecast to guest 2....
Flushing the iptables for the bridge table, no dice, same problem

You have a couple easy options.

1. Upgrade to the latest beta build from ASUS


2. Move your Guest network from the first slot to the second or third. Only the first slot is impacted.

I'm already on the second slot. I also tried the third and no dice. So I guess the beta is the only solution? Have they fixed it in the beta? or done something new?
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top