Choose your language

Choose your login

Contact us

Troubleshooting subnet filtering

This page applies to:

Editing the printer.conf.toml file doesn’t seem to do anything

After editing the file, did you remember to restart the Mobility Print service? When you look at the Mobility Print Admin Interface, changes should show immediately. Subnets are listed below each printer.

After editing the printer.conf.toml I received a “There was an error reading the printer config file” message

Does the printer.conf.toml revert back to the template every time you restart the Mobility Print server? Double-check that the rules follow the correct formatting and syntax (including spaces!). If there are formatting or syntax errors, the file is reverted back to the template.

Editing the printer.conf.toml file worked, but users can’t see any printers in their printer list

  • Remember, only users (clients) in subnets listed in the printer.conf.toml file will see printers in their printer lists.
  • Before you create subnet filtering rules, make sure that all of the printers are visible from that particular subnet. If the printers are missing, run through the steps in Configure Mobility Print .
  • Confirm how users are discovering the printers. Subnet filtering is intended to work with the mDNS, DNS-SD, and Known Host discovery methods. However users that get connected using the Cloud Print feature will see all of the printers published by the Mobility Print server.

When using Subnet Filtering with the DNS discovery method

  • When you configure DNS Setup in from the Mobility Print Admin interface, make sure that you list all of the subnets and create the correct DNS records by running the DNS commands generated by the Mobility Print Admin interface. This creates the Reverse Lookup Zones and Conditional Forwarder needed for macOS and iOS clients to work with Subnet Filtering. To see how the records should look, take a look at Mobility Print DNS Record Examples.
  • Make sure there is no Forward Lookup Zone style of Mobility Print DNS record.  Specifically, you only want the style of DNS records described in “Method B”  on our page Mobility Print DNS Record Examples  
  • Do the Reverse Lookup Zones have 4 octets? For example 0.16.10.10.in-addr.arpa.
  • Do the subnet filtering rules precisely match the subnets used by the clients on the network? If you create subnet filtering rules for two subnets, for example; 10.0.1.0/24 and 10.0.2.0/24, you cannot use 10.0.1.0/23 as a shortcut.

When only macOS and iOS devices have trouble discovering the printers

This is generally only a problem with the DNS discovery method, and happens because DNS records are not set up properly. For this to work successfully, you will need the B and LB pointer records in a Reverse Lookup Zone. The DNS setup wizard should tell you exactly the right DNS records to create, but it’s very easy to do this incorrectly, especially if you are setting up the DNS records for multiple Mobility Print servers. This gets complicated, so we recommend just using the Known Host discovery method instead.

If Known Host is not an option, then you’ll have to double-check how your DNS records are set up, and ensure the reverse lookup zone exactly match the subnet of the device. For example, if you create DNS records for two subnets like 10.0.1.0/24 and 10.0.2.0/24, then you can’t use 10.0.1.0/23 as a shortcut. See DNS Record Examples for more details on how this works.

Other considerations

  • If you are still having trouble, test the subnet filtering rules one at a time. After restarting the Mobility Print service, you should see the change immediately in the Mobility Print Admin interface.
  • If you want to use Subnet Filtering with BIND DNS servers, then there is a different method for setting up the DNS records that requires setting up Reverse Lookup Zones. If this sounds like your situation, let us know and we’ll send you special instructions.

Comments