itkin@mrspoc.UUCP (Steven M. List) (11/01/88)
I've just connected up my two spanking new 'Blazers and am delighted, overall.
However I seem to have a small problem. When someone dials in interactively
to my dialin 'Blazer at PEP speeds, there is no problem. When someone dials
in interactively to the 'Blazer at 2400 baud, there also seems to be no
problem. When UUCP connects at PEP speeds, no problem. Now, the problem...
When UUCP connects at 2400 baud, it gets through sending the login ID and,
apparently, password, and then hangs. I don't really have the option of
making all my low speed connections come in on another number. Does anyone
have any suggestions? Here're are the register settings from my 'Blazer:
E0 F1 M1 Q1 P V1 X1 Version BA4.00
S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006
S10=007 S11=070 S12=050
S45=255 S47=004 S48=000 S49=000
S50=000 S51=004 S52=001 S53=002 S54=003 S55=003 S56=017 S57=019 S58=003 S59=000
S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=001 S67=001 S68=255
S90=000 S91=000 S92=001 S95=000
S100=000 S101=000 S102=000 S104=000
S110=255 S111=255 S112=001
S121=000
Thanks for any help you can offer.
--
: Steven List @ Transact Software, Inc.
: {coherent,mips,pyramid,satyr,ubvax,wesley}!mrspoc!itkin
: Voice: (415) 961-6112wtm@neoucom.UUCP (Bill Mayhew) (11/03/88)
In article <1889@mrspoc.UUCP>, itkin@mrspoc.UUCP (Steven M. List) writes:
+ .... When someone dials
+ in interactively to the 'Blazer at 2400 baud, there also seems to be no
+ problem. When UUCP connects at PEP speeds, no problem. Now, the problem...
+
+ When UUCP connects at 2400 baud, it gets through sending the login ID and,
+ apparently, password, and then hangs.
+
+ E0 F1 M1 Q1 P V1 X1 Version BA4.00
+ S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006
+ S10=007 S11=070 S12=050
+ S45=255 S47=004 S48=000 S49=000
+ S50=000 S51=004 S52=001 S53=002 S54=003 S55=003 S56=017 S57=019 S58=003 S59=000
+ S60=000 S61=045 S62=003 S63=001 S64=000 S65=000 S66=001 S67=001 S68=255
+ S90=000 S91=000 S92=001 S95=000
+ S100=000 S101=000 S102=000 S104=000
+ S110=255 S111=255 S112=001
+ S121=000
Here's what's happening:
The registers 58 and 68 control how the modem accoplishes hand shaking. In
PEP mode the handshaking is almost irrelevent to uucp, as the modem itself
controls the reception and generation of the g protocol packets between
ends. If the modem's buffer fills up, it only needs to not send any more
ACKs to the transmitting host until room becomes available in the buffer.
You can think of this as a passive software flow control.
In non-PEP mode, the intelligence of the spoofing software is not in
effect. If the receiving host beings to slip behind the transmitting end,
the modem may request flow control. The effect is disasterous, if the
selected flow control is an in-band data character, such as X-on/X-off or
ENQ/ACK. The flow control character generated by the modem will be passed
back to the sending host and bring the g protocol to a halt.
Register 58 has the following operating modes to control DTE-DCE hand shaking:
0 : don't use any hand shaking
1 : use the RTS / CTS leads (local host)
2 : full duplex host-host using RTS / CTS leads
3 : xon/xoff in-band data stream
4 : apply methods 2 & 3 simultaneously
5 : enq/ack hewlett-packard in-band data stream
6 : apply methods 3 & 5 simultaneously
Register 68 controls the DCE-DCE operating modes for hand shaking:
0-6 : meaning same as for register 58
1 : not relevent in this case ( not defined )
255 : use the same as specified in local modem'e register 58
Most people should probably use register 68 = 255. I can't think of a
reason for anything else at the moment, but I'm sure there is some weird
system that uses two different types of flow control on the same link.
Register 58 = 0 is a sort of 4th down punt solution. There will probably
be some situations where data gets lost, but the modem keeps its nose out
of the business, and hopefully, uucico can request a retransmission of any
packets that get garbaged. People that dail in might not like this
soltuion.
Register 58 = 1 is pretty good, if your CPU port supports hardware flow
control. Vax DZ ports don't under bsd4.2 with the garden variety tty
device drivers. This allows your end to initiate modem-modem flow control,
if the other end doesn't have flow control (PEP mode).
Register 58 = 2 would be ideal, as it allows the state of the RTS to be
passed directly to CTS on the opposite end and vice versa (if I read the
manual correctly). This in effect emulate a hardwire connection between
the two hosts. We use this between impulse and the neoucom mailserver
(both of which are 3b1 Unix PCs). This has resulted in an optimal transfer
rate of around 1200 char/sec for big files (100K+). I'm impressed. I'm
not sure what happens if you have S58=2, but some generic v.22 modem calls
you. Ideally, S58=1 would be a fall-back modality, but you could live with
S58=0 as a fallback in the case of uucico transfers. Anybody at Telebit
care to comment on this?
On the Unix PC, you can use /etc/hfc to ignore RTS/CTS toggles and pay
attention to xon/xoff. This is helpful for instances where your dial-in
has to be shared with dumb deivces like vt100s (which generate copious
quantities of xoff requests) at low baud rates. (See some of my previous
discussions).
--Bill