I'm using a X.25 service to call USA for UUCP exchange.
The problem is that when I log to the remote system, I get the message
Share=<system_name> and my side respond with the UUCP message S<remote_name>
-r0 -x9 .
Until this point everything is fine. But from this point, the system stuck
and after 30 sec's or so, i get ERR and then i hanged up.
While running the uucico in my side with the maximum debug level, I noticed
that before the remote system sends it's Share= line, it's sends ^P character.
The ^P known as a prefix for commands in X.25 pads and I belive that this is
what hang the system, it's just enters a command mode for the pad and quit
the regular link with the remote side.
Well, 2 solutions may be effective:
1st) Disable the ^P command in the X.25 pads. I don't know how to do that
if any of you can help....
2nd) Set any parameter (which I don't know) so the remote uucico won't send
^P before the Share= line (or any other line).
PLEASE HELP, THIS IS URGENT.
Thanks in advance,
Gil Ben-Noon.
>While running the uucico in my side with the maximum debug level, I noticed
>that before the remote system sends it's Share= line, it's sends ^P character.
>The ^P known as a prefix for commands in X.25 pads and I belive that this is
>what hang the system, it's just enters a command mode for the pad and quit
>the regular link with the remote side.
>Well, 2 solutions may be effective:
>1st) Disable the ^P command in the X.25 pads. I don't know how to do that
> if any of you can help....
>2nd) Set any parameter (which I don't know) so the remote uucico won't send
> ^P before the Share= line (or any other line).
Only the 1st solution is likely to work - even when you use one of the
alternative protocols in uucico it still insists on sending the ^P
before any protocol negotiation (bad design, IMHO...).
The X.25 PADs I've seen could be made transparent on the local end by
sending ^Pset1:0,2:0,5:0,12:0 but it might depend on the defaults of
some of the other parameters. The real problem, though, is that you
also need to make the remote PAD transparent, and unless you are
going directly to an X.25 device in the remote unix machine, the other
end is unlikely to be able to chat with the PAD. At least one vendor's
PAD (I forget which) allows remote parameters to be given to the local
PAD, but most require setting up X.29 "triggers" so that when you send
a pre-defined character sequence to the local pad it will generate X.29
commands to change the remote pad parameters. Check with the X.25
service supplier - they probably already have done that.
On the other hand, you might want to try to use some other protocol to
reduce your X.25 packet counts. A modern version of kermit with large
packets and windowing would probably do much better by requiring fewer
acks to be returned, at the expense of sending 2 characters for every
control character in your data.
Les Mikesell
l...@chinet.chi.il.us
Gil,
I dial up a British Telecom (BT) PSS PAD using a async modem in order
to do uucp 'f' and 'g' protocol xfers between my Minix/386 PC and a
SunOS 4.1 uucico over the JANET x25 network.
The PAD ^P escape is straight-forward, and in discussions on
comp.os.minix we finally realised that the hang-up problem is caused by
^S being interpreted as XON/XOFF flow control in the uucp data stream.
This was not as obvious as it may seem in retrospect! especially when
the comments in the 'f' protocol driver suggest *enabling* XON/XOFF
flow control.
Here is how my system <minke.uk.mugnet.org> dials a Sun <rri1> connected
to the JANET network via a dial-up PSS PAD and remote gateway (passwords
replaced by AAAA...)
Tony
----
from L.sys:
#site times dev,pro speed phone script
#----- ------ ------ ------ ------ ------
rri1 Any ACU 1200 0000000 \
"" \r\rD1\r\r \ # PAD profile
NUI? AAAAAAAAAAAAA \ # user id
ADD? AAAAAAAAAAAA \ # JANET gateway
.000072315010*P7*D \ # DTE of rri1
ogin: nuucp\r\010Set?\s1:0,3:2,4:10,5:0,12:0 # PAD parameters
^^^^
Ctrl+P is escape from data stream
--
-------------------------------------------------------------------------------
Dr. A.J.Travis <a...@uk.ac.sari.rri> | Rowett Research Institute,
| Greenburn Road, Bucksburn, Aberdeen,
| AB2 9SB. UK. tel 0224-712751