I wanted to provide a bit of an update on the Apple HomePod. I found one student had registered an one of these on our network so I reached out to them to get some feedback. We have an 802.1x SSID and an Open SSID for the Apple HomePod - with Aruba AirGroup handling the Mdns traffic.
- "I have had my device since February and it has been working great so far." - "I primarily use it for a speaker for my Apple TV and there are a few times that it takes a minute for my device to locate it but I have not ran into this problem in a while." - I suspect this may been due to the "mDNS" AirGroup credit" - "There are some features that do not work since my iPhone and HomePod are on separate networks like being able to create notes and text messages but those features are ones that I don’t think I would have used anyways." I haven't looked into the create notes/text messages yet to see if there's a separate AirGroup mDNS service id that would need to be created yet. The BIG Kicker is - there appears to be no direct way to get the MAC Address of the Apple HomePod for initial set-up – based on the two cases we’ve had so far. I haven’t been able to get a hold of one of these to check for alternative methods as of yet. * The student had a friend bring over their Android Phone and setup a mobile hotspot – and obtained the MAC Address that way. * TechZone Service Center tested on of the devices this week – and also had to setup a mobile hotspot and run “Fing – ARP Scan” to obtain the MAC Address. * https://discussions.apple.com/thread/8275373 * https://www.reddit.com/r/HomePod/comments/7wed0r/how_do_i_find_the_homepods_wifi_mac_address/ After registering the MAC Addresses, the devices worked relatively well. Very frustrating about the MAC Address thing. Oh – and side-note – as I mentioned this earlier about not ruling out a “defective device”. I made progress on the single “Google Home Mini” that initially appeared to be defective from a “this one works – that one doesn’t” perspective – confirmed an issue with Aruba AirGroup for those interested. 😊 -> https://community.arubanetworks.com/t5/Wireless-Access/Google-Home-Mini-AirGroup/m-p/414019#M79672 -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Ian Lyons Sent: Thursday, February 15, 2018 11:58 AM To: [email protected] Subject: Re: [WIRELESS-LAN] Apple Home Pod 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. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
