LPD on non-standard port

[Aaron Sakovich]

VMS 7.3-2, TCP/IP Services v5.4-6

So, I've got a bunch of users with printers at home. They want to be able to print from OpenVMS to their printers.

I thought that it would be easy to setup a remote SSH tunnel (515:localhost:20001) so that the VMS system could send an LPD job to the PC's port 515 via the local VMS port 20001.

Everything worked okay until I tried to print. It turns out that the LPD Symbiont choked on a print command of the format:

$ Print /Queue=TCPIP$LPD_Out/Param=(host=localhost:20001,printer=PCprinter) testprint.txt

It didn't know what to do with the 20001; the specific error message was:


Job TESTPRINT (queue TCPIP$LPD_OUT_WOODY_1, entry 3084) terminated with error status
%NONAME-E-NOMSG, Message number 0764A05A

And in the TCPIP$LPD_OUT_WOODY_1.LOG file, I got:

%TCPIP-E-LPD_SYNERR, syntax error when parsing /PARAMETER=:20001

Does anyone know of any way to allow for non-standard LPD ports in TCP/IP Services?

I really wanted to do it this way, so as to not expose port 515 through the VPN, rather it would be tunneled in a secure connection. Additionally, it would prevent users from getting stale DNS data when a new user logged in to the VPN, and having the print job for UserA get dumped on UserB's printer. (Accomplished by each user getting a different port for their SSH tunnel.)

Any ideas?

[Volker Halle]

Aaron,

the Wizard suggested to use TELNETSYM for printing on non-standard ports.

http://h71000.www7.hp.com/wizard/wiz_8115.html

Volker.

[Volker Halle]

Aaron,

I've found '-LPD port configurability' (whater that means) mentioned in the TCP/IP proposed roadmap for 2009

http://h41267.www4.hp.com/filelib/se/sv/632971892320468750_TCP%20IP.pdf

Volker.

[David Jones_21]

I can't get DCPS to LPD to another port either, though 'IP_rawTCP' protocol does let you change the port from the default 9100.

[Hoff]

Can you provide some background on the mobility of your users (and associated requirements) and what sorts of firewalls are in use? This is less a question of lpr/lpd itself than one of the firewall(s), VPN/tunnel and the printer(s). And of dynamic addresses.

The particular firewalls and printers and firewalls and connection patterns are key here.

There are various ways to go after this, most involving port mapping at the firewall if lpr/lpd is a lock. Others have mentioned telnet and raw.

An approach I'd likely investigate here is to bridge the networks using a SOHO firewall, though keeping the malware inevitably running on the home network blocked from the corporate network as best as feasible. A SOHO-oriented server (or printing via the current client) on the home LAN can be used, as well. As part of connecting in, the corporate firewall targets the printer(s).

Another option is a custom print symbiont that checks the access and the network, and then launches the print job. That's rather more coding, but feasible.

I'd be tempted to look into IPv6, if that's available for your client hosts. That gives you unique addresses for your printers.

[Aaron Sakovich]

I'd *love* to use telnetsym, but there is no such receiver/server process available on the XP PC client. At least not that I'm aware of -- is there something I'm missing?

Telnetsym would allow me to use DCPS, which would be even better, from my perspective!

FWIW, I am broaching the subject with our firewall/VPN team, although I know in the past they have discouraged the use of LPD (not sure if that was outbound LPD, though).

[Hoff]

You're piping the printing directly into the client host and along to an attached printer? (Shudder.) That's a configuration -- and with any operating system running in the client -- that I try to avoid, as it tosses multiple layers of complexity -- and weirdness -- into the printing environment.

Going direct to a NIC-based printer is far easier to configure and to support, in my experience. Even if you have to create and open up port mapping through the firewall and from there along to the printer. Or open up IPv6 access, as that's way harder to port-scan.

How many clients are we discussing? Do only fixed sites require this printing, or does this involve mobile access?

[Aaron Sakovich]

Weird is my middle name...

I'm looking at 8 clients at the most for this config. We're just talking about a small group of home-based developers.

NIC-based printers are out of the question, as the printers were purchased and delivered without consulting our needs (I was lucky that I spoke up and said PCL/Postscript was essential, and even luckier that the LJ3050 was their default choice for multifunction printers. I'd probably been SOL if it hadn't!)

LPD is by far the cleanest implementation, although it does not allow any of the functionality that DCPS would provide.

[Bojan Nemec]

Aaron,

I am unable to test in this moment, but looking at your command:

$ Print /Queue=TCPIP$LPD_Out/Param=(host=localhost:20001,printer=PCprinter) testprint.txt

The DCL parser will probably see as /Param=(host=localhost=20001,printer=PCprinter).

Try to put localhost:20001 in braces:

$ Print /Queue=TCPIP$LPD_Out/Param=(host="localhost:20001",printer=PCprinter) testprint.txt

Bojan

[Aaron Sakovich]

Great idea -- I shoulda thought of that one.

But. *sigh* No joy.

%TCPIP-E-LPD_SYNERR, syntax error when parsing /PARAMETER=:20001

[Dale A. Marcy]

Probably will not work, but I would also try the following (replace ~ with " used ~ because """ get confusing to me to try and count)

$ Print /Queue=TCPIP$LPD_Out/Param=(~host=localhost:20001~,printer=PCprinter) testprint.txt

and

$ Print /Queue=TCPIP$LPD_Out/Param=(~host=~~localhost:20001~~~,printer=PCprinter) testprint.txt