Wireless Access

Reply

Google Home Mini - AirGroup

I had brought this up in another conversation, but figured inquire as all other Chrome devices work correctly - just not the Google Home Mini.

 

I was just curious if anyone has Airgroup working with their Google Home Mini specifically? Have a TAC Case open concerning the Google Home Mini not showing up as an AirGroup Server (ArubaOS 6.5.3.3 and 6.5.4.0). The Google Home works perfectly, but not the Google Home Mini - reviewing the mDNS packets between the Google Home and Google Home Mini - they look identicial. If I disable "Drop Broadcast and Unknown Multicast" and disable Airgroup - the devices can discover each-other.

Re: Google Home Mini - AirGroup

Worked with TAC and they escalated to the development team. What's bizarre - on a hunch - went and bought another Google Home Mini (same firmware/software/etc - only difference is a month in the manufacturing date). The second works just fine with Airgroup. That would point to a defective device - however, mDNS works just fine on a home network - as well as on an SSID with multicast enabled and AirGroup DISABLED. What myself and TAC saw in the debug logs for mDNS was periodic cases where the mDNS responses were being discarded.

Occasional Contributor I

Re: Google Home Mini - AirGroup

Did you create an Airgroup Service ID or do they work with a built in service?

Brett W.
K-12

Re: Google Home Mini - AirGroup


@brettmwillwrote:

Did you create an Airgroup Service ID or do they work with a built in service?


They work with the built-in "googlecast" service (although i do see the Google Home's mDNS packets with another servicre "googlezone" - don't have much details on what that is used for at this time (maybe controlling Chromecast from Google Home - although I'd imagine "googlecast" would be sufficient. My knowledge of mDNS/SSDP is still low - although I've been the only one "crazy/determined" enough to understand these devices to the point that I'm jokingly the new "multicast administrator".

 

Something else to keep in mind. Configuring a Google Home successfully vill vary between iOS and Android (at least in my experience) as they use different "initial setup methods" - note this was with a Smart Phone on a DOT1X SSID and a Google Home Mini living on a IoT SSID.

 

1. Android (Wi-Fi Direct) - After pushing the Home Mini to connect to the desired SSID (IoT SSID) - my phone would try and move over - fail...but the Home Mini would maintain it's connection to the IoT SSID - at which point I'd move my phone back to our DOT1X SSID and allow AirGroup to work it's magic.

2. iOS Bluetooth (Preferred) or (Wi-Fi Direct) - Each time I ran the Home Mini - after pushing the Home Mini i to connect to the IoT SSID - my phone would try and move over - fail - the Home Mini would "give up/disconnect" from the IoT SSID (short window for AirGroup to work). I think what was happening - Home Mini would move over - iOS Home Setup App would timeout - I'd run the app again (it would use Bluetooth) - and redo the IoT SSID config - AirGroup would never get opporunity. My theory is if I were to forgo the Bluetooth and use just Wi-Fi Direct - I should get the same end-success I had with Android. I still need to do more testing

 

Note - If the Google Home loses it's network connection (IoT SSID) stops broadcasting - The Google Home will begin broadcasting it's own SSID again (Google-Home-Name) to update the network config.

Guru Elite

Re: Google Home Mini - AirGroup

You need to add the googlezone ID to the googlecast service for multiroom/multidevice services.

Tim Cappalli | Aruba Security
@timcappalli | timcappalli.me | ACMX #367 / ACCX #480

Re: Google Home Mini - AirGroup

Had a conference call with TAC/Development team last Wednesday, and they have followed me down the rabbit hole. One of the attributes I noticed in the user-debug logs called "origin" has helped narrow down the problem:

 

1. Working Google Home Mini - origin=1

2. Non-Working Google Home Mini - origin=2

 

Developer informed me when an mDNS packet is received from a client termintating to the controller - is flagged as origin=1 - if an mDNS packet is received from another controller on the same VLAN - such as with when doing AirGroup Clustering = it's flagged as origin=2. In our case - the controller is discarding the record instead of classifying it as an AirGroup server. We did enable AirGroup clustering just in case to check for any changes. No change.

 

So for whatever reason that Developer/TAC is unsure yet, the controller is classifying the mDNS response of this specific Google Home Mini - (manufacturerd a month earlier than the working one - with a MAC Address ending in 'C') - as originating from outside the controller.

I'm glad I enjoy puzzles. 

Re: Google Home Mini - AirGroup


@cbjohnswrote:

Had a conference call with TAC/Development team last Wednesday, and they have followed me down the rabbit hole. One of the attributes I noticed in the user-debug logs called "origin" has helped narrow down the problem:

 

1. Working Google Home Mini - origin=1

2. Non-Working Google Home Mini - origin=2

 

Developer informed me when an mDNS packet is received from a client termintating to the controller - is flagged as origin=1 - if an mDNS packet is received from another controller on the same VLAN - such as with when doing AirGroup Clustering = it's flagged as origin=2. In our case - the controller is discarding the record instead of classifying it as an AirGroup server. We did enable AirGroup clustering just in case to check for any changes. No change.

 

So for whatever reason that Developer/TAC is unsure yet, the controller is classifying the mDNS response of this specific Google Home Mini - (manufacturerd a month earlier than the working one - with a MAC Address ending in 'C') - as originating from outside the controller.

I'm glad I enjoy puzzles. 


My persistence for understanding is slowly being rewarded. :-) Hoping this is indeed the source of the issue! Wasn't quite the "ending in 'C' - but appears to be related to MAC Address so far! Latest TAC Update:

 

I am discussing with development team on this issue and they have suspected that the origin sent as 2 to be the culprit. It is because in header format, we attach a pattern 0xde to detect if it's from different controller or not.

Since the MAC address of this mini contains 0xde it looks like the header is getting corrupted with this pattern 0xde and hence we are seeing this problem. They are working on a fix for this.

Christopher Johnson
Wireless Network Engineer
cbjohns

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: