Wireless Access

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.

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.

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

---

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

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. 

---

@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

any updates on if this ever got fixed?

---

@Nightrest wrote:

any updates on if this ever got fixed?

---

Hi Nightrest,

TAC informed me that the development team were working on a fix for this specific issue under a "development ticket" with the header getting corrupted, but my initial "support ticket" was closed. I don't see anything in the recent release notes pertaining to that bug as of yet. In theory you would only run into this if the MAC Address of the Google Home Mini contained "DE".

1. Do you have the "googlecast" airgroup service enabled?

show airgroup status | include googlecast

2. Does the Google Home Mini show up as a "server"?

show airgroup servers | include <mac address>

I won't pretend to know the full implications of this change, but I got ours to work by disabling “Broadcast filtering”: Get Google Home devices to work on Aruba-based wireless networks

I'm marking my specific/unique situation as closed to avoid further troubleshooting that is not related to my unique case which involved the controller misclasifying the mDNS packets from my unique Google Home Mini as originating from a foreign controller - hence dropping the traffic.

I will mention though to Nate that I would use caution with that setting. Unsupressed and unfiltered multicast/broadcast traffic can quickly degrade wireless performance on networks. I know this experience all to well back with our Meru environment (the drop in the bandwidth and increase in clients is one of my favorite real-time/historical references on why we can't just "make something work") when I discovered the settings had been reverted to "enabled". With that said, I understand the frustration of getting initial setup of a Google Home Mini with an iPhone (especially as the iPhone likes to user Bluetooth for initial setup) - I had a theory that with bluetooth enabled it would use bluetooth, attempt to move over to the same SSID as the iphone, fail...restart the app...and it would restart the entire process over again - even to the degree of resetting the networking settings on the Google Home Mini.

In case anyone else has the same problem I did.  My MAC did not contain the characters that the OP listed, but I was still not able to get my Google Home Mini to join my IAP network.

I have an IAP 225.

My android phone running the latest Google Home app could find the home mini just fine, but when it tried to push the wifi settings to the phone the home mini never would join the network.

Initially the error I was getting was that it wanted me to check my network name.  I disabled all Broadcast optimization on my SSID from the advanced configuration of the SSID and the home app changed its error to having me check my password.  

My final fix was to change my IAP to "prefer 5Ghz" instead of "Force 5Ghz" under the RF settings.  At that point, the Google Home Mini was able to join my network just fine.

I suspect that it was programmed to only join in 2.4ghz for wider compatibility, but once it did join the network I found that it had already moved over to a 5gig channel, so changed my RF settings back to force 5GHz.

Hope this helps others.