Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!mcdchg!wucs1!wucs2!sw1e!uusgta
From: uusgta@sw1e.UUCP
Newsgroups: comp.dcom.lans
Subject: Re: Connecting a printer to an Ethernet
Message-ID: <497@sw1e.UUCP>
Date: Fri, 13-Mar-87 07:12:44 EST
Article-I.D.: sw1e.497
Posted: Fri Mar 13 07:12:44 1987
Date-Received: Sat, 14-Mar-87 14:42:33 EST
References: <5923@charlie.UUCP> <57700001@umn-cs.UUCP>
Organization: Southwestern Bell Telco GHQ St. Louis, MO
Lines: 39

In article <57700001@umn-cs.UUCP>, wsmith@umn-cs.UUCP writes:
> is set up a printcap entry as below:
> 
> bridge|lp2:\
> 	:lp=/dev/null:sd=/usr/spool/bridge-lp:lf=/usr/adm/bridge-errs:\
> 	:af=/usr/adm/bridge-acct:if=/usr/local/bin/bridge-filter:tr=\f:

I have done this, running into problems with the above when for other reasons
I had to add another (besides acctng) filter entry.  Since there is no filter
that *All* data will go through when more than one filter is defined filters
are "stopped" and started by lpd.  This is rough when the filter is your only
com path.
Fortunately the hack to lpd is straightforward. In the lpd code (common.c I
think) find the place where either a dev or a socket (to another lpd) is opened
& add a third choice.  Whole hack fits in couple dozen lines (but I obfuscated
that into several hundred & a daemon :-) ) There are a couple changes to lpq
also.  I found it helpful to add an address entry to printcap & put a bridge
address in internet form there. You don't want the address in /etc/hosts cause
then users can open telnet connections & screw with the printer. Being able to
specify the address simplifies testing since you can sit at a terminal & watch
what happens.  I would send you the code except I've changed jobs & management
at my old job is braindamaged.  (You can reach them only by phone and have them
start uucp for one q run.  Paranoia at a University?)

  There was a continuing problem that confuses the hell out of me. Occasionally
the Bridge would say it's connected when it wasn't. Netstat showed the socket
in FIN_WAIT_2.  Listening the Bridge port out corrected the problem.  Also the
Bridge discards buffered data after socket shutdown.  A workaround is a kludgey
one second sleep after data is finished before closing the socket.
I sure would like to know what caused the FIN_WAIT_2 problem.  If ANYONE
knows of shutdown problems twixt a Bridge (CS100 for us) & BSD please let 
me know.  Also if convenient for you, send me mail and I'll send for voice #'s
to my old job.  They are supposed to be on NSFnet soon but have heads in sand
till then.  _DEITY knows if they are willing to share code.   Hope all this
is still true.  I'm now the BSD bigot in a SV shop :-).
-- 
#			---Tom Adams---
# {bellcore,ihnp4}!sw1e!uusgta	St. Louis MO	314-235-4237
# Opinions expressed here are mine, not those of Southwestern Bell Telephone