Everything Instant On

Version 2.0.0 on Instant On introduces "Shared Services" which is probably just enabling "Airgroup" - it seems to work okay with common mDNS services like Airplay, Googlecast, etc. but it does NOT work with Sonos. All my speakers that used the Instant On AP's for their connection have disappeared, all the wired speakers (with wifi disabled) remain. I have power cycled everything and it has no affect. I'm guessing that when "Shared Services" was built into the latest release, they also enabled multicast filtering for the AP, Sonos uses UPNP SSDP multicast for discovery and control. At a minimum the following needs to be enabled for Sonos to work:

Sonos Airgroup service

airgroupservice "Sonos"
id "urn:schemas-upnp-org:service:GroupRenderingControl:1"
id "urn:schemas-sonos-com:service:Queue:1"
id "urn:schemas-upnp-org:service:AVTransport:1"
id "urn:schemas-upnp-org:service:RenderingControl:1"
id "urn:schemas-tencent-com:service:QPlay:1"
id "urn:schemas-upnp-org:service:GroupManagement:1"
id "urn:schemas-upnp-org:service:ZoneGroupTopology:1"
id "urn:schemas-upnp-org:serviceeviceProperties:1"
id "urn:schemas-upnp-org:service:MusicServices:1"
id "urn:schemas-upnp-org:service:AlarmClock:1"
id "urn:schemas-upnp-org:device:ZonePlayer:1"
id "urn:schemas-upnp-org:serviceystemProperties:1"
id "urn:schemas-upnp-org:service:ContentDirectory:1"
id "urn:schemas-upnp-org:service:ConnectionManager:1"
id "urn:smartspeaker-audio:servicepeakerGroup:1"
id "urn:schemas-upnp-org:device:MediaServer:1"
id "urn:schemas-upnp-org:service:AudioIn:1"
id "urn:schemas-upnp-org:device:EmbeddedNetDevice:1"
id "urn:schemas-upnp-org:service:EmbeddedNetDeviceControl:1"
id "urn:schemas-upnp-org:service:HTControl:1"

I'm guessing their is no way for me to roll back firmware to v1.4.1?

I'm going to try moving the Sonos speakers off of the Aruba AP and onto Sonosnet with the hopes that I will be able to least use them again for the time being, but seeing as the Sonos Move is only wifi/bluetooth, with no access to Sonosnet, it will be rendered useless until this gets fixed. 

Thanks,

Scott.

@scott83

I got the same problem with the update.  In my case I am using the Spotify app and it no longer detected the speakers.

Then I used the Sonos app directly:  it saw my speakers and I was able to play Sonos Radio.  I then used Spotify inside the Sonos app and that worked too.

I then went back to the Spotify app and I could see the speakers and was then able to play music directly from the Spotify app.

Can you try and get back to this community to see if you made it work?

Thanks.

Hey Stephane,

Only 5 of my 9 speakers show up in the Spotify app, I tried your suggestion but it didn't work for me. Spotify Connect also uses mDNS for discovery and if they have enabled multicast filtering on the AP now and haven't allowed the Spotify Connect mDNS traffic then it will break like it has done with the Sonos UPNP SSDP multicast. 

I tried again to setup my Sonos Move speaker after a factory reset but it failed, it connects to the AP fine, but it is missing the UPNP SSDP traffic specific to Sonos and it won't let me finish setting it up. Oddly enough, the Airplay function of the Move works as "Unnamed Room" as it isn't completely setup as the Sonos Controller app on my phone can't see the speaker. 

I only use my Sonos speakers for airplay and it is hit or miss if they actually show up as an airplay speaker. One of them will occasionally show up and I can airplay but the other has not come back as an airplay speaker but both my Apple TV's show up under AirPlay.

@Fortyfourfive I just noticed that on my MBP that most of the Sonos Airplay audio targets have disappeared. All of them were there this morning, now only 2 remain, the Apple TV target is still there. If I look at the "Services detected on this network" under "Shared Services" on my SSID configuration they are all identified still so I'm not sure what is up with that. They do appear to be working on my son's iPad and my work iPhone. 

I tried using Airgroup on my Aruba Instant setup back in the day but I bailed on it, too many issues with Chromecast, and sadly with Instant On we have no ability to add custom services, restrict it to specific VLANs, or disable it. I have to admit that Airgroup did work flawless with my Sonos when it was setup as a custom service with the details I mentioned above. 

 

I have a more complicated setup than most:

VLAN 201 : main SSID - where all my mobile devices, Apple TV, Chromecast, etc. and majority of my Sonos reside

VLAN110 : Sonos beta SSID - I have a handful of speakers here, on a different Sonos account, that I use when I participate in Sonos betas.

VLAN 102 : guest SSID - guests / my work phone cause don't trust my IT department

My guest SSID can see all of the airplay and chromecast devices on the other two VLAN / SSID! This is without checking to allow them in the "Shared Services" tab! If I enter firewall rules to allow traffic between the VLANS on my router, it actually connects! I don't think this should be expected behaviour! If it's not checked to allow this then I don't think the services should be visible on other SSID! 

I don't use SONOS myself but I'm using Raumfeld. This seems to be working fine up to now but I will monitor it.

Did anyone who has problem with SONOS already contact support on this?

I guess this would be the best option.
I already had contact to support a few times and one of these contacts ended in the implementation of the ability to choose which wifi channels shouldn't be used.

Hello,

It is not only Sonos, my DLNA server also vanished from the network.

I am unable to make it work since the update.

Regards,

R

@Rurik Yeah, unfortunately they are probably blocking the Service ID's required for your DLNA service to work.

I did some more research by looking in the Sonos device XML files and then confirming with an old IAP-205 with Airgroup enabled, on the DLNA side, Sonos requires the following to work:

urn:schemas-upnp-org:device:ZonePlayer:1
urn:schemas-upnp-org:service:AlarmClock:1
urn:schemas-upnp-org:service:MusicServices:1
urn:schemas-upnp-org:serviceeviceProperties:1
urn:schemas-upnp-org:serviceystemProperties:1
urn:schemas-upnp-org:service:ZoneGroupTopology:1
urn:schemas-upnp-org:service:GroupManagement:1
urn:schemas-upnp-org:service:HTControl:1
urn:schemas-tencent-com:service:QPlay:1
urn:schemas-upnp-org:device:MediaServer:1
urn:schemas-upnp-org:service:ContentDirectory:1
urn:schemas-upnp-org:service:ConnectionManager:1
urn:schemas-upnp-org:device:MediaRenderer:1
urn:schemas-upnp-org:service:RenderingControl:1
urn:schemas-upnp-org:service:ConnectionManager:1
urn:schemas-upnp-org:service:AVTransport:1
urn:schemas-sonos-com:service:Queue:1
urn:schemas-upnp-org:service:GroupRenderingControl:1
urn:schemas-upnp-org:service:VirtualLineIn:1
urn:smartspeaker-audio:servicepeakerGroup:1    

I haven't been able to confirm the other two I posted earlier (that was a copy+paste from the arubanetworks.com forums and not confirmed by me) so I'm not sure of there origin and if they are actually needed or not:

urn:schemas-upnp-org:device:EmbeddedNetDevice:1
urn:schemas-upnp-org:service:EmbeddedNetDeviceControl:1

Sonos is now also using mdns (this is new to me, a couple years ago there was no mdns on sonos, it looks like only the newer players are using mdns, the old ZP120/Connect:AMP doesn't use mdns) for mdns to work, Sonos requires:

_sonos._tcp

The following is required for Spotify Connect to work: (When I added this in Airgroup, all my Sonos players immediately became visible in the Spotify app):

_spotify-connect._tcp

Other important mdns services required for home automation:

Homekit:

_hap._tcp
_homekit._tcp

Lutron Caseta (Smartbridge):

_lutron._tcp 

I'll open a ticket with support tomorrow. 

Dear Instant On Community,

Thank you for your feedback. We were able to reproduce the issue with Sonos speakers not being detected by music streaming apps and are working on a solution.

Until the problem is resolved, if you experience issues with your Sonos speakers, please try the following steps:

• Open your Sonos app and you should see all your speakers. Inside the Sonos app, select “Browse” and play music with one of your music services.
• Then you can leave the Sonos app and open your music service app directly. You should now be able to connect to your Sonos speakers. 
• Other music apps should also now detect the speakers. Note: we tested this procedure with Spotify.

As well, the reported DLNA issue is now solved. You can upgrade your Instant On Access point to version 2.0.1 to get the fix.

We regret the inconvenience and thank you for your support.

Thanks @Florent for the prompt investigation and instructions for a workaround. 

You mentioned that the DLNA issue had been fixed, did that include allowing the required Service ID's for Sonos DLNA I had mentioned two messages ago?

I upgraded to 2.0.1 and unfortunately things still do not work like they did in 1.4.1.

It sounds like maybe none of the mDNS/Bonjour fixes were implemented yet? I'm beginning to wonder if Sonos hasn't made, or started to make the transition away from DLNA discovery, to mDNS/Bonjour discovery? I think tomorrow I will contact Sonos support and see if they have any insights they can provide. 

My apologies if I'm stating the obvious here, but Sonos has two modes you can connect their speakers in:

 WM=0 mode which is Sonosnet, you connect 1 speaker or a Sonos Boost or Bridge to ethernet and it will form a proprietary wireless mesh for only Sonos speakers, they don't use the Aruba wifi for the speakers but you may have your controller device (phone, laptop, etc. ) on the Aruba wifi.

WM=1 mode which is wifi, the speakers connect to the Aruba wifi network as clients. The Sonos Move portable speaker can only run in WM=1 mode, it is unable to connect as WM=0 and belong to Sonosnet. You controller devices (phone, laptop, etc.) would be on the same wifi network as the speakers, the Aruba wifi. 

In pre-2.0.0 I was running my system in WM=1 where the speakers were using my Aruba wifi as clients but I believe in pre-2.0.0 there was no multicast/broadcast filtering taking place and no Airgroup running (Shared Services). Everything worked fine.

After upgrading to 2.0.0, I lost visibility to all the speakers that were connected to the Aruba AP in WM=1, they were still connected on the wifi network but now because of filtering, the Sonos discovery protocols where being blocked. I removed them off my wifi and set them up to run in WM=0 mode, and they became visible again to my Sonos app. Unfortunately, the Sonos Move doesn't support WM=0 and since upgrading to 2.0.0 I am unable to use it at all. 

I guess if you eventually enable mDNS/Bonjour for _sonos._tcp and it starts working again then we will know if they've started to depreciate the DLNA discovery but, none the less, I will still contact Sonos support and see what they have to say.

I think enabling the _spotify-connect._tcp m DNS/Bonjour will fix the direct play for the Sonos players there, I tried your workaround but it didn't work for me. 

Thanks again for looking into this. I have a ticket open with support and they are still investigating as I have other issues related to the addition of Shared Services. 

@scott83Thank you again for your quick feedback and sorry to hear that the workaround does not work for you. Do you mind telling me which model of Sonos speakers you are using? Thank you.

You're welcome @Florent, no worries, I'm sure we'll get this all figured out eventually. 

My wallet pains me to say this, but I have at least 1 of the following Sonos models:

-Play:1
-One (gen1)
-One (gen2)
-One SL
-Play:5 (gen2)
-SYMFONISK
-Beam
-Playbar
-Sub (gen2)
-Amp
-Connect:AMP (gen2)
-Port
-Connect (gen2)
-Boost 
-Move

I don't currently have the Play:5 (gen2), Connect (gen2), or Port connected at the moment. 

When I was researching what discovery protocols where in use, it appeared that the newer products were using both sonos and spotify-connect mDNS/Bonjour whereas the older products like Connect:AMP where only broadcasting spotify-connect mDNS/Bonjour. 

Hey @Florent ,

I fired up Wireshark and did some packet sniffing this afternoon, I was connected wirelessly to the SSID tagged to VLAN 201, VLAN 201 is where my clients and most of the media devices reside, either wired or wirelessly.

I can see mDNS requests for Spotify Connect and replies from some of my Sonos players (via the Aruba AP Airgroup / Shared Services service), it’s a mixed bag of my Sonos players on who replies: some old players, some new players, some on wired on ethernet, some on Sonosnet wireless (these on Sonosnet would appear as wired devices to the Aruba AP)., that would actually mean that all my Sonos would appear as wired clients as they are in WM=0 mode (sonosnet) as I can't get them to work on the Aruba wifi as clients in WM=1 mode. 

I can see SSDP requests from clients and replies from my Sonos players (via the Aruba AP) as well but I believe that Sonos also uses other broadcast traffic for speaker setup, etc. I will try and sniff this traffic at a later date.

When I open the Sonos app on my MBP, I can see in Wireshark that it does a SSDP search to:
239.255.255.250:1900 (multicast)
255.255.255.255:1900 (broadcast)
Looking for:
urn:schemas-upnp-org:device:ZonePlayer:1

And then Aruba AP returns a pile of responses with all the Sonos players on the network that have that Service ID. So that one part appears to work. I can’t tell whether AP is also communicating the other DLNA/SSDP Service ID’s that Sonos uses.

I haven’t seen any _sonos._tcp requests or replies being made on the wireless, so I don’t know how those fit in. Haven’t had chance to contact Sonos support yet to see if they can provide any insight.

I did however see the AP query for a long list of mDNS services, and those did include:
_sonos._tcp
_spotify-connect._tcp
_hap._tcp
_homekit._tcp
_lutron._tcp
etc.

I’m also having issues with SSDP and the DIAL protocol. I have two Nvidia Shield 2019 on my network, one is connected via ethernet, one is connected via wifi, both on the same VLAN.

When I go to cast on my Android Pixel 3a phone in apps that use DIAL (Netflix):
-Shield on wifi —> not visible
-Shield on ethernet — > visible

Same in Chrome on MacOS which also uses DIAL. The mDNS (googlecast) on both Shields seem to work okay.

So I also fired up Wireshark on the wired side of VLAN 201, my Windows 10 PC, and saw something interesting, the Aruba Airgroup / Shared Services service does NOT send out queries for mDNS or DLNA/SSDP services down the wire, it appears it just listens to what is on the wire. When I opened up my Spotify on the wired side of VLAN201, then all my Sonos speakers, which reside on wired side, appeared on the wireless side of VLAN201 as all the Sonos speakers send out a mDNS response for the Spotify Connect mDNS request and the AP picked that up and must have put in it’s cache. There are strange things happening with Airgroup/Shared Services with VLAN’s as the AP isn’t keeping services confined to their respective VLAN even when the service isn’t checked to be shared. I have a ticket open for this already.

I had mentioned earlier that my MBP couldn’t see all my Sonos airplay targets, it appears that the MBP isn’t doing mDNS requests for airplay targets so that’s possibly an Apple issue? I do the see the Aruba AP querying for airplay services but only on the wireless side and I have clients on the wired side but they never see the request from the wireless clients. I don’t know if maybe the MBP is expecting unsolicited advertisements of the Airplay servers as well? Again, these don’t appear to be making it through from the wired side for some reason.

I’m like to spend more time on this but I’ll have to save it for another day.

-Scott.

Dear @Florent ,

I can confirm that DLNA still does not work in 2.0.1. I am using a minidlna server running on the network and none of the wireless clients connected through AP11 are able to see it. Any client reaching the server from wired connection works perfectly.

I can also confirm what others experienced about airprint. It is not working 100%, some of the clients can see the Samsung printer on the network, others not.

There is also a problem with Chromecast audio clients. They frequently just disappear from the network.

One additional strange thing. I upgraded to 2.0.1 the day it came out. Since then the installation date changed 2 times on the AP while firmware version remained the same. Now it tells me I installed the actual firmware 2 days ago, which is for sure not the case. What is also strange that I have no update schedule on Sundays, so either 2.0.1 was pushed again to the device as a critical update or I do not understand what happened.

Regards,

Rurik

Same problem here, 5x AP11 with version 2.0.1. All speakers gone. Its random, after the update it worked for about 4 hours then speakers disapeared. Now my kitches speakers (2x Play:1) still play the music it was tuned to but the sonos app doenst see them anymore, looks like it connect through SonosNet now. Play:1 in my backyard only works with LAN connection and appers in the Sonos app if  i do so.

Its frustrating that Aruba apperantly does a poor testing and uses its userbase as alfa/betatesters. This issue was with 1.3 also but solved with 1.4 and now its back. I wish i had choosen Ubiquity as I first planned. I thought Aruba had more experiance but I was clearly wrong.

I am not using Sonos, but Sonoff (rather similar name, different purpose). I am using home automation called "home-assistant' and it has been controlling my smart switches (or relays, if you please) for a while now, using this plugin: https://github.com/AlexxIT/SonoffLAN

It is using multicast, and since I am not sure if my AP12 devices (four of them) had version 2.0.0 or just skipped directly to 2.0.1, I cannot tell if there is a regression with 2.0.1 behaviour comparing to 2.0.0. However - comparing to past versions, there is no doubt that there has been a regression. Multicast is being cut off, which prevents my switches from working. The GUI does not allow configuring anything about it. 

I have made sure my backbone switch (old Cisco 2960) has IGMP snoop disabled, so no throttling here. Just the switches. This is very frustrating. If anyone from HPE is reading this - please release a fix soon, with the option to enable/disable unfiltered multicast.

Thanks

I'm experiencing problems with AirPrint on a Brother printer that resides on a different VLAN than the one that my SSID is bridged into. 

I suspect it is because multicast filtering is enabled. I have confirmed that the printer is checked off within Shared Services. A ticket has been opened. 

Between this and seeing large latency/jitter/packet loss on my APs (separate ticket open with no resolution in sight), I'm very disappointed in this ION setup, I should've stuck with Ubiquiti. 

Hi

Thank you for your feedback. We have made several improvements to the Shared Services feature in Instant On 2.0 software release. However, since there are multiple deployment combinations and multiple models of Sonos devices, we are aware of some these use cases that are not working. We are actively investigating them to find a fix. We will release a new software to address it. Appreciate your patience. If there are any other issues you are facing, please reach out to Instant On support.

Hi,

It would be nice a dual firmware feature, to have a possibility to switch back to any previous ( working ) release.

 

Dear @Sharanya ,

How exactly do you mean when you say: "If there are any other issues you are facing, please reach out to Instant On support."?

I am a Hungarian end-user customer. There is not a single Hungarian contact phone number on the support page.

I cannot register on the Aruba Support Portal as it is only open for companies, so I cannot register with my gmail or hotmail address.

If I post my problem here, I get a standard answer to contact support (which I cannot, due to the above mentioned reasons) or that my problem is already solved (it is not).

Thank you,

Rurik

I live in Israel, and there is no phone number for Israel support either. I used a chat (which I cannot find now for the life of me) - but I guess you can mail the support directly. Since I have an open case around the multicast issue, I have the support direct e-mail: gsd_csc_case_mngmt@hpe.com

I have learned a few interesting things:

1. The AP12 (as well as others, I assume, it's just that I have AP12) has SSH CLI, but we - the regular people - cannot login to it. It requires opening by Aruba support team. 

2. Also - it requires OTP available only to Aruba/HPE employees.

3. The simple workaround is (when and if you have a CLI, and it will apply until you reboot the AP) to set 'no airgroup' on configure terminal ('conf t') and to apply using 'commit apply'. As said before - you cannot do it because you can't have CLI to the device without support enabling it (for a limited time) and without having HPE employee generating the OTP password.

So - this is my insight about it. Good luck!

@ezaton @Rurik I always use the chat option to initiate contact with support, a "Chat Now" icon pops up in the bottom right hand of my browser window when I go to the "Contact Support" page via the menu at the top of this site.

@Rurik On the support page do you have the chat option in the lower left hand side of the page? And can you call into 

Austria:

08-1000-2000

I'm also seeing this problem on an older sonos system where we updated the network.  Personally I don't like sonos and the network issues they have with STP and any time I have to use them they almost always wired amps with wifi turned off.  I hope a fix is coming soon cuz otherwise I'm ripping these out and going back to cisco SMB APs, I'll have no choice, clients will be moving back in soon.  Please do something a.s.a.p. cuz I have liked these until this sonos BS.  Has anyone tried HEOS with these?  I prefer them to sonos but again I almost always wire them except for my personal use.   

Today I changed my visibilty and control to summary

My 2.4 wifi band so only channel 1 is an option despite having 3 APs, deselected 6, 11 options

I put all my Sonos on wifi, disco'd the ethernet on two that were wired with wifi disabled.

changed sonosnet to use channel 1 too even though they're set for wifi (wm1)

Now they seem pretty stable.

 

I did read that sonos wants all APs on a single channel but for the life of me I can't image why  unless they're still meshing somehow.  On sonosnet sure, they're meshed and have to be on only 1 channel.  IMHO on wifi APs should have all channels available but this seems to be working now and if I plug anyone in that device won't be visible most of the time.  Sometimes it pops up which is good so I can enable the wifi again and unplug the ethernet cable.  What a PITA but at least I might not have to pull the Aruba APs and put in another brand, knock on wood.

So broacasts, multicast aren't forwarded to the wired network but somehow make it through to the other APs?  Very strange!

It would be nice to hear something from Aruba, progress, eta, work arounds, anything!

 

@VAV @scott83 @ezaton @Rurik @vbec27  We are diligently working towards a resolution to the current issues with shared services that everyone is experiencing.

@GThiesen : Just installed 2.0.2, DLNA problem is still not resolved. This is getting frustrating for a product of this category.

@Rurik  Do you have shared services running or turned off? The default is off when this patch was installed.

@GThiesen : where should I see this? I cannot find this option.

@Rurik Only on the portal click on networks then the configuration cog on the right for shared services.

I also can't see a configuration cog on the networks page

@GThiesen : There is no such option for me. I opened up every submenu reachable either on the site or in the mobile app.

@Rurik @Ibeme  This is for the portal only the phone App is not updated yet.

 

 

yes I know but it doesn't even show up there in my case.

@Ibeme  Add a VLAN under networks and the Cog should appear.

yep, that did the trick.
Thank you.

@GThiesen : ok, after addig VLAN it appears

Instant On 2.0.2 was released yesterday. Have it a try and let us know how it goes with your Sonos speakers. Thanks!

@GThiesen @Florent after the instructions I was able to enable the shared services option and it seems to be working.

I will try different clients during the weekend, if I will encounter any other errors I will let you know.

Thank you for the help so far!

Regards,

Rurik

Do the option need to be turned on or off to solve the Sonos problem?

@Charmacas Leave the service off as that is the default and they should work with everything in the same VLAN.

I have updated, and it did not work well with my IoT devices (the whole discovery thing). A few days back a tech support escorted me through a CLI session where the device had its 'AirGroup' turned off, which solved all the problems I have had. Now, the portal has this option (called "Shared Services" - open the 'Networks' and click on the cog at the corner. It's there).

Following the 2.0.2 upgrade, the shared services were automatically turned on, which resulted in non-functional multicast. Turning off this option (which has become possible with 2.0.2, I think) worked around this and, "sovled" the problem for the time being.

After the update to 2.0.2 My Sonos reapeared. Updates as fast as I could my Sonos OS to S2 and it worked for a few days. Today al is gone again. In my case the portal and app do not have the option to disable "Shared Services". **bleep** I am stuck with a defective product for far to long now.

@RudiK  For shared service go into networks create a wired network any VLAN and save then you should have the cog in networks for shared services by default it should be disabled.

I would like to share with you the current progress status of my support call, so you'll have some idea of the source of this problem, as I see it. I would be happy if any Aruba relevant personnel would correct me where I am wrong. In this note - an open and transparent behavior (as I have experienced in the last support call, BTW) is a powerful tool - it encourages customers to help and take a part in the process, instead of demanding results and being impatient.

Since version 2.x, multicast protocols are being categorized and permitted across Wifi networks (or VLANs, if you wish). This is the added feature. However - not all multicast-related protocols are actually being categorized correctly. As it seems, the AP manages to categorize well most protocols. So Apple iPrint was well identified, and mDNS was well identified as well (port 5353), as well as some other protocols. However, where the AP were able to transfer all muticast traffic before, regardless of categorization, this is not the case anymore. Attempting "smarter" wireless noise reduction, with the added feature of propagating shared services between networks, the AP attempts to decide which communication is known multicast transportation, and thus - allow it to run in the same Wifi network (capable of announcing it to other Wifi networks - aka - 'shared services') and which is not identified, and thus - blocked. The problem is that if the 'AirGroup' feature is enabled, any unidentified multicast traffic is getting blocked.

The support session I've had was actually a collection session, where we have enabled/disabled 'shared services' and viewed the results in the IoT devices discovery protocol. The results were sent back to Aruba for further analysis. 

I have suggested, and I hope it will get into the product soon, that instead of the Boolean state of 'shared services' where it either identified the protocol and blocks any unknown, and the 'shared services off' where every multicast traffic is allowed - to have  an additional flag when 'shared services' are enabled, which controls the 'unknown' protocols behavior. In this case, while HPE/Aruba are attempting to identify all ever existing protocols, or attempting to identify a rule to match them all - we customers have the choice of how the AP behaves - either permits or blocks whatever the AP cannot categorize.

I hope we'll have results soon.

It sounds like shared services pertains only to vlans so is it inter vlan routing?  Does it pass broadcasts between vlans automatically?  Could someone explian or post a link to what exactly shared services is for and what it does?  

One job I have with Sonos and aruba 15's had multiple networks but no vlans and Sonos devices weren't being discovered on the same network, some wired, most wi-fi.  I made everything wi-fi, all APs same 2.4 RF channel and they then seemed solid when on fw rev 2.0.1.  Haven't been able to get back into the job since they updated to fw rev 2.0.2.

I would like the devices to be wired that can be permanettly wired and discovery to work, I can't imagine a reason to want broadcasting between vlans facilitated on my APs of all places but I would like to know what it is and what its for.  I don't see most people wanting to get sonos or other similar streaming services to work across networks but just on a single network unless they doing some sort of systems integration with 3rd party controllers and processors.  

 

 

 

---

@VAV wrote:

It sounds like shared services pertains only to vlans so is it inter vlan routing?  Does it pass broadcasts between vlans automatically?  Could someone explian or post a link to what exactly shared services is for and what it does?  

One job I have with Sonos and aruba 15's had multiple networks but no vlans and Sonos devices weren't being discovered on the same network, some wired, most wi-fi.  I made everything wi-fi, all APs same 2.4 RF channel and they then seemed solid when on fw rev 2.0.1.  Haven't been able to get back into the job since they updated to fw rev 2.0.2.

I would like the devices to be wired that can be permanettly wired and discovery to work, I can't imagine a reason to want broadcasting between vlans facilitated on my APs of all places but I would like to know what it is and what its for.  I don't see most people wanting to get sonos or other similar streaming services to work across networks but just on a single network unless they doing some sort of systems integration with 3rd party controllers and processors.  

 

 

 

---

This was not supposed to be inter-VLAN. The idea, as I see it, was to have cross VLAN (or wireless) discovery and shared sevices, allowing you to share a network printer on one network to other wireless networks, without the hassle of network routing and/or firewall rules involved on the backbone/router. The idea is nice, however, when the AP starts identifying communication and blocking it within the same VLAN, this becomes a problem. And currently - this is what's happening.

Thanks for your support.

In the portal I can only add wireless networks not wired. Tried to create a new site and move a AP11 to that. No succes as the removed AP11 cannot be found by the create new site wizzard. I am very frustrated with this product now and I wil never recommend this product to anyone.

You are not supposed to add wired networks. You are supposed to add wireless networks only. This is an access point, not a switch. You can tag different wireless networks to different VLANs, however, it is required to have these VLANs in your backbone beforehand. Routing, traffic shaping and everything else - would be handled by the backbone switch, not the AP.

Do note, however, that when you add (or modify) a wireless network, you can define which VLAN it is tagged at, on the wired layer. Still - this VLAN should exist beforehand.