I have been working with Aruba and noticed that the Christmas batch of gear (all varieties) seems not to be classified as it was leading into the Holiday season.
Specifically Google Mini and Echo's. I use fingerprinting (via Clearpass) to validate what vlan the devices get, if any. I have had to override the fingerprint on my gear and just heard yesterday that 3rd Tier Engineering is putting in a fix for the fingerprinting so that other schools will get a better (clearer) fingerprint response of the devices. Ian -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Johnson, Christopher Sent: Thursday, February 15, 2018 11:53 AM To: [email protected] Subject: Re: [WIRELESS-LAN] Apple Home Pod 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:[email protected]] On Behalf Of Chuck Anderson Sent: Thursday, February 15, 2018 6:08 AM To: [email protected] 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. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
