Path: utzoo!utgpu!attcan!uunet!lll-winken!csd4.milw.wisc.edu!leah!rpi!rpi.edu!deven From: deven@rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga Subject: Re: forwarded message concerning DNet 2.0 Message-ID: Date: 24 May 89 23:13:56 GMT References: <8905241959.AA20054@postgres.Berkeley.EDU> Sender: usenet@rpi.edu Organization: RPI Public Access Workstation Lab, Troy NY Lines: 135 In-reply-to: dillon@POSTGRES.BERKELEY.EDU's message of 24 May 89 19:59:09 GMT In article <8905241959.AA20054@postgres.Berkeley.EDU> dmose@drizzle.cs.uoregon.edu (Daniel Albert Mosedale) writes: >>From @mist.math.uoregon.edu:dmose@drizzle.cs.uoregon.edu >I've been mucking around with DNet 2.0 for awhile and I still can't get it >to work. I actually haven't installed V2.0 for myself yet (still using V1.10) but I think it's not a problem with DNet itself, at least, not a change between the versions. >I've been starting DNet with >run dnet -X -8 That much should be fine. >after which I use the DNet window to dialup (via a 1200 baud modem) some >sort of port switcher known as the Gandalf switch. Never heard of it, but unless it plays with the data stream in any way, (which I doubt) it isn't your problem. >I use this to connect to UONet which is a Bridge CS/200 terminal >server. This could likely be where your problem lies. >I connect to the VAX I'm on now (BSD Unix 4.3). After loggin in, I >hit the ecmchar ^[, and after setting fcf=none, fct=none, >ecmchar=disabled, and (sometimes) xmitbinary = on, I attempt to start >dnet on the unix side. RPI has a Bridge CS/1, with dialup ports connected to modems through an IBX data switch. When I first tried to run DNet over it, about 6 months ago, I couldn't ever get it to work reliably. At that time, the xmitbinary option was unavailable. I had set fcf=none fct=none ecmc=disabled and nas=unul. But it never worked quite right until I tried more recently, with the xmitbinary option available. Now, what happens is, I dialup the CS/1, connect to a Sun 3/50 (BSDish SunOS 4.0 Unix) and enter amiga for a termtype, _wait for a prompt_, and then type the ecmc (^^) and do set fcf=none fct=none ecmc=disabled xmitbinary=on followed by a resume. THEN I type return a few times and then "dnet". After switching to binary mode, it gets a single EOF (ignored because of csh set ignoreeof, prints warning) and then the tty adjusts. However, if you're at the "TERM = (dialup) ?" prompt, it will insist on sending anything buffered (usually one character unless you type fast) as if it were alone on a line. But at the shell prompt, it can accomodate the switch. Why this is, I haven't yet figured out. Once I start DNet on the Unix end, the original DNet window closes and an fterm opens, but does not connect. Then I must break the dnet process, killing the fterm and bringing back the dnet window. Somehow, it is almost always back at the CS/1's "Telnet> " prompt, though the ecmc was disabled. This I can't understand, either. Anyway, I then resume the session again, and usually dnet starts running fine at that point. Regardless, my experience has been that once I get it to open a single fterm window (i.e. show the dimensions) then the dnet connection works reliably after that. I haven't yet figured out why it takes such contortions to start it going. >So far so good. The DNet window closes, FTerm opens up, says >opening...please wait, after a few seconds the window dimensions >appear on the titlebar, and I guess dnet then runs either .login or >.cshrc since the computer asks the normal TERM = (vt100)? and I'll >hit return, as always when I login, at which point things start to >screw up. I can no longer type anything, and nothing appears in the >DNet window.....however, wathching the lights on my modem, then SEND >light flickers about once every half second, and the receive is >constantly on. This locked state will go on indefinitely, or until I >shut off the modem. It runs your .login; it starts csh with an argv[0] of -fshell. (at least under V1.1) I modified my .login to set the termtype to "amiga" BEFORE running DNet, as it will be passed down in the environment. And, you should not have it ask for a termtype if a clearly defined one like vt100 or amiga is set. (For such as "network", "dumb", "dialup" and other generics, ask.) As far as what dnet is doing at that point, it would appear that it is trying to send some packet over and over again, consistently failing every time. This could happen because of transparency problems, which you could encode around. Another possible reason is that dnet is sending data too fast, and consistently overflowing a buffer somewhere along the way, only receiving bits and pieces of the packets. This could be solved if dnet would simply pause occasionally, at which time the buffers would clear. Another problem I've run across with this Bridge CS/1 in particular (not elsewhere) is that on some rare occasions, if it is outputting a LOT of data, the data stream will suddenly become total garbage (but in normal ascii-character range) until the flow of data stops, at which point it reverts to normal. Whether this is a bug in the TCP implementation or an internal buffer overflow problem or what, I have no idea. But it can happen. Matt, please take note: if dnet keeps retrying the same packet, have it pause occasionally; that may juset fix it. >An earlier article suggested using stty -parity and some other option >....the stty on our machine doesn't support those particular keywords, >although it supprots the setting in other forms. I tried messing around >with a bunch of those, as well as starting DNet with -h0, and none of >it makes a difference. I don't know the particulars of the VAX Unix, but if it's reasonably similar to SunOS 4.0, then you needn't worry about stty. At least, I've gotten DNet to run without it. >Another things to note...above I said that I only set xmitbinary=on >sometimes...this is because 95% of the time when I turn xmitbinary >on, and then resume my session with the unix box, I start having >typing problems: every time I type 1 character, a return is >automatically supplied, and then csh prints a list of all files in >the current dir which start with that letter. the few times when >xmitbinary doesn't mess things up like this, I still have the same >locked condition with dnet. perhaps you do have to deal with stty then... under SunOS, it will automatically reset things correctly, from the shell prompt, but not from the TERM = (dialup)? prompt. It might be an added feature of Sun's csh or tty driver; I don't know. Regardless, you will NOT get dnet to run properly without using binary mode. Try typing "sleep 1 dnet " and THEN type ^] to change the CS/200's modes. When you resume, dnet should already be running, and as it puts the tty in raw mode, will probably not have the problem with superflous EOL's and EOF's. Deven -- shadow@[128.113.10.2] Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet Troy, NY 12180-2306 <> "Simple things should be simple and complex things should be possible." - A.K.