mcr@Latour.Sandelman.Ocug.On.Ca (Michael Richardson) (11/27/90)
I've just set up a Sun 3/60 at home with uucp, news, etc...
This is far from my first time setting up such a system, however
I seem to be having problems with several connections.
The machine 'latour.Sandelman.Ocug.On.Ca'
(which I did post about before) has replaced 'julie', and taken
over all Julie's connections.
However, several of my connections don't seem to work anymore,
for reasons I'm rather stumped on.
Two of the machines (isishq and atronx) don't run Unix. isishq
has Binkley as a front end, atronx has Welmat. Welmat actually
provides most of the function of /etc/getty, Binkley does some magic.
I can cu to the machine and do the scripts manually and get connected,
but uucico can't do it.
On atronx, Welmat shows the characters received in a window. Russell
(the admin) says that he got some pretty weird ones: reverse line feeds,
etc.. What _I_ saw was '^M^Mjlie^M' -- I had sent 'uujulie'
I then tried to add an extra 'ogin: \r ogin:' to the send-expect
sequence: the ^M never made it there.
Now, I didn't think TOO much about this until setting up a connection
to another (Unix) site failed in a similar manner.
_My_ guess is that uucico is doing something strange to the tty (well,
cua1) modes after receiving the connect message.
Doing an 'stty -a >dev/cua1' tells me that parity is disabled, etc..
And all looks well. (I can post if anyone likes)
The 'stty -a >/dev/cua1' differs in that XON/XOFF is enabled,
but I have tried setting things up while cu'ing identical to the way
that it was for uucp and I have no problem. I have also tried the
reverse.
Could uucico be adding parity on itself?
The 3/60 is connected to a Telebit. The Telebit is locked at
19.2k. The connections that I have had problems with are 2400 baud (atronx),
V.32 (isishq), and micor(PEP).
RTS/CTS is hooked up, but according to stty, disabled. (How DO
I enable them by default?) The cable COULD be bad. (Continuity does
check)
This has really got me stumped. Any help would be much appreciated,
as getting the micor connection to work will mean that I can move
my news feeds around and get a 386 with a slow serial board/driver
out of bottleneck and let it do real work again.
--
:!mcr!: | The postmaster never | So much mail,
Michael Richardson | resolves twice. | so few cycles.
mcr@julie.UUCP/michael@fts1.UUCP/mcr@doe.carleton.ca -- Domain address
- Pay attention only to _MY_ opinions. - registration in progress.mcr@Latour.Sandelman.Ocug.On.Ca (Michael Richardson) (11/28/90)
In article <1990Nov27.045059.8308@Latour.Sandelman.Ocug.On.Ca> mcr@Latour.Sandelman.Ocug.On.Ca (Michael Richardson) writes: > _My_ guess is that uucico is doing something strange to the tty (well, >cua1) modes after receiving the connect message. > Doing an 'stty -a >dev/cua1' tells me that parity is disabled, etc.. >And all looks well. (I can post if anyone likes) > The 'stty -a >/dev/cua1' differs in that XON/XOFF is enabled, >but I have tried setting things up while cu'ing identical to the way >that it was for uucp and I have no problem. I have also tried the >reverse. > Could uucico be adding parity on itself? From what I can tell (Welmat can dump all the characters in hex that it receives after answering the phone, but before recognising a session) the characters ARE being sent with parity. Aside from fixing Welmat so that it strips the parity on some characters (Fidonet sync characters have the high bit set, so I wasn't striping the characters) how can I change this behaviour of uucico? I haven't got the Sun sysadmin manuals, and I don't recall seeing anything in the AT&T HDB manuals about this. What has Sun changed? -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so few cycles. mcr@julie.UUCP/michael@fts1.UUCP/mcr@doe.carleton.ca -- Domain address - Pay attention only to _MY_ opinions. - registration in progress.
guy@auspex.auspex.com (Guy Harris) (12/03/90)
> I haven't got the Sun sysadmin manuals, and I don't recall seeing >anything in the AT&T HDB manuals about this. What has Sun changed? The way it chooses the parity to use when transmitting characters. The code was lifted from the 4.3BSD UUCP, which: 1) defaults to even parity 2) permits you to put a fake "send" string (which you'd couple with a null "expect" string) to set the parity. P_ZERO sets it to zero, P_ONE sets it to one, P_EVEN sets it to even, P_ODD sets it to odd. This is in the Sun sysadmin manuals for 4.1, so I suggest you get them instead of flying blind....