home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / sys5 / r4 / 1117 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  1.9 KB
  1. Xref: sparky comp.unix.sys5.r4:1117 comp.dcom.modems:18870
  2. Path: sparky!uunet!mcsun!sun4nl!tuegate.tue.nl!svin09!wsinis07!debra
  3. From: debra@wsinis07.info.win.tue.nl (Paul De Bra)
  4. Newsgroups: comp.unix.sys5.r4,comp.dcom.modems
  5. Subject: Re: uucp woes
  6. Keywords: uucp esix worldblazer sas
  7. Message-ID: <4890@svin09.info.win.tue.nl>
  8. Date: 4 Jan 93 09:30:00 GMT
  9. References: <1993Jan01.191128.4566@wisdom.bubble.org> <1993Jan4.081829.17615@netcom.com>
  10. Sender: news@svin09.info.win.tue.nl
  11. Reply-To: debra@info.win.tue.nl
  12. Followup-To: comp.unix.sys5.r4
  13. Organization: Eindhoven University of Technology, the Netherlands
  14. Lines: 28
  15.  
  16. In article <1993Jan4.081829.17615@netcom.com> gerg@netcom.com (Greg Andrews) writes:
  17. >
  18. >Jeff, what other conclusion can be drawn?  Your analyzer trace showed
  19. >the bytes that the WorldBlazer and your ESIX system exchanged.  It logged
  20. >everything the WB sent to the computer.  That trace showed a perfect
  21. >transfer up to the failure point.  Suddenly, the ESIX uucico started 
  22. >rejecting a packet from the WB.  Examination of that packet shows:
  23. >...
  24.  
  25. This happened to me before, with different versions of Unix (different
  26. vendors, different hardware, etc), but all running some variety of HDB
  27. uucp as with sVr3.2 and sVr4.
  28.  
  29. I normally have no problem with uucp transfers (using hardwired lines locked
  30. at 38.4k or with a T2500 at 19.2k), but once in a while i find a file that
  31. won't transmit *ever*. No matter what i do, like even slowing down to a
  32. crawling 300baud, the file will never be accepted by uucp.
  33. I have tried retransmissions after some other files, but no go.
  34. The only way to transfer such a problem file is to change it (like uuencode).
  35. I would say there is a hidden bug somewhere in HDB uucp (not having source
  36. code i can't say for sure of course) that consistently refuses some
  37. bit-pattern.
  38.  
  39. Since i have encountered this problem a few times (happens about once
  40. every two years or so over the last 5 or six years) maybe others have too.
  41.  
  42. Paul.
  43. (debra@win.tue.nl)
  44.