🚀 go-pugleaf

In <CnL41y.32L@rco.qc.ca> root@rco.qc.ca (Superuser) writes:

> Problem: can ipx packets from a terminal emulator be routed across
>          the internet through tcp packets, to another remote 
> 	 host, such as an sco system running ipx [via i/p tunneling]?
> 
> Situation: we have 2 novell file servers in 2 different cities.
>            we want to use the novell 3.12 i/p tunneling option to
>            send tcp packets bewteen both servers, to establish
>            connectivity. we will be using routers at each end,
> 	   which will connect through ethernet to the servers.
> 	   the routers speak only tcp. the routers will be running 
> 	   ppp between each other.
> 
>   	   there will also be an sco unix system running tcp and
> 	   ipx at one of the sites [let's say, site #1]. this unix
> 	   system will be connected through ethernet to the novell
> 	   network, and will run both tcp and ipx [as supplied by sco]
> 
> Question:  if we use the ipx 'drivers' supplied by sco, which allow the
> 	   use of an int14 interface by a workstaion in order to contact 
> 	   the sco unix system, [to use a terminal emulator, for example], 
> 	   can we have workstations at site #2 [the remote site] communicate
> 	   properly with the unix system at site #1, which supports
>   	   tcp and ipx? 
> 
> 	   would the ipx packets adressed to the remote unix site be properly 
> 	   converted to tcp packets, and then converted back to ipx packets 
> 	   and sent to the unix system?
> 
> if this made any sense, would you be able to tell me if this is feasible?
> e-mail and/or posts are invited.

I think it makes sense :-).  To be completely honest, we have never
tried such a setup.  Our test network setup contains lots of systems
acting as pure IPX routers, and the NVT protocol works without problems
from a DOS machine on one LAN to a SCO server separated by these routers.

It should (don't you just hate it when people use the "should" word?) 
work as long as

    1) The IP Tunnel is truly transparent, and is just used to
       transport the IPX packets from one site to another
    2) And, the SAP/bindery information is also somehow bridged.
       The nvtd daemons on the SCO systems advertise their presence
       to the world via SAP packets.  The NVT client must have
       access to this info to determine the existance of the remote servers.

Good Luck, if you do try it, please let me know via email how it turns
out.

---
Larry Philps              Senior Software Engineer            larryp@sco.com
SCO Canada, Inc., 130 Bloor St. West, 10th floor, Toronto, Ontario.  M5S 1N5
Phone: (416) 922-1937                                    Fax: (416) 922-2704