papd: Printing of a single line of text takes over 6 minutes

[justMaku]

Describe the bug

I'm trying to expose my HP LaserJet printer to my Mac Plus using CUPS and papd. I have successfully configured the printer to appear in Chooser on the Mac side and am able to print to it but it takes a significant amount of time to print even the most basic documents.

I've looked at the packet dump and there's a constant stream of data being exchanged between the server and the client, in the 90 second time period I had the packets dumped, at least 8kb of data has been sent, which I would expect to be enough for the print job.

To Reproduce
N/A

Expected behavior

Printing doesn't take 7 minutes to complete.

Environment

• Server OS: Raspbian
• Client OS: Mac System Software 7.0.1
• Netatalk Version: 4.3.0

Configuration

papd.conf

# PAP print server daemon configuration (Netatalk 4.x)
#
# See the `papd.conf' manual page for examples.

# cupsautoadd:op=root:

Office LaserWriter:\
   :pr=HP_LaserJet:\
   :op=maku:\
   :

Logs

Attach syslogs from the malfunctioning process, maxdebug log level

[justMaku]

Tried again, this time the print took even longer and in the end did not actually print anything (and no job is present in the spool).

Aug 23 22:51:52 appletalk papd[3047]: child 3053 for "Office LaserWriter" from 65355.1
Aug 23 23:10:46 appletalk papd[3047]: child 3053 done

FWIW - I just checked and the postscript files being generated are enormous - 35kb for two lines of text - but even then it should not be taking minutes to transfer.

[NJRoadfan]

Going to need more information on your setup.

On the mac side:
-Is this a real or emulated machine? I know minivmac's LToUDP emulation is SLOW to transmit and printing takes forever.
-What version of the LaserWriter driver? Stock System 7.0 should have LaserWriter 7.0 installed. Optionally you can install LaserWriter 7.1 or LaserWriter 8 and see if that helps.

On the server:
-What version of Raspian? Raspian is pretty old at this point, did you mean Raspberry Pi OS?
-Is this a CUPS printer queue? What version of cups and cups-filters is installed? I'm assuming its whatever the distro repo came with.
-Have you tried to print using a papd.conf with just the cupsautoadd line uncommented? This will automatically add all your system's CUPS queues to papd and broadcast them over the network. Try printing to the same printer this way.

The logs indicate that papd received a job of some sort (a child process is forked to handle it), so its seeing some data from the client.

[justMaku]

Setup is as follows:

1. Mac Plus with BlueSCSI emulating the DaynaPort to provide network connectivity with MacTCP - I wasn't aware netatalk can work with vMac systems.
2. Driver is the stock one from System 7
3. Server is running:

maku@appletalk:~ $ uname -a
Linux appletalk 6.12.34+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux

4. Yes, it's CUPS version 2.4.2-3+deb12u8 and 1.28.17-3+deb12u1 for cups-filters
5. I tried, same results.

Printing the same postscript file using the pap commands commits the print almost instantly.

[NJRoadfan]

I have used RPi OS bullseye for dev and testing. I don't think the issue is with CUPS or papd. Unfortunately I don't have a BlueSCSI with Wifi to reproduce your setup, but I know AppleTalk can be wonky over Wifi (Multicast issues) and the DaynaPort emulation is another unknown factor as well.

I'm assuming your BlueSCSI and RPi are both on Wifi connected to the same access point. This would avoid the other AppleTalk problem with WiFi, the SNAP packet header mangling that can happen with some access points when transiting to Ethernet.

[justMaku]

I'm using an AirPort Express and the only two devices on the network are the Mac Plus and the Raspberry Pi. Other file transfers (FTP/AFP) work just fine with "reasonable" speeds.

I'll keep digging...

[rdmark]

Can you try enabling debug logging on BlueSCSI to see what goes on in the emulated DaynaPort device when the issue reproduces?

https://bluescsi.com/docs/Logging