dplatt@coherent.uucp (Dave Platt) (01/30/88)
The following is a message I mailed to telebit!mike last week concerning
my experiences in connecting a TrailBlazer Plus to our Sun file/news
server. My experiences may prove useful to other people who are
attempting to establish similar connections. Updates at the end...
--- begin letter --
1/22/88
I spent all of yesterday attempting to establish a viable Sun/Trailblazer
marriage. At this point, I can report partial success (PEP connections
to uunet are stunningly effective), great frustration, and some specific
recommendations for simple enhancements to the TrailBlazer that would
greatly ease this sort of task.
Background: we have a Sun 3/280 system, which (like almost all Sun
systems) does not support CTS flow-control on its serial ports.
[May legions of stinging ants infest the jockey shorts of the engineers
and managers who promulgate this revolting design philosophy!]. Our
neighbors (sun, ames, ibuki, and uunet) run a mixed bag of modems:
- ibuki is 1200-baud only
- sun has a TrailBlazer configured with S92=0 [normal answering sequence]
and a V.22bis-baud modem.
- ames has a TrailBlazer configured with S92=1 [reverse answering
sequence, with PEP tones after V.22/212 tones], a V.22bis (U.S. Rotobics)
and a rotor full of 212s.
- uunet has a rotor of TrailBlazers configured with S92=1.
The faster modems at sun and ames are frequently busy, and so we'd like
to fall back and use the slower ones when necessary. Naturally, we want
the 'Blazer-to-'Blazer connections to use PEP even if the receiving modem
has S92=1. I was able to achieve the latter by burying an S50=255
in the 'Blazer dialing sequences; the modem resets to S50=0 when DTR
is dropped at the end of a connection.
Specific problems encountered so far:
1) We'd really prefer to leave our DTE-to-'Blazer connection set to 9600
baud (can't use 19200 'cause Sun UUCP doesn't recognize it... grrr.)
Unfortunately, we run into flow-control problems when the 'Blazer
connects to a V.22bis or 212. The Sun doesn't honor CTS flow control,
and we cannot use XON/XOFF or ENQ/ACK flow control under UUCP (which
is an 8-bit, transparent-link protocol). The net result is that locking
the DTE speed to 9600 baud causes UUCP conversations to fail.
This is rather embarrassing... I had assumed that the 'Blazer would be
capable of buffering up three full uucp packets, and wouldn't have
to drop CTS. The U.S. Robotics 2400e is quite capable of doing this,
and we had successfully run uucp at 1200 and 2400 baud with the DTE
link locked at 4800 baud. I spoke with Bob Boynton (Telebit tech.
support) yesterday afternoon, and he informed me that the 'Blazer
deliberately limits its buffering to 30 bytes when in emulation
mode.
** Recommendation #1: increase the amount of buffering done in emulation
mode to at least 256 bytes. Perhaps the amount of buffering done
should depend on the S111 (async protocol support) setting: 256
bytes for uucp, and at least 1024 for xmodem/ymodem and Kermit.
This would greatly improve the 'Blazer's ability to arbitrate
between a dumb, high-speed DTE link and a lower-speed remote modem.
2) Next, I tried unlocking the DTE link, and running it at the speed
of the remote modem. This leads to difficulties also, because the
'Blazer requires more autobauding than the standard Hayes "AT"
sequence.
Our uucp is rather dumb, and doesn't support chat scripts or other
intelligent/programmable sequences during modem initialization (e.g.
HoneyDanBer uucp's modemcap file). I was able to patch uucico, changing
the standard uucico modem-initialization string ("ATQ1E0V0...") into
a magic cookie that I thought would autobaud the 'Blazer [and believe
me, patching a stripped uucico binary with adb is no fun!]. I tried a
magic cookie of "AAAAAAAAAAAAAAT<cr>", which works at 9600 baud and at
1200 baud but doesn't seem to work at 2400 baud. I then tried a cookie
consisting of a mix of "A" and 0xFF bytes, in the hope that the 0xFF
bytes would look like "mark" signals (pauses between characters).
This was partially successful; the modified cookie works at 9600 and
2400 baud, but not at 1200 baud. Sigh.
** Recommendation #2: publish the content of an autobaud string that can
be sent to the modem ->at any line speed, and with no pauses between
characters<-, and will successfully autobaud the modem at any of the
speeds that the 'Blazer supports. If no such string exists, then either
modify the autobauder to implement one, or publish the requirement
for inter-character pauses in the documentation.
3) The next difficulty involves result codes. When our uucp dials out at
2400 baud, it looks at the result code returned from the modem to
determine whether it should "roll back" the DTE connection to 1200
baud; this occurs if the remote modem is a 212, rather than a
V22.bis. There's a problem, though. If we configure the 'Blazer
with ATX1 (return extended result codes) so that it will return
a speed-specific result code, then the 'Blazer also insists on
sending a non-standard code 52 (RRING), which our uucp doesn't
understand and declares to be an "UNKNOWN DIALER ERROR" that
terminates the connection attempt. If we configure with ATX0 (basic
result codes only), then the 'Blazer returns a result code of 1 for
both 1200- and 2400-baud connections, and our uucp incorrectly attempts
to roll back to 1200 baud even if the remote modem is a V.22bis.
This is another area in which the U.S. Robotics 2400 modem is distinctly
friendlier than the 'Blazer. It provides several ATX modes in which
extended call-completion result codes are returned, while the "RINGING"
code (11) is suppressed.
At this point, we're running with ATX1, and accepting the fact that about
50% of our 2400-baud connection attempts are being aborted due to an
"UNKNOWN DIALER ERROR" when the 'Blazer reports the RRING code 52.
** Recomendation #3: implement an ATX4 (or some other number) mode in which
codes 0-50 are enabled, and 52 is suppressed. Or, implement additional
partial-quiet modes that selectively suppress code 52.
Our current status is that 9600-baud PEP connections seem to work
perfectly; V.22bis connections work erratically, depending on whether
the modem sends a code-52 response or not; 212 connections work properly,
although we actually issue the dialing sequence at 2400 baud and then
roll back to 1200 when the modem connects, because I haven't been able
to find a magic cookie that will autobaud the 'Blazer at both 1200
and 2400 baud.
At this point, any one of three enhancements would enable us to run
reliably at all three speeds:
- If we could use CTS flow-control, we could lock the DTE speed to 9600
baud and not lose data. We could use ATX0 (basic result codes) without
problems, because our uucp doesn't attempt rollback when connections
are dialed at 9600 baud.
- If the 'Blazer was capable of buffering 3 uucp packets in V.22bis/212
emulation modes without dropping CTS, then we could lock DTE to 9600
and not lose data.
- If the 'Blazer was capable of returning an extended result code when
a connection was established, but could be prevented from politely
sending code 52 (RRING) during a call, then we could dial both
V.22bis and 212 calls at 2400 baud, and fall back to 1200 baud in
the latter case.
Mike... is there any chance that either a larger emulation-mode buffer,
or an improved extended-result-code mode could be implemented, kluged,
or patched into our modem? If necessary I'd be glad to drive our modem
down to your shop for a PROM replacement.
At this point, I'm considering reinstalling our U.S. Robotics 2400e modem
on a second serial port, and using it for all of our V.22bis and 212
calls... it seems to be somewhat better suited to medium-speed use at
this time. Doing so would require that I move a hardwired 9600-baud
link to our neighbor "aimt" to another machine; this would be a major
pain in the butt.
Summary: the 'Blazer is a very impressive product, with a price that's
hard to beat (at the USENET discount rate, at least). It still has a few
rough edges that make it a trifle difficult to adapt to dumb hardware and
software (e.g. Sun serial ports and obsolete uucp code).
[Late flash... Chuq just called to inform me that hardware flow control
will be implemented in SunOS 4.0. This would resolve most of our
problems, if it actually works... there's some reason to believe that
Sun's new ALM (an 8-port serial expander) was designed without
CTS support in hardware... in which case the operating-system change will
do no good whatsoever for ALM ports.]
Thanks for reading and considering this.
--- end of letter ---
Mike responded to my letter by sending me a small patch to Sun's uucico
that eliminates the 4800-baud speed table entry and replaces it with
a 19200-baud entry. I haven't tried this yet, but will probably do
so next week; this should pep up our netnews connections to uunet and
ames by 10-20%. Mike has not yet responded to my questions about
changes to the emulation-mode buffering scheme or the result-code
selections.
I haven't reinstalled our U.S. Robotics 2400e for use at 1200 and
2400 baud; I'll probably do so once Sun deigns to ship us SunOS 3.5
so that we can install our ALM, which will have plenty of spare ports.
All in all, I'm very glad that we decided to spring for a 'Blazer.
The frustrations s I've experienced in the Sun/'Blazer marriage
aren't enough to detract significantly from the wonder of seeing a
cross-country uucp connection delivering news at 9600 baud with
no pauses! Our uunet connection time has been cut down from over
two hours per night (via Tymnet) to an average of about 20 minutes;
even given the higher $/hour rate for the uunet 800 number, the
switchover will probably save us almost 50% in our uunet hourly charges.
The modem should thus pay for itself within six months.
Nice work, Telebit! And, with a a little bit of additional polishing,
you'll have an incredible gem indeed.
--
Dave Platt
UUCP: ...!{ames,sun,uunet}!coherent!dplatt
Internet: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.netgrr@cbmvax.UUCP (George Robbins) (01/31/88)
In article <218@coherent.uucp> dplatt@coherent.uucp (Dave Platt) writes: > > I spent all of yesterday attempting to establish a viable Sun/Trailblazer > marriage. At this point, I can report partial success (PEP connections > to uunet are stunningly effective), great frustration, and some specific > recommendations for simple enhancements to the TrailBlazer that would > greatly ease this sort of task. I've been doing pretty much the same work with trying to get the telebit modems to work nicely with ultrix. Here are a few of my observations / comments on your message. 1) The Telebit autobauding has got to be improved! At high speeds, it seems like it needs to "think" about the "A" in the AT sequence and just blasting an "ATxxx" at it at 9600/19200 baud doesn't do any good. Ultrix uucico sends a a series of pre-dial stuff with sleeps in between - +++ ATH ATZ +++ ATDT... - so I was able to patch the second, generally redundant, +++ to send a single "A", which worked pretty well. 2) The S50/S92 mode arbitration seems to be a catch 22. If the remote site (like uunet) has S92 set to 1 to minimize problems with incoming calls from slow modems, the only way to establish a PEP session is for me to put an "ATS50=255" in the dialing sequence somewhere. Unforturnatly, Ultrix likes to translate = to some other character! So, I kludged the +++ stuff above to send +++ ATZ A ATS50=255 ATDT (the ATS50 has to be separate so that our USR modems don't toss the entire dial string), but now if I use the Telebit to call a dumb modem, it tries to get a PEP connection and reports no carrier! 3) Telebit could/should fix this in two ways - a) let S50=254 mean "set transmission mode appropriate to selected or auto-bauded interface data rate" b) let S50=255 mean "try to establish PEP call, but fall back if dumb modem on the far end". I don't see why both of these couldn't be done. In fact it's kind of hard to believe S50=255 doesn't work as in (b), so I'll have to try it again. 4) It's fairly easy to fix the "uucp doesn't support 19200 baud" problem. If your uucp isn't stripped, it's a table of ints (longs) called spds set up as pairs of baud/stty codes, so pick on you don't like and change it to 19200/14 (decimal please). If your uucp is stripped, the table is right near the beginng of the data section, so you can use $m to find where the data section begins, then just page thru with ?d until you see a sequnece of 50...75...110...200...300 numbers. 5) Make sure your inteface a) supports 19200 baud hardware wise, and b) doesn't loose skillions of incoming character at high baud rates. For example, DEC DZ11's don't support 19200 baud. There are lots of systems that will choke on 19200 incoming, especially under heavily loaded conditions or when some other bottleneck is invoked, perhaps during disk dma or some poorly implemented kernal sequence with interrupts disabled. 6) I was kind of suprised by the relative lack of user friendly/flex dialing stuff in the command set as compared to my 2-year old USR Courier 2400 modems. Still, given a choice, I guess I'd rather have the ROM's full of high-speed / performance code than friendlies. 7) The setups that Rick Adams posted a while ago are hopelessy optimistic. Many versions of uucp available to the non-source licensed crowd dont't support any hayes auto-dial or if they do, don't include the provisions for putting dialer commands in the L-devices file. In thise case, the only recourse is to set up the line as a direct connection "DIR" and put the dialing commands in the send/expect script. Many uucp's even lack the \r and \d escapes for sending return and delays, making life even more difficult. If your uucp doesn't support \c, it's adb time. 9) Here is some info on how to setup uucp connections with a Trailblazer or other "Hayes" type modem when you are blessed with a "stupid uucp": It assumes that you have "modem control" on the port your modem is connected to and that the modem is set up to "Hangup" and hopefully "Reset Parameters" when DTR is dropped. If you don't have this degree of modem control you're playing a dangerous (phone bill) game without built-in Hayes support to send the +++ ATH commands to terminate calls. The resulting L.sys file is going to look remakably ugly, but as long as it works, who cares. You can embelish on the script, but it's best to stick to the simplest script that works reliably. Trying to be fancy will just make it harder to get working and more fragile when it comes to different modems or funny connection behaviour on the far end. Here is a typical L-devices entry: (check your uucp documentation) DIR ttyd0 0 19200 Here is a typical "stupid uucp" L.sys sequence: fishvax Any,15 ttyd0 19200 ttyd0 <dialing stuff> <auto-baud/break stuff> <login> the autobaud/break stuff and login stuff are no different from the usual brain pain, so I'll just list a typical dialing sequence vertically: "" A\c expect nothing/anything, send "A" with no carriage return. "" \c "" \c expect nothing/anything, send nothing - a kludgy way to get a delay if your uucp doesn't support \d. If it does, just put a \d in the above sequence. Repeat as needed to generate enough delay. If this doesn't work try 'foo-\c-""' which should mean expect foo, timeout many seconds, send nothing, expect nothing/anything. "" ATS50=255DT19995551212^M\c Expect nothing/anything, send dial command / carriage return. Note that the ^M represents a control/M literally inserted in the file via ^v^m in via or thru clever use of "tr" if you can't get an editor to handle the task - use \r it if works!!! CONNECT Expect CONNECT, otherwise timeout and abort the call. At this point, your fall into your "normal" send/expect sequences needed for any auto-bauding on the remote system, followed by the send/expect sequences for the login/password. Use the hints for ^M and delay generation as needed to meet any perverse autobauding requirements. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
chris@mimsy.UUCP (Chris Torek) (01/31/88)
Incidentally, we worked around the `SunOS uucp is too stupid to do chat scripts' problem on the one machine that (for various reasons) cannot run 4.3BSD UUCP by marking the line `hardwired' and setting the login sequence to start with A\dA\dA\dT\r\c OK ATS255=1X0\r\c OK ... This is, of course, the wrong way to do it, and is painful to use if you have more than one modem; it does, however, work. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
dplatt@coherent.uucp (Dave Platt) (02/02/88)
After some a couple of days of fiddling around, trying options, and
muttering arcane curses directed at both hardware and software, I've
managed to establish a successful and reliable marriage between our
new TrailBlazer Plus modem and our Sun 3/280 file-server. We're now
using the 'Blazer for uucp dialout into other 'Blazer modems as well
as into V.22bis (2400-baud) and 212 (1200-baud) modems, and are also
answering calls from another 'Blazer at Ames. I'm posting a short summary
of our configuration for the benefit of others who may be establishing
similar hookups.
First issue: we wanted to lock the modem-to-host communication link to
19200 baud in order to achieve maximum throughput. Unfortunately,
Sun's obsolete uucp software does not recognize 19200 as a valid
speed. telebit!mike forwarded to me the instructions for patching
uucico to establish a 19200-baud speed (the 4800-baud speed is
sacrificed to make this possible); here's what must be done:
------------------------------------------
Date: Thu, 6 Aug 87 17:24:46 PDT
From: gnu (John Gilmore)
Message-Id: <8708070024.AA28084@hoptoad.uucp>
To: sun!mclinger
Subject: SunOS 3.3 uucp patch to support 19200 baud
This patch to /usr/lib/uucp/uucico allows it to parse '19200' as a
valid speed for dialing out (in L.sys and L-devices). There is a table
which consists of pairs of ints, e.g. 9600 and B9600 (13). This patch
replaces the entry for 4800, B4800 (12) with 19200, B19200 (14). Be
sure to check the permissions and ownerships of uucico and restore them
after patching.
To locate the 4800 baud entry, you can do:
adb -w /usr/lib/uucp/uucico
20000?L 0t4800
This should display an address. On hoptoad (68020 version) this address
is 20A0C. To display that table entry, you can do:
?DD
it should say:
xxxxxx: 4800 12
to patch it,
?W 0t19200 0t14
Don't forget the 0t's, which say these numbers are in decimal.
You're done, type ^D and try it.
------------------------------------------
The SunOS 3.3 patch that John suggests works fine on SunOS 3.4 as well.
With this patch in place, the 'Blazer's DTE can be locked to 19200
baud for both incoming and outgoing calls (S51=254, S66=1). In order to
accept incoming calls at 19200 baud, it's necessary to add a new entry
to /etc/gettytab (I called it "T") and to modify the ttyd0 (or whichever)
entry in /etc/ttys to read "1T". It's also necessary to set the Sun
kernel's configuration flags for the port to the "require hardware
carrier detect" position, and to configure the modem with S53=1
so that the hardware carrier-detect signal is sent to the Sun only
when carrier is actually received from the remote modem.
For security reasons, we decided to prevent the 'Blazer from answering
calls in other than PEP mode, so that "crackers" with 300/1200/2400-baud
modems could not attempt to log into our system. This was done by
setting S50=255.
In order to ensure that the modem reset itself to a stable configuration
between calls, we set S52=2; when the Sun drops DTR at the end of each
call, the modem hangs up (if it hasn't done so already) and resets itself
to the configuration stored in nonvolatile memory.
Because we've set the modem's default configuration to "PEP mode only",
we must arrange to re-enable automatic speed detection when we dial
a V.22bis or 212 modem. We do this by burying the appropriate S50
command in the dialing sequence in the L.sys file; it's an ugly hack,
but it does work. For example, one such sequence looks like:
ibuki Any,9 ACUHAYES 19200 5551212;S50=0;d "" \d\r\c in:-""-ogin: foobar
We've stored X0 in the modem's default configuration, so that the modem
does not send a "52" response (RRING) to the host when it dials a number
and hears the phone ring; code 52 completely confuses uucp and causes
calls to be terminated with an UNKNOWN DIALER ERROR message. Unfortunately,
setting X0 also causes "no dial tone" and "busy" to be reported to the
host as a "no carrier" situation, thus making it a bit more difficult to
determine why a call wasn't completed; this is an annoyance rather than
a real problem.
The biggest difficulty I had in getting this configuration to work
properly was getting flow control to work properly. Quite simply,
Sun hardware and software currently does not support hardware (CTS)
flow control; software flow control (XON/XOFF or ENQ/ACK) is useless
during uucp connections. This wasn't a problem when our 'Blazer called
another 'Blazer in PEP mode, because the modems' use of g-protocol
spoofing implements all of the necessary flow control at the uucp-packet
level. We did have severe problems when our 'Blazer phoned a 1200- or
2400-baud modem; our uucp would try to send 3 packets at 19200 baud,
the 'Blazer would drop CTS partway through the first packet, the Sun
wouldn't stop sending the packet, and the 'Blazer dropped the unwanted
bytes on the floor. At a result, we never managed to send a single
intact packet, and the connection would time out.
After many hours of frustration, and a very helpful suggestion by
rick@seismo, I achieved a working interface by a very simple trick:
I turned flow control OFF at the modem (S58=0, S67=0, S68=0). It turns
out that the TrailBlazer is quite capable of buffering up 3 uucp packets'
worth of data when operating in emulation mode... but it will only do so
if flow control is disabled. If flow control is enabled, the 'Blazer
refuses to buffer up more than about 30 bytes of data before it drops
CTS, and once it has dropped CTS it apparently refuses to accept more
data. This is one detail that isn't documented in the TrailBlazer manual;
it should be, I think.
For the last few days, our 'Blazer has been talking quite happily with
at least three other 'Blazers, a V.22bis, and several 212s. It's
very impressive to watch news articles come flowing across the country
from uunet at >9600 baud; we can now receive a standard compressed batch
of news in about one minute. With today's uunet rates, I believe that
the TrailBlazer will pay for itself within six months; it's cutting our
per-day newsfeed cost from uunet by almost 50%.
This is one amazing piece of hardware/firmware; the folks at Telebit
are to be commended for their design and implementation. There are
still a couple of rough spots in the interface (easier autobauding,
and an X mode that would enable extended result codes but suppress
RRING would be useful), but all in all it's really a fantastic piece
of work. Thanks, y'all at Telebit!
--
Dave Platt
UUCP: ...!{ames,sun,uunet}!coherent!dplatt
Internet: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.netgrr@cbmvax.UUCP (George Robbins) (02/02/88)
In article <272@coherent.uucp> dplatt@coherent.uucp (Dave Platt) writes: > > Because we've set the modem's default configuration to "PEP mode only", > we must arrange to re-enable automatic speed detection when we dial > a V.22bis or 212 modem. We do this by burying the appropriate S50 > command in the dialing sequence in the L.sys file; it's an ugly hack, > but it does work. For example, one such sequence looks like: > > ibuki Any,9 ACUHAYES 19200 5551212;S50=0;d "" \d\r\c in:-""-ogin: foobar Does this really work? I tried using the semicolon after the number and thought it dialed, answered and stayed the command mode, in other words it was too late... What worked for me was to user the L-dialcodes to hide the dirty stuff. In my L.sys file have have ACU 19200 PEP5551212 .... and in the dialcodes file (this is really gross) PEP ^H^HS50=255S53=0DT Note those ^H's are real live backspaces which are used to "erase" the DT part of the ATDT the dialer code sends to the modem. Works good and keeps most of the scum out of the L.sys file. WARNING: Ultrix UUCP translates ='s in the "phone" number to commas, apparently as an attempt to provide a dialer independent "pause" capability. Easily patched, but kind of an obstacle for the innocent. I've recently gotten Ultrix "shared modem" dial-in/out support to work with the Trailblazer, on a DMF-32 no less! The trick is to have the default configuration have S53=2 so that the modem doesn't assert DSR in command mode, which would make getty think that there is a call in progress and refuse to give up the line. The various +++ATHATZ stuff the dialer code does is dialed "blind", since the interface is hard-wired to ignore incoming data without carrier detect. However in the middle of the dialing sequence, the S53=0 switches to carrier and DSR on so the dialer code can see the "CONNECT". The remaining problem is that the modem doesn't seem real eager to re-autobaud once it's decided on the transmission rate. Dropping DTR seems to make it more receptive, however when the modem is passed from the "dial-in" mode in getty to "dial-out" mode in uucp, carrier doesn't seem to get dropped. Maybe I should try the "fixed interface speed", but I thought standard hayes type autobauding seemed more reasonable. Maybe I'll try a biggie object patch to drop/raise DTR. One might wonder why I'm messing with the built in "hayes" dialer code in Ultrix instead of the "hayesq" or generic dialer support. I guess it's just a matter of building on what works... I've tried hacking the generic dialer support a couple of times and can't seem to get it to do the same thing on two successive calls. 8-( BTW, anybody have any ideas on what's a good cheap interface to support the Trailblazer on a Vax? The DMF32 has a little baby FIFO that suggests I don't want to share an interface with incoming 19200 baud lines with users typing or laser printers with X-ON/X-OFF flow control. I just got a DHU11 to replace the old DZ clone for general dialup support, but the defectoid thing has a screwed up architecture that limits output data rate to 9600 bps. I wonder if there's any legit way to enable the "hardware" X-on/X-off support on the DMF32? -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
dplatt@coherent.uucp (Dave Platt) (02/04/88)
In article <3238@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > > 2) The S50/S92 mode arbitration seems to be a catch 22. If the remote > site (like uunet) has S92 set to 1 to minimize problems with incoming > calls from slow modems, the only way to establish a PEP session is > for me to put an "ATS50=255" in the dialing sequence somewhere. > Unforturnatly, Ultrix likes to translate = to some other character! > So, I kludged the +++ stuff above to send +++ ATZ A ATS50=255 ATDT > (the ATS50 has to be separate so that our USR modems don't toss > the entire dial string), but now if I use the Telebit to call a > dumb modem, it tries to get a PEP connection and reports no carrier! > > 3) Telebit could/should fix this in two ways - a) let S50=254 mean > "set transmission mode appropriate to selected or auto-bauded > interface data rate" b) let S50=255 mean "try to establish PEP call, > but fall back if dumb modem on the far end". I don't see why both > of these couldn't be done. In fact it's kind of hard to believe > S50=255 doesn't work as in (b), so I'll have to try it again. I'm afraid that S50/S92 is, indeed, a Catch 22 situation, especially if you cannot embed an S50=xxx command in your dialing string. Putting S50=255 in your modem-init string, as you appear to have done, will certainly cause you problems when you call "dumb" modems, because the 'Blazer will ignore 212/V.22bis answer tones. Ultrix's habit of translating "=" to a "pause" is a big misfeature, and deserves to be disabled. I'm afraid that your suggestion in 3(b) may be impossible to implement. There are three basic classes of modems that you may wish to call: a) 'Blazers set with S92=0. b) 'Blazers set with S92=1. c) Slower (103/212/V.22bis) modems. If you're calling modems in classes (a) or (c), you can set S50=0 and establish connections with no problem. As you've pointed out, calling a modem in class (b) is the problem... your 'Blazer must be set to ignore the 212/V.22bis answer tone at the beginning of the sequence, and wait until it hears the PEP answer-scream. Unfortunately, it may not be possible for a single 'Blazer setting to call modems in all three of these classes. The real problem comes when you dial a slower (non-PEP) modem. If you wait long enough to see whether the modem you've called is a 'Blazer with S92=1 (i.e. you ignore the first 20-30 seconds of 212/V.22bis/V.22 answer signal), then a real 212/V.22bis modem will probably decide that it has been answering for long enough, and will hang up the phone! As I recall, 212/V.22bis modems tend to send only about 20 seconds of answer signal before timing out... they typically won't remain off-hook long enough for a 'Blazer to wait 30-40 seconds for a PEP answer and then attempt to fall back. With respect to your suggestion in (3a): I'd agree that a "set connection mode based on selected interface speed" mode could be useful, but I'd rather see it assigned to a number other than S50=254; I find S50=254 to be very useful as is. Also, in order to make use of this mode in practice, the TrailBlazer's autobauding capability would need to be made much more reliable... I haven't yet found an autobaud sequence that can works reliably at all necessary speeds (1200, 2400, 19200) when blasted at the modem at full connection speed. Rumor has it that Sun is considering porting HoneyDanBer uucp to their systems... if this is true, then it will become much easier for us to write successful-autobaud modem-init sequences. -- Dave Platt UUCP: ...!{ames,sun,uunet}!coherent!dplatt Internet: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net
ken@jose.UUCP (Ken MacLeod) (02/13/88)
The following patch also works on 'uucico' and 'cu' on the
NCR Tower 32/600. The 'uucico' patch was found at 0x13eb2 on my
system. The 'cu' patch was found at 0x2160 for '4800' and 0x21b0
for '12'. We also run our system locked at 19200.
In article <272@coherent.uucp>, dplatt@coherent.uucp (Dave Platt) writes:
< After some a couple of days of fiddling around, trying options, and
< muttering arcane curses directed at both hardware and software, I've
< managed to establish a successful and reliable marriage between our
< new TrailBlazer Plus modem and our Sun 3/280 file-server. We're now
< using the 'Blazer for uucp dialout into other 'Blazer modems as well
< as into V.22bis (2400-baud) and 212 (1200-baud) modems, and are also
< answering calls from another 'Blazer at Ames. I'm posting a short summary
< of our configuration for the benefit of others who may be establishing
< similar hookups.
<
< First issue: we wanted to lock the modem-to-host communication link to
< 19200 baud in order to achieve maximum throughput. Unfortunately,
< Sun's obsolete uucp software does not recognize 19200 as a valid
< speed. telebit!mike forwarded to me the instructions for patching
< uucico to establish a 19200-baud speed (the 4800-baud speed is
< sacrificed to make this possible); here's what must be done:
<
< ------------------------------------------
<
< Date: Thu, 6 Aug 87 17:24:46 PDT
< From: gnu (John Gilmore)
< Message-Id: <8708070024.AA28084@hoptoad.uucp>
< To: sun!mclinger
< Subject: SunOS 3.3 uucp patch to support 19200 baud
<
< This patch to /usr/lib/uucp/uucico allows it to parse '19200' as a
< valid speed for dialing out (in L.sys and L-devices). There is a table
< which consists of pairs of ints, e.g. 9600 and B9600 (13). This patch
< replaces the entry for 4800, B4800 (12) with 19200, B19200 (14). Be
< sure to check the permissions and ownerships of uucico and restore them
< after patching.
<
< To locate the 4800 baud entry, you can do:
<
< adb -w /usr/lib/uucp/uucico
< 20000?L 0t4800
<
< This should display an address. On hoptoad (68020 version) this address
< is 20A0C. To display that table entry, you can do:
<
< ?DD
<
< it should say:
< xxxxxx: 4800 12
<
< to patch it,
<
< ?W 0t19200 0t14
<
< Don't forget the 0t's, which say these numbers are in decimal.
< You're done, type ^D and try it.
<
< ------------------------------------------
<
< The SunOS 3.3 patch that John suggests works fine on SunOS 3.4 as well.
<
--
Ken MacLeod Price Savers Wholesale Warehouse
ut-sally!utah-cs!utah-gr!uplherc!sp7040!jose!ken Salt Lake City, Utah
(801) 277-6966 (evening) (day) (801) 264-7224
I don't let anyone share my views, there all mine.mangler@cit-vax.Caltech.Edu (Don Speck) (02/15/88)
In article <3238@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes: > For example, DEC DZ11's don't support 19200 baud. They do on 4.2bsd. DEC doesn't document it because the rate is not divided exactly (it's actually 19600 baud) but it's close enough for many devices. The 64-character silo provides enough buffering for only 1/30 of a second, so any kernel printf will cause dropped characters, but that's true of any serial interface for a vax. The thing that makes it useless for high-speed devices like Trailblazers is the lack of CTS flow control. The Able DH/DM is one of the few Unibus serial interfaces that provides CTS, but because it uses a DZ11-compatible distribution panel (which doesn't have a wire for CTS) this is done in a very kludgey way. At the DH/DM and at the panel, you jumper RI and CTS together. This sacrifices the RI signal, but 4.2bsd doesn't do anything with that anyway. It's a pain to configure, but works quite well, at least with our U-B terminal switch. The 256-byte silo helps. The Emulex CS21/H has a 256 byte silo too, but the factory settings restrict it to 64 bytes for DEC diagnostic compatibility, so check the switches. The CS21/H lacks CTS, so it will not fare much better than the DZ11. Able DH/DM's can sometimes be bought cheap from VMS sites/dealers that have acquired some by buying an old Unix vax. I have 3. Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck