For many educators, Google Expeditions is an exciting way to take classes to locations around the world in minutes. Through an ever-growing collection of Expeditions, we can visit France, parts of the Ocean and even travel off the spinning rock we call Earth.
(If you don’t want to hear the story of the app and jump right to the solution, scroll down a few paragraphs) The support pages for Expeditions contain some guidance about the requirements to run Expeditions on your network, mainly:
“Check with your IT admin to see if your school Wi-Fi network is enabled for peer-to-peer networking. If it isn’t, you can use a standalone router or run a hotspot from a phone.”
One of those two sentences made me cringe, mainly because getting a stable, reliable and well-running wireless network is a bit more complex when it comes to a school. With a heavy reliance on wireless networks for the simple aspect of Internet access to the more complex wireless phones used for 911 emergencies, most school IT departments want to control the wireless landscape within their walls and even the surrounding grounds. Dropping in an access point that moves around the building not connect to your school network poses a variety of issues. Then there is the personal hotspot idea. Those left me working on the first sentence and I asked myself “do we have peer-to-peer network enabled” Sure enough we did. So with that I fired open the Expeditions app on my iPad, another on my iPhone and found a place to visit. However, the Guide device, that is the one leading the Expedition, didn’t appear on my Explorer.
Please wait a few to troubleshoot
Needless to say, it took some time to troubleshoot the issue. Often, one of the best ways I’ll gain new perspective to a problem is to put it aside for a day or two.
We are a Cisco wireless shop – so while this is specific to Cisco, your vendor will have something similar.
So, what is the fix? In short – Bonjour / mDNS. In essence services run on a network and rather than require configuration of specific settings, we can have our network share the information through a service string. Using the mDNS Browser (In your WLC -> Controller -> mDNS -> mDNS browser) you will see a new service string appear for the device in Guide mode:
_googexpeditions._tcp.local.
This service string will need to be added and assigned to an mDNS profile.
But wait, there is more:
- Make sure the newly created mDNS service setting is assigned to an mDNS profile
- This mDNS profile may also need to be assigned to a specific wireless network
- Don’t forget to assign the mDNS profile to your Interface / Interface Groups on the controller.
If you are wondering why we have four Interfaces in our Interface Group – this allows our services to cross VLANS in our building. We have four wireless VLANS, each with a subnet. Creating a virtual interface on the controller “sticks” an interface into each VLAN so the controller can listen for traffic, cache it, then send it back out the other interfaces.
Bonus: When creating our service, we used orgin “ALL” This is really helpful for using AirPlay across subnets. With an interface in each wired VLAN we can also “listen” for broadcasts on the wired network and present them to the wireless side.