Skip navigation

Tag Archives: Bonjour

Click here for a tl;dr version that just gives you the fix without the background.

At my school, we have a fairly robust iPad program, and the decision was made, when we began to ramp up the deployment of iPads, that users should be able to print to their iPads.

Like so many of Apple’s technologies, AirPrint is one of those things that works well in a home environment but pretty quickly breaks down when taken into an enterprise environment.  Sure, you could go out and buy all new printers that have AirPrint built in, but when you’ve got a dozen or more printers that you might want to have available for iPad users, that quickly becomes a very expensive proposition.

You can roll your own AirPrint solution using a Linux box running avahi, but most people and departments would rather have a pre-baked solution, and then there’s only really one option: Printopia Pro.  If you’re running any sort of Bonjour gateway, such as the one built in to Cisco’s wireless access point controllers or Aerohive’s HiveManager cloud controller, you don’t even need more than one instance of the software.

And then Apple broke it all.

An engineer at the company that now develops Printopia Pro told me that for iOS 8 and OS X Yosemite, Apple moved away from a widely-used open-source mDNS discovery daemon to their own, in-house-developed daemon, and that’s where all the trouble started.

In a best-case scenario, we could maybe advertise four printers, and we often had to manually restart the Printopia Pro service when even those printers disappeared.

There is a solution that should work for most deployment cases, though.

This solution works only on networks running IPv4 and assumes that your Printopia Pro server is using a static IP address.  No, I don’t know all the technical details behind the IPv4/6 portion of this fix; I could have asked, and would have been very interested to find out the answer, but I didn’t feel like I had time for a several-hour conversation at the time.

Log in to your Printopia server and open the Terminal application and run the following command

networksetup -setv6off Ethernet

networksetup -setv6off EthernetLike the option says, this command turns off IPv6, which can’t be done through the GUI.  Next, open Printopia’s Advanced Settings.

Open Advanced Settings (command + comma)Under the General tab, there is a box to check that says “Publish printers using IPv4 addresses only.”  Uncheck this box if it’s checked.  Yes, that may seem counter-intuitive, but remember that you just turned off IPv6.

Picture of General tab under Advanced Settings with arrow pointing towards bottom-most checkbox with directions to uncheck that option.At this point, it’s worth making sure that printers are being advertised only over the Ethernet interface.  For each printer group, click “Settings…”

Picture indicating location of Settings button for printer groupand, under the Network Interfaces tab, select the bottom radio button and then select only your Ethernet interface.

Network Interface tab opened with only the Ethernet interface, en0, selected.Finally, for good measure, restart the Printopia service from the General tab.  Within a minute of applying these changes, we went from seeing four printers advertised over Printopia to seeing all seven printers that we were sharing.  You can check to make sure that the printers are being advertised over your network using the free Bonjour Browser application.

Bonjour Browser application window showing printers being advertised.So far, this solution has been totally stable for us, though it’s also recommended that you update your instance of Printopia Pro to the most recent release,, which can be downloaded here.


What have I been puzzling over on and off for the last few weeks? Enabling AirPlay discovery across VLANs.

The school I work at has been deploying Apple TVs to a lot of classrooms in the last several months, initially to solve a problem that Apple themselves had caused with buggy firmware for the Thunderbolt ports on their new MacBooks. Our teachers rely a lot on projectors, and the fact that around 30 of our teachers were suddenly unable to project from their brand new computers caused a huge problem. Enter Apple TV. The fact that you can use an Apple TV to mirror your computer’s display wirelessly was a huge hit with a lot of teachers who were tired of having to plug and unplug cables every time they wanted to put something up on the projector. Of course, the introduction of around 30 Apple TVs was not without its problems as well, especially as our wireless network started taking a hit from all the added traffic, especially when teachers wanted to stream video from their computer (over wireless) onto the Apple TV in their room (never mind the fact that Apple TVs have Netflix, Youtube, and Vimeo apps installed which would allow users to cut out the middleman of the computer).

Along with the influx of Apple TVs has come a wave of iPads and a lot of smart people thinking about educational uses for iPads.

Now all of this is great, and a lot of the kinks have been worked out or are being worked out by getting the Apple TVs hooked up to ethernet ports rather than going over the wire and by trying to figure out who still needs Apple TVs since the release of Apple’s Thunderbolt firmware 1.1 update, which solved the problem that got us so many Apple TVs in the first place. The big problem now is figuring out how to make our Apple TVs available to guest presenters during conferences and the like.

Our network is split up into several VLANs based on function, with students and faculty on networks that have their access controlled by a RADIUS server that looks at MAC addresses. We also have a WPA2-secured guest network for guests (duh). For individual guests who need access to functions on the access-controlled networks, it’s not too difficult to put their MAC in the system temporarily and remove them again when they leave, but that becomes impractical with high volumes of guests on campus. Logistically, it’s just too difficult to collect a thousand MAC addresses or even just a hundred for all the presenters at a conference, let alone spending the time, even with a script automating the process, to add and later remove all these clients from our RADIUS server.

Now if things were simple, we could just put a temporary hole in the firewall to allow traffic between the guest network and the network that has our Apple TVs on it. Unfortunately, Apple, in their desire to make everything as simple as possible, uses Bonjour (their implementation of multicast DNS) to make AirPlay-capable devices work together with almost zero user-intervention. Bonjour advertisement and discovery messages go out over link-local multicast, making it impossible, at least in an IPv4 setting, to ever get them out beyond Layer 2.

So what’s the solution?


Avahi is a FOSS implementation of mDNS that can, with the flip of a boolean switch in its config file, can reflect Bonjour packets between subnets.

I’m still reading through documentation and seeing how Avahi can be implemented in our network with as little extra strain to the infrastructure as possible, but in the mean time, here are a couple of articles touching on the subject from and Prolixium dot com.