mk59200@kaarne.tut.fi (Kolkka Markku Olavi) (05/05/89)
I can't get DNET working! Can someone out there help?
Unix end: Sun 3/260, SunOS 4.0.1, Sun cc
Amiga end: A500, KS1.2, WB1.3, ARP1.3, ConMan1.3, PopCLI3
The connection is through a TCP/IP terminal server, but I checked that
it is 8bits, no parity.
Symptoms:
I can connect and login to the Sun normally through the Dnet startup
window, but when I try to start dnet, the Amiga side goes to a loop
where it alternately opens and closes Fterm and Dnet windows, but
nothing appears in them (except sometimes # or { characters)
--
Markku Kolkka
mk59200@tut.fideven@pawl.rpi.edu (Deven Corzine) (05/06/89)
In article <6974@etana.tut.fi> mk59200@kaarne.tut.fi (Kolkka Markku Olavi) writes:
I can't get DNET working! Can someone out there help?
Unix end: Sun 3/260, SunOS 4.0.1, Sun cc
Amiga end: A500, KS1.2, WB1.3, ARP1.3, ConMan1.3, PopCLI3
The connection is through a TCP/IP terminal server, but I checked that
it is 8bits, no parity.
Yet, this could be your problem. If this terminal server uses the
TELNET protocol, then you're shit outta luck. DNet will NOT run over
_telnet_, because even though the telnet protocol is a full 8-bit data
path, it isn't *quite* transparent enough. I believe the problem may
be due to the fact that by definition the telnet protocol stream may
NOT under any circumstances contain a single CR (0x0d) or a single LF
(0x0a) in the data stream. The three choices are CR, NUL; LF, NULL;
CR, LF. A plain CR or LF would be converted either to the character
followed by a NUL (0x0a) [preferable] or to a CR, LF pair. The CR, LF
pair is a generic EOL and will often (on Unix systems) be treated as a
single LF. [Unix newline character] Unfortunately, this can leave
you in a situation where you can not type a CR in the input stream.
[Can be nasty telnetting out.] Anyhow, I digress. DNet will not run
over telnet, probably because of this point of non-transparency.
Unless Matt has specifically changed it for 2.0 [I haven't tried it
yet] but I don't think so. [Matt?] The other major point of
nontransparency in telnet is the escape character, usually ^]. (don't
know the character code offhand.)
On the other hand, the rlogin protocol IS transparent enough to run
dnet over. If you can use a straight TCP connection or an rlogin
connection (which is fairly close) DNet should run fine over it. With
a telnet connection, you can't do much about it.
Symptoms:
I can connect and login to the Sun normally through the Dnet startup
window, but when I try to start dnet, the Amiga side goes to a loop
where it alternately opens and closes Fterm and Dnet windows, but
nothing appears in them (except sometimes # or { characters)
The # and { characters appear to be a sychronization phase in the dnet
protocol. Anyhow, this sounds like a transparency problem...
Matt, could you please consider an enhancement to optionally escape
certain characters, etc. It would let a LOT of people use DNet who
currently can't because they don't have a direct dialup...
Deven
--
shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847
shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America
deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>>
"Simple things should be simple and complex things should be possible." - A.K.dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (05/07/89)
:[Can be nasty telnetting out.] Anyhow, I digress. DNet will not run
:over telnet, probably because of this point of non-transparency.
:Unless Matt has specifically changed it for 2.0 [I haven't tried it
:yet] but I don't think so. [Matt?] The other major point of
:nontransparency in telnet is the escape character, usually ^]. (don't
:know the character code offhand.)
:
:On the other hand, the rlogin protocol IS transparent enough to run
:dnet over. If you can use a straight TCP connection or an rlogin
:connection (which is fairly close) DNet should run fine over it. With
:a telnet connection, you can't do much about it.
DNet will not run under telnet for that and other reasons... like
^] causes an escape. DNet *will* run under rlogin because rlogin recognizes
when a terminal is placed in RAW mode and turns off it's escapes.
: Symptoms:
: I can connect and login to the Sun normally through the Dnet startup
: window, but when I try to start dnet, the Amiga side goes to a loop
: where it alternately opens and closes Fterm and Dnet windows, but
: nothing appears in them (except sometimes # or { characters)
Sounds like carrier detect is not connected. DNET V2 checks the CD
line to support modems set to auto-answer. You can use the -h0 option on
the Amiga side to tell DNet to ignore the CD line.
:Matt, could you please consider an enhancement to optionally escape
:certain characters, etc. It would let a LOT of people use DNet who
:currently can't because they don't have a direct dialup...
The solution here is for somebody to write their own serial.device,
or perhaps commodore make it a standard feature of the serial device to
encode 8 bits down to alpha-numeric or something. I dunno. To tell you
the truth I have a very low tolerance for systems which do not provide a full
8 bit transparent comm.
-Mattgore@eecs.nwu.edu (Jacob Gore) (05/07/89)
/ comp.sys.amiga / deven@pawl.rpi.edu (Deven Corzine) / May 5, 1989 / >If this terminal server uses the >TELNET protocol, then you're shit outta luck. DNet will NOT run over >_telnet_, because even though the telnet protocol is a full 8-bit data >path, it isn't *quite* transparent enough. [lists possible problems] There is a telnet binary mode, and the terminal server may support it. >The other major point of >nontransparency in telnet is the escape character, usually ^]. That's a function of the telnet user interface, not of the protocol itself. The terminal server may allow you to change it to another character, or disable it altogether. >On the other hand, the rlogin protocol IS transparent enough to run >dnet over. I'm surprised you haven't pointed out that "\n~", if followed by a command that rlogin recognizes (such as "^Z", ".", etc.), is an escape sequence, and needs to be disabled too (granted, it is less likely to occur in a random data stream, but...) Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore
deraadt@xenlink.UUCP (Theo A. DeRaadt) (05/07/89)
In article <8905070127.AA13702@postgres.Berkeley.EDU>, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
- :[Can be nasty telnetting out.] Anyhow, I digress. DNet will not run
- :over telnet, probably because of this point of non-transparency.
- :Unless Matt has specifically changed it for 2.0 [I haven't tried it
- :yet] but I don't think so. [Matt?] The other major point of
- :nontransparency in telnet is the escape character, usually ^]. (don't
- :know the character code offhand.)
- :
- :On the other hand, the rlogin protocol IS transparent enough to run
- :dnet over. If you can use a straight TCP connection or an rlogin
- :connection (which is fairly close) DNet should run fine over it. With
- :a telnet connection, you can't do much about it.
-
- DNet will not run under telnet for that and other reasons... like
- ^] causes an escape. DNet *will* run under rlogin because rlogin recognizes
- when a terminal is placed in RAW mode and turns off it's escapes.
If anyone wants a program that will fake the telnet stuff, I have one
for BSD (what? telnet on a non-BSD? :-) that I hacked up one boring
rainy/snowy night.. lemme know if you want source. You will have source,
so you can toast the escape key feature, or I can bind it to a cmdline
option....
Of course, I have an idea that telnet might have an option to turn off
the escape character... never checked.
<tdr.vinsci@ra.abo.fi (Leonard Norrg}rd DC) (05/07/89)
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) wrote: >:[Can be nasty telnetting out.] Anyhow, I digress. DNet will not run >:over telnet, probably because of this point of non-transparency. >:Unless Matt has specifically changed it for 2.0 [I haven't tried it >:yet] but I don't think so. [Matt?] The other major point of >:nontransparency in telnet is the escape character, usually ^]. (don't >:know the character code offhand.) >: >:On the other hand, the rlogin protocol IS transparent enough to run >:dnet over. If you can use a straight TCP connection or an rlogin >:connection (which is fairly close) DNet should run fine over it. With >:a telnet connection, you can't do much about it. > > DNet will not run under telnet for that and other reasons... like >^] causes an escape. DNet *will* run under rlogin because rlogin recognizes >when a terminal is placed in RAW mode and turns off it's escapes. I had the same problem when I first started using DNet, ie. the terminal servers the modems are connected to didn't have a binary line as default. Our servers are Bridge Communications CS200 with 10 ports, running Bridge's TCP/IP software. After some experimenting and RTFM:ing I found out that it was indeed possible to get a binary path over telnet with these servers. It's somewhat of a kludge, but it works: Since you can't set the telnet session parameters before you actually have a session, you need to escape to the server and change the parameters to binary after you login but before you start DNet. So, the CS200 command looks like this: set fct=none fcf=none ecmchar=disabled xmitbinary=on This disables flowcontrol (usually xon/xoff), disables the telnet escape character and finally leaves any combination of CR/LF alone. Appended is the output from a "SHOW PARAMETERS" on the CS200 with the above command executed (the "do binary" executes a macro which contains the above command). Of course, this won't help if your server is of some other type... -- Leonard Norrgard, vinsci@abo.fi, vinsci@finabo.bitnet, +358-21-654474, EET. -----$(SCISSORS)--------------$(SCISSORS)------------$(SCISSORS)------------- (!3) ASAc.110>> do binary (!3) ASAc.110>> sh para Parameters for PortId !3, current session ...................Port Transmission and VTP Characteristics................... BUffersize = 82 DeVice = ( Terminal, Glass, DeFault ) InterAction = ( Verbose, Echo, NoMacroEcho, MacroBreak, BroadcastON, NoLFInsert ) InitMacro = "" MaxSessions = 3 PRIvilege = GlobalNM .........................Port Physical Characteristics......................... BAud = 9600 BSPad = None CRPad = None FFPad = None LFPad = None TabPad = None DataBits = 8 DUplex = Full LinePRotocol = ASynchronous PARIty = ( None ) StopBits = 1 UseDCDout = ( AlwaysAssert, NoToggle ) UseDTRin = Ignore .................Session Transmission and VTP Characteristics.................. BReakAction = ( InBand ) BReakChar = Disabled DIsconnectAction = None DataForward = None ECHOData = OFF ECHOMask = ( AlphaNum, CR, Term, Punct ) ECMChar = Disabled NetAScii = UseLF FlowControlFrom = None FlowControlTo = None FlushVC = OFF IdleTimer = 2 LongBReakAction = ( Listen, OutofBand ) LFInsertion = None MOde = Transparent XmitBinary = ( ON ) ..................Session & User Interface Editing parameters.................. ERAse = ^? LineERAse = ^U LocalEDiting = ( NoDataEditing, CmdEditing ) ReprintLine = ^R VERBatim = Disabled WordERAse = ^W
deven@pawl.rpi.edu (Deven Corzine) (05/08/89)
Well, *I* appreciate the information; at RPI, we have a Bridge CS/1, [CS/1T?] which is the "official" passthru, intended to replace the Gould [itsgw.rpi.edu, a BSD machine] as an Internet terminal server. I don't have access to any manuals for them, [I don't believe RPI has any such manuals.] and last time I tried to get dnet running over the CS/1, I got it to start up by a "set nas=unul" [set netascii=usenull] and disabling xon/xoff. (and maybe the ecmchar) It worked, until DNet tried to send a large amount of information and appeared to overflow a buffer... every time it resent the offending packet. Instant infinite loop. *sigh*. (a situation where killing the fterm or even dnet itself is useless. [well, maybe killing dnet would've done it; that was before I figured out that at&d would set the Supra 2400 modem to ignore DTR...]) I never noticed anything about a "xmitbinary" setting, but I'll give it a try next time I have a chance. Anyway, thanks for the idea... Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
franks@ritcsh.UUCP (Francis Shea) (05/08/89)
In article <6974@etana.tut.fi> mk59200@kaarne.UUCP (Kolkka Markku Olavi) writes: >Symptoms: > I can connect and login to the Sun normally through the Dnet startup >window, but when I try to start dnet, the Amiga side goes to a loop >where it alternately opens and closes Fterm and Dnet windows, but >nothing appears in them (except sometimes # or { characters) > > Markku Kolkka > mk59200@tut.fi I also am having problems starting dnet. I can log on to the vax but when i type dnet for the connection the fterm window just sits and waits. It says something like opening..wait. I have tried to change the servers file and all other files i could find but to no avail.. I would appreciate any help also...... thanks in advance frank shea
billsey@agora.UUCP (Bill Seymour) (05/09/89)
From article <6974@etana.tut.fi:, by mk59200@kaarne.tut.fi (Kolkka Markku Olavi):
: I can't get DNET working! Can someone out there help?
: Unix end: Sun 3/260, SunOS 4.0.1, Sun cc
: Amiga end: A500, KS1.2, WB1.3, ARP1.3, ConMan1.3, PopCLI3
: The connection is through a TCP/IP terminal server, but I checked that
: it is 8bits, no parity.
:
: Symptoms:
: I can connect and login to the Sun normally through the Dnet startup
: window, but when I try to start dnet, the Amiga side goes to a loop
: where it alternately opens and closes Fterm and Dnet windows, but
: nothing appears in them (except sometimes # or { characters)
What you need to do is run DNet with the -h0 option. that disables
the carrier detect portion, and you no longer need to be going through a
modem to get your system working. It took me a while to find out just what
I needed to do to get this working, but 'Run DNet -X -h0' works for me!
: --
: Markku Kolkka
: mk59200@tut.fi
--
-Bill Seymour ...tektronix!reed!percival!agora!billsey
...tektronix!sequent.UUCP!blowpig!billsey
Creative Microsystems Northwest Amiga Group At Home Sometimes
(503) 691-2552 (503) 656-7393 BBS (503) 640-0842mk59200@kaarne.tut.fi (Kolkka Markku Olavi) (05/09/89)
Thanks to Leonard Norrgard, Matt Dillon and others who helped, I have now Dnet running. As a summary, here's how to use Dnet through a Bridge TCP/IP terminal server: 1. On Amiga side: start Dnet with command dnet -8 -X -h0 2. Connect and login to Unix system 3. Set Unix terminal options to 8 bit, no parity checking stty -parity -istrip 4. Set terminal server's options hit left-Amiga-B (send break) set xmitbinary=on fct=none fcf=none resume 5. start Unix side of Dnet Now, FTERM should start normally. Easy, isn't it? :-) -- Markku Kolkka mk59200@tut.fi
ecphssrw@afws.csun.edu (Stephen Walton) (05/10/89)
In article <3151@ritcsh.UUCP>, franks@ritcsh (Francis Shea) writes: >In article <6974@etana.tut.fi> mk59200@kaarne.UUCP (Kolkka Markku Olavi) writes: >> I can connect and login to the Sun normally through the Dnet startup >>window, but when I try to start dnet, the Amiga side goes to a loop > >I also am having problems starting dnet. I can log on to the vax but when i >type dnet for the connection the fterm window just sits and waits. Francis, Kolkka and anyone else who is using dnet over a direct-connect line, as opposed to through a modem, needs to start Dnet with the -X and -h0 switches. -X tells Dnet that you are on a manual connect line, and -h0 tells Dnet to ignore carrier detect. Without -X, you'll find the remote end unable to "putfile" because the default security level (in s:dnet.config) assumes a hostile environment. Without -h0, Dnet will refuse to open any servers until it sees carrier detect, which will never happen on the three-wire line into my office, or probably yours either. Matt Dillon told me all this, to give credit where it's due. Dnet is fun, now if only I had TekTerm in addition to Fterm... -- Stephen Walton, Dept. of Physics & Astronomy, Cal State Univ. Northridge RCKG01M@CALSTATE.BITNET ecphssrw@afws.csun.edu swalton@solar.stanford.edu ...!csun!afws.csun.edu!ecphssrw
deven@pawl.rpi.edu (Deven Corzine) (05/12/89)
In article <10260018@eecs.nwu.edu> gore@eecs.nwu.edu (Jacob Gore) writes: / comp.sys.amiga / deven@pawl.rpi.edu (Deven Corzine) / May 5, 1989 / >If this terminal server uses the >TELNET protocol, then you're shit outta luck. DNet will NOT run over >_telnet_, because even though the telnet protocol is a full 8-bit data >path, it isn't *quite* transparent enough. [lists possible problems] There is a telnet binary mode, and the terminal server may support it. True enough. I found that I could indeed force our telnet server into binary mode, and I am now running dnet (v1.1) over it. It's not an option that I recall being available in the software version which was running when I originally tried to figure it out... >The other major point of >nontransparency in telnet is the escape character, usually ^]. That's a function of the telnet user interface, not of the protocol itself. The terminal server may allow you to change it to another character, or disable it altogether. I understand it's a function of the UI, but the fact remains that ^] is a common escape character for telnet *programs* and it is a point of nontransparency, even though the protocol does not define it. On the Bridge CS/1 I'm using, the escape character ("ECMChar") is normally ^^, but is currently disabled. >On the other hand, the rlogin protocol IS transparent enough to run >dnet over. I'm surprised you haven't pointed out that "\n~", if followed by a command that rlogin recognizes (such as "^Z", ".", etc.), is an escape sequence, and needs to be disabled too (granted, it is less likely to occur in a random data stream, but...) The only reason I didn't point it out was I was getting tired of typing, the article was getting long enough as was, and it wasn't directly relevant. Yes, rlogin has "tilde escapes" which must be preceded with a newline. They are also disabled when the remote tty is put into raw mode, as dnet does, so it wasn't directly relevant. Technically, the tilde escapes are also a UI issue, but are also so fixed the distinction blurs, and is unimportant regardless. Purists. :-) Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.