Airprint missing paper size and finishing options on iPadOS 16

[csfjeff]

Describe the bug On iPadOS when I call up a print dialog and select a CUPS Airprint queue the dialog would present options for choosing paper size and finishing options. These no longer appear in iPadOS 16. They do appear no problem if I choose a real Airprint printer, so there seems to be 2 parts to this - Apple has changed something about how they parse those options and CUPS seems likely to be missing something that a real Airprint queue does have.

To Reproduce Steps to reproduce the behavior:

1. On iPad with OS 16 installed choose to print a document, select a printer that is a CUPS Airprint queue 2 The print dialog does not contain the Paper size selector, or the Finishing Options selector.

Expected behavior On iOS 15 the missing options are presented, and on iOS 16 pointed at a real Airprint printer shows the expected options. It's only the combination of iPadOS 16 and a CUPS queue.

Screenshots Added screenshot of iPadOS 15 vs 16 print dialog, with missing options circled in red. Our devices are in French so screen shot is in French, but the missing dialogs would be Paper size and Finishing options.

System Information:

• OS Ubuntu 22.0.4 with CUPS 2.3.3 and Ubuntu 23.10 (beta) with CUPS 2.4.5 tested
• iPad OS v 16.1.1 and 16.5 tested with issue, iPad OS 15.6.1 tested without issue.

Additional context

Results of IPP get-printer-attributes.test command I have attached text files that are the result of running a get-printer-attributes.test command to compare the differences between a CUPS queue response and an Airprint printer response.

I did spend a bunch of time pouring over the differences, and white there are quite a few differences, there are a couple that jumped out to me:

• CUPS missing 'finishing-template-supported', 'finishings-col-ready' and 'finishings-col-supported' attributes.
• In 'ipp-features-supported' attribute the Printer includes a 'airprint-1.8' option in the list.
• In 'media-col-supported' the CUPS queue is missing media-size-name and media-color options.
• CUPS queue has a lot more entries in the 'operations-supprted' attribute.
• Big difference in the 'urf-supported' attribute:
  • CUPS has ["V1.4", "CP1", "W8", "PQ3-4-5", "RS600", "DM1", "FN81-80-79-78-77-76-75-74-31-30-29-28-23-22-21-20"]
  • Printer has ["CP255", "DM1", "FN3-4-5-14-20-21-22-23-28-29-30-31-74-75-76-77-78-79-80-81", "IFU1-2-3-4-5", "IS1-2-3-4-5", "MT2-3-4-5-6", "OB1-2-3-4", "PQ3-4-5", "RS600-1200", "V1.4", "W8"]

DNS-SD records to compare Results of a dns-sd -Z _ipp._tcp,_universal command to browse the Airprint record. TEST-Techno-B8155 is the CUPS 2.4.5 queue and BUR-Techo-Direct is the direct Airprint printer queue.

_ipps._tcp                                      PTR     TEST-Techno-B8155._ipps._tcp
TEST-Techno-B8155._ipps._tcp                    SRV     0 0 631 cups-tester.airprint.csf.bc.ca. ; Replace with unicast FQDN of target host
TEST-Techno-B8155._ipps._tcp                    TXT     "txtvers=1" "qtotal=1" "rp=/printers/TEST-Techno-B8155" "note=TEST-Techno-B8155" "pdl=application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/tiff,image/urf" "product=(AltaLink B8155 - IPP Everywhere)" "ty=AltaLink B8155 - IPP Everywhere" "priority=0" "adminurl=http://cups-tester.airprint.csf.bc.ca:631/printers/TEST-Techno-B8155" "UUID=3f10235a-ec4d-32cc-673b-09bbbfc4fab6" "TLS=1.2" "URF=CP255,DM1,FN3-4-5-14-20-21-22-23-28-29-30-31-74-75-76-77-78-79-80-81,IFU1-2-3-4-5,IS1-2-3-4-5,MT2-3-4-5-6,OB1-2-3-4,PQ3-4-5,RS600-1200,V1.4,W8" "Binary=T" "Transparent=T" "TBCP=F" "kind=document,envelope,label" "Bind=F" "Collate=T" "Color=F" "Copies=T" "Duplex=T" "Punch=3" "PaperCustom=T" "PaperMax=>isoC-A2" "Sort=T" "Staple=T" "AIR=username,password" "usb_MFG=Xerox" "usb_MDL=AltaLink B8155" "Scan=F" "Fax=F" "print_wfds=T" "mopria-certified=2.1"

_ipp._tcp                                       PTR     BUR-Techno-Direct._ipp._tcp
BUR-Techno-Direct._ipp._tcp                     SRV     0 0 631 BUR-B8155-Techno.local. ; Replace with unicast FQDN of target host
BUR-Techno-Direct._ipp._tcp                     TXT     "txtvers=1" "qtotal=1" "rp=ipp/print" "note=Bureau CSF - Richmond" "pdl=application/postscript,application/vnd.hp-PCL,application/pdf,image/tiff,image/jpeg,application/PCLm,image/pwg-raster,image/urf" "product=(Xerox AltaLink B8155)" "ty=Xerox AltaLink B8155" "priority=8" "adminurl=http://BUR-B8155-Techno.csf.bc.ca.local./protocols/airprint.php" "UUID=223527f4-11f6-11ec-aba3-e649401e6b30" "TLS=1.2" "URF=CP255,DM1,FN3-4-5-14-20-21-22-23-28-29-30-31-74-75-76-77-78-79-80-81,IFU1-2-3-4-5,IS1-2-3-4-5,MT2-3-4-5-6,OB1-2-3-4,PQ3-4-5,RS600-1200,V1.4,W8" "rfo=ipp/faxout" "usb_MFG=Xerox" "usb_MDL=AltaLink B8155" "Binary=T" "Transparent=T" "TBCP=F" "kind=document,envelope,label" "Bind=F" "Color=F" "Collate=T" "Copies=T" "Duplex=T" "Punch=3" "PaperCustom=T" "PaperMax=>isoC-A2" "Sort=T" "Staple=T" "Scan=T" "Fax=T" "print_wfds=T" "mopria-certified=2.1"

ipp-attributes-cups.txt ipp-attributes-printer.txt

[zdohnal]

Hi @michaelrsweet ,

can you look into it once you have a time? I don't have iPad to properly play with this...

[dkosovic]

I can confirm I have the same behavior with iOS/iPadOS 16.5.1.

I've attached Wiresharp IPP filtering between iOS 16.5.1 and CUPS 2.4.5 involving two Get-Printer-Attributes requests and the corresponding responses.

iOS-16.5.1-Wireshark.txt

[csfjeff]

Kinda getting stressed out here - our 3000+ school iPads were just updated over the summer so now it looks like all my users are going to be coming back to printers that have lost functionality over the summer - my poor help desk is going to be overwhelmed :(. Has there been any research to see what's going on here? Or advice on ways we might be able to mitigate?

[michaelrsweet]

@csfjeff Sorry, I've been neck-deep in a bunch of projects and haven't had a chance to properly look at this, although it could end up being an issue with iOS since the change in behavior happened with the new iOS version... Everything in the provided attribute dumps looks correct, with the only significant difference being that the CUPS media-col-ready attribute doesn't show media-source or media-type values, but that is common for AirPrint servers so iOS shouldn't care.

[csfjeff]

Yeah, the issue definitely starts with iOS 16 for sure (haven't had a chance to test iOS 17 yet), so Apple is definitely doing something different. I've tested it against a couple of real Airprint printers I have access to (Brother personal and Xerox multifunction copiers) and seeing no issues with the real printers. I'm guessing here, but seems likely Apple decided to be very strict about how they are parsing the Airprint queues, and CUPS isn't quite matching what Apple wants to see.

[michaelrsweet]

OK, so I've done some initial testing - CUPS 2.4.1 from Ubuntu 22.04 LTS seems to work just fine with iOS 16. There are some minor differences between the attributes reported by 2.4.1 and current 2.4.6, so I'm going to bisect things until I find the change that caused this regression.

[michaelrsweet]

OK, so my issue with CUPS 2.4.6 seemed to be missing (input) filters for "image/urf". I've fixed that for my test server and now I am able to choose paper sizes as expected.

What driver are you using on the CUPS side of things?

[csfjeff]

Sorry for slow reply - in about 95% of my cases, CUPS is setup direct to IPP Everywhere queues. We're mostly using Xerox Altalink copiers and a few other misc HP and Xerox printers that are also IPP Everywhere. We do a have a very few number of older printers that require drivers but I'm trying to phase those out to standardize on IPP Everywhere.

[michaelrsweet]

OK, so are you forcing everyone to go through the CUPS server for accounting, access control, etc? If they are IPP Everywhere then they are almost certainly AirPrint already, so unless you need accounting or access control you are better off using DNS to provide addresses and SRV/TXT records...

[csfjeff]

That's correct, we're using PaperCut to track printing and do accounting.

[csfjeff]

I'm trying to test CUPS 2.4.1 on Ubuntu 22.04 myself, and sadly not having any success with Paper Sizes. When I first select "Print" the dialog that pops up has a paper size option shown, but once I select one of the actual CUPS Airprint queues it goes away :(.

[dkosovic]

I have the issue with iOS 16.6 and CUPS 2.4.5 when using static-DNS to provide addresses and SRV/TXT records.

When using CUPS 2.4.6 and multicast DNS, I'm not able to reproduce the issue with iOS 16.6.

I've got to update the former to CUPS 2.4.6 and also check if I've missed something with the static-DNS.

[csfjeff]

@dkosovic - Were you able to dig anymore into that? I also am using static-DNS SRV/TXT records so would definitely be curious if I'm missing something.

[dkosovic]

I used the macOS rvictl utility that comes with Xcode to do a tcpdump on my home network of my iPhone USB connected to a MacBook where iOS 16.6 is doing the right thing with CUPS 2.4.6.

Find iPhone-Wireshark.txt attached of the interesting mDNS packets. Ideally, I should have toggled the iPhone AirPlane mode first to flush the DNS cache before doing the tcpdump, but nonetheless don't think anything useful was lost. Note: the print queue is called print01 and linux is the hostname of the VM I used for CUPS 2.4.6.

From that output, looks like the following are used with iOS 16.6:

• _universal._sub._ipp._tcp and _universal._sub._ipps._tcp
• _ipp._tcp and _ipps._tcp
• print01 @ linux._ipp._tcp and print01 @ linux._ipps._tcp
• _printer._tcp
• print01 @ linux._printer._tcp

Interesting how _printer._tcp is used, but _print._sub._ipp._tcp and _cups._sub._ipp._tcp (along with *._ipps.* counterparts) aren't with iOS 16.6. I haven't been providing _printer._tcp in my Wide Area Bonjour SRV/TXT records.

Here is an extract from macOS dns-sd utility :

_printer._tcp                                   PTR     print01\032@\032linux._printer._tcp
print01\032@\032linux._printer._tcp             SRV     0 0 0 linux.local. ; Replace with unicast FQDN of target host
print01\032@\032linux._printer._tcp             TXT     ""

Extract from Bonjour Printing Specification Version 1.2.1 :

If the printer only supports IPP it MUST register the IPP service type and then assert that LPD is not supported by registering the LPD service type (_printer._tcp) with a port number of 0.

I haven't done any testing yet with modified Wide Area Bonjour SRV/TXT records, but will be trying _printer._tcp with port number of 0.

[dkosovic]

I upgraded to CUPS 2.4.6 and added _printer._tcp SRV/TXT DNS records, but still no luck with iOS 16.6. It didn't even appear to be querying _printer._tcp SRV/TXT records like it does with mDNS.

I'm going to try and force CUPS 2.4.6 on my home network to use ipp instead of ipps, which will help with the wireshark debugging and compare it to my workplace that is using Wide Area Bonjour.

[michaelrsweet]

@dkosovic Does your cupsd.conf file have any BrowseDNSSDSubTypes lines in it?

You can try adding:

BrowseDNSSDSubTypes _cups,_universal,_print

This is the default value with stock CUPS but the "_universal" part is critical for iOS to see your printer.

[dkosovic]

On my home network where iOS 16.6 works correctly with CUPS 2.4.6 (I just created a dummy print queue and used the same IPP Everywhere generated PPD file from work that I've been testing against), although cupsd.conf doesn't explicitly have a BrowseDNSSDSubTypes line, I can confirm _cups, _universal, and _print subtypes are being advertised.

On my home network, I rebuilt the Fedora 38 cups-2.4.6 RPM by replacing --with-tls=gnutls with --without-tls to force it to use ipp instead of ipps. iOS 16.6 still works correctly, I couldn't see anything obviously different in the wireshark analysis when comparing to my workplace (apart from mDNS packets being replaced with DNS).

At my workplace, I forgot to add the _print subtype in the DNS zone file, anyway, here is the latest iteration of what I am using (to simplify debugging, I don't have corresponding _ipps records for this queue) :

_ipp._tcp                    PTR     lpHC301._ipp._tcp
_cups._sub._ipp._tcp         PTR     lpHC301._ipp._tcp
_universal._sub._ipp._tcp    PTR     lpHC301._ipp._tcp
_print._sub._ipp._tcp        PTR     lpHC301._ipp._tcp
lpHC301._ipp._tcp            SRV     0 0 631 cups-test.eait.uq.edu.au.
lpHC301._ipp._tcp            TXT     "rp=printers/lpHC301" "note=Hawken room C301" "pdl=application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf" "air=none" "UUID=07595a3b-3d15-3f64-6664-f43c4e8f10da" "TLS=1.2" "Color=F" "Duplex=T" "Staple=T" "PaperMax=tabloid-A3" "printer-type=0xB076" "URF=V1.4,CP1,W8,PQ4,RS600,DM1,FN30-29-28-22-20"

In my last attempt, I removed any key/value pairs that are described as not mandatory for IPP or IPPS in the Bonjour Printing Specification Version 1.2.1 I also added PaperMax=tabloid-A3, but none had any effect.

I don't have any iOS or iPadOS users that need to print on anything other than A4 or use the finishing options. Fortunately, macOS is fine and doesn't have the same issue.

[csfjeff]

I don't have any iOS or iPadOS users that need to print on anything other than A4 or use the finishing options. Fortunately, macOS is fine and doesn't have the same issue.

Sadly I have about 4000 of them that are about to all fire up for the new school year - starting to feel a bit desperate here. Anything I can do to help test?

[dkosovic]

I've finally got paper size and finishing working correctly with iOS 16.6 and static DNS SRV/TXT records. The trick is to use the exact same order for the key/value pairs in the TXT record as what CUPS 2.4.6 is advertising over mDNS.

To simplify things, I removed key/value pairs that the Bonjour Printing Specification Version 1.2.1 says are deprecated for IPP and IPPS, my final TXT record in DNS has:

"rp=printers/lpHC301" "adminurl=https://cups-test.eait.uq.edu.au:631/printers/lpHC301" "note=Hawken room C301" "pdl=application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf" "UUID =4a7d03f3-1d39-3846-57de-36f84592787d" "TLS=1.2" "URF=V1.4,CP1,W8,PQ3-4,RS600,DM1,FN30-29-28-22-20" "mopria-certified=1.3" "Duplex=T" "Staple=T" "Copies=T" "printer-type=0xB076"

[csfjeff]

Good find @dkosovic, that almost gets me going...

I can confirm that iOS 16.5 & 16.6 now presents the paper sizes and finishing options after matching my static DNS records to what CUPS advertises by default...

Except (and this is a big one) as soon as I turn the print authentication options on it breaks again...

The only difference I can see is that CUPS adds an entry for "air=username,password" to the mdns advertisement, and that single extra entry seems to be enough to break the iOS printing again. Ugh :(.

"txtvers=1" "qtotal=1" "rp=printers/CUPS-Techno-Test" "ty=AltaLink B8155 - IPP Everywhere" "adminurl=https://cups-test.local.:631/printers/CUPS-Techno-Test" "note=CUPS-Techno-Test" "priority=0" "product=(AltaLink B8155)" "pdl=application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf" "air=username,password" "UUID=2f678fb7-5060-3bb1-681c-146b6f0e1e0c" "TLS=1.2" "URF=V1.4,CP1,W8,PQ3-4-5,RS600,DM1,FN81-80-79-78-77-76-75-74-31-30-29-28-23-22-21-20" "mopria-certified=1.3" "Duplex=T" "Staple=T" "Copies=T" "Punch=T" "printer-type=0x40B176"

[csfjeff]

In fact, I reverted to my original static DNS entry and then just removed the air=username,password entry and everything works (except accounting of course)... Starting to think this is specifically a bug on Apple's part with dealing with Airprint printers that require authentication.

[csfjeff]

I'm not 100% confident I did it correctly, but I also tried enabling authentication on a direct Airprint queue from our Xerox Altalink, and as soon as that air=username,password option comes up, the paper size and finishing options disappear.

[dkosovic]

I was using air=none in my earlier iterations (when I disabled authentication and removed ipps DNS records) and it wasn't working properly with iOS 16, so looks like it only works properly when the air attribute isn't advertised at all.

I agree, looks like an Apple bug.

[csfjeff]

Ugh, sadly I haven't had tonnes of luck getting Apple to fix bugs that I've reported, but here goes.

[michaelrsweet]

@csfjeff You might be running into a limit on the size of the TXT record - try removing "printer-type" and limit "pdl" to "pdl=application/pdf,image/jpeg,image/urf,image/pwg-raster" (the common AirPrint/IPP Everywhere/Mopria formats). You also don't need the "Copies=T".

[dkosovic]

Using the printer-type and pdl suggestions, the following 289 byte TXT record (which is well within the recommended 512 byte limit) and putting air=username,password at the front unfortunately still doesn't work correctly with iOS 16 :

"air=username,password" "rp=printers/lpHC301" "note=Hawken Building room C301" "pdl=application/pdf,image/jpeg,image/urf,image/pwg-raster" "UUID=4a7d03f3-1d39-3846-57de-36f84592787d" "TLS=1.2" "URF=V1.4,CP1,W8,PQ3-4,RS600,DM1,FN30-29-28-22-20" "mopria-certified=1.3" "Duplex=T" "Staple=T"

[dkosovic]

iOS 17 seems to have fixed the paper size and finishing options not appearing when air=username,password is in the mDNS advertisement (in my case when using CUPS 2.4.6).

I'm not able to find any printers with iOS 17 when using Wide Area Bonjour, but think that is more likely an eduVPN issue with iOS 17, tcpdump indicates none of the necessary (unicast) DNS queries for Wide Area Bonjour are occurring on my iPhone.

[csfjeff]

@dkosovic - Just installed iPad OS 17.0 to test, and can confirm that Airprint is generally messed up - I do have 2 of our office copiers set to broadcast Airprint/mDNS and they are sometimes, intermittently showing up. But none of our DNS-SD based Airprint printers are appearing - these are ones that are discovered via a DHCP provided DNS search scope. So I don't think it's just you're eduVPN environment.

[csfjeff]

Sadly iPadOS 17.0.1 also does not find DNS-SD based Airprint printers. It sometimes finds my mDNS queues, but it takes a long time for them to show up, and they seem to appear and disappear randomly.

[csfjeff]

@dkosovic - Just curious if you were able to find any more details about the iPadOS 17 not browsing dns-sd print records? I've filed a bug with Apple on that and have been faithfully testing very iPadOS 17 beta to come out and so far no luck on my end. But I'm not sure how to debug that at the network / tcpdump level.