david@ms.uky.edu (David Herron -- One of the vertebrae) (07/17/89)
Does anybody have a similar configuratrion working?
I have v2.01 which I ftp'd from ucbvax.berkeley.edu the
other night.
What happens is I call out using dterm, log in, set my
DNETDIR variable to point to /tmp/.david.DNET and type
dnet. The dnet.servers file points to /u/e/staff/david/local.ultrix.
The dnet.servers on the amiga points to boot:system, which is
where I put all the dnet binaries. In both cases these directories
are in my PATH. When I type dnet, the dterm window goes away
and an fterm window starts. But quickly after the original
dterm window comes back, the fterm window goes away, and a new
fterm window comes back. It keeps doing this ... until I turn
off the modem. QuitDnet won't kill it.
Runing with -p and -d (debug & packet debug) shows
DNET RUNNING
SEND 05 3 bytes
DNET RUNNING
SEND 05 3 bytes
DNET RUNNING
SEND 05 3 bytes
DNET RUNNING
SEND 05 3 bytes
DNET RUNNING
SEND 05 3 bytes
...
Until I turn the modem off. Sometimes it prints that it received
a "16" with so many bytes, but that doesn't keep the fterm from
being killed.
Oh, and it's not the trailblazer either because this happens when
I call a 2400 baud modem with my trailblazer.
I tried turning off all the flow control on the remote trailblazer.
My trailblazer uses hardware flow control -- It doesn't step on
^S/^Q and is otherwise transparent to characters.
There was a couple of compile errors -- warnings actually --
when compiling the unix end. I could reproduce those if necessary.
On the Amiga end I'm just using the binaries in the distribution.
I installed the dpipe: handler in the distribution, even though
the docs didn't say to... (Does it matter that I didn't MOUNT it
until after startup-sequence finished?)
My DNETDIR is in /tmp because my home directory is NFS mounted
from a machine other than the one the modems are on.
"boot:" is the name listed for the boot device in MountList. It
was named DH0: at format time. Oh, but I see the dnet.servers
now refers to dh0:system ...
I tried "stty pass8" once .. no change
Any ideas?
Thanks,
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- WARNING: Hunting season is now open in West Virginia!shadow@pawl.rpi.edu (Deven T. Corzine) (07/17/89)
In article <12183@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: [DNet choking w/Trailblazer] sounds like a transparency problem... DNet is unbelievably unforgiving of the slightest point of nontransparency. (A severe design flaw, in my opinion.) Going through a terminal multiplexor? >QuitDnet won't kill it. QuitDnet is useless unless the DNet protocol is already running properly. [another design flaw? ;-)] >Oh, and it's not the trailblazer either because this happens when >I call a 2400 baud modem with my trailblazer. Still could be the modem's fault. Tried with a DIFFERENT modem? >I tried turning off all the flow control on the remote trailblazer. >My trailblazer uses hardware flow control -- It doesn't step on >^S/^Q and is otherwise transparent to characters. Kill all flow control everywhere you can find it, and then some. >There was a couple of compile errors -- warnings actually -- >when compiling the unix end. I could reproduce those if necessary. Sloppy code. Don't worry about it; that's not your problem. Your problem is somewhere in the data stream. >On the Amiga end I'm just using the binaries in the distribution. >I installed the dpipe: handler in the distribution, even though >the docs didn't say to... (Does it matter that I didn't MOUNT it >until after startup-sequence finished?) Dpipe: matters not at all, until you try to use the SCLI server on the Amiga. This isn't your problem either. >My DNETDIR is in /tmp because my home directory is NFS mounted >from a machine other than the one the modems are on. Contrary to Matt's claim that the Unix-domain sockets fail when network-mounted, my DNETDIR is ~/.dnet/ [not actually using "~"] which is in an NFS-mounted partition. It works fine. [SunOS V4.0 BSD Unix] Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (07/21/89)
You CAN run DNet over a trailblazer, but you have to turn off
handshaking completely... no xon-xoff or even hardware handshaking.
I suggest you also turn off compression.
If it still screws up it might be other things you are going
through to reach your ultimate destination, like a terminal server
or something.
:Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
:Contrary to Matt's claim that the Unix-domain sockets fail when
:network-mounted, my DNETDIR is ~/.dnet/ [not actually using "~"] which
:is in an NFS-mounted partition. It works fine. [SunOS V4.0 BSD Unix]
:
:Deven
Turns out that it does work. But only the machine that
created the socket can connect to it. :-)
-Mattshadow@pawl.rpi.edu (Deven T. Corzine) (07/21/89)
On 21 Jul 89 03:56:48 GMT, dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) said: Deven> Contrary to Matt's claim that the Unix-domain sockets fail when Deven> network-mounted, my DNETDIR is ~/.dnet/ [not actually using Deven> "~"] which is in an NFS-mounted partition. It works fine. Deven> [SunOS V4.0 BSD Unix] Matt> Turns out that it does work. But only the machine that Matt> created the socket can connect to it. :-) Well, of *course*... They're Unix-domain sockets, implemented internally. But the fact that the actual file system link to the socket is on an NFS partition doesn't affect it. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2214 12th Street, Troy, NY 12180 Phone: (518) 271-0750 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.