QandA: Questions and Answers about TSLIP
----------------------------------------

(Also see IP.SKETCH, COPYRIGHT, and the man pages)

"tslip" stands for SLIP using Taylor UUCP dialing.  

It is available for for anonymous ftp from 

	netcom.com  : /pub/jima/tslip-*.tar.gz  [latest and greatest]
or
	ftp.tcp.com : /pub/SVR4/slip/tslip-*.tar.gz

where "*" is the current release number (ftp server courtesy of Jim Lick).
You will also need Taylor UUCP 1.04, to which a small patch must be applied.
A patch file is included with tslip (you'll need the patch utility from 
ftp.uu.net:/systems/gnu/patch-2.*.tar.gz).

If you already have Taylor UUCP, apply the patch.  Otherwise, you can get
a pre-patched copy of Taylor UUCP from

	netcom.com : /pub/jima/uucp-1.04-w-tslip-patch.tar.gz

-----------------------------------------------------------------------------

* I don't have access to FTP ...

  Send me (jima@netcom.com) mail and I'll mail you the file(s) 
  uuencoded.  Your mail link must support very long messages (tslip is ~150k 
  uuencoded, and Taylor UUCP is ~1.5 megabyte).  
  Let me know whether you need Taylor UUCP.

* I've never used Taylor UUCP before ...

  Subscribe to the mailing list.  Send a message to asking to subscribe to
  	taylor-uucp-request@gnu.ai.mit.edu
  Include your e-mail address in the body of the message.
  
* Does tslip implement VJ header compression ("compressed slip")?

  Yes.

* Will tslip log in (as well as dial up) a server host?

  Yes.  Normal uucp login chat scripts are used.

* Does tslip support dial-IN (slip servers) as well as dial-OUT?

  No.  Slip server support tools (by Greg Whitehead and Geoff Arnold) are 
  included in the distribution but have not yet been converted to work with
  tslip.  I hope to include tested server tools in a later release.  
  Several volunteers are currently working on this.

* How is tslip different than the standard slipd supplied with ESIX SVR4.0.4?

  1. Dialing is *on demand*, initiated from the kernel, transparent to IP.
     For example, when you type "ftp ftp.uunet.net", packets are sent over
     the slip interface, causing your system to dial up your slip server,
     log in, and link the modem line under the slip driver.  All this is
     invisible to IP and higher levels, except for the delay.

     An idle timeout releases an unused slip modem link, after which it is
     again available for cu, uucp, etc.  When IP traffic re-appears the
     slip connection is restored, possibly using a different modem.

  2. Tslip uses Taylor UUCP code to dial out, and to execute the login
     chat (just like uucico).  This means that the same configuration files
     can be used for both uucp and slip connections.

  3. tslip works :-).  ESIX SVR4.04 doesn't.  Maybe it did in earlier releases.

* Will tslip work with SVR4.2 ?

  Initial 4.2 releases apparently made some incompatible change to the Data 
  Link Provider Interface (probably) which needs to be identified and the 
  driver modified accordingly.  

  *UPDATE* [3/94]: I have received several reports of a fixed IP driver for
  Consensys 4.2 which works with tslip.  This fixed IP driver is now included
  with TSLIP (see driver/ipfix_Con4.2/README*).  I have not tested this myself,
  as I don't have 4.2 running here. -JimA

* Will tslip work with SVR3?

  No, but it might be convertable.  Tslip is DDI/DKI conformant, 
  which means driver entry points are called with a newer calling sequence
  and the driver calls portable variants of kernel routines.  

* Will TSLIP work with dynamic client IP address assignment. 

  No.  You must have a permanent IP address assigned to your end of the
  slip interface.  This is because packets must be routed to the TSLIP 
  interface before a connection is made (this is what triggers a dial-out).

* I call a Cisco box which dynamically allocates the *server* IP addresses.  
  Will this work?

  Yes.  The IP address of the server can change with each call:

  All client machines must have unique IP addresses for their ends of
  their slip links, and a single unused (i.e., bogus) address in the same
  network can be used by all clients to refer to the slip server (gateway)
  machine when invoking ifconfig.  "route" can then be used to make
  packets to all (or specified) addresses get forwarded to this
  fictitious address, causing them to be sent down the slip link.

  Once packets arrive at the slip server, they will be routed to the final
  destination based on the recipient IP address in the packet header.
  The server will extract the source IP address of each packet and build a 
  reverse route, so that return packets get sent back over the proper link.  
  
  The IP address assigned by the server to IT's end of each slip link
  is unimportant because no packets need to be addressed to that specific
  IP address.  Clients route packets to the fictitious gateway address
  just to get packets injected onto the slip link (slip "networks" are
  point-to-point, after all, so all packets arrive at the other end).
  The slip server remembers which IP address(es) appear to be on the other 
  (client) side of each slip link, and routes return packets accordingly.

  It may be that all the IP addresses used by client and server for the slip
  link must share the same network number for routing to work properly. I'm 
  not sure about this.

* What about PPP?

  There is a fond hope that a freely available PPP driver for Solaris
  can be made to work on SVR4, and integrated with tslip to provide a
  unified package supporting both slip and ppp.  This won't happen real
  soon, however.

Thanks for giving tslip a try.

-Jim Avera (jima@netcom.com)

@(#)QandA	1.3 (01 Apr 1994)
