Sorry, I did not read all of the recs, but, simply send it back and get a new one.

@John B - unfortunately I must unwind this setup as none of my speakers reside where there is an ethernet jack. Where the wired Play1 is now is not in its position in the house. More importantly, this is all supposed to work wirelessly. I invested in Sonos products because they’re wireless products - I’m not supposed to work around their software and firmware issues by laying down home wiring.

@Corry P - yes starting with the last configuration change I am resetting both routers each time I make a change (which limits me to Sonos debugging early in the morning). Also I have factory-reset the APs per a previous suggestion.

I’m sure right now with the wired Play1 SonosNet is probably making all the previously discussed settings moot; by unwiring the Play1 I’m pretty much starting at ground zero in debugging the issues with the Move although I’ll force rebooting the APs after any config change just in case ASUS isn’t well-behaved after making changes.

So the configuration to this point (including a wired Play1 which is about to get unplugged) is:

BRIDGED/WIRED ASUS RT-AC3200

• All default settings.
• All unwired Sonos devices connected to this AP’s SSID

MAIN ASUS RT-AC86U, ALL DEFAULT SETTINGS PLUS

• SmartConnect disabled
• “IGMP Snooping” enabled (on both bands)
• IPTV tab/Enable Multicast Routing disabled
• No Sonos devices connected to this AP’s SSID

I’ll enable “Enable Multicast Routing” and unwire the Play1 which largely gets me back to @Xander P original config suggested with the exception of SmartConnect being disabled per John B.

FYI upon enabling the setting “Enable Multicast Routing” the menu introduces 2 new drop down boxes: Default IGMP Version (“V1;V2;V3 - I’ll leave it at “V3”) and Enable Fast Leave (I’ll leave it at “Disable”). Does Sonos have any guidance on these settings?

Let’s see if this initial config helps the Move function properly.

OK.  Sonos is indeed a wireless system but it was originally designed to use SonosNet, which requires a single Sonos component to be wired (to bridge between SonosNet and WiFi).  There are still many situations in which SonosNet is the best option, and I see this additional option as a strength of Sonos, not a weakness.

I strongly suspect that the configuration will survive the unwiring of the Play;1 and the return to fully WiFi.  If it doesn’t, then the Sonos Boost is designed for just such a scenario, as I have already said.

Hi @ybl84f1 

I think having all Sonos products and your controllers on a single AP will help matters. Let’s see.

@Xander P , @Corry P , @John B ,

Well it’s been a while but I wanted to let you all know that the Move is working as it should and what the final conclusions are.

First, unfortunately John I need to unwind what I did because the wired Play1 is not normally in a position where it can be wired; none of the devices are. And also wireless placement is one of the reasons I invested in Sonos to begin with and there’s no reason it shouldn’t work.

So after a lot of trial and error I found that Xander’s guidance on these 2 settings enables it to work correctly:

• Multicast Routing (IGMP Proxy) and Efficient Multicast Forwarding (IGMP Snooping.)
• Enable IGMP Snooping.

What additionally is required however, at least in my configuration, is a reboot of both routers as well as the Sonos devices. Regarding the routers it’s not enough just to change the settings without rebooting, which is what I was doing in the beginning. Also I don’t know if you could simply reboot one of the routers or just one of the Sonos devices - it may be possible but it’s too time consuming to figure out and not really necessary.

Note SmartConnect on both APs is on and has no effect on the outcome.

So again the Move is now behaving exactly as it should and besides the very poor OOB experience and the time-consuming debugging effort I’m very pleased with it.

After all this here is some feedback to Sonos regarding the Move:

• Equip your 1-800 support team with this debug information, you’ll save yourself money and reduce customer frustration, churn and product return. I started with phone support, and even after sending diagnostic information from the app several times over the course of more than an hour their suggestions addressing this issue were completely irrelevant or useless.
• Consider having a router-specific self-help section; it would have been much easier for me and less expensive for Sonos to simply have an “ASUS” page of FAQs, BKMs and settings to reference, especially since at the end of the day it was simply 2 settings that needed toggling.
• Diagnostics: There’s absolutely no reason the Sonos app could not have automatically diagnosed this and provided more guidance for correcting it instead of leaving it to the consumer. At first bootup of the Move the Sonos app could communicate at least enough with the Move to register it, then failed to see it at all after registration. So somehow they were able to connect initially which means they could coordinate to help debug a network issue.
• Also, as noted many times above, in cases where the Move fails in a multi-band network the Move could fall back to 2.4Ghz to operate. This may not be ideal but it is a solution that could be presented to the user as an option or to help debug in a diagnostics mode. Again a wireless Play1 should not outperform a brand-new Move that is designed to be portable.

Thanks to those that provided helpful and meaningful guidance. If there’s any final questions about the network setup or something you would like me to try let me know otherwise I think we can close out this thread.

Cheers.

Hi @ybl84f1 

I’m glad to hear you’re now able to enjoy your Move as intended! Thanks for updating us with what fixed it for you, too.

Thank you also for the feedback.

We do have this information, but only in relation to the Asus RT-AC68U, whereas you have mentioned a RT-AC86U. I’ll see if we can get this updated. Thank you.
 

A good idea, which I’ll look into. Unfortunately, most users don’t think of their router being the problem until they’ve already contacted us (usually because devices that aren't interested in talking to each other can talk to the internet). Also, there are a lot of routers out there, and a lot of different ways people can install/configure them. This information is available to our technical support agents, however.

This would increase complexity, and complexity increases problems. Considering all the possibilities, it would also be very difficult to code and would likely often be less than helpful if incorrect. I do see your point, however, and more helpful setup messaging could be added, perhaps with links to help pages.

Is it the Move that failed? From it’s point of view, it got connected, but the network failed it. Given that the Move doesn’t know if it can’t connect to the App because you’ve left the house with your phone or if there’s a problem with the network, I don’t see how this could be reliable. In addition, some people turn off their speakers when not in use, so having the rest of the system freak out when they do this wouldn’t be ideal.

Having a restriction to 2.4GHz as an option for speakers that can connect to 5GHz is a good idea, however.

You can currently prevent the Move from connecting to 5GHz by not telling it the credentials for that band (though the bands do need to be separate).

You’re very welcome! The thread will be closed automatically when there has been no activity on it for a while.