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

(Please also see the files WHAT_IS_TSLIP and COPYRIGHT)

"tslip" stands for SLIP using Taylor UUCP dialing.  

It is available for for anonymous ftp from 

	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.1.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.  The core slip driver came from the SVR4 slip code on ftp.tcp.com.

* 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?

  Probably not yet.  Slip server support tools (by Greg Whitehead 
  and Geoff Arnold) are included in the distribution and "should work", 
  BUT HAVE NOT YET BEEN TESTED with the new daemon.  Therefore some changes
  are probably required.  I hope to include tested server tools in a later
  release.  I'd appreciate any volunteers to work on this...

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

  1. Well, tslip works :-).  ESIX SVR4.04 doesn't (at least the dial-out
     portion), and ESIX admits it, and doesn't have the resources to
     address the problem.  Perhaps it worked in earlier releases...

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

  3. Dialing is *on demand*, initiated from the kernel, transparent to IP.
     For example, when you type "ftp netcom.com", 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.
  
  4. Modem lines need not be dedicated to slip.  After the idle timeout
     expires, a serial port is detached from the slip driver and the call
     disconnected.  Then the port is again ready for use by cu, uucp, etc.

* Will tslip work with SVR3?

  Probably not, 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 some new kernel routines.  I have a fuzzy impression 
  that DDI/DKI was introduced with SVR4, in which case you would 
  have to convert the interfaces to the old style (should not be too hard).  
  The system must use streams-based TCP/IP which communicates with slip driver
  using DLPI (Data Link Provider Interface).

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

  Yes (I'm fairly sure).  In fact, I believe netcom works this way.

  If your client machines all have unique IP addresses for their ends of
  their slip links, 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 slip 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?

  Several folks have sent me mail saying they have seen public PPP code, 
  but don't have anything working at the moment.  I'd be glad to work with 
  anyone to add a PPP driver to tslip so that either PPP or SLIP could be 
  used on any interface.


Thanks again for your willingness to give tslip a try.
Please let me know your experiences.

-Jim Avera (jima@netcom.com)
