Looking for something that can snoop DDP Appletalk over Ethernet. I have been trying to get the Apple IIgs LaserWriter driver (and likely older Mac LaserWriter drivers) to print to a netatalk box running papd with no luck (GS/OS dies before any job spools). I am at the point where I need to see network activity with the netatalk box to see where its breaking and to also log communication with a known working printer on the network. Something that runs on a Mac is fine, I know Apple made a program called 'AppleTalk Peek' for this. Something that runs on Windows and Linux is fine as well. Ethereal claims to have rudimentary DDP Appletalk support, but I don't know if it will "see" PAP packets.
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Suggestions for AppleTalk Packet Sniffer?
- Thread starter NJRoadfan
- Start date
Byte Knight
Well-known member
No idea for a sniffer, but did you know you can TCP print with your IIgs over a network using Treehugger?
Well aware of TreeHugger. I'm trying to expand on print options for IIgs and potentially older Macs (using older LaserWriter drivers). The quality of the Postscript LaserWriter driver on a IIgs exceeds the currently available PCL and dot matrix drivers on GS/OS in particular.
cheesestraws
Well-known member
What physical layer? LocalTalk or EtherTalk? For EtherTalk, pretty sure Wireshark will do what you want. Wireshark is what Ethereal turned into some considerable time ago. It will capture anything and make a good shake at decoding it.
The emulated IIgs I'm testing with is on Ethernet, although the real thing would be communicating via LocalTalk and a Shiva Fastpath bridging it to Ethernet. I kinda wish the GS/OS LaserWriter driver was a bit more graceful in failing. Flat out locking up the machine and crashing usually isn't the way to go when something fails.
The source (yeah its out there) doesn't reveal any obvious reason why it would crash. I even went as far as flat out spoon-feeding it the responses it wants from the printer, even though I know it works with non-LaserWriters with Postscript 3.
The source (yeah its out there) doesn't reveal any obvious reason why it would crash. I even went as far as flat out spoon-feeding it the responses it wants from the printer, even though I know it works with non-LaserWriters with Postscript 3.
OK, WireShark seems to be picking up what I'm looking for, although its detection of PAP specific packets is a bit iffy. Whats odd is that it can't seem to properly label PAP packets from the emulated IIgs, but does from an emulated Mac no problem. The LaserWriter driver queries the printer/spooler and receives a response and then......hangs. Something isn't kosher with the response, but I need to test this against a known working AppleTalk connected printer (my HP Laserjet) and also test on a real IIgs to real out any weird Localtalk-to-Ethernet bridge bugs in GSport.
Once I get home back to my "real" hardware, I am going to have to run more tests.
My notes, no need to read:
-Test printing from GSport to HP LaserJet. Do packet capture and see if it works.
-Test printing from real IIgs to HP LaserJet. Do packet capture (hopefully all the forwarded packets from the Fastpath show up on the Ethernet side), I know printing works with this already.
-Start clobbering the source of netatalk's papd server to properly respond to the queries generated by the IIgs LaserWriter driver. Right now I know they don't match what the IIgs driver expects.
Once I get home back to my "real" hardware, I am going to have to run more tests.
My notes, no need to read:
-Test printing from GSport to HP LaserJet. Do packet capture and see if it works.
-Test printing from real IIgs to HP LaserJet. Do packet capture (hopefully all the forwarded packets from the Fastpath show up on the Ethernet side), I know printing works with this already.
-Start clobbering the source of netatalk's papd server to properly respond to the queries generated by the IIgs LaserWriter driver. Right now I know they don't match what the IIgs driver expects.
Last edited by a moderator:
cheesestraws
Well-known member
(FWIW, by the way, I've had good luck with NetMinder / NetCapture LocalTalk for LocalTalk packet capture, but I've never used it for PAP)
OK, looks like the LaserWriter 7 driver is "OK" once I added support to netatalk's papd to respond to "BeginFontListQuery", although if I try to feed it a font list larger than one ATP packet, it crashes. This HAS to work because all printers with the "Postscript 35" font set return a list larger than one packet. So my "to-do" list of packet traces has expanded.
Macintosh client tests:
-Capture packet trace between LaserWriter 7 driver and real printer.
-Capture packet trace between LaserWriter 7 driver and AppleShare Spooler.
Apple IIgs client tests:
-Capture packet trace between GSport and real printer.
-Capture packet trace between GSport and AppleShare Spooler.
-Capture packet trace between real Apple IIgs and real printer.
-Capture packet trace between real Apple IIgs and AppleShare Spooler.
I added the AppleShare spooler tests because they should be a good baseline reference implementation of a PAP spooler that was tested with Apple's own drivers.
On a side note. The LaserWriter 8 driver is far more forgiving of query responses. It mostly ignores bad/missing data and uses whats in the user-supplied PPD file. The older drivers really balk at missing font data and has no error handling for it, a big no-no because you can't assume the host on the other end of the line is always going to give you the correct data.
The problem with the Apple IIgs driver appears to be that is asks for two queries in one request, but attempts to read back the results with two separate PAP Read requests. It will never get a response to the second request with how papd works (if you send queries in a batch, it responses in a batch), yet somehow this works with real printers and I'd assume other spoolers. We'll see what the packet traces show me.
Macintosh client tests:
-Capture packet trace between LaserWriter 7 driver and real printer.
-Capture packet trace between LaserWriter 7 driver and AppleShare Spooler.
Apple IIgs client tests:
-Capture packet trace between GSport and real printer.
-Capture packet trace between GSport and AppleShare Spooler.
-Capture packet trace between real Apple IIgs and real printer.
-Capture packet trace between real Apple IIgs and AppleShare Spooler.
I added the AppleShare spooler tests because they should be a good baseline reference implementation of a PAP spooler that was tested with Apple's own drivers.
On a side note. The LaserWriter 8 driver is far more forgiving of query responses. It mostly ignores bad/missing data and uses whats in the user-supplied PPD file. The older drivers really balk at missing font data and has no error handling for it, a big no-no because you can't assume the host on the other end of the line is always going to give you the correct data.
The problem with the Apple IIgs driver appears to be that is asks for two queries in one request, but attempts to read back the results with two separate PAP Read requests. It will never get a response to the second request with how papd works (if you send queries in a batch, it responses in a batch), yet somehow this works with real printers and I'd assume other spoolers. We'll see what the packet traces show me.
I got this figured out. Freedom of Press comes with a PAP spooler to allow its Postscript RIP to be used over the network. Tracing its communication, netatalk's PAP implementation is clearly not "by the book". BeginFontListQuery is supposed to send each font name and the list terminator in separate PAP data packets. When multiple queries are sent to a printer or spooler, each query response should be sent back as a separate PAP data packet.
Whoever wrote netatalk's PAP spooler played fast and loose with the standard and assumed that query requests would be sent one at a time. It's batching up the replies, which it shouldn't be doing. I guess that person was only testing against the LaserWriter 8 driver and said "good enough, ship it!". Plus, the way its currently written, its impossible to change its behavior without completely re-writing a good chunk of code......something it needs anyway because it has by far the most complicated text parsing system I've ever seen!
Whoever wrote netatalk's PAP spooler played fast and loose with the standard and assumed that query requests would be sent one at a time. It's batching up the replies, which it shouldn't be doing. I guess that person was only testing against the LaserWriter 8 driver and said "good enough, ship it!". Plus, the way its currently written, its impossible to change its behavior without completely re-writing a good chunk of code......something it needs anyway because it has by far the most complicated text parsing system I've ever seen!
Continuing on my ramblings.....
I managed to get netatalk's papd to satisfy the IIgs LaserWriter driver's queries. In the process, classic LaserWriter drivers (pre-8.0) on the Mac side now appear to work 100%.
The problem is even though the IIgs LaserWriter driver is spooling the entire print job now, nothing is printing on the Linux side of things. Still something "not right" with the data transfer (or data sent) that netatalk refuses to send the job to the CUPS print queue.
I managed to get netatalk's papd to satisfy the IIgs LaserWriter driver's queries. In the process, classic LaserWriter drivers (pre-8.0) on the Mac side now appear to work 100%.
The problem is even though the IIgs LaserWriter driver is spooling the entire print job now, nothing is printing on the Linux side of things. Still something "not right" with the data transfer (or data sent) that netatalk refuses to send the job to the CUPS print queue.
