A: This information is mainly for people who do not have a wrapper utility like kppp or pppconfig, or are not able to get those utilities to work correctly. If you need to manually configure PPP to dial in to your ISP, you will need the following information:

 

• The port that your modem is connected to: /dev/ttyS0-/dev/ttyS3, which correspond to COM1-COM4 under MS-DOS.
• The phone number of your ISP's data connection.
• The user name and password that your ISP gave you.
• The IP addresses of the primary and possibly secondary Domain Name Service that you will use when dialing in to the ISP. This assumes that you will not be using a DNS that you installed on your system.

  When you have all of this information, make sure that the programs pppd and chat, at the very minimum, are installed correctly. In most current distributions, they are installed in the /usr/sbin/ directory, and you will need to be logged in as root to use them. In addition, the following programs are also useful for configuring network connections, determining network status, and diagnosing problems: /sbin/ifconfig, /sbin/route, /bin/ping, /usr/sbin/traceroute. These are the basic steps that you need to follow to configure PPP. You must be logged in as root.

• Make sure that the serial port and modem are operating correctly. Using a program like minicomm or kermit, you should be able to send AT commands to the modem and receive the OK string in response from the modem.
• Enter the primary and possibly secondary Domain Name Server IP addresses in the /etc/resolv.conf file, using dotted quad notation, with the nameserver label. For example:

  order hosts,bind nameserver 196.182.101.103 nameserver 196.182.101.104

  The nameserver addresses in the example above are examples only. They don't correspond to actual network hosts. The first line, order hosts,bind, tells your networking software, when it resolves network domain addresses, to first look in the /etc/hosts file, and then use the bind service; i.e., the DNS servers, which are specified on the lines that begin with nameserver.

• Locate the chat script that PPP will use to dial the modem and connect to your ISP. In many systems, this is either in the /etc/chatscripts or /etc/ppp directory, and will be called provider or something similar. You can store a chat script anywhere, provided that you tell pppd to use it rather than the default script. Refer to the chat and pppd manual pages, and the information below, for details. Here is a sample chat script:

  ABORT BUSY ABORT "NO CARRIER" ABORT VOICE ABORT "NO DIALTONE" "" ATDT<your_isp's_phone_number> ogin <your_user_name> word <your_password>

  This is a chat program for a simple, script based login. The chat program uses the pair of strings on each line as a match/response pair. When it starts, it sends the string "ATDTyour_isp's_phone_number," where you have substituted the actual phone number of course. It then waits for the string ogin (a substring of the word login) and sends your user name. It then waits for word (a substring of password) and sends your password. If your ISP uses a different login and password prompts, and any additional prompts, you will need to edit the script accordingly. Again, refer to the chat manual page for details.

  If your ISP uses PAP or CHAP authentication, you will need to edit the pap-secrets or chap-secrets files in /etc/ppp directory as well. Refer to the manual pages for these files, as well as the instruction in the files themselves.

• The configuration of pppd, the program that maintains the actual connection, is usually contained in two or three separate files. The first is usually /etc/ppp/options, which contains options that all of your system's PPP connections will use. (Yes, you can have more than one; as many as your computer has serial ports, generally.)

  Here is a sample /etc/ppp/options file:

  #/etc/ppp/options asyncmap 0 auth crtscts lock noipx # ---<End of File>---

  The options may be given on one line or each on a separate line. Many options files are much longer, and come with a description of each option. Here, the options mean, in order, don't remap any characters between the PPP client and server; always use password, PAP, or CHAP authentication when making a connection; use the modem's hardware handshake lines for flow control; lock the serial port when in use so no other programs can access it; and do not use the IPX network protocol.

• For connection set-up on each individual serial port or PPP host, there will either be an /etc/ppp/options.ttyS1, for example, options file for /etc/ttyS1, or a file for your ISP in the /etc/ppp/peers directory. The default is often called /etc/ppp/peers/provider. Here is a sample of the default provider file:

  noauth connect "/usr/sbin/chat -v -f /etc/chatscripts/provider" defaultroute /dev/ttyS1 38400 persist

  There might be an explanation of these and other options in the /etc/ppp/peers/provider file itself. You can also refer to the pppd manual page for details. Briefly, they mean: do not use PAP authentication for this connection; use the chat program and the /etc/chatscripts/provider script, which is described above, to dial the phone and log in; set the network default route to the PPP connection (so when your network software needs to resolve an network address that is not on your local machine(s), it will use the PPP connection to the Internet); use /dev/ttyS1 as the serial port for the connection; set the modem speed to 38400; and keep the pppd daemon running even if the connection fails.

That is all of the configuration you need. To actually start and stop PPP, there are often /usr/bin/pon and /usr/bin/poff scripts (in Debian), or something similar, and they are usually very simple, and only contain the command:

$ /usr/sbin/pppd call ${1:-provider}

This will start pppd and use the call option to call the server that you type on the command line, or the provider given in the /etc/ppp/peers/provider file if you do not specify a remote server. After making the call and logging in (about 30 seconds), you should be able to use the /sbin/ifconfig program to determine that the connection really did establish a PPP interface (the first will be ppp0, the second will be ppp1, etc., depending on how many simultaneous PPP connections you have. If something goes wrong, you can look at the /var/log/ppp.log file to determine what happened. You can also view the log as the connection is being made, by "tailing" it in another window; that is, viewing it as pppd logs the connection's status information. To do this, use the command (again, as root):

$ tail -f /var/log/ppp.log

On some systems the PPP output is directed to /var/log/messages, in which case your system may not have a dedicated PPP log file.

You should be also able to ping one of your ISP's domain names (e.g., mail.isp.com) and receive a response.

These are the most basic steps for configuring a PPP connection. You will also need to take into account what other network connections may be present (for example, if there's an Ethernet connection that has already been assigned the default route), as well as various security measures at your ISP's end. If you're having trouble making the dial-up connection, usually the best way to determine what may be going wrong is to use Seyon, minicomm, kermit, or some other program to dial and log in manually to the ISP, and determine just exactly what you have to do to log in, then duplicate that in the PPP scripts.

Most Linux documentation also has additional instructions for configuring PPP connections.

Refer to Where Are the Linux FTP Archives? and Where Is the Documentation?.

A: The www.CablemodemInfo.com and xDSL Web page at http://www.cablemodeminfo.com has a section devoted to Linux.

See also the Cable-Modem-HOWTO at the LDP.

A: See the NFS-HOWTO for up to date information.

A: This information is partly taken from Nicolai Langfeldt's excellent NFS HOWTO, and is current as of 10/1/1999:

Most version 2.2.x kernels need a set of patches to install the knfsd subsystem, maintained by H.J. Lu, to communicate efficiently (if at all) with Sparc, IBM RS, and Alpha machines, and probably others. This package is actually a collection of patches to the kernel sources. Better support for non-Intel architectures is included in the 2.4 kernels.

There is also a user-space server. Although it lacks remote file locking, it is easier to install. It may be equally efficient.

In the Documentation/Changes of recent kernel distributions, there is a list of URL's for both the knfsd server and the user-space server.

In the case of older Solaris releases, the lack of statd or lockd on a client or server machine may cause incompatibility. On some versions of Solaris, statd can be used to exploit features of the automounter. Sun released a patch to correct this, but statd still needs to be started by root on such systems. On recent Solaris systems, refer to the information in /etc/dfs/dfstab and the share(1M) manual page to enable volume sharing. In addition, the rpcinfo program can tell you if statd or lockd are available on the local or remote machines.

The linux-kernel mailing list has on-and-off discussions of the status of the NFS subsystem, which appears to be changing rapidly.

[Nicolai Langfeldt, Robert Kiesling, Anders Hammarquist]

A: Virtual File System. It's the abstraction layer between the user and real file systems like ext2, Minix and MS-DOS. Among other things, its job is to flush the read buffer when it detects a disk change on the floppy disk drive.

VFS: Disk change detected on device 2/0

A: Linux supports read/write access of Windows for Workgroups and Windows NT SMB volumes. See the file Documentation/filesystems/smbfs.txt of the Linux kernel source distribution, and How To Upgrade/Recompile a Kernel.

There is also a suite of programs called Samba which provide support for WfW networked file systems (provided they're for TCP/IP). Information is available in the README file at metalab.unc.edu/pub/Linux/system/network/samba/.

The SMB Web site is http://www.samba.org, and there is also a Web site at samba.anu.edu.au/samba/.