Recipe for OS/2 TCP/IP (and IAK) PPP

Updated 96/04/25 - Tony Rall

These were posted to comp.os.os2.networking.www by Rall May 22,1996

* Use at least the July, 1995, version of (downloadable from  tcpip\bin\ppp.exe should be dated at least 95/07/13.

* If your provider has given specific instructions for connecting
  using OS/2 TCP/IP or the Warp IAK, follow them (to the letter)
  (and hope they know what they're doing - not many do with respect
  to OS/2).

* Use the "Dial Other Internet Providers" application (slippm.exe).

* "Add Entry"

* Page 1:
  - Fill in Name, Description, Login ID, and phone number.
  - Leave Password blank but check "Required" (you will be prompted
    for your pw each time you dial).
  - For the Login Sequence use "NONE".  PAP authorization will be
    attempted by ppp.  If this does not work with your provider, try
    a completely blank Login Sequence.  If this doesn't work, look at
    the help information (put cursor in the area and hit F1).

    * General comments about the Login Sequence:
      o Several characters are invalid in a LS without being preceded
        by the escape character "\", plus other special characters
        (these same comments apply to the Login ID, password, and
        modem initialization strings):
          space - replace by "\s"
          carriage return - replace by "\r"
          back slash "\" - replace by "\\"
          double quote " - cannot be used at all (near as I can tell)
          2 second delay - use "\d"
      o The first string is sent from you to your provider - it is
        usually just a carriage return, "\r".
      o Alternate lines are those that the dialer is to wait for from
	your provider.  The dialer (actually slattach.exe) will ignore
	everything it receives until it get an exact match with the
	string you've entered - and the comparison is case-sensitive.
	If slattach doesn't get what it expects in (by default) one
	minute, it will abort the connection.
      o If it does get a match, it will send the next line in the
	Login Sequence.
      o The online help for the Login Sequence is reasonably good.  To 
	see it, place your cursor in the LS and hit F1.  It omits a
	couple of details; you can get those using, at an OS/2 command
	prompt, "slattach -?".

    * If a Login Sequence, by itself, is insufficient for your needs,
      you must go to a Rexx script (a .cmd file).  One of the most
      frequent motives for this is when you have a provider that 
      doesn't have enough phone lines to accommodate his customers
      (I would have to be pretty desperate to use a provider like
      that) - in this case, you may want an automatic redial script.
      The Login Sequence doesn't supply this capability.  (Note:
      using a response file (.rsp) provides no functional advantage
      over using a regular Login Sequence; the only impetus I can
      see for a response file is if slippm.exe has some undesirable
      side effects in your environment.)  When specifying a cmd or rsp
      file in the LS, it must be done in lower case.

      Unfortunately, IBM does not include any sample scripts for ppp.
      If you feel that you need a Rexx scrip, I recommend trying to
      get a hold of pppdial.cmd, distributed at popular OS/2 ftp
      sites as

      If you want to make your own, issue "ppp -?" for help on the
      parameters required by the ppp driver.  Annex.cmd (or
      slipup.cmd) would need to be changed in the following ways:

      The arguments are passed differently to ppp scripts than they
      were for slip.  They come in as individual parameters which,
      in Rexx, must be separated by commas in your script.  (The
      third parameter is CMD - I don't know of a use for it, so I
      discard it.)  The "parse arg" statement near the beginning of
      your script must look like this:
       parse arg interface , port , . , dialcmd , username , password
      typical values: ppp0   com1       ATDTnnn   userid     password

      Change all occurrences of the function calls "slip_..." to

      Assuming your provider supports PPP IP address configuration (this
      is dynamic and under the covers), you can remove the parsing of
      addresses, configuring the interface, and setting the default
      route - this will be taken care of automatically.
  - Connection Type: PPP

* Page 2:
  - Leave blank Your IP Address, Destination IP Address, Netmask.
  - Don't change the MRU (ppp seems to ignore this anyway).
  - Domain Nameserver - add the numeric IP address of your provider's
    primary nameserver, e.g.,
  - Your Host Name - enter a name for your PC (mine is "trall").  Put
    the same name in config.sys via a SET statement; e.g.,
  - Your Domain Name - usually the name of your provider, e.g.,

* Page 3:
  - All of this information is optional.  Entering it correctly will
    make it easier to use the related applications.  Your provider
    should supply anything you use here.

* Page 4:
  - Modem Type - I don't mess with this, but if you don't understand
    the commands for your modem and you can find it in the list, go
    ahead and select it.
  - Com Port - Get this right.  Note that if you use anything above
    com2 you need to define it in CONFIG.SYS with a COM.SYS statement.
  - Speed (Baud) - This misnamed field is referring to what is 
    actually called the DTE speed - the data transfer rate between
    the com port and the modem.  In general, the higher, the better.
    But the standard com support (COM.SYS) currently supports no
    higher than 57600.  If you seem to be having problems communicating
    with the modem, drop this to 9600 to ensure that this is not the
  - Data Bits - Leave at 8.
  - Parity - Leave at NONE.
  - Prefix - Leave at ATDT (unless you don't have tone dialing; then 
    use ATDP).
  - Mode - Leave at Dial
  - Initialization Strings - If your modem type was not in the list
    at the top of the page, see below.

The reason there are 2 init. strings is that some modems require a delay
between a reset and any other commands.  Typically the first command is
to reset to factory defaults; then the other string is used to make any
changes needed from those defaults.  In practice, most modems work fine
with just one string (which can be quite long), and this avoids the
2 second delay that is inserted between the 2 strings.

I recommend you try this (in Init. string 1; leave Init. string 2 


Not all of these commands are available on every modem; if you get
ERROR when you dial (as a response from the modem), start removing
stuff until you don't.

 &F    reset to factory defaults (check your modem manual to see if
       there is a different command for this; if there are several,
       use the one for asynchronous communication with RTS/CTS
       (hardware) flow control)
 M1    speaker on (usually a default)
 E1    echo on (so you can see the commands being sent to the modem, 
       including the dial string)
 S0=0  no auto-answer
 &C1   signal true carrier-detect
 &D2   hangup when DTR drops (this is how slip/ppp makes the modem
       break the connection)


* After clicking on the Dial icon, it switches to Hangup and then
  immediately switches back to Dial - quitting immediately.
  - Your com port is not defined to OS/2.  On ISA bus machines,
    COM1 and COM2 are the only ones defined by default.  If you use
    COM3 or 4, you need to add a COM.SYS statement to config.sys (and
  - Make sure there are no spaces in your userid or password; you
    can substitute \s for any spaces.
  - Make sure the Netmask (on page 2 of the dialer settings) is not - I consider it best to leave this field totally
  - Your com port is still held by some other program (another com
    or fax program).  You must exit that program before dialing.
  - Anyone using the original red spine Warp (for Windows) and 
    communications apps should have at least fix pack 5 installed.

* The dialer does not appear to talk to the modem and, after one
  minute, terminates with a failure.  This occurs most often on
  redial attempts.  Issuing the following command before dialing
  may help:
    MODE.COM COMn:1200

  On other modems, forcing the modem to reset after the previous
  connection helps.  Change &D2 in your modem init. string to &D3
  (not all modems support this command).

  Other users have solved this problem by replacing com.sys with
  the shareware (by Ray Gwinn) SIO.SYS, generally available at your
  favorite download sites.

  Make sure you have this statement in config.sys:
    SET HOSTNAME=nameofmypc
  Lacking this, ppp.exe may hang for one minute before redial

* [io_event] Unsupported protocol (xxxx) received.
  The remote server is trying to setup additional communications 
  protocols (such as IPX) that ppp.exe does not support.  This is just
  an informational message.  Ppp.exe will reject that protocol; this
  will not cause a problem unless the server insists on that protocol
  being supported.

* [io_event] Unsupported protocol (2080) received.
  This is a special case of the previous item.  The 2080 is definitely
  not a ppp protocol - it happens to be a couple of ASCII characters
  typically used to format text (non-ppp) messages.  In other words,
  the server is not yet in ppp mode (but OS/2 is).

  This usually means that either:

  * you didn't get correctly logged in (from the server's viewpoint),
    and it is sending you error messages, but ppp.exe is expecting
    formatted ppp messages at this point

  * you did get logged in, but the server is sending a few more
    text messages, such as:
     Ok, you're on
     Let me get my ppp code fired up
     Hold on a sec
     Ok, it's up
     Have a good day.

  If you want to eliminate this error, you have to find out what the
  messages are.  In the first case (bad login), correcting the login
  should suffice.  In the second, you'll need a fancier Login Sequence
  (not a blank or NONE LS).  One way to determine what is being sent
  is to put an intentional error in your LS: after the last line to be
  sent to the server add a line with "xxxyyy".  This won't match, so
  the Status window will display all messages received.  If it wasn't
  indicating a login error, replace the xxxyyy with the last part of
  the last such message.  In the example above, the last line in your
  Login Sequence should contain:

* Invalid FCS - Bad frame check sequence (corrupt ppp packet)
  May not have been intended as a ppp packet if OS/2 has entered ppp
  mode while the remote system is still sending text messages.  The
  latter can often be corrected by improvising a better Login
  Sequence (see "unsupported protocol (2080)" above).  But you don't
  have to do anything at all if you just get a few of these  messages
  at the start of the connection.  If they continue throughout your
  session, you should try to correct the problem - they usually
  indicate a phone or modem flaw that can be corrected by some
  combination of the following:

  * getting a better serial card (with a buffered uart)
  * running the com port at a lower speed, as low as 9600 ("baud" on
    page 4)
  * replacing the serial cable
  * getting a better phone connection (note that if the modems are
    both using error control, such as V.42, this is not a likely
    cause for the bad packets)
  * using a better initialization string for the modem
  * suppressing modem compression (such as V.42bis)
  * replacing the modem
  * replacing com.sys with the shareware sio.sys (or vice versa)

* After the message "Enter Ctrl-C or Ctrl-Break to End Session", you 
   notice : DCD lost, exiting
   info : Exit called
   info: Terminating link
  This could be caused by an attempt by your system to send mail to
  a mail gateway if you do not have a correctly configured mail setup. 
  Messages may end up queued in etc\mqueue\.  When you make your 
  connection an attempt is made to send these messages immediately.  If
  you still have a bad mail configuration, you can get the error
  described above, and ppp (erroneously) hangs up.  Erase the files in
  the etc\mqueue directory and try redialing.

  Or you're using a cable between your com port and the modem that does
  not include a working CD (carrier detect) wire.

* You tell the system to hangup, but the modem stays off-hook (it does
  not hangup).  This can run up your phone bill (if a toll call) and
  can foul up your next connection attempt.  There are 2 ways that
  software can tell the modem to hangup:

  The "+++ ATH0" escape sequence and command will make most modems
  hangup, but I know of no way to make the dialer issue this. 

  The method used by the dialer is to drop DTR.  Unfortunately this
  requires that the modem pay attention to the DTR signal, and modems
  can be configured to ignore it.  On many modems the default setting
  is to obey DTR (and hangup when it drops); on other modems &D2 should
  be included in the init. string.

  Some modems may not recognize the change in the DTR signal.  This
  can be controlled by the setting of S25, on at least most modems.
  If &D2 by itself is insufficient to provoke hangup, add S25=5 to
  your modem initialization string.