Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!teal.csn.org!dfishman From: dfishman@teal.csn.org (Dan Fishman) Subject: Re: remote lpr/lpd problems... Message-ID: <BxnsKC.C27@csn.org> Sender: news@csn.org (news) Nntp-Posting-Host: teal.csn.org Organization: Colorado SuperNet, Inc. X-Newsreader: Tin 1.1 PL4 References: <BxM76t.9Dw@unx.sas.com> Date: Fri, 13 Nov 1992 14:36:10 GMT Lines: 46 sastdr@torpid.unx.sas.com (Thomas David Rivers) writes: : : I'm having an interesting problem with the lpd on 386bsd. : : Namely, if I (from a remote lpr) print a small file, things work : fine. However, if I remotely print a large file the lpd on 386bsd : "looses the connection." : : Looking at the lpd sources, I see such a message emitted if a read : from the incoming socket returns <= 0; which is reasonable. (i.e. it : either got EOF sooner than expected or there was a problem.) : : The number of bytes read before this happens is *always* 5120; which is : a rather suspicious number. : : So, I was wondering if there is a limit somewhere I'm running into. I : couldn't find anything, but thought I would post and ask.. : : : - Thanks - : - Dave Rivers - : (rivers@ponds.uucp (home)) : (sastdr@unx.sas.com (work)) : : : -- : UPDATE ALL INFORMATION AND POD INTO COSMOS - Federal Express I'm not currently a 386BSD user but this could be a basic datacomm issue such as I have seen in a BSD4.2 port. If the printer is serial attached (RS232) then it may be doing BOTH a XON/XOFF flow control handshake and an DTR HI/LOW flow control handshake. DTR is the norm for DOS, XON/XOFF is the norm for most UNIX. The DTR handshake however may appear to the UNIX serial line driver as a lost line (lost modem control). If this is the issue, many (I don't know about 386BSD) drivers have a control (ioctl) to enable/disable modem control protocols (or possibly even use DTR as a standard handshake). Another solution is to modify a cable so as to preclude the DTR handshake from reaching the CPU side of the cable as any modem control signal. This would mean tying required modem control signals high or low as required for your serial IF/driver. OR NOT! It could be a more subtle networking problem since you specifically mentioned remote printing? Hope this helps. Dan Fishman (dfishman@csn.com)