Hi Chuck, Both Google Home Mini's did indeed share the same OID - I actually considered that idea towards the end. I've joked that it just doesn't like that the "non-working" one ends with a letter instead of a number - (scratch that now it just doesn't like if it ends with letter 'C'). I also relocated both to a separate VLAN (to force new IP Addresses) on the off-chance there was a bizarre IP Address conflict and ruled out other discovery methods that might have given me false impression that the "defective device" worked with mDNS at home/lab environment (such as Bluetooth or arp scan [had a couple printers utilize that method]).
As far as I can tell - our controller receives the mDNS response, processes it, then immediately discards it - according to the debug logs. I know the controller will "block queries" if there isn't a matching "Server" that has already been categorized "such as googlecast" - but I'm not sure if that's the same as a discard. I'm hoping the development team will be able to give me an answer as at this point I'm more troubleshooting the AirGroup service itself than the Google Home Mini. Just a bit more bizarre than the "Roku App" issue we ran into last year. Development team determined that the "Roku App" is using an invalid uPnP/SSDP syntax -- http://community.arubanetworks.com/t5/Wireless-Access/Roku-streaming-stick-Not-registering-with-AirGroup/m-p/378957#M77916 I'll add that I know a majority of the things that I've troubleshooted is more the "convenience aspect" - Roku works just fine without the Roku App (can even specify the IP Address directly) - Google Home Mini will answer queries/play music just fine (without completing the setup). It's more to help me understand, recognize, and identify what's going on. mDNS/SSDP is "convenience" for a majority of the devices - but it's necessary for Chrome-Cast. Till I know why this Google Home Mini doesn't work, I can't be sure this issue isn't going to "appear" on a ChromeCast that has been working. Christopher Johnson Wireless Network Engineer AT Infrastructure Operations & Networking (ION) Illinois State University (309) 438-8444 Stay connected with ISU IT news and tips with @ISU IT Help on Facebook and Twitter -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Chuck Anderson Sent: Thursday, February 15, 2018 6:08 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Apple Home Pod Did both the working and non-working Minis have the same or different MAC OIDs (first three octets)? Maybe the Aruba controllers use that to classify them. On Thu, Feb 15, 2018 at 02:02:54AM +0000, Johnson, Christopher wrote: > Hi Chris, > > Depending on how far down the rabbit hole you're going to go. There seem to > be supposedly a lot of problems with the Home Pod setup process (not even in > a enterprise network) - > https://www.macrumors.com/2018/02/14/homepod-setup-troubleshooting/ > > > I wanted to bring that point up so you don't rule out "an issue with the > specific Home Pod itself" as I recently made the same error with a Google > Home Mini (first and only ticket I received) - we tested the Google Home last > year - and worked perfectly. We're an Aruba Deployment that leverages > AirGroup (mDNS/SSPD proxy) and ClearPass (Radius/Device Registration) for > suppressing/controlling the discovery protocols so only Billy will discover > Billy's Chromecast for example. > > * Google Home (Tall Version) works with AirGroup - the service sees the > mDNS responses and classifies it as a server. > * Google Home Mini does not work with AirGroup - the service sees the > packets and discards them repeatedly (it should classify the device as either > a Server, User, or both) > * I performed a packet-capture to compare the Tall vs Mini - they're both > identical (minus mac address and ip-address) > * Mini works in a home network with mDNS. > * Mini works in a lab when I allow mDNS to run rampant (with AirGroup > Disabled) > * I made the error in thinking the issue was between the Tall and Small > version - it wasn't: > * I go and buy another Google Home Mini - plug it in - and AirGroup > classifies it as an Server - works perfectly. The only difference - this one > was manufactured a month after the other one. Logically, this would point to > a defective device - but still mDNS works in other scenarios. I'm sure > there's something else going on. > * Software/Firmware is identical - multiple factory resets > > I have a TAC case opened with Aruba - after working with them for a couple > days - they've escalated to their development team as it's definitely the > controller that's failing to classify this device as a Server - just don't > understand yet why > > 1. If you can and have the capability - can you find other "Home Pods" on > your network via device-registration or classification (Clearpass as that > fingerprinting) > 2. You reminded me of my situation while I helped the student - my success > with setting up a Home Mini with iOS was much lower than Android. > * Android (Wi-Fi Direct) - After telling the Home Mini to connect to > the desired SSID - my phone would try and move over - fail...but the Home > Mini would maintain it's connection to the SSID - at which point I'd move > back to our dot1x network and allow AirGroup to work it's magic. > * iOS Bluetooth (Preferred) or (Wi-Fi Direct) - Each time I ran the > Home Mini - after telling the Home Mini to connect to the desired SSID - my > phone would try and move over - fail - the Home Mini would eventually "give > up/disconnect" from the SSID. I think what was happening - device would move > over - Home Setup App would timeout - I'd run the app again (it would use > Bluetooth) - and redo the SSID config. 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. > > > Other Note - I had a small chuckle while at the local Wal-Mart asking for a > Google Home Mini - the employee commented (wait let me get you one that > hasn't been opened) - there was an entire row of them. My thoughts - either > people didn't like them....or with this being a university town...a bunch of > students bought them, couldn't get them working...and returned them. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
