philf@MED-ISG.STANFORD.EDU (Phil Fernandez) (01/13/88)
There was a recent message to this group asking for information about a program that would allow Asynch telecommunications programs to use telnet on a 3C501 board. I've not been able to track down any information on this front, and wanted to pose this question to this netgroup again. I have an immediate need for such a program to support the Grateful Med program. Any information would be most appreciated. Phil Fernandez Stanford University Medical School
snorthc@NSWC-OAS.ARPA (01/13/88)
Grateful Med, that is rich. The first case of an asynch program controlling telnet sessions on a 3c500 board that I ever heard of was Bridge's TCPterm and etherterm programs. I think someone modified the CMU-PCIP to use the 14H INT about 6 mo ago, but I haven't heard anymore on that subject. I might be able to provide you with a pointer, but unless you are a MSC codesmith you should steer clear. It seems to be a common capability for the 'NetBIOS' boards, UB, Bridge both allow this. BE WARNED you may have troubles printing to a serial printer if you do this, the mode command (for printing) likes 14H as well. Anyway, best of luck. My only relationship with UB and Bridge is as a customer. Stephen Northcutt (snorthc@nswc-g.arpa)
GFoster@A.ISI.EDU (Glen Foster) (01/13/88)
Phil,
I know of two packages that do this, they work by redirecting the INT
14 vector to a suitable board driver for the 3Com 3501 board.
Unfortunately, the application program accessing the redirector must
use the INT 14 to do asynch I/O, Reflection (by Walker, Richer &
Quinn) is the only program of which I am aware that allows this
option. If a program can do over 1200 baud on a 5 mHz 8088, then it
talks to the hardware and won't work with a serial port redirector.
Now if you have source and can insert the proper hooks, anything might
be possible.
The packages are:
TCP Term
Bridge Communications (now owned by 3Com)
2081 Stierlin Road
Mountain View, CA 94043
(415) 969-4400
This is a full-fledged communications program that has terminal
emulation, scripting etc. I am more familiar with the product
EtherTerm which is virtually the same except that it talks to Bridge
equipment running the XNS protocol stack (rather than the Dod protocol
stack, Bridge equipment supports both). It is too massive for our
use, we have to have an HP terminal emulator (it is vt100) so we have
to run Reflection (~250K) on top of EtherTerm (~200K) and quickly run
out of memory (especially with PC LAN drivers loaded). The product
itself seems to be pretty robust although the user interface stinks.
BWCOM
Beame & Whiteside Software Ltd.
259 Fiddler's Green Rd.
Ancaster, Ontario
Canada L9G 1W9
I am not at all familiar with this package having just heard of it, I
have sent for information on it and will pass this along if you are
interested. I suspect it suffers from the same problem as
{TCP|Ether}Term, being too big for its britches when what I really
want is a bare bones serial port redirector, but we will see . . .
Glen Foster
-------msa@clinet.FI (Markku Savela) (01/16/88)
> I think someone modified the CMU-PCIP to use the 14H INT about 6 mo ago, > but I haven't heard anymore on that subject. I might be able to > provide you with a pointer, but unless you are a MSC codesmith you > should steer clear. I *hacked* the CMU-PCIP telnet to catch the INT 14H. I even posted the assembler (MASM) code which did the catching. What I didn't post, were the modified modules 'TN.C' and 'TELNET.C'. Should/Can I? They are useless without the full PC-IP distribution. The new Kermit 2.29c uses INT14 if it doesn't find the standard serial port. I could use that on top of my telnet, if I could somehow force the use of INT14.... > BE WARNED you may have troubles printing to a serial printer if you do > this, the mode command (for printing) likes 14H as well. I have normally 3COM net on my PC and I usually redirect PRN to a remote printer on a server. I can still print to PRN (=remote printer) while my "catcher" is active. 3COM seems to catch printer earlier than INT14. There shouldn't be any problems, if the catcher leaves other ports alone (my version just calls the original INT14 handler for those). I use my program in connection with my own VT100 emulation. The host system is microVAX II running CMU TEK TCP-IP and sometimes Apollo workstation. Before raising any hopes too high, I must mention couple of problems (I haven't done much to the program after the first try): - sometimes the echo from VAX seems to get one character too late. The state goes away, if I just stop for second or two. - a more serious problem is, that occasionally it loses a bunch of characters (coming from vax to pc). (I have an internal buffer for incoming TCP data. If the buffer becomes full, I just throw away -- I didn't know enough of the internal PC-IP tasking to try a task switch while handling TCP upcall -- if that is possible/allowed, the problem may go away...). That's it. I just wanted to test an idea, the result works but is not perfect. ps. Is there a version PC-IP, which would have the FTP? -- -- (I cannot send private mail -- not allowed here, sorry) -- Markku Savela, UUCP: msa@clinet.fi -- Nokia Information Systems -- P.O. BOX 780 SF-00101 HELSINKI, FINLAND
jbvb@ftp.UUCP (James Van Bokkelen) (01/19/88)
1. You'd better not do a tk_yield() or a tk_block() while inside the dispose upcall from the PC-IP TCP. Use a buffer as big as the TCP window PC-IP is offering, instead, and be careful about what window you pass when you open the TCP connection. 2. We added an FTP, but we charge for our code. Stanford added an FTP, but they are limiting their source distribution, because they've sold their code to some of the other commercial vendors. I think you can still get cheap binaries from them, though. James VanBokkelen FTP Software Inc.