hal@manta.mel.dit.csiro.au (Harold A. Miller) (12/20/90)
Hi there! I have a new friend with a 3b1, and am trying to get him uucp- connected through my site. I have some problems that maybe someone here could help with. My apologies if this has been discussed a bazillion times here, but as I've never needed to, I haven't been monitoring this group. I promise, though ..... (I have a Tektronix unix box myself, that I use as "control" testing. It *all* works fine on the Tek, including files that fail to the 3b1) The modem connection goes through an Annex server, to a Sun 3. I can get him in successfully on 'cu'. I can get him logged in on uucico. His machine transmits to mine just fine, uucp and/or mail. When it comes to master/slave turnaround, however, things seem to become randomly bad. Some files work fine (from the Sun to the 3b1), some fail, then go on a reconnection. Others *always* fail, regardless of what I've tried. They always succeed to the Tek box. Error seems to always be the same (bad header), at apparently the same packet (counting isn't always easy in the debug output of uucico). Once there is an error, the connection is effectively dead. The 3b1 times out on alarms (about 16 if I recall correctly). The Sun is sitting there wondering where the 3b1 went, and eventually times out. This only happens on Sun-to-3b1 traffic. All 3b1-to-Sun works, including the bidirectional protocol negotiation and acks. I keep thinking it might have something to do with flow control, but I haven't figured out where it could be failing, nor why it works on the Tek. Only other relevant point I can think of is it has an American 1200 baud internal modem, trying to talk to any of half a dozen different Australian modems. I don't think this is really relevant, as I've taken a pair of Australian ones, one at each end (external to the 3b1) and get the same errors. Could his uucico be corrupted? We reloaded his entire system from his original floppies, and got the same results. Any ideas? I'd like to get him on line. Thanks. HM -- -- |Hal Miller, DIT, CSIRO, | Networking Environments Project | |55 Barry St, Carlton, | (TEL) +61 3 347 8644 (FAX) +61 3 347 8987 | |VIC 3053, Australia | Internet:hal@mel.dit.csiro.au |
prg@mgweed.UUCP (Gunsul) (12/21/90)
In article <1990Dec20.042245.10942@mel.dit.csiro.au>, hal@manta.mel.dit.csiro.au (Harold A. Miller) writes: > > This only happens on Sun-to-3b1 traffic. All 3b1-to-Sun works, including > the bidirectional protocol negotiation and acks. I keep thinking it might > have something to do with flow control, but I haven't figured out where it > could be failing, nor why it works on the Tek. > > Thanks. > HM > -- > -- > |Hal Miller, DIT, CSIRO, | Networking Environments Project | > |55 Barry St, Carlton, | (TEL) +61 3 347 8644 (FAX) +61 3 347 8987 | > |VIC 3053, Australia | Internet:hal@mel.dit.csiro.au | > Xref: cbnewse unix-pc.general:5792 comp.sys.att:6677 Gosh Hal, this sure sounds strange.. I'm not a bit familiar with any of the Sun systems, but one thing popped into my mind when I read this -- could the problem be with using the same port for inbound and outbound traffic? I'm not sure if the Sun has something like "uugetty" for bi-directional uucp connections.. I've seen real strange things happen on 3B type machines prior to HDB that had a "getty" running on an "out-bound" port... -- AT&T | This space | (708)-859-4485 Phil Gunsul | intentionally | att!mgweed!prg Montgomery, IL | left blank.. | AT&T Information Systems
israel@mitisft.Convergent.COM (Paul Israel) (12/21/90)
What version of the software do you have? Are you using stock AT&T uucp or Honey-Danber? As I understand it, the uucp code was patched twice between AT&T 3.51 and 3.51m, so you may well be sitting on some buggy code. I'm currently running 3.51m, which I've used successfully in both directions with the internal modem. -- Paul Israel Renegade Systems, 434 South Bernardo Ave, #2 Sunnyvale, CA 94086 Disclaimer: "Who, me? I wasn't even there!" ctnews!mitisft!hamster!israel