   Here are the files I'm using.  I've included a little chk_ojt.exe utility
that just tries to ARP it's router to make sure that the Network packet
driver is functioning.  I think the syntax for it is "chk_pkt my_ip netmask
router_ip".
Example:  "chk_pkt 139.78.159.1 255.255.255.0 139.78.159.254"

   The Goslip.exe takes 3 to 5 parameters.  Three parameters are required.
The first is the decimal based IP address.  The same IP address is used for
the GoSlip host and the remote station.  Next is the decimal based netmask.
Finally the router IP address must be given.  The 2 optional parameters are
the HEX based vectors of the two packet drivers.  The first is the packet
driver connected to the network.  The second is the packet driver that is NOT
connected to the network.  If you don't give these 2 parameters then Goslip
will search for the first 2 packet drivers it finds above 60h and try to ARP
you router from them.  I think it should be able to locate the proper
interrupts in almost all cases.

   There is almost no screen output when Goslip is running.  Your remote client
needs to be configured for compressed slip if you use CSLIPPER for the slip
packet driver on the server. (I use trumpet just fine)  The program runs on the
server until a key is pressed.  I've found getting the packet drivers
configured more difficult than getting Goslip to work.   Typing GOSLIP without
any parameters will display the usage message.


Eddy,
   Just wanted to let you know what this is doing "inside".  The program hooks
up to the 2 packet drivers.  One I'm considering an ARPing interface and the
other a Slip interface. (Although it wouldn't have to be slip.  I think it
could be ISDN, PPP, or anything else.)
   The server will only answer ARP packets addressed to it.  It won't answer a
PING or anything else sent to it.  It is very passive.  All IP traffic,
except ARP requests, is simply moved over to the remote packet driver.  If
there is a client (Slip or otherwise) on the other end and it responds to a
Ping, then our server just takes those packets comming in on its slip packet
driver and puts them onto the ARPing packet driver.  Pretty simple and doesn't
take much horsepower.  Let me know if that kind of design causes any
problems for you guys with a datacomm perspective.

   I've used a free package called SLIPGATE to address some of the phone
security issues.  Slipgate hooks into the Com port the slip packet driver
(CSLIPPER?) is using.  Slipgate can be set up with passwords and time limits
for users.  It can also be set up to do dial-back or call-on-demand dialing.
It also logs all activity on the slip packet driver.  It seems to work pretty
well to me.



Jim Wirt
