RT-AC5300 + Google Home/Chromecast, something wrong getting everything to play nice.

[JoshuaW22]

Hello!

Long story short: I bought a RT-AC5300, hoping to get full coverage in my home, and have gotten nothing but weeks of frustration in return.

I have a few Google homes, and a 3 chromecast devices around my home.

At this stage, I've spent many a night diggin through old forum threads looking for solutions, but haven't found any fixes for the lack of connectivity between devices.

To be clear: I always can "Cast to nearby chromecast" device, but otherwise it's 1 in 10 odds that any of the three chromecasts are available as a cast option.

To date I have:

Disabled the firewall, and the AI protection, QOS, Gameboost, etc.
Disabled Smart connect,
Used all three wifi band's with the same and dissimilar SSIDs,
Factory reset,
Ensured all APs are NOT isolated
Enabled and disabled IGMP snooping, Airtime Fairness, Universal beamforming on each band
Enabled Multicast Routing (IGMP Proxy)
Enabled IGMP Snooping (IPTV section)

And a few other tweaks I am likely not remembering

Currently, I see this, repeated in my logs:

May 29 20:48:28 acsd: eth1: NONACSD channel switching to channel spec: 0x1002 (2)
May 29 20:50:08 acsd: selected channel spec: 0x1007 (7)
May 29 20:50:08 acsd: Adjusted channel spec: 0x1007 (7)
May 29 20:50:08 acsd: selected channel spec: 0x1007 (7)
May 29 20:50:10 acsd: eth1: NONACSD channel switching to channel spec: 0x1007 (7)
May 29 20:51:21 acsd: selected channel spec: 0x1002 (2)
May 29 20:51:21 acsd: Adjusted channel spec: 0x1002 (2)
May 29 20:51:21 acsd: selected channel spec: 0x1002 (2)
May 29 20:51:23 acsd: eth1: NONACSD channel switching to channel spec: 0x1002 (2)
May 29 20:52:51 acsd: selected channel spec: 0x1007 (7)
May 29 20:52:51 acsd: Adjusted channel spec: 0x1007 (7)
May 29 20:52:51 acsd: selected channel spec: 0x1007 (7)
May 29 20:52:53 acsd: eth1: NONACSD channel switching to channel spec: 0x1007 (7)
May 29 20:54:27 acsd: selected channel spec: 0x1002 (2)
May 29 20:54:27 acsd: Adjusted channel spec: 0x1002 (2)
May 29 20:54:27 acsd: selected channel spec: 0x1002 (2)
May 29 20:54:30 acsd: eth1: NONACSD channel switching to channel spec: 0x1002 (2)
May 29 20:55:56 acsd: selected channel spec: 0x1007 (7)
May 29 20:55:56 acsd: Adjusted channel spec: 0x1007 (7)
May 29 20:55:56 acsd: selected channel spec: 0x1007 (7)
May 29 20:55:57 acsd: eth1: NONACSD channel switching to channel spec: 0x1007 (7)



And Here's my wireless log:

I am not sure what else I can do, but really miss having chromecast, and Google home working.

Not even sure if this is the right spot, but I am running Merlin, which was installed hoping it would get this working.

Help!

 

[doczenith1]

My Google home is working just fine connected to 2.4 Ghz. My chromecast is connected via the USB Ethernet adapter and working ok.

My setup is pretty much all defaults with some minor changes. Try these wifi settings on 2.4 with the channel set to whichever is least busy in your environment.

I would disable airtime fairness as it can cause problems. I have Enable Smart Connect off.

My 5 Ghz setup is similar.

 

[vlad33x]

Is UPnP off? If yes, then you need to forward the Chromecast port. If I remember correctly, that Chromecast depends on UPnP.

 

[doczenith1]

I have UPnP turned off. No need to forward any ports to Chromecast.

 

[ColinTaylor]

Is UPnP off? If yes, then you need to forward the Chromecast port. If I remember correctly, that Chromecast depends on UPnP.

This is wrong. Chromecast does not use UPnP (IGD) to forward ports. Chromecast does use SSDP (which is part of UPnP) but this has nothing to do with the router's UPnP function which is something completely different.

https://www.cisco.com/c/en/us/td/do...hnotes/7-6/chromecastDG76/ChromecastDG76.html
http://www.dial-multiscreen.org/home

I think the confusion comes from people talking about "UPnP" as if it were one thing (NAT traversal), it's not. Whether or not the router's UPnP option is enabled has no bearing whatsoever on whether devices on the LAN can communicate with each other using SSDP.

 

[eibgrad]

What specifically are these chromecast enabled devices? Smart TVs? Is the chromecast built-in? Are they wireless?

 

[JoshuaW22]

Hey All,

Thanks for the quick replies.

Upnp is on.

Chromecast enabled devices are actual hardware chromecasts connected to TV's via HDMI, 2 version 1, and one new 4K capable Chromecast Ultra.


Some new information for the case as well.

Found this thread, which seems to be related:
https://www.snbforums.com/threads/asus-aimesh-causes-almost-no-2-4ghz-throughput.48971/page-4

I imagine Apple Homekit and chromecast use similar archetecture?

 

[JoshuaW22]

On that note, disabled IGMP Snooping and things are already looking like they may be resolved. Need to wait a day for testing, but will report back.

 

[ColinTaylor]

As I understand it your problem is not with the casting itself but the fact that some devices aren't detected as targets to cast to. If so, then it would make sense that it a multicast issue, and therefore possibly related to IGMP Snooping.

If you haven't done so already, try comparing devices that are all connected to the same access point to those that are connected to different access points. There have been occasional problems reported (I don't know whether they were real problems) suggesting that multicast/broadcast traffic wasn't working properly between devices connected to different APs.

Regarding the errors in your log, it looks like your router is constantly changing the 2.4GHz channel between 2 and 7. Perhaps because the control channel is set to auto and it is detecting co-channel interference. Try setting it to a fixed channel, like 1, 6 or 11.

 

[EmeraldDeer]

Table of odds of success with IGMP settings

25%   IGMP Snooping Disabled   IGMP Proxy Disabled
25%   IGMP Snooping Disabled   IGMP Proxy Enabled
25%   IGMP Snooping Enabled    IGMP Proxy Disabled
25%   IGMP Snooping Enabled    IGMP Proxy Enabled

 

[JoshuaW22]

Confirmed, Disabled IGMP snooping, and disabled auto channel selection on all 3 bands, things are looking much much better already. Still not 100% (The odd device wont show up periodically) but will after a few refreshes, etc.

Yay!

 

[vlad33x]

This is wrong. Chromecast does not use UPnP (IGD) to forward ports. Chromecast does use SSDP (which is part of UPnP) but this has nothing to do with the router's UPnP function which is something completely different.

https://www.cisco.com/c/en/us/td/do...hnotes/7-6/chromecastDG76/ChromecastDG76.html
http://www.dial-multiscreen.org/home

I think the confusion comes from people talking about "UPnP" as if it were one thing (NAT traversal), it's not. Whether or not the router's UPnP option is enabled has no bearing whatsoever on whether devices on the LAN can communicate with each other using SSDP.

Well, thanks for the clarification, good to know this! It's a common misconception than, because Google keeps telling their users that it is required for the proper function of a Chromecast.

https://support.google.com/chromecast/forum/AAAAt7PFQG4Aa7vnbAbbCA?hl=en

 

[ColinTaylor]

Well, thanks for the clarification, good to know this! It's a common misconception than, because Google keeps telling their users that it is required for the proper function of a Chromecast.

https://support.google.com/chromecast/forum/AAAAt7PFQG4Aa7vnbAbbCA?hl=en

Yes, it's annoying. That forum post from "Grace" is the thing that gets repeated over and over again on internet forums. If you trawl through the reddit thread where she told people to turn off UPnP because of the PewDiePie hack you will eventually come across someone posting the information in my previous reply.

Even on the Google Home help pages they continue the confusion. See here where they say "UPnP (Universal Plug and Play), also known as multicast, allows for the discovery of UPnP enabled devices on the same Wi-Fi network" (my emphasis). So what they're saying is that multicast should be enabled, and that the multicast option is called "UPnP" on the router! This is clearly not the case on Asus routers (or any other router I've used) where the UPnP option means something else and there are separate options for multicast.

 

[JoshuaW22]

Dang, so half a week update:

Still having issues with range and connectivity.

Range: My old rt87u could reach every corner of my home, high and low with relatively strong connectivity, my new RT-AC5300 seems to have both: slightly less range, and periodic blips where devices disconnect for a moment. (Causing issues with items like a Nintendo switch dropping matches, but immediately being able to reconnect to the online system without issue.)

Connectivity: As prior, google home and chromecast devices work only periodically. I've been primarily checking by trying to cast the android youtube app, which pops up letting me see which devices are cast options. Sometimes I see all, much much more often I see one, or two, and often I see "Cast to nearby device" (instead of "Living Room TV" or w/e) which never works.

I tried a firmware upgrade back to the ASUS firmware, to setup a new lyra trio as an AIMesh setup. The AIMesh helps the range, but not at all the connectivity (I didn't really think it would help the connectivity).

Not using the Lyra currently, intend to set it up as a "game network" type thing on a seperate SSID, so we can ignore it for now.


Is there a recommended setup for the IPTV settings? I specifically see mention of IGMP snooping + multicast there as well, which seems it may be related?

Also, anyone have a settings hierarchy I can work through to debug one setting at a time? I am a little lost here, and google searching and updating random settings (and them back if they don't work) doesn't seem to be getting this fixed..

 

[ColinTaylor]

There seems to be multiple places where IGMP/multicast can be enabled or disabled. As well as the IPTV settings look at Wireless Professional > Enable IGMP Snooping. Remember that they have to be set individually for each of the 3 bands. I'd start by disabling all of the settings you can find.

 

[JoshuaW22]

Yeah, ive already disabled it in all 4 locations. (IPTV doesn't appear to have per said settings?)

Does DHCP routing have any impact on upnp?
Ideal setting?



These seem like this may be related to these?

#206
https://github.com/RMerl/asuswrt-merlin.ng/issues/206

#162
https://github.com/RMerl/asuswrt-merlin.ng/issues/162

#154
https://github.com/RMerl/asuswrt-merlin.ng/issues/154

#102
https://github.com/RMerl/asuswrt-merlin.ng/issues/102

#102 in particular actually mentions Chromecast devices


#102 is also spot on with regard to my experience. Devices I cannot access can still communicate with each other. Not always, but damn near always, I can ask my Google home to cast to a device I cannot see from mobile devices.


Seems something is going on.... Not sure what though...

 

[JoshuaW22]

For my own sanity, reset to factory settings again. No change.

Item of note:
The only device I can cast to directly is the chromeast ultra, which has an ethernet line to the router.
Checked again just now, at the moment, no devices can be cast to except the ultra, with it's wired connection. Can still cast to all devices using voice commands through the Google home though. So all is communicating together except cell phones and PCs cannot cast to anything.

 

[ColinTaylor]

Does DHCP routing have any impact on upnp?
Ideal setting?

No it doesn't, but I'm not sure what setting you're referring to. Is it "Use DHCP routes" under IPTV, if so just ignore it.

These seem like this may be related to these?

Those were the type of issues I was speculating about in post #9. That is why I said:

If you haven't done so already, try comparing devices that are all connected to the same access point to those that are connected to different access points. There have been occasional problems reported (I don't know whether they were real problems) suggesting that multicast/broadcast traffic wasn't working properly between devices connected to different APs.

I don't use any of these casting devices myself and I can't really follow how all you devices are connected. But my suggestion above was to try and determine whether it was the same apparent multicast/broadcast issue.

EDIT: The most promising information about (what appears to be) this problem came from @ryannathans. Unfortunately he hasn't logged into the forum since this thread.

 

[JoshuaW22]

It was the IPTV stuff, I will ignore it for now.



At this point I have no devices using 5ghz bands, only the single 2.4 SSID for all devices.

Issue persisting.


I am not familiar with the tests done in the thread you linked, but will see if I can learn some new software a little later today.

Any advice, or instructions that can be shared, I am Keen to help get this solved.


Not sure if this helps in the mean time:


SSID: "Network Name"
RSSI: 0 dBm SNR: 0 dB noise: -89 dBm Channel: 2
BSSID: 2C:FD:A1:E5:79:B0 Capability: ESS ShortSlot
Supported Rates: [ 1(b) 2(b) 5.5(b) 6 9 11(b) 12 18 24 36 48 54 ]
VHT Capable:
Chanspec: 2.4GHz channel 2 20MHz (0x1002)
Primary channel: 2
HT Capabilities:
Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ]
VHT Capabilities:
Supported VHT (tx) Rates:
NSS: 1 MCS: 0-11
NSS: 2 MCS: 0-11
NSS: 3 MCS: 0-11
NSS: 4 MCS: 0-11
Supported VHT (rx) Rates:
NSS: 1 MCS: 0-11
NSS: 2 MCS: 0-11
NSS: 3 MCS: 0-11
NSS: 4 MCS: 0-11

Interference Level: Acceptable
Mode : AP Only

Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS Tx rate Rx rate Connect Time
18:B4:30:E7:26:7D Yes Yes -53dBm n No Yes No No 2 144.4M 52M 01:01:56
18:B4:30:AB:3C3 Yes Yes -66dBm n No No Yes No 1 65M 65M 01:19:40
24:F5:A2:5F:5A:45 Yes Yes -57dBm n No Yes Yes No 1 65M 1M 01:21:13
08:86:3B:70:0F:F1 Yes Yes -64dBm n No Yes Yes No 1 65M 58.5M 01:26:40
18:B4:30:9A:1D:99 Yes Yes -65dBm n No No Yes No 1 65M 65M 01:37:44
3C:28:6D:EE:A3:F0 Yes Yes -66dBm ac Yes Yes Yes No 2 156M 1M 01:40:12
F4:F58:CA:73:00 Yes Yes -63dBm n No Yes No No 1 65M 72.2M 01:40:25
D8:6C:63:65:66:C4 Yes Yes -71dBm n No Yes No No 1 72.2M 72.2M 01:40:26
54:60:09:F2:55:66 Yes Yes -45dBm n No Yes No No 1 72.2M 72.2M 01:40:26
30:FD:38:78:4D:85 Yes Yes -53dBm n No Yes No No 1 72.2M 65M 01:40:27
4865:F07:8F Yes Yes -46dBm n No Yes No No 1 57.8M 72.2M 01:40:29
F4:F58:BE:0A:0A Yes Yes -57dBm n No Yes No No 1 58.5M 72.2M 01:40:29
6C:AD:F8:87:CF:1D Yes Yes -44dBm n No Yes Yes No 1 65M 65M 01:40:29
B4:75:0E:0C:2B:E5 Yes Yes -61dBm n No Yes Yes No 1 72.2M 1M 01:40:31
60:38:E0:4C:BE:5D Yes Yes -50dBm n No Yes Yes No 1 65M 1M 01:40:32
18:B4:30:82:65:FF Yes Yes -56dBm n Yes Yes No No 1 72.2M 72.2M 01:40:35
34:E1:2DC:58:2A Yes Yes -45dBm n No Yes Yes No 2 144.4M 86.7M 01:40:35
1C:F2:9A:61:BB:F2 Yes Yes -52dBm n No Yes No No 1 72.2M 1M 01:40:36
B4:F1A:EC:49:5F Yes Yes -69dBm ac No Yes Yes No 2 130M 104M 01:40:37
18:B4:30:AB:4E:67 Yes Yes -63dBm n No No Yes No 1 65M 39M 01:40:39
20F:B9:63:5E:EF Yes Yes -25dBm n No Yes Yes No 2 144.4M 1M 01:40:39
E8:61:7E:FF:73:0F Yes Yes -72dBm n No Yes Yes No 2 130M 26M 01:40:40

SSID: "Network Name 5"
RSSI: 0 dBm SNR: 0 dB noise: -92 dBm Channel: 36/80
BSSID: 2C:FD:A1:E5:79:B4 Capability: ESS
Supported Rates: [ 6(b) 9 12(b) 18 24(b) 36 48 54 ]
VHT Capable:
Chanspec: 5GHz channel 42 80MHz (0xe02a)
Primary channel: 36
HT Capabilities:
Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ]
VHT Capabilities:
Supported VHT (tx) Rates:
NSS: 1 MCS: 0-11
NSS: 2 MCS: 0-11
NSS: 3 MCS: 0-11
NSS: 4 MCS: 0-11
Supported VHT (rx) Rates:
NSS: 1 MCS: 0-11

Interference Level: Acceptable
Mode : AP Only

Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS Tx rate Rx rate Connect Time

SSID: "Network Name 3"
RSSI: 0 dBm SNR: 0 dB noise: -91 dBm Channel: 161/80
BSSID: 2C:FD:A1:E5:79:B8 Capability: ESS
Supported Rates: [ 6(b) 9 12(b) 18 24(b) 36 48 54 ]
VHT Capable:
Chanspec: 5GHz channel 155 80MHz (0xe39b)
Primary channel: 161
HT Capabilities:
Supported MCS : [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ]
VHT Capabilities:
Supported VHT (tx) Rates:
NSS: 1 MCS: 0-11
NSS: 2 MCS: 0-11
NSS: 3 MCS: 0-11
NSS: 4 MCS: 0-11
Supported VHT (rx) Rates:
NSS: 1 MCS: 0-11

Interference Level: Acceptable
Mode : AP Only

Stations List
----------------------------------------
idx MAC Associated Authorized RSSI PHY PSM SGI STBC MUBF NSS Tx rate Rx rate Connect Time

 

[JoshuaW22]

Okay, so followed these instructions in the link you shared:

1. Remove all USB drives and Ethernet cables from the router, including the WAN cable.
2. Perform an NVRAM erase
   1. By unplugging the power plug from the router (and not from the ac power socket on the wall).
   2. Wait 2 minutes, then, holding the WPS button, plug in the power plug into the router and continue holding the WPS button until the router reboots (about 30 seconds or more).
3. When the router has booted up (be patient, this may take longer than normal)
   1. Do a quick/temporary wizard set up to gain access to the advanced GUI controls.
   2. Once inside the GUI, select the 'format jffs partition on the next reboot' and reboot the router.
4. Once the router has booted up again, reset the router via the GUI to factory defaults, making sure to select the box that says 'initialize all settings...) too.
   1. Do another quick/temporary wizard set up to gain access to the advanced GUI controls.
5. Flash the same firmware you are currently using (384.10_2).
6. Plug in the WAN cable while the router is rebooting.
   
7. When the wizard comes up this time,
   1. use new SSID's with no spaces or special characters that are at least 8 characters long (and no smiley faces).
   2. Make sure the password also has no special characters or spaces and is at least 16 characters long (and no smiley faces too).

Everything is working as expected at the moment!!
However, it's always been intermittent, so will keep an eye and report back here in the coming days with regard to stability.

Currently, all devices playing nice, across both bands (5/2.4) as well, smart connect appears to be working as expected, without issue.

Notes:
New SSID is without spaces.
Received a warning about loosing openvpn, openssl, etc. upon the JFFS partition format process.
--> Any chance this can be connected? Not sure why, but my gut says it is, as this is the step which was not completed during prior firmware upgrades / factory settings resets in past attempts.

Currently, everything is default settings with the exception of having setup the sambda media server.

Will be working on adding elements back to my setup over the coming days, keeping notes, and will report back.