Hi

I hope this is the right forum to post this in, it seemed the best fit for the question.

Ok, we have an IBM Thinkpad running specialist auto diagnostic software built on a custom build of SCO linux - I say custom as I don't seem to be able to alter any of the configuration.

We really need to be able to print from it, but it only prints in PS format to a limited number of printers and despite having a network printer which allegedly offers PC5/PC6 and PS support it just prints pages and pages of garbage.

As this didn't work, I have set up a virtual PS printer on a nearby XP box using Ghostscript and Redmon to try printing across the network from the auto diagnostic pc. I have verified it works, so I'm pretty sure that's not the problem.

Since this (really freaking annoying) software has to be on a specific IP address, I wanted to take it off our general network, so I have connected the two computers with a crossover Ethernet cable and given them correct IP addresses to be able to connect.

The problem is, the software on the diagnostic computer has no ability to see Windows or a an shared printer, only to print to a specific IP address. Because of this I am trying to find if there is a way that I can get the Windows XP PC to accept any data sent to its IP address to print to the Virtual PS printer?

I used Wireshark to look at the traffic on the cable and there is a print request from the auto diagnostic PC to the XP box on Port 9100. However, the XP box only sends back a Reset command in the other direction. The auto diagnostic PC continues to send requests but the same thing happens and nothing prints.

Sorry for the long post, but I wanted to explain the situation as best I could. I have tried so many ways to do this, but just can't seem to find the right setting or missing link in the chain.

Thanks

Dani AI

Generated

— the Wireshark trace you described (SYN then an immediate RST) is the important clue: Windows XP is not listening on TCP/9100 (or a firewall is rejecting the connection), so the diagnostic box opens a socket and the XP host immediately rejects it. ’s suggestion (adding Print Services for Unix) installs an LPD/LPR server (port 515), which helps only if the SCO box can be made to use LPR — otherwise you still need something on XP that accepts raw JetDirect (9100) connections.

Quick checks

  • Confirm XP has a listener on 9100:

    netstat -an | find "9100"
  • Temporarily disable the XP firewall or add an inbound exception for TCP 9100 while testing.

Practical (low-effort) solution
Run a small TCP listener on the XP box that writes each incoming connection to a .ps file, then send that file to the local virtual printer. Example patterns (exact switches depend on the nc/ncat build you use):

nc -l -p 9100 > C:\temp\job.ps

or

ncat -l 9100 --keep-open > C:\temp\job.ps

When the connection closes, submit the file to the XP print queue:

print /D:\\localhost\VirtualPSPrinter C:\temp\job.ps

Notes, caveats and tweaks

  • Use a loop or the ncat --keep-open/-k option to handle multiple jobs. Some netcat builds exit after one connection.
  • Make sure the virtual PS printer is configured to accept raw PostScript (print processor/data type = RAW) so Windows does not re-render the job.
  • If you can change the SCO box to use LPR, ’s LPD approach is cleaner; otherwise a small TCP→spool proxy (above) or a dedicated 9100-to-spooler utility is the usual fix.
  • Test on the isolated crossover link first. Opening 9100 on an Internet-exposed interface is a security risk.

You'll need to add Print Services for Unix to the XP box. Right click My Network Places and left click Properties; click the Advanced menu and then Optional Networking Components. Select Other Network File and Print Services (check box) and then click Next. (you may be prompted for the Windows XP cd at this point).

When adding the printer on the Linux box, the print server name will be the name(or IP address) of the XP computer and the queue name will be the share name of the printer(i believe the queue is case sensitive)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.