However, callback from Linux box to different clients can be organized quite easily without CBCP, if you use mgetty. Then you can start PPP after callback. No need in additional software, utilite callback from mgetty package enough. You have only edit /etc/mgetty/login.config and modify Windows client side.

It works with Linux, DOS (telix), Win3.11 (with Shiva dialler or Trumpet Winsock), Win95, Win98 (WinNT don't checked yet). Here is running Debian Linux, so users of other distributions have to check placement of configuration files. Thanx to Eloy A. Paris for help preparing this page.

You can also try another callback solutions:

• http://www.icce.rug.nl/docs/programs/callback/callback.html
  
• http://www.dyer.demon.co.uk/slug/tipscrip.htm
  

• How it works
• Configuring Linux box
• Configuring client side
• Security

• How it works.

  Here is descriebed, how callback works with Windows and Linux, which both uses scripts. Without script (say DOS with telix) you have to get commands manually.

  • Windows with script
    • Windows dial-up networking dials the Linux PPP server and establish connection.
      
    • Windows runs his dial-up networking script.
      
    • Linux sends a login prompt (this is mgetty, the one that does that, not login).
      
    • The Windows script, which was waiting for the login prompt from the Linux box, detects the login prompt and sends a login name for callback (for example cback). NB! Don't use real user (who can log on to Linux box) here - then he can only use callback, but not simple call. Also it's very unsecure solution.
      
    • When mgetty sees that the login name is cback, it knows it does not need to fork a simple login, but forks a program callback that comes with the mgetty package. So, mgetty runs callback and exits.
      
    • callback creates lockfile for ttySx and asks the user for the number to call back (if this number isn't fixed in configuration file).
      
    • mgetty restarts, finds lockfile from callback and waits for establishing of callback connection.
    • The Windows script, which was waiting for enter phone number to callback sees this string and sends the phone number. If phone number is fixed in configuration file, this step must be skipped in script.
      
    • When callback has the phone number, it hangs and calls back to that number.
      
    • The Windows script is now waiting for RING. When it sees this string it sends a ATA to the modem (so the modem answers the call) and starts waiting again for the login prompt.
      
    • When connection is establised, callback removes lockfile and exits.
      
    • mgetty see, that lockfile is removed and continues normal work - sends login prompt.
      
    • After the Windows script sees the login prompt, the normal login sequence starts.

    It is very important that before callback hangs the call, the modem in the Windows box does not tell to Windows that the call has been dropped. Otherwise, Windows Dial-up Networking will abort everything (because it thinks the call was dropped with no reason). It's made by sending to the modem command AT&C. It makes the modem to report the Carrier Detect line is always active. Windows looks at this line to know if the communication between modems is established or not. In practice &C is added to modem init string. To restore modem settings, client can send AT&C1A instead of ATA, both works.

  • Linux with script
    • On client side starts pppd with command line like

      /usr/sbin/pppd call provider
      

    • With option call provider pppd will look in /etc/ppp/peers for a file provider, which contains information on how to connect to ISP called "provider".

    • File /etc/ppp/peers/provider contains option

      connect "/usr/sbin/chat -v -f /etc/chatscripts/provider"
      

    • pppd starts chat program, which reads chat script from /etc/chatscript/provider/, dials the modem and starts the remote ppp session:
      • chat dials, connects and waits for login prompt.
        
      • Server sends a login prompt (this is mgetty, the one that does that, not login).
        
      • The client's chat script, which was waiting for the login prompt from the server, detects the login prompt and sends a login name for callback (for example cback). NB! Don't use real user (who can log on to Linux box) here - then he can only use callback, but not simple call. Also it's very unsecure solution.
        
      • When mgetty sees that the login name is cback, it knows it does not need to fork a simple login, but forks a program callback that comes with the mgetty package. So, mgetty runs callback and exits.
        
      • callback creates lockfile for ttySx and asks the user for the number to call back (if this number isn't fixed in configuration file).
        
      • mgetty restarts, finds lockfile from callback and waits for establishing of callback connection.
      • The client's chat script, which was waiting for enter phone number to callback sees this string and sends the phone number. If phone number is fixed in configuration file, this step must be skipped in script.
        
      • When callback has the phone number, it hangs and calls back to that number.
        
      • The client's chat script is now waiting for RING. When it sees this string it sends a ATA to the modem (so the modem answers the call) and starts waiting again for the login prompt.
        
      • When connection is establised, callback removes lockfile and exits.
        
      • mgetty see, that lockfile is removed and continues normal work - sends login prompt.
        
      • After the client's chat script sees the login prompt, the normal login sequence starts.

    It is very important that before callback hangs the call, the modem in the client's box does not tell to chat that the call has been dropped. Otherwise, chat will abort everything (because it thinks the call was dropped with no reason). It's made by sending to the modem command AT&C. It makes the modem to report the Carrier Detect line is always active. chat looks at this line to know if the communication between modems is established or not. In practice &C is added to modem init string. To restore modem settings client can send AT&C1A instead of ATA, both works.

  Back to top
  

• Configuring Linux box.

  Actually you have to edit only /etc/mgetty/login.config by adding there different callback users (but if you want to tune callback parameters like debug level, you can edit also /etc/mgetty/callback.config).

  • /etc/mgetty/login.config

    You have to add here line(s) like

    • Top_Secret_Dialer  -   -   /usr/sbin/callback -S
      call_to_Mary       -   -   /usr/sbin/callback -S 123456
      call_to_Jonh       -   -   /usr/sbin/callback -S 654321

    In case of first configuration line (user Top_Secret_Dialer) callback asks for phone number, where to call back, so this user can call back everywhere.

    For more security You can also fix phone numbers, where to call by adding of this number to end of configuration line. So you can configure different users with different fixed callback numbers and (if you want) one privileged callback user.

    Switch -S forces callback to use the line where callback is started from for dialing out. (callback can make use of multiply modem lines).

    NB! Don't use * instead of some callback user name! In this case mgetty falls to infinite callback and never reach real login.

  • /etc/mgetty/callback.config

    Actually here's no need to edit this file. Default settings are good enough. If you want, you can adjust here debug level, port speed etc. Here are samples and explanation of options.

  
  

  Back to top
  

• Configuring client side

  On client side you have to add &C to modem init string and edit (or create) dial script (Windows).

  • Adding &C to modem init string
    • DOS (with telix). Edit file telix.cnf in telix directory. Find modem init string (variable minit) and add there &C (just before ^M).

    • Win3.11 (with Shiva dialler). Edit file modems2.ini in iexplore directory. Find modem init string (variable InitString) and add there &C.

    • Win95 and Win98. Open "Control panel" -> "Modems" -> "Properties" -> "Advanced" -> "Extra settings" and add there &C.

  • Dial scripts

    Both Linux and Windows clients uses dial scripts. With DOS client (telix) you have to get all conmmands manually. Necessary commands are clearly visible in script for Windows below.

    In Windows script client first log on Linux box and then starts pppd. In Linux script /AutoPPP/ is used. Both ways can be used in both scripts, it depends of server configuration, if /AutoPPP/ works.

    • Windows

      If you want to use dial script, you have to create it (or edit existing one). Dial script (here named callback.scp) is same for all Windows versions, but placement can vary. In Win3.11 it's usually in c:\iexplore\ directory.

      • Sample script callback.scp

        proc main
        waitfor "ogin: "
        transmit "Callback_User^M"
        waitfor "number for callback: "
        transmit "123456^M"
        waitfor "RING"
        transmit "ATA^M"
        waitfor "ogin: "
        transmit $USERID
        transmit "^M"
        waitfor "assword: "
        transmit $PASSWORD
        transmit "^M"
        waitfor "> "
        transmit "ppp^M"
        endproc

    • Linux

      Here you have to make two scripts: /etc/ppp/peers/provider for pppd and /etc/chatscript/provider for chat. As you can see, this Linux client supports also IPX over PPP and restores modem settings after callback.

      • Sample script /etc/ppp/peers/provider

        # This file was generated by pppconfig.  You can edit the following lines
        # but please do not delete lines or the change the comments or you will
        # confuse pppconfig.
        noauth          #pppconfig_noauth
        connect "/usr/sbin/chat -v -f /etc/chatscripts/provider" #pppconfig_connect
        debug           #pppconfig_debug     
        /dev/ttyS0      #pppconfig_dev
        115200          #pppconfig_speed
        defaultroute    #pppconfig_route
        noipdefault     #pppconfig_ipdefault
        user Real_User  #pppconfig_user
        # End of pppconfig controlled lines.  You can add lines below here without
        # confusing pppconfig.
        ipx
        ipxcp-accept-network
        ipxcp-accept-remote
        ipxcp-accept-local
        novj

      • Sample script /etc/chatscript/provider

        ABORT BUSY
        ABORT VOICE
        ABORT "NO DIALTONE" 
        ABORT "NO ANSWER"
        "" ATZ
        OK ATDT987654
        CONNECT \d\d
        ogin: \q\dcback
        callback: \q1234567
        TIMEOUT 90
        RING AT&C1A
        ogin: \q\d/AutoPPP/

  Back to top
  

• Security

  This callback looks secure enough, in spite of missing password protection of callback user. Even in case of privileged callback user (who can send phone number, where to call back) it's not less secure than normal dial-up, because callback user isn't real user and callback is started before real login to Linux box.

  In case of user with fixed callback number it's more secure than normal dial-up. It's totally useless for alien - he even don't reach normal login prompt.

  So for higher security use only callback users with fixed phone numbers. If you want to use privileged callback user too, use some long complicated name. Anyway, callback is not less secure than normal dialup, but rather more secure.

Back to top

Back to Linux page