home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / bsd / 8833 < prev    next >
Encoding:
Text File  |  1992-11-14  |  2.4 KB  |  60 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!teal.csn.org!dfishman
  3. From: dfishman@teal.csn.org (Dan Fishman)
  4. Subject: Re: remote lpr/lpd problems...
  5. Message-ID: <BxnsKC.C27@csn.org>
  6. Sender: news@csn.org (news)
  7. Nntp-Posting-Host: teal.csn.org
  8. Organization: Colorado SuperNet, Inc.
  9. X-Newsreader: Tin 1.1 PL4
  10. References: <BxM76t.9Dw@unx.sas.com>
  11. Date: Fri, 13 Nov 1992 14:36:10 GMT
  12. Lines: 46
  13.  
  14. sastdr@torpid.unx.sas.com (Thomas David Rivers) writes:
  15. : 
  16. : I'm having an interesting problem with the lpd on 386bsd.
  17. : 
  18. : Namely, if I (from a remote lpr) print a small file, things work
  19. : fine.  However, if I remotely print a large file the lpd on 386bsd
  20. : "looses the connection."
  21. : 
  22. : Looking at the lpd sources, I see such a message emitted if a read
  23. : from the incoming socket returns <= 0; which is reasonable. (i.e. it
  24. : either got EOF sooner than expected or there was a problem.)
  25. : 
  26. : The number of bytes read before this happens is *always* 5120; which is
  27. : a rather suspicious number.
  28. : 
  29. : So, I was wondering if there is a limit somewhere I'm running into.  I
  30. : couldn't find anything, but thought I would post and ask..
  31. : 
  32. : 
  33. :     - Thanks -
  34. :     - Dave Rivers -
  35. :     (rivers@ponds.uucp (home))
  36. :     (sastdr@unx.sas.com (work))
  37. : 
  38. : 
  39. : -- 
  40. : UPDATE ALL INFORMATION AND POD INTO COSMOS - Federal Express
  41.  
  42. I'm not currently a 386BSD user but this could be a basic datacomm issue
  43. such as I have seen in a BSD4.2 port.  If the printer is serial attached
  44. (RS232) then it may be doing BOTH a XON/XOFF flow control handshake and
  45. an DTR HI/LOW flow control handshake.  DTR is the norm for DOS, XON/XOFF
  46. is the norm for most UNIX.   The DTR handshake however may appear to the
  47. UNIX serial line driver as a lost line (lost modem control).  
  48.  
  49. If this is the issue, many (I don't know about 386BSD) drivers have a control 
  50. (ioctl) to enable/disable modem control protocols (or possibly even use DTR as
  51. a standard handshake).  Another solution is to modify a cable so as to
  52. preclude the DTR handshake from reaching the CPU side of the cable as any
  53. modem control signal.  This would mean tying required modem control signals
  54. high or low as required for your serial IF/driver.
  55.  
  56. OR NOT!  It could be a more subtle networking problem since you specifically
  57. mentioned remote printing?  Hope this helps.
  58.  
  59. Dan  Fishman (dfishman@csn.com)
  60.