chapman@acf4.NYU.EDU (Gary W. Chapman) (07/17/90)
Can someone explain the idea of INT 14 redirectors to me? My impression is that some asynch comm programs can be told to do i/o via int 14, and that some telnet clients can be configured to use int 14 as their interface to the comm program (which thereby functions as a user interface/front end to telnet). Is this off-base? Also anyone know if non-commerical telnets from NCSA, Clarkson, Stanford, or Maryland support this? -Gary Chapman, chapman@nyu.edu
saddison@excelan.COM (Skip Addison) (07/18/90)
In article <12920042@acf4.NYU.EDU> chapman@acf4.NYU.EDU (Gary W Chapman) writes: >Can someone explain the idea of INT 14 redirectors to me? My impression >is that some asynch comm programs can be told to do i/o via int 14, and >that some telnet clients can be configured to use int 14 as their >interface to the comm program (which thereby functions as a user >interface/front end to telnet). Is this off-base? > >-Gary Chapman, chapman@nyu.edu Your understanding is correct. The INT 14 interface is based on the original IBM ROM BIOS serial port support (which was largely ignored). There are now many different implementations of INT 14 (including 2 different ones from IBM, naturally) to provide access to various modem pools, async gateways, etc. There is now a great deal of support for the NASI interface which was designed from the start to be used over a network. It's a similar concept, but more advanced and standardized.... -- Skip
chapman@acf4.NYU.EDU (Gary W. Chapman) (07/19/90)
I need more information relating to providing asynch protocol support
on top of telnet; the following explains the context:
Here is a simplified diagram of a portion of our network.
We are using Clarkson packet drivers to allow simultaneous
netware and tcp/ip access for PCs on the net. Clarkson CUTE
telnet is use for terminal emulation on the PCs. Ethernet II
only is spoken by NetWare.
Ethernet
---------------------------------------------------
| | |
PC Novell -------------------
Server | Ungermann-Bass |
| Terminal Server |
| running TCP/IP |
-------------------
| | |
modem modem modem
A PC can telnet to the terminal server in order to get a
modem to dial out of the campus. Upon reaching an external
information service, however, no protocol-based file transfer
is possible.
Ideally, I would like to be able to run Kermit from a PC
and have it use a telnet connection to get to the Terminal
Server. (We can do this with C-Kermit on our Unix machines).
Has anyone attempted to do this, or are there other
suggestions for PC modem access via the terminal servers?
Gary Chapman, NYU
chapman@nyu.edukeith@excelan.COM (Keith Brown) (07/19/90)
In article <12920043@acf4.NYU.EDU> chapman@acf4.NYU.EDU (Gary W. Chapman) writes: > > Ethernet >--------------------------------------------------- > | | | > PC Novell ------------------- > Server | Ungermann-Bass | > | Terminal Server | > | running TCP/IP | > ------------------- > | | | > modem modem modem > >A PC can telnet to the terminal server in order to get a >modem to dial out of the campus. Upon reaching an external >information service, however, no protocol-based file transfer >is possible. > This situation is not uncommon. Most popular telnet client programs support little in the way of file transfer protocols such as [XYZ]modem, kermit etc... I acknowledge that our pals at 3Com have put an Xmodem capability into their telnet client but there is a better way to crack this particular nut. If your favorite communications program does go to INT 14h to do I/O to what it believes to be an async line, it will typically have no concept/support of connection initiation or termination. The network aware extensions to INT14h provide these but not all comms packages use them. Also, there are a number of different extensions to INT 14h and your comms package may only be able to use one of them. Sod's law says it will be the one that's no use in your scenario! The lesson is that it's not enough to provide an INT 14h interceptor/redirector on it's own. You need to provide an external utility that is capable of manipulating and configuring your redirector on behalf of communications programs that don't understand it. This is the tac we have taken in our TCP/IP product for DOS. Our INT 14h redirector operates over telnet/TCP connections. We implemented a superset of the "known" INT 14h extensions and added our own extensions to allow such things as TCP connection initiation/termination and telnet protocol option negotiations under program control. Of course, the only people who actually used these extensions initially were ourselves, but we "published" them and gradually the comms software vendors are starting to write drivers that support them. If you own a comms program that doesn't, we provide a seperate utility that you can use to make the necessary calls into the INT 14h TSR to initiate the telnet connections, configure them and "attach" the connections to the COMx: devices. Then, when you fire up your old copy of ProComm and it goes out to COM2:, it may actually be speaking over a binary mode telnet connection to your local Sun (or whatever...). It's easy to create little batch scripts that install the INT 14h redirector, initiate the relevant connections, fire up your comms program and then, upon exiting, close the open connections gracefully and remove the redirector from memory. Anyway, I'll shut up about our product now. As your using packet drivers I'll take a guess that your TCP comes from FTP Software. I believe they have a similar mechanism and I'm sure James/Frances will be able to fill you in on the semantics of how they achieve this..... Keith ---------------------------------------------------------------------------- Keith Brown Phone: (408) 473 8308 Novell San Jose Development Centre Fax: (408) 433 0775 San Jose, California 95131 Net: keith@novell.COM ----------------------------------------------------------------------------
brian@la.excelan.com (Brian Meek) (07/21/90)
In article <12920043@acf4.NYU.EDU> Gary W. Chapman writes: >I need more information relating to providing asynch protocol support >on top of telnet; the following explains the context: [...] > >A PC can telnet to the terminal server in order to get a >modem to dial out of the campus. Upon reaching an external >information service, however, no protocol-based file transfer >is possible. > >Ideally, I would like to be able to run Kermit from a PC >and have it use a telnet connection to get to the Terminal >Server. (We can do this with C-Kermit on our Unix machines). >Has anyone attempted to do this, or are there other >suggestions for PC modem access via the terminal servers? > I've done this using the TELAPI (telnet API) interface that comes with LAN WorkPlace for DOS along with MS-Kermit (set for UB-Net1) connecting via telnet to a terminal server attached modem. LAN WorkPlace has the telnet "engine" and it's terminal emulators separate for this purpose. The TELAPI piece is a TSR tenet engine that supports both Int 14 and 6B that can be controlled via a separate utility called TSU (telnet session utility) if the comm package can't talk to it directly to say "open a telnet session to host_name". This type of functionality is also possible with DOS TCP/IP products from FTP Software, Wollongong and others. I vaguely recall hearing of Int 14 support from a public domain or school usable telnet package as well. good luck with it, brian ____________________________________________________________________________ Brian Meek Novell, Inc. - 2180 Fortune Dr. San Jose, CA 95131 Internet Mail: brian@novell.COM Phone: (408) 473-8375