diff --git a/Manuals/Tcpi-ug/Connectivity/Dialup.docbook b/Manuals/Tcpi-ug/Connectivity/Dialup.docbook new file mode 100644 index 0000000..da9df35 --- /dev/null +++ b/Manuals/Tcpi-ug/Connectivity/Dialup.docbook @@ -0,0 +1,11 @@ + + + IP Over Telephone Line + + &connectivity-dialup-overview; + &connectivity-dialup-policy; + &connectivity-dialup-modem; + &connectivity-dialup-server; + &connectivity-dialup-client; + + diff --git a/Manuals/Tcpi-ug/Connectivity/Dialup/client.docbook b/Manuals/Tcpi-ug/Connectivity/Dialup/client.docbook new file mode 100644 index 0000000..f28598a --- /dev/null +++ b/Manuals/Tcpi-ug/Connectivity/Dialup/client.docbook @@ -0,0 +1,17 @@ + + + The Client Computer + + + When you are configuring the client computer, you need to + install the wvdial, pppd + and system-config-network packages. From + these packages, to configure your Modem connection, you only + need to use the interface provided by the + system-config-network package. This + interface controls configuration files related to + pppd and + wvdial programs for you. + + + diff --git a/Manuals/Tcpi-ug/Connectivity/Dialup/modem.docbook b/Manuals/Tcpi-ug/Connectivity/Dialup/modem.docbook new file mode 100644 index 0000000..5f38cfa --- /dev/null +++ b/Manuals/Tcpi-ug/Connectivity/Dialup/modem.docbook @@ -0,0 +1,147 @@ + + + The Modem Device + + + In order to establish a PPP link between two computers using + the telephone line as medium for data transmission, you need + to install and configure (at least) one Modem device in each + computer. + + + + Installing Modem Devices + + To install a Modem device in a computer you need to attach the + Modem hardware to the computer and later the telephone line to + the Modem hardware. To attach the Modem hardware to your + computer, you need to connect the serial or USB cable that + comes from the Modem hardware to the appropriate input on your + computer. To connect the Modem hardware to the telephone line + system, you need to unplug the cable that connects your + telephone device and plug it on the Modem device, specifically + in the port reserved for data transmission. Later, using a + similar cable, you could connect your telephone device to the + Modem's telephone port, so you can realize telephone calls + when no data transmition take place, as well. + + + + To be on the safe side, do all the installation with the + computer turned off. Then, when everthing has been put in + place, turn the computer on. Once the system is up, you can + verify the Modem hardware using either the + lsusb or lspci commands. + These commands need to be run with administrative privileges, + so probably need to sudo them or login as + root user in order + to execute them. For example, assuming you are logged in as + root user, and you + are using an USB Modem like that one we mentioned before, the + output of lsusb command would look like the + following: + + + +Bus 003 Device 001: ID 0000:0000 +Bus 001 Device 001: ID 0000:0000 +Bus 001 Device 002: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader +Bus 002 Device 001: ID 0000:0000 +Bus 005 Device 003: ID 06e0:f104 Multi-Tech Systems, Inc. +MT5634ZBA-USB MultiModemUSB (new firmware) +Bus 005 Device 001: ID 0000:0000 +Bus 005 Device 002: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse +Bus 004 Device 001: ID 0000:0000 + + + + The relevant line here is that one mentioning the existence of + a Multi-Tech System, Inc. MT5634ZBA-USB MultiModemUSB + (new firmware) device. This line confirms that your + Modem hardware is supported by &TCD; and it is possible to + transmit data through it. Otherwise, if the Modem you + installed doesn't appear in this list, it is probably because + such hardware is not supported by &TCD;, yet. + + + + Once you have confirmed the Modem hardware has been installed + in the computer (either client or server), you need to + determine the device name the operating system assigned to it. + This information is required by programs like + mgetty and + wvdial, so they can know what + device to talk to. Assuming you've connected your Modem + device through an USB port, the operating system might use the + the /dev/ttyACM0 file to talk to it. On + the other hand, assuming you've connected your Modem device + through a serial port, the operating system might use the + /dev/ttyS0 file to talk to it. To be + absolutly sure about what device name the operating system + assigned to your Modem hardware, you can use the + wvdialconf program from + wvdial package or the + lshal command from hal + package. + + + + + Configuring Modem Devices + + Modem devices are configured through + system-config-network command. This command + produces Modem configuration files under the + /etc/sysconfig/network-scripts directory. + Configuration related to Modem devices can take different + file names, but they can be clearly identified by the value + set on the DEVICE variable, inside the + configuration file. This variable can take names like + ppp0 for the first Modem device, + ppp1 for the second Modem device, and so on for + other Modem devices. The Modem configuration files are used + by pppd and + wvdial programs when a PPP + connection is established between two computers. If you are + runing mgetty and pppd to attend incoming calls, it is very + important that you also specify the IP address and the network + mask in the configuration file of the Modem device you are + using to establish the connection. Otherwise, if the remote + peer doesn't set the IP information for you, it would be + difficult for both computer to establish a permanent + interchange of data across the link created. + + + +# Please read /usr/share/doc/initscripts-*/sysconfig.txt +# for the documentation of these parameters. +TYPE=Modem +DEVICE=ppp0 +BOOTPROTO=none +ONBOOT=no +USERCTL=yes +PEERDNS=yes +AC=off +BSDCOMP=off +VJCCOMP=off +CCP=off +PC=off +VJ=off +LINESPEED=115200 +MODEMPORT=/dev/ttyACM0 +PROVIDER=ProviderName +DEFROUTE=yes +PERSIST=no +PAPNAME=a +WVDIALSECT=ProviderName +MODEMNAME=Modem0 +DEMAND=no +IPV6INIT=no +IDLETIMEOUT=600 +NETMASK=255.255.255.0 +IPADDR=192.168.0.2 + + + + + diff --git a/Manuals/Tcpi-ug/Connectivity/Dialup/overview.docbook b/Manuals/Tcpi-ug/Connectivity/Dialup/overview.docbook new file mode 100644 index 0000000..98e0254 --- /dev/null +++ b/Manuals/Tcpi-ug/Connectivity/Dialup/overview.docbook @@ -0,0 +1,59 @@ + + + Overview + + + This manual describes the configuration of two computers, one + acting as server and other as client. The server computer (see + ) will be + configured to provide internet services and the client + computer (see ) + to make use of those internet services. The connection medium + used by both client and server computer is the telelphone line + (i.e., the same medium you use to realize telephone calls). + In this configuration, both client and server computers use + special devices named Modems to transmit data + in form of sound across the telephone line (see ). + + + + This infrastructure is made available to you free of charge, + however, you should know that maintaining it might cost you + both money and time. For example, for each hour the server + computer is on production there is an electrical consume that + need to be paid every month. Likewise, each call that you + establish from the client computer to the server computer will + cost you money, based on the location you made the call from + and the time you spend connected. + + + + To use this infrastructure, people connecting from the client + computers to the server computer must agree the conditions + described in . + + + + It is worth to mention that, you can configure one computer to + act both as server and client. In this case, your computer + acts as client of another server computer, not the one you + have configured in the same computer of your client (i.e., you + cannot call yourself and expect to answer any incoming call + using the same line you used to make the outgoing call, it + doesn't make any sense). Likewise, your server will act as + server for another client computer, not the one you have + configured. In resume, you can both receive incoming calls or + realize outgoing calls using the same telephone line, but only + when the telephone line is free from any incoming or outgoing + call. + + + + This infrastructure could result very useful to you when you + want to share IP packages with your friends and the only + communication medium you and your friends have access to is a + telephone network. + + + diff --git a/Manuals/Tcpi-ug/Connectivity/Dialup/policy.docbook b/Manuals/Tcpi-ug/Connectivity/Dialup/policy.docbook new file mode 100644 index 0000000..ef344f1 --- /dev/null +++ b/Manuals/Tcpi-ug/Connectivity/Dialup/policy.docbook @@ -0,0 +1,606 @@ + + + Terms Of Usage + + + About PPP Authentication + + + The credential required by the client computers to establish + dial-up connection with the server computer are always the + same. There is only one public username and password for all + client computers that must be used in order to establish + dial-up connection with the server computer. This information + is the following: + + + + ISP Name: projects.centos.org +ISP Phone: +53043515094 + Username: faith + Password: mail4u.2k10 + + + + The client computer can use this information to establish + connection to the server computer using any telephone number + from 10:00PM to 12:00AM. Notice how there is only one + telephone line available (e.g., +53043515094) in the server + computer to receive incoming calls. The number of telephone + lines directly affects the possibilities a client computer has + to establish connection with the server computer in an + environment where more than one client computer are struggling + among themselves to establish a dial-up connection with the + server computer. To prevent this issue from happening, it is + innevitable for the server computer to provide more telephone + lines for incoming calls (at least one for each user the + server computer expects to receive incoming calls from). + Sadly, that is not possible at present time. + + + + + + About PPP Networking + + + The simpliest configuration we can achive over the telephone + network involves two computers only where one computer would + be acting as server and another as client. In this + configuration, the client computer establishes connection to + the server to make use of internet services provided therein. + + + + When the client computer calls the server computer, the call + is attended by mgetty and then passed pppd to establish a PPP + conversation. The first thing in the conversation is + authentication and if it passes then IPCP conversation takes + place to set IP addresses and start transmitting data over the + link. IP addresses need to be set when the Modem device is + configured (see ) or you can + leave it to the server computer to assign them for you + (assuming you are calling a server computer to establish + connection to it). If you are configuring a server computer, + then it is necessary that you set the IP address and netmask + of the IP network you are planning to set through a Modem + device (e.g., ppp0). + + + + Specifiying the IP information on the server computer is very + important, otherwise the network created may end up undefined + and this would provoke errors on data transmission. When the + server computer doesn't set the network mask in the Modem + device configuration file, the pppd daemon would try to retrive + such information from the client computer and if the client + computer didn't specify either, the network recently created + would end up having a wrong network mask (e.g., 255.255.255.255) which provokes + the network to fail when someone tries to transfer data + through it. + + +
+ Simple networking over telephone line + + Simple networking over telephone line + + + +Provice-A PPP Server Province-A PPP Client +--------------------------\ /-------------------------- +192.168.0.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.0.2/24 +--------------------------/ \-------------------------- + + + + +
+ + + The + describes the simpliest configuration we can implement for a + point-to-point connection. This configuration involves two + computers only, one acting as server (the server computer) and + other action as client (the client computer). The client + computer calls the server computer to establish a PPP + connection in order to use whatever internet service the + server computer provides. In the figure we can see that there + are two IP addresses involved (192.168.0.1 and 192.168.0.2) inside the same + newtork (255.255.255.0). + + + + This configuration might be convenient for people in the same + location, near one another. Here, the client computer + establishes connection locally and can use whatever internet + service the server computer provides. Since the connection + lifetime is limited (see ) and only two + peers can be connected at the same time (assuming only one + modem is attached to the server computer), the implementation + of some internet services like chat aren't a practical offer + for the server computer to provide. However, internet + services like e-mail fit perfectly on an environment where + more than one client computer will be struggling among + themselves for establishing connection with the server + computer (e.g., people connect to send/receive their e-mail + messages to/from the server computer). + + + + + + About Extending PPP Networking + + + Based on , it is + possible to provide an extended version including several + server computers that may communicate between themselves to + distribute data collected by the client computers they serve + to. For example, consider the telephone network of a country + which is organized in provinces and each province is divided + in several municipalities. In such organization, it would be + possible to set one or more server computers for each province + and let near people to dial-up on them to use whatever + internet service they provide. Later, it could be possible + for each server computer to establish a dial-up connections + with other near server computers in order to share information + from one province to another. This configuration is + illustrated in . + + + + In this configuration, if someone in Province-A needs to send + a message to someone in Province-C (which is far away from + Province-A and making a telephone call there would imply a + considerable amount of money), there is no need (even it is + possible) for that person to realize a direct telephone call + from Province-A to Province-C. Instead, that person in + Province-A can send its messages to server A (the nearest + server on its location) making a local telephone call and + then, the server A would take care of delivering the + information using other servers following the same concept of + nearest delivery. + + +
+ Extended networking over telephone line + + Extended networking over telephone line + + + +Provice-A PPP Server Province-A PPP Client +--------------------------\ /-------------------------- +192.168.0.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.0.2/24 +--------------------------/ | \-------------------------- + | +Provice-B PPP Server | Province-B PPP Client +--------------------------\ | /-------------------------- +192.168.0.3/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.0.4/24 +--------------------------/ | \-------------------------- + | +Provice-C PPP Server | Province-C PPP Client +--------------------------\ | /-------------------------- +192.168.0.5/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.0.6/24 +--------------------------/ \-------------------------- + + + + +
+ + + The more distant a telephone call is, the more expensive it + is. This way, to move information from one province to + another, server computers must be configured to send + information to the nearest province until reaching its + destination. For example, if you are in Province-A and want to + send an e-mail message to Province-D, the server computer + configuered in Province-A must sed the e-mail message to + Province-B, then server in Province-B must be configuered to + send such message to Province-C, and then C to D. This is + required because making a direct call from Province-A to + Province-D would be too much expensive. + + + + Since telephone calls are required to establish connections + between computers and each call costs money based on the + location and the destination, it is required to set a + convenction in this area, specially if you plan to realize + interprovincial telephone calls to interchange data with computer + servers on different provinces. + + + + + + Do you make direct telephone calls to make direct data delivery? + — This configuration could be very expensive to maintain + (considering the telephone call distances), but data will be + delivered very fast to their destinations. + + + + + Do you call the nearest server computer and let it to deliver + your data to its destination? — This configuration could + be less expensive to maintain (considering the telephone call + distances), but data delivery will take much more time to + reach their destinations (and there is no way to be sure it + will do). + + + + + + + Whatever calling schema be choosed, the server computers will + always talk through UUCP to transfer data from one place to + another. The server computers will operate with two IP + addresses each, unless you plan to connect one of the server + computers to a different network (Internet, maybe?). One IP + address would identify the server computer itself and the + other would identify the client computer establishing + connection to the server computer. In this configuration it + is very importat that each server and client computer does + have one unique IP address. This way it would be possible to + move the information from one computer to another. Notice that + the number of PPP clients is directly related to the number of + telephone lines a server computer has configured to receive + incomming calls. If there is only one telephone line attached + to the server computer then, only one client computer will be + able to establish connection to that server computer. Other + PPP clients will need to wait until the telephone line gets + free in order to establish connection with that server + computer. On the other hand, if the server computer has two + (or more) attached telephone lines, it would be possible to + attend incoming calls from two (or more) PPP client at the + same time. As resume, we can say that: the more telephone + lines the server computer has attached in, the more + simultaneous connections that computer will be able to + attend/realize from/to other computers. + + + + + + About Extending PPP Networking With Ethernet + + + Assuming all the server computers with a Modem interface + attached have also one (or more) Ethernet interface attached + (which is very common nowadays), it would be possible to + extend the configuration described in + creating one Ethernet network for each server and client + computer in the configuration. For this configuration to be + implemented it is also required one switch device for each + computer with having both the Ethernet and Modem interface, as + described in . + + +
+ PPP+Ethernet networking over telephone line + + PPP+Ethernet networking over telephone line + + + +Province-A PPP/ETH Server Province-A PPP Client +--------------------------\ /-------------------------- +192.168.0.1/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.0.2/24 +--------------------------/ | \-------------------------- +192.168.1.1/24 | Ethernet | +---------------------|---- | + | | + +--------+ | + | Switch | | + +--------+ | + | | +---------------------|-- | +LAN1: 192.168.1.2-254/24 | +------------------------ | +Province-A ETH Clients | + | +Province-B PPP/ETH Server | Province-B PPP Client +--------------------------\ | /-------------------------- +192.168.0.3/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.0.4/24 +--------------------------/ | \-------------------------- +192.168.2.1/24 | Ethernet | +---------------------|---- | + | | + +--------+ | + | Switch | | + +--------+ | + | | +---------------------|-- | +LAN2: 192.168.2.2-254/24 | +------------------------ | +Province-B ETH Clients | + | +Province-C PPP/ETH Server | Province-C PPP Client +--------------------------\ | /-------------------------- +192.168.0.5/24 | Modem ~~~ TelephoneLine ~~~ Modem | 192.168.0.6/24 +--------------------------/ \-------------------------- +192.168.3.1/24 | Ethernet +---------------------|---- + | + +--------+ + | Switch | + +--------+ + | +---------------------|-- +LAN3: 192.168.3.2-254/24 +------------------------ +Province-C ETH Clients + + + + +
+ + + In this configuration, computers connected to the switch will + also be considered as client computers. It is necessary that a + coordination be implemented at time of setting IP addresses to + new server computers so no IP address be duplicated. The + illustration above, describes one main network (192.168.0/24) + which connects all the server computers using the telephone + lines as medium for data transmission. Using the Modem + interface it is possible to connect just one client computer + at a time (assuming only one modem is availalble in the server + computer). + + + + The telephone line is used by client computers to establish + PPP connections with the server computer and by server + computers to interchange data with other server computers, as + well. On the other hand, the ethernet interface attached to + each server computer let the administrator of that server + computer to connect up to 252 computers simultaneously. + + + + + + About Domain Names + + Domain names and host names are another important topic to + take care of, specially in a distributed network like those + described in and + . + Likewise IP address, names assigned to computers (both clients + and servers) must be unique. Each unique computer name is + associated to one unique IP address. Based on the nature of + point-to-point connections, there is no way for the Province-A + to know names in Province-D unless they be defined on + Province-A. In this point-to-point configuration there isn't a + top level name resolution so it isn't possible to find out + such names. Each computer in this configuration must define + the names of their closest server computer only, using BIND + (without recursion) or the /etc/hosts + file, as prefered. + + + ++------------------------+ +------------------------+ +------------------------+ +---------------------+ +| To: bob@d.domain.tld | | To: bob@d.domain.tld | | To: bob@d.domain.tld | | Bob's mailbox | +| From: mat@a.domain.tld | | From: ana@b.domain.tld | | From: jef@c.domain.tld | | (Final destination) | +| Body: 500KB | | Body: 500KB | | Body: 500KB | | | ++---|--------------------+ +---|--------------------+ +---|--------------------+ +------------------^--+ + | | | | +----v--------------|<~~~~~~~~~>|---v----------------|<~~~~~~~~~>|---v----------------|<~~~~~~~~~>|------------------|--- +srv-1.a.domain.tld | 75Km Call | srv-1.b.domain.tld | 75Km Call | srv-1.c.domain.tld | 75Km Call | srv-1.d.domain.tld +-------------------|<~~~~~~~~~>|--------------------|<~~~~~~~~~>|--------------------|<~~~~~~~~~>|---------------------- +relay to: | 5 min | relay to: | 10 min | relay to: | 15 min | +srv-1.b.domain.tld | 500KB | srv-1.c.domain.tld | 1.0MB | srv-1.d.domain.tld | 1.5MB | + + + + When the server computers call other server computers to + bridge data delivery, the server computer in Province-A + (srv-1.a.domain.tld) will never know that there is a server + computer on Province-C (srv-1.c.domain.tld) or Province-D + (srv-1.d.domain.tld), but in Province-B (srv-1.b.domain.tld) + only, its nearest location. So, when a message is sent from + srv-1.d.domain.tld to the server computer in + srv-1.d.domain.tld, the server computer in srv-1.a.domain.tld + contacts its nearest server computer (i.e., + srv-1.b.domain.tld) and delivers to it all messages sent to + srv-1.d.domain.tld. Later, since srv-1.b.domain.tld doesn't + know about srv-1.d.domain.tld server either, it delivers all + messages directed to srv-1.d.domain.tld to its nearest server + computer (i.e., srv-1.c.domain.tld). Later, the server + computer in srv-1.c.domain.tld, which knows about + srv-1.d.domain.tld, delivers to it all the messages it has for + it. Notice that, in order for this configuration to work, it + is required that all the server computer administrators do + work syncronized to garantee a well defined route for messages + to follow. Otherwise, if one of the server computers in the + path creates a route for a server computer that doesn't exist + (or doesn't define a route at all), the information will never + reach its destination when such computer is acting as a bridge + between the origen and the target server computer. + + + ++------------------------+ +---------------------+ +| To: bob@d.domain.tld | | Bob's mailbox | +| From: mat@a.domain.tld | | (Final destination) | +| Body: 500KB | | | ++--|---------------------+ +------------------^--+ + | | +---v---------------------|<~~~~~~~~~~>|-------------------|--- +srv-1.a.domain.tld | 225Km Call | srv-1.d.domain.tld +-------------------------|<~~~~~~~~~~>|----------------------- +relay to: | 5 min | +srv-1.d.domain.tld | 500KB | + + + + When the server computers make direct telephone calls (no bridge + in-between is used to transfer data), the server computer in + Province-A (srv-1.a.domain.tld) contacts the server computer + in Province-D (srv-1.d.domain.tld) making a direct telephone call + to it. In this configuration, the telephone call might cost more + than a bridged configuration where several smaller telephone calls + are dialed between the data origin and the data destination; + or less, considering that when server computers in a bridged + configuration interchange data they may move data accumulated + from other server computers, while a direct telephone call would + transmit data from one server computer to another without + intermediate steps. There is no need to overload the server + computers with foreign data when each server computer could + call themselves to transfer data directly. + + + + The elapsed time in a server-to-server conversation is + directly related to the amount of data that need to be moved + from one server to another. In a direct telephone call + configuration, telephone calls could result to be less + expensive than those in bridged configurations where server + computers may accumulate traffic from other server computers + in the path. The accumulation of traffic between server + computers increases the amount of time the last server + computer in the path before the final destination needs, in + order to transmit everything to the final destination. In a + bridged telephone call configuration, server computers acting + as bridges do act as servers as well and produce their own + traffic which is sumed to that one already accumulated in + them. This may provoke a heugh traffic in a server-to-server + conversation (remarkably on the last destination before the + final destination), that could be potentially increased with + each new server computer added to the string of server + computers acting as bridges one another. + + + + + + About Established Connection Lifetimes + + + The server computer restricts the lifetime of established + Modem connections to 15 minutes from the establishment moment + on. Once the connection has been established, if the link is + idle for 1 minute, the server computer will also close the + established connection to free the telephone line. This + control can be implemented through the + and options + inside the pppd's configuration + file. + + + + The server computer will attend incoming calls from client + computers every night from 10:00PM to 12:00AM. Outside this + range of time, the telephone could be answered by somebody, + not the computer. This control can be implemented through a + cron job and the /etc/nologin.ttyxx file; + where ttyxx represents the device name of your modem (e.g., + /etc/nologin.ttyACM0 would prevent the + Modem device installed in /dev/ttyACM0 + from answering calls). + + + + + + About Supported Services + + + The implementation of services that required persistent + connections (e.g., chats) should + not be considered as a practical offer inside the server + computer. Instead, only asynchronous services (e.g., + e-mail) should be supported. This + restriction is required to reduce the connection time demanded + by services. For example, consider an environment where you + connect to the server computer for sending/receiving e-mails + messages and then quickly disconnect from it to free the + telephone line for others to use. In this environment, there + is no need for you and other person to be both connected at + the same time to send/receive e-mail messages to/from each + other. The e-mails sent from other person to you will be + available in your mailbox the next time you get connected to + the server computer and use your e-mail client to send/receive + e-mail messages. Likewise, you don't need to be connected to + the server computer in order to write your e-mail messages. + You can write down your messages off-line and then establish + connection once you've finished writing, just to send them out + and receive new messages that could have been probably sent to + you. + + + + Another issue related to e-mail exchange is the protocol used + to receive messages. Presently, there are two popular ways to + do this, one is through IMAP and another through POP3. When + you use IMAP protocol, e-mail messages are retained in the + server computer and aren't downloaded to client computer. + Otherwise, when you use POP3 protocol, e-mail messages are + downloaded to the client computer and removed from server + computer. Based on the resources we have and the kind of link + used by the client computer to connect the server computer, + using POP3 is rather prefered than IMAP. However both are made + available. + + + + Assuming you use IMAP protocol to read your mailbox, be aware + that you need to be connected to the server computer. Once + the connection is lost you won't be able to read your messages + (unless your e-mail client possesses a feature that let you + reading messages off-line). Moreover, you run the risk of + getting your mailbox out of space. If your mailbox gets out of + space, new messages sent to you will not be deliver to your + mailbox. Instead, they will be deferred for a period of time + (e.g., about 5 days when using + Postfix defaults) hoping you to + free the space in your mailbox to deliver them. If you don't + free space on your mailbox within this period of time, the + deferred e-mails will be bounced back to their senders and you + will never see them. On the other hand, assuming you are + using POP3 protocol to read your mailbox, you always keep your + mailbox free to receive new e-mails messages and keep them for + you until the next time you establish connection with the + server computer and download them to your client computer + using your e-mail client. + + + + The information generated inside the server computer is + isolated from Internet. This way, any information generated + inside the server computer will be available only to people + connected to the same network the server computer is connected + to. For example, don't ever expect to send/receive e-mails + to/from Internet e-mail accounts like Gmail or Yahoo, nor + visiting web sites like Google or Wikipedia either. For + this to happen, it is required an established connection + between the server computer you are establishing connection + through and the Internet network those services are available + in. Without that link, it is not possible to direct your + requests to those sites. + + + + + diff --git a/Manuals/Tcpi-ug/Connectivity/Dialup/server.docbook b/Manuals/Tcpi-ug/Connectivity/Dialup/server.docbook new file mode 100644 index 0000000..a791c1c --- /dev/null +++ b/Manuals/Tcpi-ug/Connectivity/Dialup/server.docbook @@ -0,0 +1,288 @@ + + + The Server Computer + + + When you are configuring the server computer, you need to + install and configure both mgetty + and pppd programs. The + mgetty program lets you attend + incoming calls and must be configured to run through + init daemon in order + to take control over the Modem device. By default, inside + &TCD; (release 5.5), mgetty isn't + configured to start with init daemon so you need to do it + yourself (see ). + Later, for attending connection requests, you need to + configure mgetty to use the + pppd program, so the Point-to-Point + Protocol (PPP) can be talked and IP packages can be + interchanged between the client computer and the server + computer. Later, you need to configure + pppd to adjust it to your needs + (see )Once you've configured both + mgetty and + pppd programs, the server computer + should be ready to attend incoming calls. + + + + <package>mgetty</package> + + Taken from mgetty man page: — Mgetty + is a smart getty replacement, designed to be + used with hayes compatible data and data/fax modems. Mgetty + knows about modem initialization, manual modem answering (so + your modem doesn’t answer if the machine isn’t ready), UUCP + locking (so you can use the same device for dial-in and + dial-out). Mgetty provides very extensive logging facilities + —. + + + Before using the configuration provided here, it would be + useful for you to read the documentation provided by + mgetty and SysVinit + packages. This will let you to understand what you are + configuring. + + + + <filename>/etc/inittab</filename> + +# Run mgetty to control a Multi-Tech (MT5634ZBA-USB) modem attached to +# `/dev/ttyAMC0' device. Incoming calls will be attended without fax +# initalization. +ACM0:2345:respawn:/sbin/mgetty -D ttyACM0 + + + + + <filename>/etc/mgetty+sendfax/login.config</filename> + +# Automatic PPP startup on receipt of LCP configure request (AutoPPP). +# mgetty has to be compiled with "-DAUTO_PPP" for this to work. +# Warning: Case is significant, AUTOPPP or autoppp won't work! +# Consult the "pppd" man page to find pppd options that work for you. +# +# NOTE: for *some* users, the "-detach" option has been necessary, +# for others, not at all. If your pppd doesn't die after hangup, try +# it. +# +# NOTE2: "debug" creates lots of debugging info. LOOK AT IT if +# things do not work out of the box, most likely it's a ppp problem! +# +# NOTE3: "man pppd" is your friend! +# +# NOTE4: max. 9 arguments allowed. +# +#/AutoPPP/ - a_ppp /usr/sbin/pppd auth -chap +pap login debug +/AutoPPP/ - a_ppp /usr/sbin/pppd 192.168.0.2:192.168.0.3 + + + + Notice that both local and remote IP address are set here. All + other options are taken from the options + file (see ). If we + don't specify both local and remote IP addresses when pppd is + initialized, pppd will try to take such information from the + first Modem device you configured (e.g., ppp0) and will expect + the remote peer to provide its IP address. This situation can + introduce some contraditions (e.g., the local and remote + address may be on a different network.) that would make the + connection to fail. + + + + Another issue we might face out would be the netmask + specification of the poin-to-point network established between + the two computers. Inside the pppd-2.4.4 man page there is no + reference to the option, however, + there is a mention to it on the sample files installed with it + which is quiet confussing. It seems to be required that one of + the two computers establishing connection defines the netmask + information of the network they are creating. So, to do it on + the server computer (the one receiving calls), it is needed to + set the netmask definition in the Modem device configuration + file of it () along with the local IP address. Otherwise, even local and + remote IP addresses be specified through the pppd, the + connection will end up having the 255.255.255.255 netmask + which would let you ping the computer on the other end but + that will not last too long before it fails and iptables seems + to get very confused about it. + + + + Since we are already using pppd to attend login requests, + there is no need to invoke the + login program. So, comment the + related line as described below. + + + +#* - - /bin/login @ + + + + + + <filename>/etc/mgetty+sendfax/dialin.config</filename> + + I didn't touch this file, but you might need to. + + + + + <filename>/etc/mgetty+sendfax/mgetty.config</filename> + + I didn't touch this file, but you might need to. + + + + + + + <package>pppd</package> + + Taken from pppd man page: — PPP is the protocol used for + establishing internet links over dial-up modems, DSL + connections, and many other types of point-to-point links. + The pppd daemon works together with the kernel PPP driver to + establish and maintain a PPP link with another system (called + the peer) and to negotiate Internet Protocol (IP) addresses + for each end of the link. Pppd can also authenticate the peer + and/or supply authentication information to the peer. PPP can + be used with other network protocols besides IP, but such use + is becoming increasingly rare —. + + + + Before using the configuration provided here, it would be + useful for you to read the documentation provided by + ppp package. This will let you to + understand what you are configuring. + + + + <filename>/etc/pppd/options</filename> + +# Enables connection debugging facilities. If this option is given, +# pppd will log the contents of all control packets sent or received +# in a readable form. The packets are logged through syslog with +# facility daemon and level debug. This information can be directed +# to a file by setting up /etc/syslog.conf appropriately (see +# syslog.conf(5)). +debug + +# Require the peer to authenticate itself before allowing network +# packets to be sent or received. This option is the default if the +# system has a default route. If neither this option nor the noauth +# option is specified, pppd will only allow the peer to use IP +# addresses to which the system does not already have a route. +auth + +# Specifies that pppd should create a UUCP-style lock file for the +# serial device to ensure exclusive access to the device. By default, +# pppd will not create a lock file. +lock + +# Specify which DNS Servers the incoming Win95 or WinNT Connection +# should use Two Servers can be remotely configured +ms-dns 192.168.0.1 + +# If this option is given, pppd will send an LCP echo-request frame to +# the peer every n seconds. Under Linux, the echo-request is sent when +# no packets have been received from the peer for n seconds. Normally +# the peer should respond to the echo-request by sending an +# echo-reply. This option can be used with the lcp-echo-failure +# option to detect that the peer is no longer connected. +lcp-echo-interval 30 + +# If this option is given, pppd will presume the peer to be dead if n +# LCP echo-requests are sent without receiving a valid LCP echo-reply. +# If this happens, pppd will terminate the connection. Use of this +# option requires a non-zero value for the lcp-echo-interval +# parameter. This option can be used to enable pppd to terminate +# after the physical connection has been broken (e.g., the modem has +# hung up) in situations where no hardware modem control lines are +# available. +lcp-echo-failure 4 + +# Specifies that pppd should disconnect if the link is idle for n +# seconds. +idle 60 + +# Specifies that pppd should disconnect if the link have been active +# for n seconds. +maxconnect 900 + +# Disable the IPXCP and IPX protocols. +noipx + + + + + <filename>/etc/pppd/cha-secrets</filename> + +# Secrets for authentication using CHAP +# client server secret IP addresses + +# Specify the client configuration. This is when this manchine calls +# someone's else machine and tries to establish a point-to-point +# connection. Most of this configuration is handled by the +# `system-config-network' utility. +# +####### redhat-config-network will overwrite this part!!! (begin) ########## +####### redhat-config-network will overwrite this part!!! (end) ############ + +# Specify the server configuration. This is when someone's else +# machine calls this machine trying to establish a point-to-point +# connection. This part of the configuration isn't handled by +# `system-config-network' utility. By default, there is one line to +# verify client's identity with authenticating it and one line to let +# the server computer to authenticate itself with the client computer +# in case the client computer requires so. All client computers will +# be authenticated through the `faith' user. However, it is possible +# to provide anonymous authentication to client computers by using an +# empty client identity (as explained in pppd's man page) in order to +# restrict the IP address they can use. +# +"faith" "projects" "mail4u.2k10" "192.168.0.3" +#"" "projects" "" "192.168.0.3" +"projects" * "mail4u.2k10" + + + + Assuming the hostname of the server computer is + projects, when a client computer uses the faith + username to login on it, the 192.168.0.3 IP address will be + assigned to that client computer after a successful + authentication. This configuration is just for one Modem + device attached to the server computer. In case you have more + than one Modem device attached to the server computer, it + would be necessary to add one username for each Modem device + you have, in order to permit the client computers to connect + simultaneously. It is not possible to have two or more + computers with the same IP address in the same network. + + + + + + <filename>/etc/pppd/pap-secrets</filename> + + This file contains the same information of + pap-secrets file does. See . + + + + + +