To recap the problem, enabling hardware (rts/cts) flow control
in tip (by adding the hf capability) causes tip to fail with
"can't synchronize with hayes". Digging a little further it
appeared that hw flow control requires the presence of dcd
before tip can carry on a dialog with the modem, even using
cua0, whose purpose seems to be to allow a dialog in the absence
of dcd. This was on an ss2 and 4/490 running sunos4.1.[12].
What did I learn? First, I got it a little wrong; the problem
wasn't that the sun couldn't send to the modem, but rather that
anything the modem sent back was ignored by the sun. The most
depressing news was that this seems to be a problem with the
serial chip which sun uses; ie, don't expect a fix. If that
doesn't dampen your spirits, apparently hardware flow control
really only works in one direction; sun will stop output in
response to cts from the modem, but doesn't use rts to stop
output from the modem.
There were some suggestions.
The first was to use the cm capability to turn the modem's dcd
on, so tip can see modem result codes. Turns out if you're using
the modem as a dialup (du capability), the cm string is ignored,
but this trick could be useful if you want to directly connect
to the modem (eg, dial by hand atd5551212 or set up, say, a point
to point connection by hand).
The second suggestion was to have the modem keep dcd high, only
dropping it when carrier dropped. Our modem (telebit t2500)
has that option, but it doesn't seem to get along with the
sun in that mode. Using ~. to drop the connection seems
to put the modem and sun into states such that the next dialout
results a connection, but dtr is low. A ~. this time
doesn't cause a disconnect, since dtr is already low.
I've seen reference to a known sun dtr bug, but haven't
followed up on it yet.
The third suggestion was to give up and just match the tty
and transmission speeds (ie, use speed of last "at").
(This is tempting, just like the old days.)
Fourth suggestion was to give up on tip and look at cu.
(We intend to look at cu, no conclusions yet.)
Fifth suggestion is to hack tip.
(Tempting too.)
I wish I had a neat solution for you all, but it's not
a pretty sight.
Thanks to all who responded.
I'm appending excerpts from from some of the responses.
------------------
From: mikey@ccs.carleton.ca (Mike McFaul)
One thing here, are you absolutely sure that no characters make it to
the modem? I saw the same kind of behaviour when I was configuring my
modem. It turned out that the modem really was seeing the characters,
but 'tip' was not seeing them come back (as well as the responses). If
you watch the modem lights/leds carefully you could see the modem
echoing the commands and responding. It turned out that asserting
'carrier detect' solved the problem. The record in /etc/remote for my
USR courier v32.bis modem is as follows:
cub:dv=/dev/cub:br#38400:hf:nt:cm=ATE1&C0^M:di=ATE0&C1^M
Notice the 'cm' and 'di' strings, the cm string turns on 'echo' and
forces 'carrier detect' high. Once this happens everything looks
fine. The 'di' string turns off 'echo' and puts 'carrier detect' back
to normal (the modem and system are configured for in and out-bound
calls). Something interesting, if when I'm in tip and connected to the
modem in command mode I type 'AT&C1', tip will disconnect from the
modem.
------------------
From: wallen@cogsci.UCSD.EDU (Mark R. Wallen)
I think I ran into a similar problem with our
terminal server. My solution (as recommended by
Brian Kantor) was to have the modem assert DCD
all the time, except right after carrier loss,
when DCD is dropped momentarily. I think this is
a more or less standard option to the &C setting
------------------
From: guy@auspex.com (Guy Harris)
>We've run into what seems to be a bug in sun's handling of
>modem control (what's new).
No, you've run into a deficiency in the Zilog/AMD Z8530 SCC chip.
>This is in sunos4.1.1 on an ss2
>and a 4/490. It appears that enabling hw flow control disables
>cua0's ability to write out the port in the absence of dcd.
Yup. If you enable hardware flow control - which, of course, means
telling the Z8530 hardware to do RTS/CTS flow control; that's why it's
called *hardware* flow control - the Z8530 will disable its receiver if
DCD is not high, just as it disables its transmitter if CTS is not high.
Yup. What you want for dialout is *software* flow control using
modem-control lines. SunOS 4.x doesn't support that; SunOS 5.0 may, as
System V Release 4 at least purports to have an "ioctl" to enable
"bi-directional" modem-control-line flow control (where the host can
drop RTS to stop stuff from coming *in*, and the host watches to see if
CTS drops and, if it does, stops stuff going *out*).
------------------
From: arrent!root@uu.psi.com (Operator)
Suns have never really been any good at hardware flow
control. What I had to do was rebuild my kernal and
disable flow control on the Sun. I set the interface
to change to the interface speed of the modem.
------------------
From: jaf@inference.com (Jose A. Fernandez)
I too struggled with tip and XO{N,FF}. Eventually I concluded that TIP just
wasn't going to pass the XO{N,FF} through to the modem so I turned, instead,
to using cu and found several neat things about cu:
1. cu handles ALL modem speeds. You might have noticed that tip chokes
on Hayes return codes for connection speeds above 1200 baud; the Hayes
return codes are hardwired into tip and unless you can instruct your
modem to lie about its connection speed(s), tip will restrain your
best speed.
2. cu can pass through XO{N,FF}. Once the connection is established,
just hit "~%" (sans quotes) and at the cu prompt, enter "nostop" and
voila, XO{N,FF} go through smoothly.
3. cu uses a better file retrieval system than tip (except for the
fact that your remote shell has to be sh or sh-compatible).
------------------
>From caveh@csl.sri.com Tue Feb 25 16:23:26 1992
actually, it's the SUN which is deaf to input while CD is off.
what i have to say in the matter comes from first hand experience in
getting a USRobotics V.32bis (14,400 BAUD) modem hooked up to
sun3/60s. i think this applies to the ss2 since it uses the same serial
chip. it may also apply to the 4/490, but i don't the relevant specs
on it.
the main problem lies in the fact that the serial chip used by SUN
does not receive characters when CD is off. this means that when
you turn on hf, the serial chip is in essence deaf until your modem
connects to another modem. this creates a chicken-and-egg scenario
since you can't get your modem connected to another modem until you
dial out. i suppose you can send "blind" commands to your modem,
but that's another story.
i solved the problem by hacking tip. in essence, my tip does two
things differently. first, it disables CTSRTS while it is talking
to the modem (only) and then turns it on if /etc/remote requested
it after it gets the "CONNECT" string from the modem. i also use
the ascii response mode of the hayes modem such that you can
get strings from the modem like "CONNECT 14400/ARQ/V32/V42BIS"
or whatever it is. i like to know what features my modem
actually managed to negotiate with the other side! i also don't
enable auto-answer mode from tip. you might want to get the
BSD4.x version of tip and hack aculib/hayes.c into submission.
the reason you get "can't synch with hayes" is because tip doesn't
see the reply message from the modem and gets confused.
a word of warning. i pulled the hardware specs for the serial chip
SUN uses. this chip does not do the full cts/rts handshaking
for flow control that one would expect. it can only do flow
control in one direction (can't remember which). it does not
do flow control in the other direction... so even with cts/rts
enabled, you're not getting proper flow control. this is a hardware
limitation, independent of the software. motorola chips, like the
MC68681 "do the right thing".
btw, you also want the :nt: entry in /etc/remote.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:37 CDT