miorelli@pwa-b.UUCP (BoB Miorelli) (08/17/88)
Help !!! I'm trying to add a new uucp site to my system and I'm
having problems getting it to work reliably. Several other sites
have been running very well for quite some time now. My system
is Berkeley 4.3 on a VAX 750.
The system I'm connecting to is a local call (in the same city) and
we have a rather strange environment. Uucp makes the call and logs
into an account on their VAX 750 (mt xinu). Their ~uucp has a
.login that does a "stty raw pass8 -tandem litout" and then an
immediate "rlogin hgcsc -8" to get to the machine they want news/mail
on. This second machine is a SUN (don't know what kind or version of
the OS). There is a .login on the sun as well. This one does another
stty (probably unnecessary since we are now on a pty rather than a tty)
and then executes /usr/lib/uucp/uucico. It seems to work a good
part of the time. However, certain files (compressed, batched news)
fail, but other news files make it !!! To free up the line I delete
the uucp file at the top of the list and restart uucp. It works well
again until another 'problem' file is encountered. Turning on the uucp
debugger gives some information. The first indication of a problem is
uucp reporting "Bad header". Several re-xmits and then uucp reports
"Noisy Line -- Set up RXMIT". Several more re-xmits and uucp hangs up
on a timeout error. I assume that somehow something is getting trashed
in this non-standard setup. Any suggestions on how to fix it (or set
up a better method of communicating with hgcsc when the modem is on hgcvax)
are very welcome.
Hopefully my description hasn't been too confusing. Thanks so very much
for your help.
--
-->BoB Miorelli, Pratt & Whitney Aircraft
also, H & R Block tax preparer and Instructor
pwa-b!miorellicsch@tmpmbx.UUCP (Clemens Schrimpe) (08/20/88)
The problem seems to be in those rlogin-connections. As I could
determine from your debug-info your uucico tries to utilize the so
called 'g' protocol for transmission. This is quite right for non-MNP
modemconnections but it also requires a FULL (!!!) 8-bit transparent
connection which 'rlogin' wouldn't give you, since at least '~' has
a special meaning to it.
There are two possible solutions of that problem:
a) Try to make your uucico use the 'f' protocol - it will
only use 7 bits and avoid special characters like the
most characters of col. 0/1 of the ascii-chart and DEL.
Although you should set the ESCAPE character of either telnet
or rlogin to some control-char instead of '~' !
The problem with this is, that if you have a very noisy
telephone-line you'll get more problems, since the 'f'
protocol relies on a flow-controlled (that's where the name
comes from) almost error-free connection.
b) Write a simple 8-bit transparent communications-program,
which connects you to the 'uucp' port of the receiving
machine. This programm could terminate if one side simply
hangs up. (uucp = port 540/tcp [uucpd] - Berkeley Unix should
support that)
regards,
Clemens Schrimpe, netmbx Berlin
--
UUCP: csch@tmpmbx.UUCP {pyramid,unido,altger}!tmpmbx!csch
BITNET: csch@db0tui6.BITNET csch@tub.BITNET
PHONE: +49-30-332 40 15 TELEX: (066)+186672 net d
PSI: PSI%026245300043106::CSCH
X.25: 026245300043106 login: chat Password: talkmasterrobert@pvab.UUCP (Robert Claeson) (08/21/88)
In article <1142@tmpmbx.UUCP>, csch@tmpmbx.UUCP (Clemens Schrimpe) writes: > The problem seems to be in those rlogin-connections. As I could > determine from your debug-info your uucico tries to utilize the so > called 'g' protocol for transmission. This is quite right for non-MNP > modemconnections but it also requires a FULL (!!!) 8-bit transparent > connection which 'rlogin' wouldn't give you, since at least '~' has > a special meaning to it. The rlogin implementations on our Sun's and Annex'es (terminal servers) are 8-bit transparent and have no escape character.