Uh, I wasn’t aware of so many different printing protocols. Do you? While I was trying to solve a little printing problem I took a packet capture of three different printing variants over TCP/IP: Raw via TCP port 9100, LPD/LPR via TCP port 515, and Apple’s AirPrint which uses the Internet Printing Protocol IPP. As always, you can download this pcap and have a look at it by yourself.
In all three cases, I printed a simple demo page on my “HP LaserJet 200 colorMFP M276n” printer. Two times from a Windows 10 PC (from a different IPv4 subnet, hence routed and some SNMP packets) and one time from an iPhone (AirPrint, same layer 2 network, some kind of auto-discovery via IPv6). Download the pcap (7zipped, 125 KB):
Open it with Wireshark and browser through it. The “list of printing protocols” on Wikipedia indeed shows those three variants:
Raw printing is done via TCP port 9100. It is also called HP Jetdirect, or the like. Wireshark has no protocol dissector for this raw printing (little discussion here). You’ll find it via “tcp.port eq 9100”:
The Line Printer Daemon protocol/Line Printer Remote protocol (or LPD, LPR) uses TCP port 515. Wireshark’s display filter is “lpd” while you can find the whole stream with “tcp.port eq 515” or the like. It seems like the mere print data is encoded in the same way as the Raw variant:
Apple’s AirPrint uses the Internet Printing Protocol IPP on TCP port 631 (I have never heard of it). In my case, the iPhone found the printer via some MDNS discoveries that are shown in the trace as well. My printing of a single page took about 10 TCP/UDP streams and roughly 1200 packets. Uh. Hard to troubleshoot, but working without any configuration. ;) Filter for the iPhone’s MAC address in the trace to find all appropriate packets: “eth.addr == d4:a3:3d:97:60:6d”:
Filtering for “ipp” shows only some HTTP-like lines, while there are much more packets involved in the “tcp.port eq 631” flows:
Can you manage to extract the printed pages out of this trace? ;D