BEWARE of version 2.0.0 if you use Sonos

Highlighted
Occasional Contributor II

Re: BEWARE of version 2.0.0 if you use Sonos

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

Re: BEWARE of version 2.0.0 if you use Sonos

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

0 Kudos
Highlighted
Occasional Contributor I

Re: BEWARE of version 2.0.0 if you use Sonos

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.

0 Kudos
Highlighted
Occasional Contributor I

Re: BEWARE of version 2.0.0 if you use Sonos

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.

0 Kudos
Highlighted
Employee
Employee

Re: BEWARE of version 2.0.0 if you use Sonos

@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.

0 Kudos
Highlighted
Occasional Contributor I

Re: BEWARE of version 2.0.0 if you use Sonos

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.

0 Kudos
Highlighted
Occasional Contributor I

Re: BEWARE of version 2.0.0 if you use Sonos

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.

0 Kudos
Highlighted
Occasional Contributor II

Re: BEWARE of version 2.0.0 if you use Sonos

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.  

 

 

 

0 Kudos
Highlighted
Occasional Contributor I

Re: BEWARE of version 2.0.0 if you use Sonos

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.

0 Kudos
Highlighted
Occasional Contributor I

Re: BEWARE of version 2.0.0 if you use Sonos


@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.

0 Kudos