kls@ditka.UUCP (Karl Swartz) (05/21/88)
I recently put a TrailBlazer on my 3B1 (UNIX PC) and now
I can't in a 1200 baud. I've got /etc/gettydefs set to
start with 19200, drop to 2400, then to 1200. The first
to work fine, but not 1200.
Swapping 1200 and 2400 makes 1200 work, but then 2400
won't work. It seems that it won't go to the third
choice, whichever it is.
Any ideas? BTW, this is running uugetty and HDB with
3.51a system software.
--
Karl Swartz |UUCP decvax!formtek!ditka!kls
1-412/937-4930 office | {pitt,psuvax1}!idis!formtek!ditka!kls
|BIX kswartz
"I never let my schooling get in the way of my education." (Twain)mag@astroatc.UUCP (Michael A. Goldsmith) (05/23/88)
In article <282@ditka.UUCP> kls@ditka.UUCP (Karl Swartz) writes: > >I recently put a TrailBlazer on my 3B1 (UNIX PC) and now >I can't in a 1200 baud. I've got /etc/gettydefs set to >start with 19200, drop to 2400, then to 1200. The first >to work fine, but not 1200. > >Swapping 1200 and 2400 makes 1200 work, but then 2400 >won't work. It seems that it won't go to the third >choice, whichever it is. > >Any ideas? BTW, this is running uugetty and HDB with >3.51a system software. > It is not necesasary to auto-baud at all with the Trailblazer. You can set a register (S66=1, I believe. My manual is at home.) that locks the serial line betweeen the modem and the 3B1 at 9600 or whatever you wish to use. When a call comes in, the modem negotiates baud rates with the calling modem and then communicates with the caller at that rate. The serial line remains at the locked-in rate. The same thing happens on an outgoing call. Thus, you can set up your /usr/lib/uucp/L* files to place all calls at 9600 (or whatever) and uucp will be unaware that the actual communication is taking place at a lower rate. BTW, you can also chose (check the manual, I don't remember which register) whether to use XON/XOFF or RS-232 handshake signals for flow control. Hope this helps. Michael A. Goldsmith - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Name: Michael A. Goldsmith UUCP: ... {seismo | harvard | ihnp4} !uwvax!astroatc!mag arpa: astroatc!mag@rsch.wisc.edu usmail: 5800 Cottage Gr. Rd. ;;; Madison WI 53716 phone: 608-221-9001 X117 The options expressed above are my own and do not necessarily reflect those of my employer.
wtm@neoucom.UUCP (Bill Mayhew) (05/25/88)
1. When using the trailblazer, the MNP protocol will occasionally get confused and think that a non-mnp modem is in fact MNP. This is not limited to the trailblazer; I've seen it on a US Robotics HST and an AT&T CEO 2224. I think it has to do with getty echoing back MNP characters back into the modem when it tries to establish a connection with a non-mnp moden on the end running getty. 2. As alluded to in a previous article I wrote, running UUCP at lower buad rate connects and the interface locked to 9600 (or 19200 if you dare on the 3b1) can result in the telebit sending back an xoff to the host. The uucp g-protocol will gag on the xoff. Make sure that the flow control is set to hardware on the 3b1, since the 3b1 tty driver handles either hardware or software handshaking. --Bill
ahby@bungia.Bungia.MN.ORG (Shane P. McCarron) (05/25/88)
In article <1030@astroatc.UUCP> mag@astroatc.UUCP (Michael A. Goldsmith) writes: >It is not necesasary to auto-baud at all with the Trailblazer. >You can set a register (S66=1, I believe. My manual is at home.) >that locks the serial line betweeen the modem and the 3B1 at >9600 or whatever you wish to use. When a call comes in, the modem >negotiates baud rates with the calling modem and then communicates >with the caller at that rate. The serial line remains at the >locked-in rate. This is true, but... If someone dials in at a lower speed (for instance, 1200 baud), you will have a problem. Let's assume that they dial in on a brain dead machine like the 3B1 (I have one, I know). The cu on the 3B1 cannot update the screen as fast as the data is coming in, so the ph0/ph1 driver attempts to send an X/Off to the remote machine with the trailblazer on it. The remote machine is (of course) not set up to use software flow control, since that really wouldn't work well for UUCP. Moreover, the remote trailblazer doesn't handle flow control from the calling machine anyway, and it continues to spit out data even though the calling machine can't take it. This causes a lot of garbage to appear on the screen, but nothing readable. >The same thing happens on an outgoing call. Thus, you can set up >your /usr/lib/uucp/L* files to place all calls at 9600 (or whatever) >and uucp will be unaware that the actual communication is taking >place at a lower rate. This is also true, but... If the remote machine is one which spits out its PEP tones last (e.g. uunet, most machines in MN, etc...) you need to send a special initialization sequence (S50=255) before dialing. That is difficult to do if you are using the (again) brain dead dialer on the 3B1. It doesn't use the device type code (ACU, DIR, whatever), but rather the speed and ttyline, to decide which definition in the L-devices file to use. That's great, but if you want to send special sequences when dialing out to certain sites, and they are all at the same baud rate, you are screwed. Of course, these problems may be unique to the 3B1 - I have certainly never encounted this particular form of brain damage anywhere else, but that doesn't mean it doesn't exist. If you do lock the speed, lock it at 19200 - you will get much better throughput. Also, define calling devices like TELEBIT and TELEBITFAST. The TELEBITFAST device can send the additional codes needed to make the modem communicate in PEP mode. Oh! One other thing - Be sure to set S55 to 3 on dial-in modems. It enables the machine that is dialing in to send a +++ and not take your modem off-line. In my dialing sequence to trailblazers that I know are set correctly, I have a sequence like: \d\d\d+++\d\d OK ats70?\r 18031 ato\r "" \n "" \d\d\d\d\n ogin: This assures me that (at least the initial) connection is as good as it can be. If you aren't getting full throughput, what is the point of talking to a trailblazer? Call it back, and the line may improve. Oops... Another thing :-) If you are using different dialing sequences when calling another trailblazer, you should be sure to set the flag that tells the modem to reset when DTR is dropped (S52=2). This way it will go back to the saved settings after the call is complete. >BTW, you can also chose (check the manual, I don't remember which register) >whether to use XON/XOFF or RS-232 handshake signals for flow control. S58 -- Shane P. McCarron UUCP: ahby@bungia.mn.org Systems Analyst ATT: +1 612 224-9239
piet@cwi.nl (Piet Beertema) (05/25/88)
>Oh! One other thing - Be sure to set S55 to 3 on dial-in modems. It >enables the machine that is dialing in to send a +++ and not take your >modem off-line. Arrgh! That explains a problem I've been having for some time and that Telebit couldn't explain either (telebit!modems, are you listening?): after a +++ escape sequence, I couldn't get the thing online again with ATO; only the sequence AT%O ATO would restore the connection, but for that to work I had to enable remote access on the dialin modem; not really acceptable. The explanation is that I had set S55=0 (the default value) on the dialin modem. I would have expected the modem to look for the +++ escape sequence *only* in data coming in via the RS232 port. But apparently it also recognizes +++ as such when it comes in via the line: that means the modems on *both* ends were taken offline by one escape sequence, and thus both of them needed an ATO command to go online again. This looks pretty much like a bug to me. Thanks for the hint! -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl)