Hi all,

Scenario:
I have a local network with an SCO 5.0.5 server running an accounting
application and several windows 98 workstations -each with its own
printer- accessing the SCO server via TinyTerm.
Here everything works OK. All client workstations have access to the
application and print to their respectively attached printers.
Also, there are two other Windows 98 workstations (each with its own
attached printer too) in a remote branch site, connected to the
central site through a cablemodem service provided by an ISP.
The goal is to allow users at the remote site (who also access the
application on the SCO server via TinyTerm) to print to their local
printers. For one client, the approach taken at the central site was
to configure a network printer on the SCO server and point it to a
windows 98 machine running a proxy (in this case the product used was
'hhproxy' for windows) which maps and forwards all traffic sent to
port 515 to the IP address (and port 515) of the actual remote
workstation at the branch site where the print job originated. That
remote workstation runs 'winlpd', a windows lpd daemon that catches
traffic on port 515 and prints it on its local printer. This is
working perfectly well for this 1st remote client workstation.
The problem arises when I have to set up printing for the 2nd remote
client workstation because the mapping of port 515 already goes to the
1st one. To overcome this, I took the example from
http://www.pcunix.com/SCOFAQ/scotec7.html and:
1) Installed the 'netcat' ELF binary from ftp://pcunix.com/pub/netcat
on /usr/bin and set the right permissions.
2) Manually added a local printer named 'epsonlx810' (the actual
printer on the remote 2nd client is a dot matrix Epson LX 810) using
the 'netcat' model interface script (also from Tony Lawrence's FAQ)
which had previously been saved on /usr/spool/lp/model:
/usr/lib/lpadmin -p epsonlx810 -m netcat -v /dev/null
where the 'netcat' interface script contains:
# PORT=9100 # for hp, netgear, some others
shift; shift; shift; shift; shift
# The lpsched program sends 5 arguments that we are going to ignore.
# arguments 6 and on are the file names to be printed
# We just throw away everything but the file names by using shift
# 5 times
# arguments 6 through whatever are now $*
cat $* | netcat -h 192.168.0.1 -p 9100
# If you need lfcr translation, do:
# cat $* | /usr/lib/lponlcr | netcat -h printserver -p $PORT
# If you need a pagefeed, do:
# cat $* /usr/lib/Control_L | /usr/lib/lponlcr |
# netcat -h printserver -p $PORT
# 192.168.0.1 is the ip address of the Windows 98 machine
# running 'hhproxy'

I picked port 9100 because port 515 is already used to handle traffic
from the system's network printer. Anyway, 'hhproxy' will map port
9100 back to 515 when forwarding traffic to 'winlpd' on the 2nd remote
client. Port number 9100 was chosen for the sole purpose of providing
'hhproxy' a means to decide where packets come from and where to
forward them, that is, traffic to 'hhproxy' on port 515 goes to 1st
remote client's winlpd at port 515 whereas traffic to 'hhproxy' on
port 9100 goes to 2nd remote client's winlpd at port 515.
Then I ran '/usr/lib/accept epsonlx810' and 'enable epsonlx810'

Unfortunately this didn't work. Print jobs sent to the 'epsonlx810'
printer don't reach the remote printer. It seems as if 'netcat' isn't
doing its job because 'hhproxy' on the windows 98 machine (on the same
ethernet
segment) never receives any traffic on port 9100. What's more, leaving
the printing issue aside for a moment, a simple test with 'netcat'
trying to redirect its piped input doesn't work. For example, given a
test text file (say 'test.txt'), the following command doesn't work:
cat test.txt | netcat -h 192.168.0.1 -p 9100
where 192.168.0.1 is the IP address of the windows 98 machine running
'hhproxy'. Here, according to the logs on host 192.168.0.1, it never
receives anything on port 9100, so nothing gets mapped and forwarded
to the remote 2nd client with the Epson printer attached.
At the same time, 'lpstat' returns nothing. Because of this, I think
there exists an issue with my set up of 'netcat' on the SCO server and
not 'hhproxy' or 'winlpd' on the other hosts.

Can anyone please tell me what I did wrong or why netcat (and
therefore remote printing) is not functioning the way I thought it
should ? What would be the recommended or most appropriate approach
for this ?
If it were possible to set up a network printer on the SCO server to
use a port other than 515 I wouldn't have to mess with 'netcat'.
As I said above, traffic on port 515 is taken by 'hhproxy', then
mapped and forwarded to the 1st client at the remote branch, that's
why I had to pick other unused port number like 9100. I visited
http://www.pcunix.com/Jeffl/portnumbers.html for reference.
Anyway, before discussing printing issues, it's netcat that seems to
not be working here as can be told from 'hhproxy' logs.
I hope everybody understands what I tried to explain.

Thank you,

Fernando Ronci
E-mail: fernandoronci@hotmail.com

Fernando Ronci <fernandoronci@hotmail.com> wrote:

(stuff deleted, basically he's trying to use netcat to do lpr)

>I picked port 9100 because port 515 is already used to handle traffic
>from the system's network printer. Anyway, 'hhproxy' will map port
>9100 back to 515 when forwarding traffic to 'winlpd' on the 2nd remote

But what you are not understanding is that lpd is a fairly
complex protocol and netcat is NOT doing that.

See http://aplawrence.com/Unixart/netcatlpr.html for a better idea
of what you would need to do.

Better idea would be to put a printserver out there that you CAN
use netcat directly with.

--
tony@aplawrence.com Unix/Linux/Mac OS X resources: http://aplawrence.com
Get paid for writing about tech: http://aplawrence.com/publish.html

On 25 Jan 2004 12:54:53 -0800, fernandoronci@hotmail.com (Fernando
Ronci) wrote:

>I have a local network with an SCO 5.0.5 server running an accounting
>application and several windows 98 workstations -each with its own
>printer- accessing the SCO server via TinyTerm.
>Here everything works OK. All client workstations have access to the
>application and print to their respectively attached printers.
>Also, there are two other Windows 98 workstations (each with its own
>attached printer too) in a remote branch site, connected to the
>central site through a cablemodem service provided by an ISP.

If everything is going to the remote branch office via a single IP
address (i.e. you're using NAT/PAT), then you can only have one remote
netcat or LPR/LPD printer per IP port number. If you insist on
implimenting this nightmare, you need to configure the router at the
remote to redirect your netcat traffic to the workstation running the
client lpd application. This is one case where using netcat just
isn't gonna work.

Also, simply redirecting netcat traffic on port 9100 to port 515 on
the client machine is not going to magically turn netcat into a LPR
client. Only LPR clients talk to LPD print server daemons. LPR
clients also use more than port 515.

>The goal is to allow users at the remote site (who also access the
>application on the SCO server via TinyTerm) to print to their local
>printers.

Since you're using TinyTerm, you need to setup the OSR5 server lpr
print spooler for each Windoze printer. This is fairly trivial with a
simple LAN topology, and close to a nightmare when running through
multiple routers with NAT/PAT.
http://www.censoft.com/support/ttip7.php?src=
I'm not all that familiar with your unspecified Tiny Term version and
have no real clue as to how your network topology is arranged, so I
can't offer any specific port forwarding recommendations. (Hint: No
numbers, no specific answers).

>For one client, the approach taken at the central site was
>to configure a network printer on the SCO server and point it to a
>windows 98 machine running a proxy (in this case the product used was
>'hhproxy' for windows) which maps and forwards all traffic sent to
>port 515 to the IP address (and port 515) of the actual remote
>workstation at the branch site where the print job originated.

The proxy server adds yet another layer of complications to the
puzzle. It will also NOT solve the NAT problem. I like the idea, but
it just won't work.

>That
>remote workstation runs 'winlpd', a windows lpd daemon that catches
>traffic on port 515 and prints it on its local printer. This is
>working perfectly well for this 1st remote client workstation.

Yep. You've apparently successfuly redirected port 515 on the router
to a specific machine. However, from a single WAN IP address, you can
only redirect port 515 to a single Windoze workstation. Worse,
LPR/LPD opens ports other than 515 which may or may not go through
your unspecified make and model of firewall. Basically, lpr/lpd is
rather NAT firewall unfriendly. I can usually make it work, but every
once in a while, I run into a firewall that hates LPR/LPD.

>The problem arises when I have to set up printing for the 2nd remote
>client workstation because the mapping of port 515 already goes to the
>1st one.

Yep.

>Can anyone please tell me what I did wrong or why netcat (and
>therefore remote printing) is not functioning the way I thought it
>should ?

Netcat is not a protocol translator. You can't use it to juggle port
numbers. Netcat can be set to use just about any port number.
LPR/LPD cannot.

>What would be the recommended or most appropriate approach
>for this ?

I never thought you'd ask. How much $$$ do you have invested in your
firewalls? If they are the typical low end Linksys, DLink, or Netgear
boxes, toss them and get a VPN firewall and build a real Virtual
Private Network. NONE of the issues you're fighting are a problem
with VPN's, which deliver the entire office network space to the
remote office without any translations or black magic. I maintain one
system with 4 remote offices. Since everything appears as one big
network from anywhere, I have no problems with any software or
services. The routers use the IPSec protocol to argue among
themselves and deal with security. Therefore, there is no added
software on any of the client or server boxes.

I've used a variety of VPN routers for the purpose. My favorite is
Sonicwall, but it's rather expensive. There are numerous cheaper
models in the $100-$200 from the usual bottom of the line router
vendors. All that I've tried work fine. If you have some questions
on how a VPN works, ask here.


--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
jeffl@comix.santa-cruz.ca.us jeffl@cruzio.com

Tony Lawrence <apl@shell01.TheWorld.com> wrote in message news:<bv1c8k$a7d$1@pcls4.std.com>...
> Fernando Ronci <fernandoronci@hotmail.com> wrote:
>
> (stuff deleted, basically he's trying to use netcat to do lpr)
>
> >I picked port 9100 because port 515 is already used to handle traffic
> >from the system's network printer. Anyway, 'hhproxy' will map port
> >9100 back to 515 when forwarding traffic to 'winlpd' on the 2nd remote
>
> But what you are not understanding is that lpd is a fairly
> complex protocol and netcat is NOT doing that.
>
> See http://aplawrence.com/Unixart/netcatlpr.html for a better idea
> of what you would need to do.
>
Does this mean that the script at the above URL has to be called by
the printer interface script ?

Thank you,
Fernando

Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote in message news:<i1o810lisn6rq29rn727luaf3j1t355vre@4ax.com>. ..
> On 25 Jan 2004 12:54:53 -0800, fernandoronci@hotmail.com (Fernando
> Ronci) wrote:
>
> >I have a local network with an SCO 5.0.5 server running an accounting
> >application and several windows 98 workstations -each with its own
> >printer- accessing the SCO server via TinyTerm.
> >Here everything works OK. All client workstations have access to the
> >application and print to their respectively attached printers.
> >Also, there are two other Windows 98 workstations (each with its own
> >attached printer too) in a remote branch site, connected to the
> >central site through a cablemodem service provided by an ISP.
>
> If everything is going to the remote branch office via a single IP
> address (i.e. you're using NAT/PAT), then you can only have one remote
> netcat or LPR/LPD printer per IP port number. If you insist on
> implimenting this nightmare, you need to configure the router at the
> remote to redirect your netcat traffic to the workstation running the
> client lpd application. This is one case where using netcat just
> isn't gonna work.
>
> Also, simply redirecting netcat traffic on port 9100 to port 515 on
> the client machine is not going to magically turn netcat into a LPR
> client. Only LPR clients talk to LPD print server daemons. LPR
> clients also use more than port 515.
>
> >The goal is to allow users at the remote site (who also access the
> >application on the SCO server via TinyTerm) to print to their local
> >printers.
>
> Since you're using TinyTerm, you need to setup the OSR5 server lpr
> print spooler for each Windoze printer. This is fairly trivial with a
> simple LAN topology, and close to a nightmare when running through
> multiple routers with NAT/PAT.
> http://www.censoft.com/support/ttip7.php?src=
> I'm not all that familiar with your unspecified Tiny Term version and
> have no real clue as to how your network topology is arranged, so I
> can't offer any specific port forwarding recommendations. (Hint: No
> numbers, no specific answers).
>
> >For one client, the approach taken at the central site was
> >to configure a network printer on the SCO server and point it to a
> >windows 98 machine running a proxy (in this case the product used was
> >'hhproxy' for windows) which maps and forwards all traffic sent to
> >port 515 to the IP address (and port 515) of the actual remote
> >workstation at the branch site where the print job originated.
>
> The proxy server adds yet another layer of complications to the
> puzzle. It will also NOT solve the NAT problem. I like the idea, but
> it just won't work.
>
> >That
> >remote workstation runs 'winlpd', a windows lpd daemon that catches
> >traffic on port 515 and prints it on its local printer. This is
> >working perfectly well for this 1st remote client workstation.
>
> Yep. You've apparently successfuly redirected port 515 on the router
> to a specific machine. However, from a single WAN IP address, you can
> only redirect port 515 to a single Windoze workstation. Worse,
> LPR/LPD opens ports other than 515 which may or may not go through
> your unspecified make and model of firewall. Basically, lpr/lpd is
> rather NAT firewall unfriendly. I can usually make it work, but every
> once in a while, I run into a firewall that hates LPR/LPD.
>
> >The problem arises when I have to set up printing for the 2nd remote
> >client workstation because the mapping of port 515 already goes to the
> >1st one.
>
> Yep.
>
> >Can anyone please tell me what I did wrong or why netcat (and
> >therefore remote printing) is not functioning the way I thought it
> >should ?
>
> Netcat is not a protocol translator. You can't use it to juggle port
> numbers. Netcat can be set to use just about any port number.
> LPR/LPD cannot.
>
> >What would be the recommended or most appropriate approach
> >for this ?
>
> I never thought you'd ask. How much $$$ do you have invested in your
> firewalls? If they are the typical low end Linksys, DLink, or Netgear
> boxes, toss them and get a VPN firewall and build a real Virtual
> Private Network. NONE of the issues you're fighting are a problem
> with VPN's, which deliver the entire office network space to the
> remote office without any translations or black magic. I maintain one
> system with 4 remote offices. Since everything appears as one big
> network from anywhere, I have no problems with any software or
> services. The routers use the IPSec protocol to argue among
> themselves and deal with security. Therefore, there is no added
> software on any of the client or server boxes.
>
> I've used a variety of VPN routers for the purpose. My favorite is
> Sonicwall, but it's rather expensive. There are numerous cheaper
> models in the $100-$200 from the usual bottom of the line router
> vendors. All that I've tried work fine. If you have some questions
> on how a VPN works, ask here.

Thanks Tony and Jeff for your replies.
I'm going to try to convince the customer to invest some $ in new VPN hardware.

Fernando Ronci
E-mail: fernandoronci@hotmail.com

Fernando Ronci <fernandoronci@hotmail.com> wrote:
>Tony Lawrence <apl@shell01.TheWorld.com> wrote in message news:<bv1c8k$a7d$1@pcls4.std.com>...
>> Fernando Ronci <fernandoronci@hotmail.com> wrote:
>>
>> (stuff deleted, basically he's trying to use netcat to do lpr)
>>
>> >I picked port 9100 because port 515 is already used to handle traffic
>> >from the system's network printer. Anyway, 'hhproxy' will map port
>> >9100 back to 515 when forwarding traffic to 'winlpd' on the 2nd remote
>>
>> But what you are not understanding is that lpd is a fairly
>> complex protocol and netcat is NOT doing that.
>>
>> See http://aplawrence.com/Unixart/netcatlpr.html for a better idea
>> of what you would need to do.
>>
>Does this mean that the script at the above URL has to be called by
>the printer interface script ?

No.

That's just to help you understand what lpd is and netcat isn't.

--
tony@aplawrence.com Unix/Linux/Mac OS X resources: http://aplawrence.com
Get paid for writing about tech: http://aplawrence.com/publish.html