On Tue, 30 Jan 2001, Mark Edward Reed wrote:
> Hello Tim
> On 30-Jan-01, you wrote:
>
> > You need to be using a terminal that allows you to specify the device
> > name for the device you're using. Look through your terminal's
> > configuration for an entry saying serial.device (or whatever alternative
> > serial device you're using), and replace it with telser.device.
>
> > I can't remember the specifics, but you may need to play with the unit
> > number (0 or 1), as one of them is, by default, used for server
> > functions, the other for client.
If you don't want to use servers at all, just edit telserd.conf and
comment out the lines that aren't already comments.
> > I haven't used Termite, or even seen it, so I don't know anything about
> > that program, but I've used telser.device with Term. It works rather
> > nicely, as well as being the best terminal program I've used on any
> > computer platform (though fiddly to customise).
VLT+telser was my favorite Telnet client before MiamiTelnet came along.
It still has certain aspects that are better than MiamiTelnet, though I
mostly use MiamTelnet these days.
> I have the setup for the terminal program set up OK. What I'm not sure on
> is how to configure the telser.device to work with Miami. I remember a
> bunch of things I'm supposed to do if I were to set it up for use with
> AmiTCP. I don't know if I'm supposed to set anything up just to connect
> with Termite.
There's not really too much that you *have* to set up, and it's pretty
well documented. The main issue in using it with Miami is that it expects
AmiTCP: and some of its subdirectories to exist. Some people map AmiTCP:
to Miami:, but I personally prefer to keep them separate.
> I can try just putting the telser.device in DEVS: and seeing if it will run
> without hassle, but I'm worried about all the different thins I'm supposed
> to set up. (Like all the db directory files, ect...)
It needs those, but the installer should store the files as supplied, and
with a few tweaks it should be usable.
> If I get the BBS setup, I understand that a lot do use the telser.device.
> So I'll need to know what I'd need for that as well.
Yes, that's quite a bit more complicated, and there are security issues.
If you decide to get MiamiDx, look into MiamiTelnetD as well.
On Thu, 1 Feb 2001, Tim Seifert wrote:
>
> I found I had to put the telser.device file into the same directory as the
> terminal program, so I suspect I should have put "DEVS:telser.device"
> rather than just "telser.device" into the serial device gadget
> (remembering that device names are usually CaSE SeNSItive).
I have it in one of my DEVS: directories, and it works fine there (with
VLT). That's certainly where you're supposed to put drivers. If Term
expects otherwise it's a bug. It also shouldn't be necessary to include
"DEVS:" in the name, since that's where OpenDevice() is going to look.
> It's a while since I've used it, so I can't remember all my experimenting.
> But I do remember that if I had been using telser.device with Miami (as a
> server), that it was already in memory, and I didn't strike the problem of
> Term requiring telser.device to be located in the Term directory, before
> it could use it.
Resident drivers don't include the full pathname, so that part is ignored
when searching the device list. Thus an incorrect path will have no
effect. This is *really* a kludge for SANA-II drivers, since the
"Networks/" part is ignored and you'd damn well better not have different
drivers called DEVS:foobar.device and DEVS:Networks/foobar.device.
> If you wanted to use telser.device as part of a server (for a BBS, for
> instance), then you needed to set up INetD parameters in Miami, similar to
> how you set them up in AmiTCP. This is what I have left of telnet server
> configurations in Miami:
>
> Service: telnet
> Socket: stream
> Protocol: tcp
> Wait: nowait
> User: root
> Server: AmiTCP:serv/telserd
> Name: telser
> Args: -telserd
>
> Which suggests I was using something other than telser.device. Just
> firing up my BBS now, with the telnet server, and I'm getting the AmiTCP
> telnet daemon shell. Yep, the configuration is definitely set for the
> AmiTCP telnet server.
No, telserd is the server for Telser. You can't run the driver as a
program from InetD, but telserd users telser.device. AFAICT AmiTCP
doesn't include a Telnet server, but if it did it would probably be called
either "telnetd" or "in-telnetd".
> > Later I do plan on paying for a good telmet client. AmTelnet looks OK
> > and was the one I was playing with a bit. I don't really know how good
> > the Miami Telnet is since I don't have MiamiDX. (Does it allow 16
> > colour ANSI screens?)
>
> Yes it does, though since you're using your CLI console, you're limited to
> it's interface (all the problems associated with using different fonts,
> and colours, etc., that you get with the CLI).
The best way to find out about MiamiTelnet is to download the MiamiDx
archive and read MiamiDx.guide. You don't have to register it to read the
docs. :-)
> By the time I've remembered how I did it before, you'll probably work it
> out too. One thing I never did get to work, that way, was file transfers.
> They just bombed out terribly. Which was probably just due to general
> internet comms problems I has having at the time. I never resolved it, as
> my ISPs didn't allow servers, so there wasn't much motivation.
I've certainly used file transfers with VLT+Telser on the client side,
though perhaps only with Kermit. IIRC I had trouble with ZModem, which I
suspected was due to a transparency bug in Telser. I *have* used
MiamiTelnet for ZModem transfers, though.
Fred Wright
--
To unsubscribe send "unsubscribe miami-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
