mirror of https://github.com/tLDP/LDP
Editing of new "Linux-Networking" guide. This copy is not to be distributed. Its just a draft to give people an idea as to the format of the new document and a backup just in case my laptop dies.
Binh.
This commit is contained in:
parent
027e2816b7
commit
bb17c58207
|
@ -72,7 +72,6 @@ Additional packages allow filtering based on IP, IPX or MAC addresses.
|
|||
mode, so they will look at every packet that passes by its interface:
|
||||
+---------------------------------------------------------------+
|
||||
|
||||
|
||||
Ethernet Bridge + netfilter Howto
|
||||
Nils Radtke <mailto:Nils.Radtke_@_Think-Future.de>
|
||||
v0.2, October 2002
|
||||
|
@ -87,7 +86,6 @@ Additional packages allow filtering based on IP, IPX or MAC addresses.
|
|||
|
||||
Table of Contents
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
2. Required software
|
||||
|
@ -655,14 +653,10 @@ Additional packages allow filtering based on IP, IPX or MAC addresses.
|
|||
|
||||
Please have a look at the ``Ping it, Jim!'' section.
|
||||
|
||||
|
||||
|
||||
4.4. Note
|
||||
|
||||
|
||||
Apparently, there must have been a bug in the br-nf code:
|
||||
|
||||
|
||||
From: Bart De Schuymer <bart.de.schuymer_@_pandora.be>
|
||||
Date: Sun, 1 Sep 2002 21:52:46 +0200
|
||||
To: Nils Radtke <Nils.Radtke_@_Think-Future.de>
|
||||
|
@ -675,12 +669,9 @@ Additional packages allow filtering based on IP, IPX or MAC addresses.
|
|||
br-nf patch. It can gives a lot of false warnings (about bugs) in the logs.
|
||||
[...]
|
||||
|
||||
|
||||
|
||||
Personally, I never had false positives in my log. Maybe, that bug has
|
||||
been fixed. This mailed to Bart, he wrote:
|
||||
|
||||
|
||||
From: Bart De Schuymer <bart.de.schuymer_@_pandora.be>
|
||||
Date: Mon, 2 Sep 2002 18:30:25 +0200
|
||||
To: Nils Radtke <Nils.Radtke_@_Think-Future.de>
|
||||
|
@ -695,15 +686,11 @@ Additional packages allow filtering based on IP, IPX or MAC addresses.
|
|||
it is still the case. It's on my todo list.
|
||||
[...]
|
||||
|
||||
|
||||
|
||||
But (as of writing this 2002-09-19) I haven't found an official
|
||||
announcement, this particular bug has been closed. So have a constant
|
||||
look at this topic on the ``ethernet bridge mailinglist'' , if you are
|
||||
interested in it's cure.
|
||||
|
||||
|
||||
|
||||
5. Links
|
||||
|
||||
The Howto's author may be contacted via e-mail <mailto:Ethernet-
|
||||
|
|
|
@ -11,38 +11,76 @@ bus network segment.
|
|||
|
||||
<para>
|
||||
Repeaters
|
||||
Connects network segments to extend total length.
|
||||
Repeaters connect network media to extend total length. The purpose of this
|
||||
device is to eliminate the effects if attenuation. However, as is outlined in
|
||||
the 'Foreward' section of this document it can sometimes inadvertently add
|
||||
'noise' to the network signal. Please see the 'Foreward' for further details
|
||||
on this device.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Hub
|
||||
Connects nodes to a central points in a star topolgy.
|
||||
Hubs connect nodes and network resources in a network to a central point in a
|
||||
star topology. It should be noted the the usage of these devices has largely
|
||||
been eliminated as the development of 'switch' and general 'switching-fabric'
|
||||
technology has delivered increased levels of speed and efficiency in network
|
||||
communication. Switches and routers are two types of hubs.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Switch
|
||||
Connects nodes to a central points in a star topolgy: sends packets to nodes
|
||||
based on MAC address.
|
||||
Switches connect nodes in a private network to a central point in a star
|
||||
topology. They send packets to nodes based on MAC address and provide
|
||||
roughtly the same functionality as 'routers' but much more efficiently
|
||||
and on a different level.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Bridge
|
||||
Filters and moves data between segments based on MAC address.
|
||||
Bridges filter and move data between segments based on MAC address.
|
||||
For example, an ethernet bridge is a device that controls data packets
|
||||
within a subnet in an attempt to cut down the amount of traffic. A bridge
|
||||
is usually placed between two separate groups of computers that talk
|
||||
within themselves, but not so much with the computers in the other group.
|
||||
A good example of this is to consider a cluster of Macintoshes and a
|
||||
cluster of Unix machines. Both of these groups of machines tend to be
|
||||
quite chatty amongst themselves, and the traffic they produce on the network
|
||||
causes collisions for the other machines who are trying to speak to one
|
||||
another. A bridge would be placed between these groups of computers. The
|
||||
job of the bridge is then to examine the destination of the data packets one
|
||||
at a time and decide whether or not to pass the packets to the other side of
|
||||
the ethernet segment. The result is a faster, quieter network with less
|
||||
collisions. Several bridges can work together to create even larger networks
|
||||
of Ethernets using the IEEE 802.1 spanning tree algorithm. As this is a
|
||||
standard, Linux bridges will interoperate properly with other third party
|
||||
bridge products. Additional packages allow filtering based on IP, IPX or MAC
|
||||
addresses. Please see the section on 'Bridges' for further details as to
|
||||
their purpose, usage and implementation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Router
|
||||
Filters and moves data between segments based on logical address.
|
||||
A special purpose computer, hardware device or software package that
|
||||
handles the connection between two or more packet-switched networks. Routers
|
||||
spend all their time looking at the logical source and logical destination
|
||||
addresses of the packets passing through them and deciding which route or
|
||||
host to send them on to. Please see the 'Routing' section for further details
|
||||
on this device.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Brouter
|
||||
Combines bridge and router capablities.
|
||||
A network device that combines bridge and router capablities.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Gateway
|
||||
Translates between protocols and data formats.
|
||||
The technical meaning is a hardware or software set-up that translates
|
||||
between two dissimilar protocols/data formats, for example America Online
|
||||
has a gateway that translates between its internal, proprietary e-mail
|
||||
format and Internet e-mail format. Another, sloppier meaning of gateway
|
||||
is to describe any mechanism for providing access to another system,
|
||||
e.g. AOL might be called a gateway to the Internet.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
<sect1 id="DNS">
|
||||
|
||||
<title>DNS</title>
|
||||
|
||||
Setting Up Your New Domain Mini-HOWTO.
|
||||
|
||||
This document outlines the things you will probably have to do when
|
||||
|
|
|
@ -2,6 +2,7 @@
|
|||
|
||||
<title>Diald</title>
|
||||
|
||||
<para>
|
||||
The purpose of dial on demand is to make it transparently appear that
|
||||
the users have a permanent connection to a remote site. Usually,
|
||||
there is a daemon who monitors the traffic of packets and where an
|
||||
|
@ -9,73 +10,81 @@
|
|||
rules/priorities/permissions) arrives it establishes a connection with
|
||||
the remote end. When the channel is idle for a certain period of time,
|
||||
it drops the connection.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This section shows some typical scenarios for easy start using Diald.
|
||||
These scenarios include a connection from a standalone computer to an
|
||||
ISP using PPP over a modem without using pon/poff or ppp-on/ppp-off to
|
||||
a proxy/firewall server with different Internet connections through
|
||||
various ISPs.
|
||||
______________________________________________________________________
|
||||
|
||||
|
||||
1.1. Objectives
|
||||
|
||||
This section shows some typical scenarios for easy start using Diald.
|
||||
These scenarios include a connection from a standalone computer to an
|
||||
ISP using PPP over a modem without using pon/poff or ppp-on/ppp-off to
|
||||
a proxy/firewall server with different Internet connections through
|
||||
various ISPs.
|
||||
|
||||
In the present document, the following scenarios will be treated:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Presently, the following scenarios will be treated:
|
||||
· Connecting a standalone computer to an ISP using a modem and PPP
|
||||
|
||||
· Conecting a computer to a group of different ISPs with a modem and
|
||||
PPP
|
||||
|
||||
· Connecting a proxy/firewall to an ISP using a modem and PPP
|
||||
</para>
|
||||
|
||||
In following versions of this document, other scenarios will be added,
|
||||
<para>
|
||||
However, in following versions of this document, other scenarios will be added,
|
||||
as multiple instances of Diald, ISDN lines and lines used to call and
|
||||
receive calls.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Before this document, a Diald-mini-Howto exist, wrote by Harish Pillay
|
||||
h.pillay@ieee.org, that presented and example of connection to an ISP
|
||||
using a chat based authentication scheme (login and password previous
|
||||
to the pppd start, with no use of PAP or CHAP).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Example configuration files will be included in this document to serve
|
||||
as starting point to get Diald up. To obtain maximum performance and
|
||||
all programs attributes, it is necesary you read all documentation
|
||||
from the programs and reconfigure the example configuration files
|
||||
included here.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, configuration files can be in different directories depending
|
||||
on what GNU/Linux distribution you are using. If you find a file
|
||||
commented here in other directory, please, write me.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
3. Quick Diald operation description
|
||||
|
||||
|
||||
In a few words, Diald creates a new network interface and sets it as
|
||||
the default gateway. This interface is not real (in the original
|
||||
documentation it is called proxy interface). Diald monitors this
|
||||
interface, and, when packets arrive, makes a ppp connection, waits for
|
||||
it to be stablished and changes the default gateway to this new ppp
|
||||
interface (usually ppp0).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Diald monitors the interface to determine which packets have been
|
||||
received the interface and their types to decide if they are going to
|
||||
be considered to set the ppp connection up, maintain the link, drop it
|
||||
or do nothing, and how long the link should be help up after the
|
||||
packet is transmitted.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Finally, if there is no more traffic and the last packet up time is
|
||||
over, Diald will close the link.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can control days and hours when the link can go up and when it
|
||||
cannot, so you can use the low cost hours/days or low trafic times.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This previous description is valid for Diald versions from 0.16.5 to
|
||||
latest (0.99.3 when this document was finished), but latest versions
|
||||
also include aditional attributes such as user enabled list, advanced
|
||||
|
@ -83,37 +92,43 @@
|
|||
ethertap device as proxy (this is like a network interface that
|
||||
read/writes over a socket instead of a real network adapter) in place
|
||||
of slip, backup connections and other functions.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
4. Note about authentication
|
||||
|
||||
|
||||
When you connect to an Internet Services Provider, it is usually
|
||||
necesary that you send an username and a password. This can be
|
||||
accomplished using several methods; the exact method that you use is
|
||||
determined by your provider.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Added to the three shown options, you can use a link without
|
||||
authentication, (generally when the remote end is also yours).
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
4.1. Username and password - Login and password prompts.
|
||||
|
||||
|
||||
Actually, this is not an usual authentication method to access the
|
||||
Internet through an ISP.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Identification is made before pppd is started, and it is the dialer,
|
||||
usually chat, who sends the login name and the password. This data is
|
||||
sent in plaintext, so this method should not be considered secure.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
An example script for chat where you can see how to specify username
|
||||
and password to be sent before running pppd would look something like
|
||||
this:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ABORT BUSY
|
||||
ABORT "NO CARRIER"
|
||||
ABORT VOICE
|
||||
|
@ -124,27 +139,31 @@
|
|||
CONNECT \d\c
|
||||
ogin _Username_
|
||||
assword _Password_
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
The last 2 lines define username and password, and when to send it
|
||||
(after receiving «ogin» and «assword» respectively. The chat script
|
||||
only needs to see parts of the words «login» and «password» and so we
|
||||
don't check the first letter of each. This is so that we don't need
|
||||
to worry about uppercase/lowercase characters.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Suppose that this script is called provider, and it is saved into the
|
||||
/etc/chatscripts directory. Then, you can run it with:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
/usr/sbin/chat -v -f /etc/chatscripts/provider
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
4.2. PAP - Password Authentication Protocol
|
||||
|
||||
|
||||
If the provider you are using requires PAP as the authentication
|
||||
protocol, during the LCP negotiation in PPP this protocol will be
|
||||
asked to use this protocol. When the phone call is connected after
|
||||
|
@ -152,21 +171,26 @@
|
|||
username and the password, which it will look for in the /etc/ppp/pap-
|
||||
secrets file. This file must have read and write permissions only for
|
||||
root only, so that nobody else can read the passwords inside it.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
PAP is not very secure, as the password is sent in plaintext, so can
|
||||
be read by somebody that monitors your transmission line.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Simple example of /etc/ppp/pap-secrets:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
_Username_ * _Password_
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
4.3. CHAP - Challenge Authentication Protocol
|
||||
|
||||
|
||||
If the provider you are using requires CHAP as the authentication
|
||||
protocol, during the LCP negotiation in PPP this protocol will be
|
||||
asked to use this protocol. When the phone call is connected after
|
||||
|
@ -175,74 +199,86 @@
|
|||
/etc/ppp/chap-secrets file. This file must have read and write
|
||||
permissions only for root only, so that nobody else can read the
|
||||
passwords inside it.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
CHAP is more secure than PAP, as the password is never sent through
|
||||
the transmission line in plaintext. The authentication server sends a
|
||||
random identifier (the challenge), that the client must encrypt with
|
||||
its password, and then send back to the server.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Simple example of /etc/ppp/chap-secrets:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
_Username_ * _Password_
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
Sometimes an ISP uses PAP and other times CHAP, so it is common to
|
||||
define your username and password in both files.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
5. Notes about DNS name resolution
|
||||
|
||||
|
||||
Everytime you connect to an ISP, it is necesary to have configured DNS
|
||||
name resolution, so your computer can find IP addresses associated to
|
||||
a computer name.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
IP addresses of your DNS servers are placed into the /etc/resolv.conf
|
||||
file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In a standalone computer connecting to Internet, this file usually
|
||||
contains the IP addresses of your ISP's DNS servers:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#/etc/resolv.conf file for ISPname
|
||||
nameserver 111.222.333.444
|
||||
nameserver 222.333.444.555
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
In a proxy/firewall computer, this file usually contains its own IP
|
||||
address (or the loopback address, 127.0.0.1), and this computer
|
||||
includes a DNS server that translates DNS names to IP addresses by
|
||||
querying external DNS servers.
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#/etc/resolv.conf file for local DNS resolution
|
||||
nameserver 127.0.0.1
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
Installation of a local DNS server is out of the scope of this
|
||||
document. There is a lot of documentation about this, but a good and
|
||||
quick approach can be found in the DNS-Howto
|
||||
(http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html).
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
6. Connecting a standalone computer to an ISP using a modem and PPP
|
||||
|
||||
|
||||
When configuring Diald to connect your computer to an ISP, the next
|
||||
steps will be necesary:
|
||||
|
||||
· Getting the Diald package installed. The quickest way is to install
|
||||
the package that comes with your GNU/Linux distribution.
|
||||
|
||||
· Configure DNS resolver (/etc/resolv.conf file).
|
||||
|
||||
· Check that you can call an ISP. If your GNU/Linux distribution
|
||||
includes an utility to configure a connection, the quickest way
|
||||
will be to use it (pppconfig in Debian, kppp if you use KDE, etc).
|
||||
|
@ -251,72 +287,62 @@
|
|||
(http://www.linuxdoc.org/HOWTO/Modem-HOWTO.html) and Serial-Howto
|
||||
(http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html) documents can
|
||||
help you.
|
||||
|
||||
· Configure username and password in the /etc/ppp/pap-secrets and
|
||||
/etc/ppp/chap-secrets files, as mentioned in previous sections.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
And finally, going into Diald:
|
||||
|
||||
|
||||
· Prepare the Diald configuration file (/etc/diald/diald.options for
|
||||
version 0.16.5 and /etc/diald/diald.conf for later versions).
|
||||
|
||||
· Prepare filters file /etc/diald/standard.filter, or better, leave
|
||||
that file as is, and modify a copy of it that you can call
|
||||
/etc/diald/personal.filter.
|
||||
|
||||
· Prepare the script to make the call (/etc/diald/diald.connect with
|
||||
execute permissions for root) and instruction file for chat
|
||||
(/etc/chatscripts/provider), that will be used by the previous
|
||||
script.
|
||||
|
||||
· Prepare scripts to be run when the link goes up and down
|
||||
(/etc/diald/ip-up and /etc/diald/ip-down) if you want to use it
|
||||
(both must have execute permissions for root).
|
||||
|
||||
· Prepare script to set and delete routes (/etc/diald/addroute and
|
||||
/etc/diald/delroute) if you want (both must have execute
|
||||
permissions for root). This step is not necesary if you only use a
|
||||
single Diald instance.
|
||||
|
||||
· Finally, start the diald daemon («/etc/init.d/diald start» in
|
||||
Debian, «/etc/rc.d/init.d/diald start» in RedHat). Normally, Diald
|
||||
package installation process prepares the scripts to run Diald when
|
||||
the computer boot up in the /etc/rcX.d directories.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you make any change in the Diald config file when it is running, it
|
||||
is necesary to restart it («/etc/init.d/diald restart» in Debian,
|
||||
«/etc/rc.d/init.d/diald restart» in RedHat).
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
6.1. /etc/diald/diald.options or diald.conf file
|
||||
|
||||
|
||||
In this example file you must check for:
|
||||
|
||||
· Comm port where your modem is connected. Option device.
|
||||
|
||||
· Comm port speed to talk with modem. Option speed.
|
||||
|
||||
· User name to be used in ppp. Option pppd-options.
|
||||
|
||||
· Retry counters and timers.
|
||||
|
||||
· Enabled connection hours. Options restrict.
|
||||
|
||||
· Decide if you want to use the ip-up and ip-down scripts. Options
|
||||
ip-up and ip-down.
|
||||
|
||||
· Decide if you want to use the addroute and delroute scripts.
|
||||
Options addroute and delroute. Generally it is not needed to modify
|
||||
this scripts, but if you use more than one instance of Diald or
|
||||
have a complex configuration, you need it.
|
||||
|
||||
· Decide if you use the standar or personal filter file. Options
|
||||
include.
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
##########################
|
||||
# /etc/diald/diald.options
|
||||
|
||||
|
@ -435,26 +461,31 @@
|
|||
#include /etc/diald/standard.filter
|
||||
# or personal filters
|
||||
include /etc/diald/personal.filter
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
6.2. Personal filters file
|
||||
|
||||
|
||||
Manipulation of this file must be done very carefully. This file is
|
||||
used to decide when and why to start up the line, maintain it, bring
|
||||
down the line or ignore a packet, depending on the traffic type.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Generally, the Diald standar filter file is sufficient for most cases,
|
||||
but perhaps, it may be too restrictive or not restrictive enough in
|
||||
some situations. The personal.filter file that is shown has some
|
||||
corrections over the original from the 0.16 version.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In next versions of this document, other commented more restrictive
|
||||
examples will be included.
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
# /etc/diald/personal.filter
|
||||
# Filter rules shown are the same as in the standard.filter with the
|
||||
# following changes:
|
||||
|
@ -608,25 +639,28 @@
|
|||
# Catch any packets that we didn't catch above and give the connection
|
||||
# 30 seconds of live time.
|
||||
accept any 30 any
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
6.3. Making the call
|
||||
|
||||
|
||||
/etc/diald/diald.connect file (it must have execute permission):
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
/usr/sbin/chat -f /etc/chatscripts/provider
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
/etc/chatscripts/provider file. In this example file you must check
|
||||
the destination phone number:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ABORT BUSY
|
||||
ABORT "NO CARRIER"
|
||||
ABORT VOICE
|
||||
|
@ -635,23 +669,28 @@
|
|||
"" ATZ
|
||||
OK ATDT123456789
|
||||
CONNECT \d\c
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
6.4. Connection start script
|
||||
|
||||
|
||||
It must have execute permission.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This script can be used to many tasks (synchronize time, send the
|
||||
queued mail, get incoming mail, etc.).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the example, a message is sent to root with data passed to the
|
||||
script (interface, subnet mask, local ip address, remote ip address
|
||||
and cost for routing):
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#!/bin/sh
|
||||
|
||||
iface=$1
|
||||
|
@ -667,27 +706,29 @@
|
|||
# runq
|
||||
|
||||
echo `date` $1 $2 $3 $4 $5 | mail -s "diald - conecting" root@localhost
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
7. Conecting a computer to a group of different ISPs with a modem and
|
||||
PPP
|
||||
|
||||
|
||||
Many times, one standalone computer does not only connect to just one
|
||||
network. It is common to connect to different networks or to the
|
||||
Internet using some different service providers. In this case,
|
||||
changing configuration files each time you want to connect to a
|
||||
different site can be annoying.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The solution i propose here consist in using different sets of
|
||||
configuration files for each different connection. You can find here
|
||||
some scripts to automate changing from one to another.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
7.1. Note about sending mail using a relay host
|
||||
|
||||
|
||||
If your email client program uses a local Message Transfer Agent with
|
||||
a smtp relay host to send all messages, or if you use a email client
|
||||
program that sends the messages directly to your provider's smtp
|
||||
|
@ -698,7 +739,9 @@
|
|||
address is from the range of ip addresses that this provider assigns,
|
||||
to avoid having an open relay server that can be used to send spam,
|
||||
anonymous message and so on.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In the following examples, you will find how to change this parameter
|
||||
in the Smail configuration files in a simple configuration where all
|
||||
external messages are sent to a smtp relay server. If you use another
|
||||
|
@ -706,26 +749,30 @@
|
|||
must change in your MTA to include it here. If you use an email client
|
||||
program that directly sends to the external smtp server (Kmail,
|
||||
Netscape, etc.) send me your changes too.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
7.2. Scripts to automate multiple connections and changing from one
|
||||
to another
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
7.2.1. Starting up
|
||||
|
||||
|
||||
First of all, create a subdirectory of /etc/diald called providers
|
||||
where you store your scripts to automatically change from one to
|
||||
another provider and the subdirectories with the set of files to
|
||||
configure each of the providers connections.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
With the next script this directory is created and filled with the
|
||||
current configuration files from Diald, chat, pppd and Smail, that
|
||||
will be treated as a template for the next configurations.
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#!/bin/sh
|
||||
#File /etc/diald/providers/setupdialdmultiprovider
|
||||
mkdir /etc/diald/providers
|
||||
|
@ -741,40 +788,46 @@
|
|||
cp /etc/diald/ip-up /etc/diald/providers/setup
|
||||
cp /etc/diald/ip-down /etc/diald/providers/setup
|
||||
cp /etc/smail/routers /etc/diald/providers/setup
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
7.2.2. New provider
|
||||
|
||||
|
||||
With the next script the template configuration will be copied to a
|
||||
new directory to prepare it for a new provider connection or a new net
|
||||
connection. This script (/etc/diald/providers/newdialdprovider) will
|
||||
need a parameter with the provider or net name.
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#!/bin/sh
|
||||
#File /etc/diald/providers/newdialdprovider
|
||||
mkdir /etc/diald/providers/$1
|
||||
cp /etc/diald/providers/setup/* /etc/diald/providers/$1
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
Now, you will modify as you need the new files in
|
||||
/etc/diald/providers/provdidername, being providername the parameter
|
||||
passed to newdialdprovider.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
7.2.3. Changing from one to another
|
||||
|
||||
|
||||
At the end, with this script you will change all your configuration
|
||||
files related to Diald to connect to another provider or net. I use
|
||||
symbolic links to avoid using duplicate files. Using symbolic links,
|
||||
if you change any config file in its original location like
|
||||
/etc/resolv.conf, the change is really made in the
|
||||
/etc/diald/providers/providername/resolv.conf file.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#!/bin/sh
|
||||
#File /etc/diald/providers/setdialdprovider
|
||||
/etc/init.d/diald stop
|
||||
|
@ -792,12 +845,12 @@
|
|||
ln -sf /etc/diald/providers/$1/ip-down /etc/diald
|
||||
ln -sf /etc/diald/providers/$1/routers /etc/smail
|
||||
/etc/init.d/diald start
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
8. Connecting a proxy/firewall to an ISP using a modem and PPP
|
||||
|
||||
|
||||
Connecting a private net to the Internet with dedicated server which
|
||||
handles packet routing from the local network to the Internet along
|
||||
with proxy/caching services and security firewalling is a complex
|
||||
|
@ -805,23 +858,27 @@
|
|||
«Howto» documents that handle these topics much more comprehensively.
|
||||
At the end of this document you can find a list of links and
|
||||
references to such documents.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here, we are only configuring Diald supposing that the computer
|
||||
already uses IP-Masquerading, has a web proxy like Squid or similar
|
||||
working, an ISP connection correctly configured and that access
|
||||
security to TCP/UDP ports have been revised (/etc/inetd.conf file and
|
||||
others like securetty, host.allow, etc).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Basically, the only need is to reconfigure the rules for
|
||||
masquerading/filtering/accessing each time the set of interfaces
|
||||
change, that is, when the interface ppp0 is stablished and when it is
|
||||
deleted. A good location to do that are the ip-up and ip-down scripts
|
||||
from pppd.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
8.1. Example for Debian 2.1
|
||||
|
||||
|
||||
With Debian, it is sufficient to install the ipmasq package answering
|
||||
that you want to change rules sinchronously with pppd when seting it
|
||||
up. Two scripts will be created inside /etc/ppp/ip-up.d and
|
||||
|
@ -829,32 +886,44 @@
|
|||
analizes existing interfaces and makes a simple configuration that is
|
||||
valid in many cases, but you can personalize it using rule files in
|
||||
/etc/ipmasq/rules.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The only correction after installing this package is to change when
|
||||
the startup script for ipmasq is run, deleting the symbolic link from
|
||||
/etc/rcS.d and creating a new one in /etc/rc2.d to run it after
|
||||
S20diald. Now, when ipmasq is executed to analyze interfaces sl0
|
||||
already exist. S90ipmasq is a good name for this symbolic link to
|
||||
/etc/init.d/ipmasq.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Using Debian there is no need to worry about the kernel version, as
|
||||
the /sbin/ipmasq script uses ipfwadm or ipchains as needed.
|
||||
8.2. Example for Suse 6.1
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
This example is from Mr Cornish Rex, troll@tnet.com.au.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following ip-masp and routing control commands are for use with
|
||||
version 2.2 kernels, using ipchains, but they are not valid for
|
||||
version 2.0 kernels.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
We are going to supose that the ethernet interface has the 192.168.1.1
|
||||
ip address with 16 bit netmask, that is, 255.255.0.0.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This is the /etc/ppp/ip-up file:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#!/bin/sh
|
||||
# $1 = Interface
|
||||
# $2 = Tty device
|
||||
|
@ -903,12 +972,15 @@
|
|||
/sbin/ipchains -A forward -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0
|
||||
|
||||
exit 0
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
This is the /etc/ppp/ip-down file:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#!/bin/sh
|
||||
# $1 = Interface
|
||||
# $2 = Tty device
|
||||
|
@ -919,14 +991,16 @@
|
|||
/sbin/ipchains -F output
|
||||
/sbin/ipchains -F forward
|
||||
/sbin/ipchains-restore < /etc/ppp/orig.chains
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
Last file in last script, orig.chains, is the following file (original
|
||||
status of ipchains):
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
# orig.chains
|
||||
# created with: ipchains-save > orig.chains
|
||||
:input ACCEPT
|
||||
|
@ -934,93 +1008,94 @@
|
|||
:output ACCEPT
|
||||
-A input -s 0.0.0.0/0.0.0.0 -d 192.168.1.1/255.255.255.255
|
||||
-A output -s 192.168.1.1/255.255.255.255 -d 0.0.0.0/0.0.0.0
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
8.3. Example for Slackware 3.6
|
||||
|
||||
|
||||
This example is from Hoo Kok Mun, hkmun@pacific.net.sg.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This is the most simple example i have seen, but fully functional.
|
||||
From the beginning, this example configures masquerading, before the
|
||||
sl0 interface exists, and it does not change when the ppp0 interface
|
||||
appears. If you need advanced security considerations, it may be a
|
||||
little limited.
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#/etc/rc.d/rc.local
|
||||
/sbin/ipfwadm -F -p deny
|
||||
/sbin/ipfwadm -F -a m -S 192.168.0.0/24 -D 0.0.0.0/0
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
As you can see, it is for version 2.0 kernels.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
9. Programs and versions used
|
||||
|
||||
|
||||
To write this document i have used the following diald versions:
|
||||
|
||||
|
||||
· Diald 0.16.5 - Last version maintained by the original diald autor.
|
||||
|
||||
· Diald 0.99.3 - Last version until the first edition of this
|
||||
document.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
And the following pppd versions:
|
||||
|
||||
|
||||
· pppd 2.3.5
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Diald 0.16.5 version is perhaps the most extended, and the one that
|
||||
many Linux distributions include. It is suficient for many sites, and
|
||||
it is very reliable, but, of course, later versions have many
|
||||
interesting capabilites.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
10. More information
|
||||
|
||||
|
||||
Original information from where this document has been obtained can be
|
||||
found in the man pages about diald, diald-examples, diald-control,
|
||||
diald-monitor, dctrl, pppd, chat, as well as from information in the
|
||||
/usr/doc directories and in web pages of this packages:
|
||||
|
||||
|
||||
· New Diald Official Home Page: http://diald.sourceforge.net/
|
||||
|
||||
· Download of new versions: ftp://diald.sourceforge.net/pub/diald/
|
||||
|
||||
· Previous Diald home page: http://diald.unix.ch
|
||||
|
||||
· Old Diald home page until 0.16.5 version:
|
||||
http://www.loonie.net/~erics/diald.html
|
||||
|
||||
· pppd FTP site: ftp://cs.anu.edu.au/pub/software/ppp/
|
||||
|
||||
· Other site: http://www.p2sel.com/diald
|
||||
|
||||
· One more: http://rufus.w3.org/linux/RPM/
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There is a mailing list for discussion about diald on David S.
|
||||
Miller's mailing list server at vger.rutgers.edu. To subscribe, send a
|
||||
message to Majordomo@vger.rutgers.edu with the text «subscribe linux-
|
||||
diald» IN THE MESSAGE BODY.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
An archive of the list can be found in http://www.geocrawler.com.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There are also multiple RFC documents (Request For Comments) that
|
||||
define how the PPP encapsulated lines and its associated protocols
|
||||
(LCP, IPCP, PAP, CHAP, ...) must work. You can find these documents in
|
||||
the /usr/doc/doc-rfc directory and some World Wide Web sites, like
|
||||
http://metalab.unc.edu and http://nic.mil/RFC. You can ask for
|
||||
information about RFCs in RFC-INFO@ISI.EDU.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following «Howtos» can help you:
|
||||
|
||||
· DNS-HOWTO - http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html
|
||||
· Firewall-HOWTO - http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html
|
||||
· IP-Masquerade-HOWTO - http://www.linuxdoc.org/HOWTO/IP-Masquerade-
|
||||
|
@ -1030,5 +1105,6 @@
|
|||
· NET3-4-HOWTO - http://www.linuxdoc.org/HOWTO/NET3-4-HOWTO.html
|
||||
· PPP-HOWTO - http://www.linuxdoc.org/HOWTO/PPP-HOWTO.html
|
||||
· Serial-HOWTO - http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -4,10 +4,15 @@
|
|||
|
||||
<para>
|
||||
File Transport Protocol (FTP) is an efficient way to transfer files between
|
||||
machines across networks. Clients and servers exist for almost all platforms
|
||||
machines across networks and clients and servers exist for almost all platforms
|
||||
making FTP the most convenient (and therefore popular) method of transferring
|
||||
files.
|
||||
files. FTP was first developed by the University of California, Berkeley for
|
||||
inclusion in 4.2BSD (Berkeley Unix). The RFC (Request for Comments)
|
||||
documents for the protocol is now known as RFC 959 and is available at
|
||||
ftp://nic.merit.edu/documents/rfc/rfc0959.txt.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There are two typical modes of running an FTP server - either anonymously or
|
||||
account-based. Anonymous FTP servers are by far the most popular; they allow
|
||||
any machine to access the FTP server and the files stored on it with the same
|
||||
|
@ -16,80 +21,114 @@ Account-based FTP allows users to login with real usernames and passwords.
|
|||
While it provides greater access control than anonymous FTP, transmitting real
|
||||
usernames and password unencrypted over the Internet is generally avoided for
|
||||
security reasons.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
An FTP client is the userland application that provides access to FTP
|
||||
servers. There are many FTP clients available. Some are graphical, and
|
||||
some are text-based.
|
||||
</para>
|
||||
|
||||
FTP related software (servers and clients) for Linux may be found at:
|
||||
http://metalab.unc.edu/pub/Linux/system/network/file-transfer/
|
||||
|
||||
FTP was first developed by the University of California, Berkeley for
|
||||
inclusion in 4.2BSD (Berkeley Unix). The RFC (Request for Comments)
|
||||
documents for the protocol is now known as RFC 959 and is available at
|
||||
ftp://nic.merit.edu/documents/rfc/rfc0959.txt.
|
||||
|
||||
<para>
|
||||
3. Beginner's guide to using ftp
|
||||
A quick guide to using ftp.
|
||||
|
||||
The standard ftp program is the original ftp client. It comes standard with most Linux
|
||||
distributions. It first appeared in 4.2BSD, which was developed by the University of
|
||||
California, Berkeley.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
3.1 Running the ftp program
|
||||
It's easy to use ftp. Let's say you want to connect to the anonymous ftp site
|
||||
metalab.unc.edu, to download the latest Linux kernel source.
|
||||
|
||||
At the command line, type:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
$ ftp metalab.unc.edu
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The ftp program will attempt to connect to metalab.unc.edu. Another way to do this is
|
||||
to run ftp from the command line with no parameters, and use the open command, with
|
||||
the site name as an argument:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
$ ftp
|
||||
ftp> open metalab.unc.edu
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
3.2 Logging into an FTP server
|
||||
When you connect to an FTP site, it will ask you for a login (pressing enter will
|
||||
log in as your local user name, in this case, foo: We log in as anonymous or ftp,
|
||||
to get to the public archive.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
220 helios.oit.unc.edu FTP server (Version wu-2.6.0(2) Wed Nov 17 14:44:12
|
||||
EST 1999) ready.
|
||||
Name (metalab.unc.edu:foo):
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Now, we enter a complete e-mail address as the password (this is what most public
|
||||
FTP sites request).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
331 Guest login ok, send your complete e-mail address as password.
|
||||
Password:
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After a successful login, the following information is given to us:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
Remote system type is UNIX.
|
||||
Using binary mode to transfer files.
|
||||
ftp>
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
3.3 File transfer types
|
||||
After you log in to an ftp site, ftp will print out the file transfer type. In
|
||||
our case, it is binary. Binary mode transfers the files, bit by bit, as they
|
||||
are on the FTP server. Ascii mode, however, will download the text directly.
|
||||
You can type ascii or binary to switch between the types.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You want to download the kernel source, so you leave the file transfer type at
|
||||
binary. The binary type is also what you would use for any non-text files --
|
||||
such as graphic images, zip/gzip archives, executable programs, etc. If in
|
||||
doubt, use binary mode.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
3.4 Navigating and listing directories
|
||||
You do an ls to see a list of the files. The ls command on ftp servers is
|
||||
executed on the remote server, so the command line options that you can use
|
||||
with it vary from server to server. The most common options are generally
|
||||
available, check the manpage for ls for details.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ftp> ls
|
||||
200 PORT command successful.
|
||||
150 Opening ASCII mode data connection for /bin/ls.
|
||||
|
@ -106,7 +145,10 @@ dr-xr-xr-x 17 root root 512 Jun 08 11:43 pub
|
|||
dr-xr-xr-x 3 root other 512 Jul 15 1997 unc
|
||||
dr-xr-xr-x 5 root other 512 Jul 15 1997 usr
|
||||
226 Transfer complete.
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If the ls command lists so many files that they scroll off the top of the
|
||||
screen, you can use Shift-PageUp to scroll up. This works in Linux console
|
||||
mode as well as in xterm or rxvt.
|
||||
|
@ -116,6 +158,8 @@ On public FTP archives, the downloadable resources are usually held in the
|
|||
are in the directory /pub/Linux/kernel, so you type the following to get
|
||||
into that directory:
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ftp> cd pub/Linux/kernel
|
||||
250-README for kernel
|
||||
250-
|
||||
|
@ -123,51 +167,81 @@ ftp> cd pub/Linux/kernel
|
|||
250-
|
||||
250-
|
||||
250 CWD command successful.
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The messages you see, which begin with "250", are information messages sent
|
||||
by the server. In this case, the ftp server is configured to automatically
|
||||
send you the README file when you cd into the directory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
3.5 Downloading and uploading files
|
||||
Now, after doing another ls, you see that you want to cd into the v2.2
|
||||
directory. You do yet another ls, and find the file you want to download.
|
||||
It is linux-2.2.13.tar.gz. So you type this:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ftp> get linux-2.2.13.tar.gz
|
||||
local: linux-2.2.13.tar.gz remote: linux-2.2.13.tar.gz
|
||||
200 PORT command successful.
|
||||
150 Opening BINARY mode data connection for linux-2.2.13.tar.gz (15079540
|
||||
bytes).
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The ftp program has started saving the remote file linux-2.2.13.tar.gz as
|
||||
the local file linux-2.2.13.tar.gz.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you wanted to save it as the local file foo.tar.gz, you could have
|
||||
specified it like this:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ftp> get linux-2.2.13.tar.gz foo.tar.gz
|
||||
local: foo.tar.gz remote: linux-2.2.13.tar.gz
|
||||
200 PORT command successful.
|
||||
150 Opening BINARY mode data connection for linux-2.2.13.tar.gz (15079540
|
||||
bytes).
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
If you want to download more than one file at a time, you'll have to use
|
||||
the mget (multiple get) command. You can use mget together with a
|
||||
space-delimited list of filenames you want to download, or you can use
|
||||
wildcards with the mget command. For example:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ftp> mget linux*
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Would get all files starting with the string "linux". Normally, mget will
|
||||
prompt you for each file before it downloads it. You can toggle this by
|
||||
using the prompt command.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Now let's say you've written a piece of software, and you want to upload
|
||||
it to MetaLab to be included in their Linux software archive. First,
|
||||
you'd change to the /incoming directory (most public FTP servers have a
|
||||
directory, usually called incoming or uploads, where files can be
|
||||
uploaded), then you'd use the put command:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ftp> cd /incoming
|
||||
ftp> put foo.tar.gz
|
||||
local: foo.tar.gz remote: foo.tar.gz
|
||||
|
@ -175,52 +249,87 @@ local: foo.tar.gz remote: foo.tar.gz
|
|||
150 Opening BINARY mode data connection for foo.tar.gz.
|
||||
226 Transfer complete.
|
||||
10257 bytes sent in 0.00316 secs (3.2e+03 Kbytes/sec)
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The put command works the same way as the get command, so you can use
|
||||
mput to upload multiple files at the same time. You can also upload a
|
||||
local file with a different filename on the server by specifying the
|
||||
remote filename and/or pathname as an argument.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
What if the file foo.tar.gz is not in your current local directory
|
||||
when you try to upload it? You can switch local directories by using
|
||||
the lcd (local change directory) command:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ftp> lcd /home/foo/
|
||||
Local directory now /home/foo
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
3.6 Running shell commands
|
||||
The ftp client supports using the bang (!) to run local commands. For
|
||||
example, to get a listing of files in your current local directory, do this:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ftp> !ls
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The way this works is that ftp calls the shell (specified in the $SHELL
|
||||
environment variable), and it is the shell which runs ls. Thus, you can
|
||||
run any command-line which works with your shell simply by prepending "!"
|
||||
to it (the default shell in most Linux distributions is bash, the Bourne
|
||||
Again SHell). Please note that !cd does not work as you would expect,
|
||||
this is why the lcd command exists.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
3.7 Hash marks and tick
|
||||
Wouldn't it be nice if you could watch the progress while you're downloading
|
||||
a file with ftp? You can use the hash command to print out hash marks as you
|
||||
download a file:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ftp> hash
|
||||
Hash mark printing on (1024 bytes/hash mark).
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
As you can tell, ftp will print a hash mark for every 1024 bytes of data
|
||||
you download.
|
||||
|
||||
There is also a tick option.
|
||||
you download. There is also a tick option.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
ftp> tick
|
||||
Tick counter printing on (10240 bytes/tick increment).
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This will print something to this effect as you download a file:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
Bytes transferred: 11680
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
3.8 Other ftp commands
|
||||
There are many other ftp commands. If you have the permissions to do so
|
||||
(which you should, if you are connected to your own private shell account),
|
||||
|
@ -228,36 +337,44 @@ you can make a directory on the remote server using the mkdir command.
|
|||
You can remove a file on the remote server using the delete command, or
|
||||
rmdir to remove a directory. You can also change file permissions using the
|
||||
chmod command.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
For more elaborate information on using ftp, please see the online help in
|
||||
the ftp program (accessible by typing help with no arguments for a list of
|
||||
commands, or help <commandname> for specific help on a command). You can
|
||||
also read the Unix man page for ftp by typing man ftp at your command prompt.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
4. Console FTP clients
|
||||
The original ftp program was the original ftp client, and it is a good
|
||||
investment to learn it. It's the only ftp client that you can be certain
|
||||
is available on most systems (even Win32 comes with the ftp command, albeit
|
||||
an archaic, braindead version of it).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There are many other console-mode (text-only) ftp clients available. The
|
||||
listing here is by no means comprehensive, but includes the most popular
|
||||
ones. Search at FreshMeat to find more.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
4.1 NcFTP
|
||||
NcFTP is the all-time favorite ftp client of many Unix users. It comes
|
||||
bundled with most Linux distributions, and offers many advanced features such
|
||||
as tab completion and bookmarks. Version 2 of NcFTP had a curses based
|
||||
full-screen mode. This was done away with in Version 3 (now in beta).
|
||||
|
||||
It's not 100% compatible with the commands that standard ftp uses. For example,
|
||||
get and put in NcFTP act like mget and mput do in standard ftp. So if you want
|
||||
to save a remote file as a different local filename, you'd have to
|
||||
do get -z remotename localname. Thankfully, NcFTP has a nice online help system
|
||||
to assist you in learning the commands.
|
||||
|
||||
You can get the latest version of NcFTP at http://www.ncftp.com.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
4.2 lukemftp
|
||||
A port of the NetBSD FTP client to other systems, lukemftp derives its name
|
||||
from the author of most of the enhanced features, which include:
|
||||
|
@ -266,88 +383,92 @@ via proxies), context-sensitive word completion, dynamic progress bar,
|
|||
IPv6 support, modification time preservation, paging of local and remote
|
||||
files, passive mode support (with fallback to active mode), SOCKS support,
|
||||
TIS FWTK gate-ftp server support, and transfer rate throttling.
|
||||
|
||||
lukemftp is espically good for users who don't want to change to anything
|
||||
drastically different from the standard ftp client, but want more advanced features.
|
||||
|
||||
You can get the latest version of lukemftp at
|
||||
ftp://ftp.netbsd.org/pub/NetBSD/misc/lukemftp/.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
4.3 lftp
|
||||
lftp is a sophisticated command line based FTP client. Like bash, it has job
|
||||
control. It uses the GNU readline library for input, so you have command line
|
||||
completion and editing. lftp also has bookmarks, mirroring support, and can
|
||||
transfer several files in parellel.
|
||||
|
||||
You can get the latest version of lftp at http://ftp.yars.free.net/projects/lftp/.
|
||||
|
||||
Debian packages are available at ftp://ftp.freshmeat.net/pub/debs/lftp/.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
4.4 cftp
|
||||
Comfortable FTP (cftp) is a full screen mode client. What it lacks in features,
|
||||
it makes up for in ease of use. You browse through the directories using the
|
||||
arrow keys and enter.
|
||||
|
||||
You should be able to get the latest version of cftp at
|
||||
http://ftp.giga.or.at/pub/nih/cftp/.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
4.5 yafc
|
||||
Yafc is a very nice ftp client, with features including directory cache,
|
||||
remote filename completion, aliases, colorized ls, recursive get/put/ls/rm,
|
||||
nohup mode transfers, tagging (queueing), multiple connections, proxy support
|
||||
and more. It has support for Kerberos4 authentication.
|
||||
|
||||
You can get the latest version of yafc from
|
||||
http://www.stacken.kth.se/~mhe/yafc/.
|
||||
|
||||
Debian packages are available at
|
||||
http://members.home.com/decklin/experimental/.
|
||||
|
||||
Redhat packages are available at
|
||||
http://lz.freeservers.com/linux/yafc.html.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
5. X Window FTP clients
|
||||
There are several graphical FTP clients designed to run on the X Window
|
||||
system. These clients offer ease of use for users who are used to
|
||||
graphical environments, and sometimes offer versatile options that would
|
||||
be hard to implement in a text-based ftp client.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
5.1 gFTP
|
||||
gFTP is an FTP client for X Windows written using Gtk. The interface has
|
||||
some similarities to the popular WS_FTP software commonly used on a certain
|
||||
unstable operating system.
|
||||
|
||||
gFTP features simultaneous downloads, resuming of interrupted file transfers,
|
||||
file transfer queues, downloading of entire directories, ftp proxy support,
|
||||
remote directory caching, passive and non-passive file transfers, drag-n-drop
|
||||
support, a very nice connection manager and more.
|
||||
|
||||
If you are running Red Hat Linux and have the GNOME desktop installed, then
|
||||
you probably already have gFTP. If not, you can download gFTP from its
|
||||
homepage at http://gftp.seul.org/.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
5.2 WXftp
|
||||
WXftp is an FTP client for the X Window System designed to be used mainly
|
||||
on Linux workstations. It is written using the WXWindows toolkit, so it
|
||||
can be compiled to use either Motif or GTK+
|
||||
|
||||
It includes an intuitive user interface (much like WS_FTP), a session
|
||||
manager, on-line help, a progress bar, and more
|
||||
|
||||
Check out WXftp's homepage at http://www.wxftp.seul.org.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
5.3 LLNL XDIR and XFTP
|
||||
LLNL XFTP was one of the first graphical FTP clients for Linux. It supports
|
||||
FXP (file transfer between two remote hosts), and has a Motif based interface.
|
||||
|
||||
More information is available at http://www.llnl.gov/ia/xdir_xftp/.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
5.4 guiftp
|
||||
Guiftp is a simple ftp client written with the GTK+ toolkit. It's good if
|
||||
you don't need many features and want a simple, clean look.
|
||||
|
||||
Guiftp's homepage is at http://www.altern.org/ldufresne/guiftp/.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
6. FTP Servers
|
||||
6.1 How an FTP Server works
|
||||
A traditional FTP server is executed from inetd (the internet superserver
|
||||
|
@ -355,7 +476,6 @@ daemon). The standard FTP port is port 21. When a user tries to log in, the
|
|||
FTP server uses a standard system call to check the user name and password
|
||||
against the entries in the system password file, or the NIS tables if you
|
||||
are using NIS. If the login is correct, the user is given access to the system.
|
||||
|
||||
Anonymous FTP works differently. The user logs in with either the anonymous
|
||||
or the ftp username (this can be defined in the config file). He is then
|
||||
given access to a directory tree that has been chroot()'ed. This ensures
|
||||
|
@ -363,13 +483,11 @@ that the user can not gain access to directory trees he is not authorized
|
|||
for. The chrooted directory tree usually contains a mock filesystem,
|
||||
with bin/, etc/, and lib/ directories. The files for download are usually
|
||||
put in the pub/ directory.
|
||||
|
||||
The reason for a mock filesystem in an anonymous FTP tree is that the FTP
|
||||
daemon runs external commands for ls requests. You can also place additional
|
||||
programs in the bin directory, and a user can run them with the SITE command
|
||||
in his ftp client. For example, Red Hat's FTP includes the RPM command
|
||||
(for users to query RPM packages on the site).
|
||||
|
||||
Some FTP servers work differently. For example, some will allow user accounts
|
||||
to be set up independant of the system-wide password file (FTP-only accounts).
|
||||
Some servers (ProFTPD and NcFTPd for instance) have built-in ls commands and
|
||||
|
@ -377,18 +495,20 @@ do not need a special directory tree within the chroot structure. Other ftp
|
|||
servers stray altogether from the standard ftp concept. FTP4ALL, for example,
|
||||
does not use system passwords at all. It uses it's own user and group file,
|
||||
and has features such as upload/download ratio and customizable server messages.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
6.2 Help with FTP Servers
|
||||
WU-FTPD
|
||||
WU-FTPD is the ftp daemon included with many Linux distributions, including
|
||||
Red Hat and Caldera. You can learn more about WU-FTPD at http://www.wu-ftpd.org.
|
||||
|
||||
The WU-FTPD FAQ can be found on the web at http://www.cetis.hvu.nl/~koos/wu-ftpd-faq.html.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
ProFTPD
|
||||
ProFTPD is a powerful FTP server that includes Apache-style configuration,
|
||||
extensive support for virtual hosts, and internal ls.
|
||||
|
||||
A complete command reference and downloads can be found at http://www.proftpd.org
|
||||
</para>
|
||||
|
||||
|
|
|
@ -8,23 +8,31 @@ Frame relay is a protocol used with leased lines to support speeds up to
|
|||
network. Frame realy connections use a virtual circuit, called
|
||||
a PVC (private virtual circuit), to establish connections. Once established,
|
||||
connections use a low overhead and do not provide error correction.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A frame realy compatible router is used to attach the LAN to the frame
|
||||
relay line. Frame relay lines are available in speeds ranging from 56 Kbps
|
||||
to 1.544 Mbps, and varying proportionally in cost. One advantage of frame
|
||||
relay is that bandwidth is available on demand: you can install a line
|
||||
at 56 Kbps and later upgrade it to a higher speed by ordering the service
|
||||
from the carrier, usually without replacing any equipment.
|
||||
</para>
|
||||
|
||||
Frame Relay is a new networking technology that is designed to suit
|
||||
data communications traffic that is of a `bursty' or intermittent
|
||||
nature. You connect to a Frame Relay network using a Frame Relay
|
||||
Access Device (FRAD). The Linux Frame Relay supports IP over Frame
|
||||
Relay as described in RFC-1490.
|
||||
<para>
|
||||
It was specifically designed and is well suited to data communications traffic
|
||||
that is of a `bursty' or intermittent nature. You connect to a Frame Relay
|
||||
network using a Frame Relay Access Device (FRAD). The Linux Frame Relay
|
||||
supports IP over Frame Relay as described in RFC-1490.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Frame Relay device names are `dlci00', `dlci01' etc for the DLCI
|
||||
encapsulation devices and `sdla0', `sdla1' etc for the FRAD(s).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
Kernel Compile Options:
|
||||
|
||||
|
||||
|
@ -33,42 +41,52 @@ from the carrier, usually without replacing any equipment.
|
|||
(24) Max open DLCI
|
||||
(8) Max DLCI per device
|
||||
<*> SDLA (Sangoma S502/S508) support
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
Mike McLagan, mike.mclagan@linux.org, developed the Frame Relay
|
||||
support and configuration tools.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Currently the only FRAD supported are the Sangoma Technologies S502A,
|
||||
S502E and S508.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To configure the FRAD and DLCI devices after you have rebuilt your
|
||||
kernel you will need the Frame Relay configuration tools. These are
|
||||
available from ftp.invlogic.com. Compiling and installing the tools
|
||||
is straightforward, but the lack of a top level Makefile makes it a
|
||||
fairly manual process:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
user% tar xvfz .../frad-0.15.tgz
|
||||
user% cd frad-0.15
|
||||
user% for i in common dlci frad; make -C $i clean; make -C $i; done
|
||||
root# mkdir /etc/frad
|
||||
root# install -m 644 -o root -g root bin/*.sfm /etc/frad
|
||||
root# install -m 700 -o root -g root frad/fradcfg /sbin
|
||||
rppt# install -m 700 -o root -g root dlci/dlcicfg /sbin
|
||||
|
||||
|
||||
root# install -m 700 -o root -g root dlci/dlcicfg /sbin
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Note that the previous commands use sh syntax, if you use a csh
|
||||
flavour instead (like tcsh), the for loop will look different.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
After installing the tools you need to create an /etc/frad/router.conf
|
||||
file. You can use this template, which is a modified version of one of
|
||||
the example files:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
# /etc/frad/router.conf
|
||||
# This is a template configuration for frame relay.
|
||||
# All tags are included. The default values are based on the code
|
||||
|
@ -207,14 +225,20 @@ from the carrier, usually without replacing any equipment.
|
|||
# CIRbak=16
|
||||
# Bc_bak=16
|
||||
# Be_bak=0
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
When you've built your /etc/frad/router.conf file the only step
|
||||
remaining is to configure the actual devices themselves. This is only
|
||||
a little trickier than a normal network device configuration, you need
|
||||
to remember to bring up the FRAD device before the DLCI encapsulation
|
||||
devices. These commands are best hosted in a shell script, due to
|
||||
their number:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#!/bin/sh
|
||||
# Configure the frad hardware and the DLCI parameters
|
||||
/sbin/fradcfg /etc/frad/router.conf || exit 1
|
||||
|
@ -232,7 +256,7 @@ from the carrier, usually without replacing any equipment.
|
|||
#
|
||||
route add default dev dlci00
|
||||
#
|
||||
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -1,18 +1,17 @@
|
|||
<sect1 id="IP-Accouting">
|
||||
<sect1 id="IP-Accounting">
|
||||
|
||||
<title>IP-Accouting</title>
|
||||
<title>IP-Accounting</title>
|
||||
|
||||
<para>
|
||||
8.4. IP Accounting
|
||||
|
||||
This option of the Linux kernel keeps track of IP network traffic,
|
||||
performs packet logging and produces some statistics. A series of
|
||||
rules may be defined so when a packet matches a given pattern, some
|
||||
action is performed: a counter is increased, it is accepted/rejected,
|
||||
etc.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
6.3. IP Accounting (for Linux-2.0)
|
||||
|
||||
The IP accounting features of the Linux kernel allow you to collect
|
||||
and analyze some network usage data. The data collected comprises the
|
||||
number of packets and the number of bytes accumulated since the
|
||||
|
@ -20,15 +19,18 @@
|
|||
categorize the figures to suit whatever purpose you may have. This
|
||||
option has been removed in kernel 2.1.102, because the old ipfwadm-
|
||||
based firewalling was replaced by ``ipfwchains''.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
Kernel Compile Options:
|
||||
|
||||
|
||||
Networking options --->
|
||||
[*] IP: accounting
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
After you have compiled and installed the kernel you need to use the
|
||||
ipfwadm command to configure IP accounting. There are many different
|
||||
ways of breaking down the accounting information that you might
|
||||
|
@ -39,12 +41,15 @@
|
|||
number of services and that you are interested in knowing how much
|
||||
traffic is generated by each of ftp and world wide web traffic, as
|
||||
well as total tcp and udp traffic.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You might use a command set that looks like the following, which is
|
||||
shown as a shell script:
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
#!/bin/sh
|
||||
#
|
||||
# Flush the accounting rules
|
||||
|
@ -76,21 +81,25 @@
|
|||
# List the rules
|
||||
ipfwadm -A -l -n
|
||||
#
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
The names ``ftp-data'' and ``www'' refer to lines in /etc/services.
|
||||
The last command lists each of the Accounting rules and displays the
|
||||
collected totals.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
An important point to note when analyzing IP accounting is that totals
|
||||
for all rules that match will be incremented so that to obtain
|
||||
differential figures you need to perform appropriate maths. For
|
||||
example if I wanted to know how much data was not ftp nor www I would
|
||||
substract the individual totals from the rule that matches all ports.
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
root# ipfwadm -A -l -n
|
||||
IP accounting rules
|
||||
pkts bytes dir prot source destination ports
|
||||
|
@ -110,9 +119,10 @@
|
|||
231 18831 out tcp 0.0.0.0/0 0.0.0.0/0 * -> *
|
||||
0 0 in udp 0.0.0.0/0 0.0.0.0/0 * -> *
|
||||
0 0 out udp 0.0.0.0/0 0.0.0.0/0 * -> *
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
6.4. IP Accounting (for Linux-2.2)
|
||||
|
||||
The new accounting code is accessed via ``IP Firewall Chains''. See
|
||||
|
|
|
@ -1,31 +1,8 @@
|
|||
ISDN (Integrated Services Digital Network)
|
||||
<sect1 id="ISDN">
|
||||
|
||||
Originally developed as a digital alternative to the standard PSTN telephone system for voice
|
||||
communications. It was introduced in 1984, but is only now being widely implemented in the U.S.
|
||||
There are two available ISDN packages:
|
||||
|
||||
- BRI (Basic Rate Interface) include two B channels (64 Kbps apiece) for voice or data transmissions,
|
||||
and a D channel (16 Kbps) for call control. This is the ordinary consumer ISN service.
|
||||
|
||||
- PRI (Primary Rate Interface) is a more expensive alternative that includes 23 B channels and one D channel.
|
||||
This is the equivalent of a T1 line, explained below.
|
||||
|
||||
ISDN's B channels are typically used for packet-switched data transmission, and the D channel is typically
|
||||
used for call control and switching; however, the D channel can also be used for data transmission in
|
||||
low-bandwidth applications.
|
||||
|
||||
3.6. ISDN
|
||||
|
||||
The Linux kernel has built-in ISDN capabilies. Isdn4linux controls
|
||||
ISDN PC cards and can emulate a modem with the Hayes command set ("AT"
|
||||
commands). The possibilities range from simply using a terminal
|
||||
program to connections via HDLC (using included devices) to full
|
||||
connection to the Internet with PPP to audio applications.
|
||||
|
||||
· FAQ for isdn4linux: http://ww.isdn4linux.de/faq/
|
||||
|
||||
7.1. ISDN
|
||||
<title>ISDN</title>
|
||||
|
||||
<para>
|
||||
The Integrated Services Digital Network (ISDN) is a series of
|
||||
standards that specify a general purpose switched digital data
|
||||
network. An ISDN `call' creates a synchronous point to point data
|
||||
|
@ -47,7 +24,9 @@ low-bandwidth applications.
|
|||
service which could deliver either telephone (via digitised voice) or
|
||||
data services to your home or business without requiring you to make
|
||||
any special configuration changes.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
There are a few different ways to connect your computer to an ISDN
|
||||
service. One way is to use a device called a `Terminal Adaptor' which
|
||||
plugs into the Network Terminating Unit that you telecommunications
|
||||
|
@ -62,10 +41,22 @@ low-bandwidth applications.
|
|||
allows you to install an ISDN card into your Linux machine and then
|
||||
has your Linux software handle the protocols and make the calls
|
||||
itself.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Linux kernel has built-in ISDN capabilies. Isdn4linux controls
|
||||
ISDN PC cards and can emulate a modem with the Hayes command set ("AT"
|
||||
commands). The possibilities range from simply using a terminal
|
||||
program to connections via HDLC (using included devices) to full
|
||||
connection to the Internet with PPP to audio applications.
|
||||
|
||||
· FAQ for isdn4linux: http://ww.isdn4linux.de/faq/
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
Kernel Compile Options:
|
||||
|
||||
|
||||
ISDN subsystem --->
|
||||
<*> ISDN support
|
||||
[ ] Support synchronous PPP
|
||||
|
@ -73,33 +64,38 @@ low-bandwidth applications.
|
|||
< > ICN 2B and 4B support
|
||||
< > PCBIT-D support
|
||||
< > Teles/NICCY1016PC/Creatix support
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
The Linux implementation of ISDN supports a number of different types
|
||||
of internal ISDN cards. These are those listed in the kernel
|
||||
configuration options:
|
||||
|
||||
</para>
|
||||
|
||||
· ICN 2B and 4B
|
||||
|
||||
· Octal PCBIT-D
|
||||
|
||||
· Teles ISDN-cards and compatibles
|
||||
|
||||
|
||||
<para>
|
||||
Some of these cards require software to be downloaded to them to make
|
||||
them operational. There is a separate utility to do this with.
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
Full details on how to configure the Linux ISDN support is available
|
||||
from the /usr/src/linux/Documentation/isdn/ directory and an FAQ
|
||||
dedicated to isdn4linux is available at www.lrz-muenchen.de. (You can
|
||||
click on the english flag to get an english version).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A note about PPP. The PPP suite of protocols will operate over either
|
||||
asynchronous or synchronous serial lines. The commonly distributed PPP
|
||||
daemon for Linux `pppd' supports only asynchronous mode. If you wish
|
||||
to run the PPP protocols over your ISDN service you need a specially
|
||||
modified version. Details of where to find it are available in the
|
||||
documentation referred to above.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -3,99 +3,155 @@
|
|||
<title>LAN-Topologies-and-Architectures</title>
|
||||
|
||||
<para>
|
||||
A network's topology is the configuration, or shape, of the wiring used in the network.
|
||||
Network architectures are standards for communication, such as Ethernet and Token Ring.
|
||||
This section describes the common technologies and architectures.
|
||||
A network's topology is the configuration, or shape, of the wiring used in
|
||||
the network. Network architectures are standards for communication, such
|
||||
as Ethernet and Token Ring. This section describes the common technologies
|
||||
and architectures.
|
||||
</para>
|
||||
|
||||
The terms network architecture and network topology are often used interchangeably, even
|
||||
in some Microsoft documentation. For clarity throughout this book, topology refers to the
|
||||
configuration of network wiring and communication (star, bus, ring), and architecture refers
|
||||
to standards (Ethernet, Token Ring, ARCnet).
|
||||
<para>
|
||||
The terms network architecture and network topology are often used
|
||||
interchangeably, even in some Microsoft documentation. For clarity throughout
|
||||
this book, topology refers to the configuration of network wiring and
|
||||
communication (star, bus, ring), and architecture refers to standards
|
||||
(Ethernet, Token Ring, ARCnet).
|
||||
</para>
|
||||
|
||||
Network Topologies
|
||||
|
||||
Different types of LANs are wired in different ways. The nodes might be connected to each other,
|
||||
to a central hub, or to a continuous cable (bus). The four major network topologies are discussed
|
||||
below.
|
||||
<para>
|
||||
Different types of LANs are wired in different ways. The nodes might be
|
||||
connected to each other, to a central hub, or to a continuous cable (bus).
|
||||
The four major network topologies are discussed below.
|
||||
</para>
|
||||
|
||||
Each type of network has a physical topology (the actual wiring) and a logical topology (the
|
||||
path the data follows). In some types of networks these are identical. However, some networks
|
||||
use different physical and logical topologies. For example, Token Ring networks use a physical
|
||||
star topology and a logical ring topology.
|
||||
<para>
|
||||
Each type of network has a physical topology (the actual wiring) and a logical
|
||||
topology (the path the data follows). In some types of networks these are
|
||||
identical. However, some networks use different physical and logical
|
||||
topologies. For example, Token Ring networks use a physical star topology and
|
||||
a logical ring topology.
|
||||
</para>
|
||||
|
||||
Bus
|
||||
|
||||
In a bus topology, a single cable supports an entire network segment. This cable is the bus,
|
||||
sometimes called a backbone. Nodes are attached at vairous points along the cable. Depending
|
||||
on the network architecture, nodes may be connected directly to the bus with T-connectors, or
|
||||
a cable called a drop cable can be connected between the bus and each node.
|
||||
<para>
|
||||
In a bus topology, a single cable supports an entire network segment. This
|
||||
cable is the bus, sometimes called a backbone. Nodes are attached at various
|
||||
points along the cable. Depending on the network architecture, nodes may be
|
||||
connected directly to the bus with T-connectors, or a cable called a drop
|
||||
cable can be connected between the bus and each node.
|
||||
</para>
|
||||
|
||||
Bus networks typically use coaxial cable. Devices called terminators are used at either end
|
||||
of the bus. These absorb the signal to prevent signals from reflecting back and forth on the
|
||||
bus, which creates extra traffic.
|
||||
<para>
|
||||
Bus networks typically use coaxial cable. Devices called terminators are used
|
||||
at either end of the bus. These absorb the signal to prevent signals from
|
||||
reflecting back and forth on the bus, which creates extra traffic.
|
||||
</para>
|
||||
|
||||
The bus topology is usually inexpensive for smaller netwroks, since no devices are required
|
||||
aside from the cable and connectors, and a minimum length of cable is required. Ethernet
|
||||
10Base2 and 10Base5 are common bus networks.
|
||||
<para>
|
||||
The bus topology is usually inexpensive for smaller netwroks, since no devices
|
||||
are required aside from the cable and connectors, and a minimum length of cable
|
||||
is required. Ethernet 10Base2 and 10Base5 are common bus networks.
|
||||
</para>
|
||||
|
||||
The chief disadvantage of a bus topology is that a break in any point in the bus will bring
|
||||
the network down. Also, the coaxial cable used in these networks is generally harder to work
|
||||
with than twisted pair cable.
|
||||
<para>
|
||||
The chief disadvantage of a bus topology is that a break in any point in the
|
||||
bus will bring the network down. Also, the coaxial cable used in these networks
|
||||
is generally harder to work with than twisted pair cable.
|
||||
</para>
|
||||
|
||||
Star
|
||||
|
||||
In a star topology, each node is connected with its own cable to a central device node called a hub.
|
||||
The hub internally connects each node to the other nodes. Star-wired nodes typically use UTP cable.
|
||||
Ethernet 10BaseT is the most common network with a star topology.
|
||||
<para>
|
||||
In a star topology, each node is connected with its own cable to a central
|
||||
device node called a hub. The hub internally connects each node to the
|
||||
other nodes. Star-wired nodes typically use UTP cable. Ethernet 10BaseT
|
||||
is the most common network with a star topology.
|
||||
</para>
|
||||
|
||||
While a greater length of cable is required for this topology, it is more reliable than a bus
|
||||
because each node has its own cable. A problem in a cable will generally only affect a single node.
|
||||
Most hubs have visual indicators to make it easy to diagnose cable problems.
|
||||
<para>
|
||||
While a greater length of cable is required for this topology, it is more
|
||||
reliable than a bus because each node has its own cable. A problem in a cable
|
||||
will generally only affect a single node. Most hubs have visual indicators to
|
||||
make it easy to diagnose cable problems.
|
||||
</para>
|
||||
|
||||
Star netowrks using UTP cable are often less expensive than bus networks using coaxial cable because
|
||||
the ease of wiring and inexpensive wiring offsets the added expense of hubs. They are also easier
|
||||
to expand, since a new node can be wired to the hub without disconnecting other nodes.
|
||||
<para>
|
||||
Star networks using UTP cable are often less expensive than bus networks
|
||||
using coaxial cable because the ease of wiring and inexpensive wiring offsets
|
||||
the added expense of hubs. They are also easier to expand, since a new node can
|
||||
be wired to the hub without disconnecting other nodes.
|
||||
</para>
|
||||
|
||||
Ring
|
||||
|
||||
In a ring topology, the nodes are connected to each other to form a circle. Each node receives signals
|
||||
from its upstream neighbour, and passes them on to its downstream neighbour. Ring networks often
|
||||
use token passing, as describe in 802.5, for media access.
|
||||
<para>
|
||||
In a ring topology, the nodes are connected to each other to form a circle.
|
||||
Each node receives signals from its upstream neighbour, and passes them on to
|
||||
its downstream neighbour. Ring networks often use token passing, as describe in
|
||||
802.5, for media access.
|
||||
</para>
|
||||
|
||||
FDDI and Token Ring are two common networking systems that use ring topologies. Token Ring networks are
|
||||
actually physically wired as a star, but use a special hub that is wired internally as a ring, and
|
||||
function in a logical ring.
|
||||
<para>
|
||||
FDDI and Token Ring are two common networking systems that use ring topologies.
|
||||
Token Ring networks are actually physically wired as a star, but use a special
|
||||
hub that is wired internally as a ring, and function in a logical ring.
|
||||
</para>
|
||||
|
||||
Ring topologies offer the advantage of equal access to the network media through token passing,
|
||||
so they are often used in networks with many clients or with high-speed clients. The main
|
||||
disadvantage of a ring topology is the same as a bus: a single node's failure can disrupt the
|
||||
entire network. Ring networks can also be more difficult to troubleshoot and expand.
|
||||
<para>
|
||||
Ring topologies offer the advantage of equal access to the network media
|
||||
through token passing, so they are often used in networks with many
|
||||
clients or with high-speed clients. The main disadvantage of a ring
|
||||
topology is the same as a bus: a single node's failure can disrupt the
|
||||
entire network. Ring networks can also be more difficult to troubleshoot
|
||||
and expand.
|
||||
</para>
|
||||
|
||||
Mesh
|
||||
|
||||
A mesh topology provides fault tolerance through redundant links. In this system, each node is connected
|
||||
to every other node with seperate cables. Thus, a three-node network would use three cables; a four
|
||||
node network would use eight cables; and a 10-node network would require 45 cables.
|
||||
<para>
|
||||
A mesh topology provides fault tolerance through redundant links. In this
|
||||
system, each node is connected to every other node with seperate cables. Thus,
|
||||
a three-node network would use three cables; a four node network would use
|
||||
eight cables; and a 10-node network would require 45 cables.
|
||||
</para>
|
||||
|
||||
The main advantage of this system is a high degree of reliability. Any cable (or even several,
|
||||
depending on the size) could be severed without any nodes losing access to the network. The obvious
|
||||
disadvantage is that mesh topologies require large amounts of cable, making them very expensive
|
||||
<para>
|
||||
The main advantage of this system is a high degree of reliability. Any cable
|
||||
(or even several, depending on the size) could be severed without any nodes
|
||||
losing access to the network. The obvious disadvantage is that mesh
|
||||
topologies require large amounts of cable, making them very expensive
|
||||
to install and expand.
|
||||
</para>
|
||||
|
||||
A mesh topology can use routers (described below) to choose the best path for each network transmission.
|
||||
This allows redundant links to provide increased efficiency as well as relability.
|
||||
<para>
|
||||
A mesh topology can use routers (described below) to choose the best path for
|
||||
each network transmission. This allows redundant links to provide increased
|
||||
efficiency as well as relability.
|
||||
</para>
|
||||
|
||||
Hybrid
|
||||
|
||||
A hyrbid topolgy is any combination of the above topologies. One common hybrid technology is a star bus,
|
||||
in which several star-wired networks segments are interconnected with a bus. This topology is useful in
|
||||
networks where groups of workstations are close together, but several distant groups need to be connected.
|
||||
<para>
|
||||
A hybrid topolgy is any combination of the above topologies. One common hybrid
|
||||
technology is a star bus, in which several star-wired networks segments are
|
||||
interconnected with a bus. This topology is useful in networks where groups of
|
||||
workstations are close together, but several distant groups need to be
|
||||
connected.
|
||||
</para>
|
||||
|
||||
Another hyrbid technology is a star ring, or star-wired ring. This is the topology used bby Token Ring
|
||||
networks. The wiring forms a star topology, but hub is interally connected a ring.
|
||||
<para>
|
||||
Another hybrid technology is a star ring, or star-wired ring. This is the
|
||||
topology used by Token Ring networks. The wiring forms a star topology,
|
||||
but hub is interally connected a ring.
|
||||
</para>
|
||||
|
||||
The mesh topology, while too expensive to be practical in itself, is useful in hybrid forms. For example,
|
||||
workstations might be connected by a star topology while three of four critical servers are wired in a mesh.
|
||||
This adds reliablity to complex networks.
|
||||
<para>
|
||||
The mesh topology, while too expensive to be practical in itself, is useful in
|
||||
hybrid forms. For example, workstations might be connected by a star topology
|
||||
while three of four critical servers are wired in a mesh. This adds reliablity
|
||||
to complex networks.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -171,7 +171,6 @@ communication.
|
|||
best possible signalling between machines and allows you to use
|
||||
hardware (RTS/CTS) flow control.
|
||||
|
||||
|
||||
Pin Name Pin Pin
|
||||
Tx Data 2 ----------------------------- 3
|
||||
Rx Data 3 ----------------------------- 2
|
||||
|
@ -183,15 +182,12 @@ communication.
|
|||
RLSD/DCD 8 ---------------------------/- 20
|
||||
\- 6
|
||||
|
||||
|
||||
|
||||
9.2. Parallel port cable (PLIP cable)
|
||||
|
||||
If you intend to use the PLIP protocol between two machines then this
|
||||
cable will work for you irrespective of what sort of parallel ports
|
||||
you have installed.
|
||||
|
||||
|
||||
Pin Name pin pin
|
||||
STROBE 1*
|
||||
D0->ERROR 2 ----------- 15
|
||||
|
@ -212,8 +208,6 @@ communication.
|
|||
SLCTIN 17*
|
||||
GROUND 25 ----------- 25
|
||||
|
||||
|
||||
|
||||
Notes:
|
||||
|
||||
· Do not connect the pins marked with an asterisk `*'.
|
||||
|
@ -249,6 +243,7 @@ communication.
|
|||
cabling you may find that the ethernet is unreliable or doesn't work
|
||||
at all. Normally you'd use `T pieces' to interconnect the machines, so
|
||||
that you end up with something that looks like:
|
||||
|
||||
|==========T=============T=============T==========T==========|
|
||||
| | | |
|
||||
| | | |
|
||||
|
@ -256,8 +251,6 @@ communication.
|
|||
| | | | | | | |
|
||||
----- ----- ----- -----
|
||||
|
||||
|
||||
|
||||
where the `|' at either end represents a terminator, the `======' rep
|
||||
resents a length of coaxial cable with BNC plugs at either end and the
|
||||
`T' represents a `T piece' connector. You should keep the length of
|
||||
|
|
|
@ -3,7 +3,6 @@
|
|||
<title>Multicasting</title>
|
||||
|
||||
<para>
|
||||
|
||||
This HOWTO tries to cover most aspects related to multicast over
|
||||
TCP/IP networks. So, a lot of information within it is not Linux-spe-
|
||||
cific (just in case you don't use GNU/Linux... yet). Multicast is cur-
|
||||
|
@ -637,7 +636,6 @@
|
|||
(either supplied by the program or returned by the kernel) is optval.
|
||||
The optnames involved in multicast programming are the following:
|
||||
|
||||
|
||||
______________________________________________________________________
|
||||
setsockopt() getsockopt()
|
||||
IP_MULTICAST_LOOP yes yes
|
||||
|
@ -647,8 +645,6 @@
|
|||
IP_DROP_MEMBERSHIP yes no
|
||||
______________________________________________________________________
|
||||
|
||||
|
||||
|
||||
optlen carries the size of the data structure optval points to. Note
|
||||
that in getsockopt() it is a value-result rather than a value: the
|
||||
kernel writes the value of optname in the buffer pointed by optval and
|
||||
|
@ -657,8 +653,6 @@
|
|||
Both setsockopt() and getsockopt() return 0 on success and -1 on
|
||||
error.
|
||||
|
||||
|
||||
|
||||
6.1. IP_MULTICAST_LOOP.
|
||||
|
||||
You have to decide, as the application writer, whether you want the
|
||||
|
@ -674,32 +668,23 @@
|
|||
|
||||
Regard that optval is a pointer. You can't write:
|
||||
|
||||
|
||||
setsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, 0, 1);
|
||||
|
||||
|
||||
|
||||
to disable loopback. Instead write:
|
||||
|
||||
|
||||
u_char loop;
|
||||
setsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));
|
||||
|
||||
|
||||
|
||||
and set loop to 1 to enable loopback or 0 to disable it.
|
||||
|
||||
To know whether a socket is currently looping-back or not use
|
||||
something like:
|
||||
|
||||
|
||||
u_char loop;
|
||||
int size;
|
||||
|
||||
getsockopt(socket, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, &size)
|
||||
|
||||
|
||||
|
||||
6.2. IP_MULTICAST_TTL.
|
||||
|
||||
If not otherwise specified, multicast datagrams are sent with a
|
||||
|
@ -708,17 +693,12 @@
|
|||
put that value into a variable (here I name it "ttl") and write
|
||||
somewhere in your program:
|
||||
|
||||
|
||||
u_char ttl;
|
||||
setsockopt(socket, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));
|
||||
|
||||
|
||||
|
||||
The behavior with getsockopt() is similar to the one seen on
|
||||
IP_MULTICAST_LOOP.
|
||||
|
||||
|
||||
|
||||
6.3. IP_MULTICAST_IF.
|
||||
|
||||
Usually, the system administrator specifies the default interface
|
||||
|
@ -726,11 +706,10 @@
|
|||
this and choose a concrete outgoing interface for a given socket with
|
||||
this option.
|
||||
|
||||
|
||||
struct in_addr interface_addr;
|
||||
setsockopt (socket, IPPROTO_IP, IP_MULTICAST_IF, &interface_addr, sizeof(interface_addr));
|
||||
|
||||
>From now on, all multicast traffic generated in this socket will be
|
||||
From now on, all multicast traffic generated in this socket will be
|
||||
output from the interface chosen. To revert to the original behavior
|
||||
and let the kernel choose the outgoing interface based on the system
|
||||
administrator's configuration, it is enough to call setsockopt() with
|
||||
|
@ -747,8 +726,6 @@
|
|||
interface, although the remainding interfaces might be used for
|
||||
multicast forwarding if the host is acting as a multicast router.
|
||||
|
||||
|
||||
|
||||
6.4. IP_ADD_MEMBERSHIP.
|
||||
|
||||
Recall that you need to tell the kernel which multicast groups you are
|
||||
|
|
|
@ -698,12 +698,8 @@
|
|||
|
||||
Typically you would use a command similar to the following:
|
||||
|
||||
|
||||
|
||||
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
|
||||
|
||||
|
||||
|
||||
In this case I'm configuring an ethernet interface `eth0' with the IP
|
||||
address `192.168.0.1' and a network mask of `255.255.255.0'. The `up'
|
||||
that trails the command tells the interface that it should become
|
||||
|
@ -723,7 +719,6 @@
|
|||
There are many other options to the ifconfig command. The most
|
||||
important of these are:
|
||||
|
||||
|
||||
up this option activates an interface (and is the default).
|
||||
|
||||
down
|
||||
|
@ -1756,17 +1751,11 @@
|
|||
such as tcpdump to allow them to display names instead of numbers in
|
||||
their output. The general syntax of the file is:
|
||||
|
||||
|
||||
|
||||
protocolname number aliases
|
||||
|
||||
|
||||
|
||||
The /etc/protocols file supplied with the Debian distribution is as
|
||||
follows:
|
||||
|
||||
|
||||
|
||||
# /etc/protocols:
|
||||
# $Id$
|
||||
#
|
||||
|
@ -1799,8 +1788,6 @@
|
|||
ipip 94 IPIP # Yet Another IP encapsulation
|
||||
encap 98 ENCAP # Yet Another IP encapsulation
|
||||
|
||||
|
||||
|
||||
5.9.2. /etc/networks
|
||||
|
||||
The /etc/networks file has a similar function to that of the
|
||||
|
@ -1808,22 +1795,14 @@
|
|||
against network addresses. Its format differs in that there may be
|
||||
only two fields per line and that the fields are coded as:
|
||||
|
||||
|
||||
|
||||
networkname networkaddress
|
||||
|
||||
|
||||
|
||||
An example might look like:
|
||||
|
||||
|
||||
|
||||
loopnet 127.0.0.0
|
||||
localnet 192.168.0.0
|
||||
amprnet 44.0.0.0
|
||||
|
||||
|
||||
|
||||
When you use commands like the route command, if a destination is a
|
||||
network and that network has an entry in the /etc/networks file then
|
||||
the route command will display that network name instead of its
|
||||
|
@ -1860,16 +1839,12 @@
|
|||
those users who are disallowed from logging in. It might looks
|
||||
something like:
|
||||
|
||||
|
||||
|
||||
# /etc/ftpusers - users not allowed to login via ftp
|
||||
root
|
||||
uucp
|
||||
bin
|
||||
mail
|
||||
|
||||
|
||||
|
||||
5.10.2. /etc/securetty
|
||||
|
||||
The /etc/securetty file allows you to specify which tty devices root
|
||||
|
@ -1877,16 +1852,12 @@
|
|||
program (usually /bin/login). Its format is a list of the tty devices
|
||||
names allowed, on all others root login is disallowed:
|
||||
|
||||
|
||||
|
||||
# /etc/securetty - tty's on which root is allowed to login
|
||||
tty1
|
||||
tty2
|
||||
tty3
|
||||
tty4
|
||||
|
||||
|
||||
|
||||
5.10.3. The tcpd hosts access control mechanism.
|
||||
|
||||
The tcpd program you will have seen listed in the same /etc/inetd.conf
|
||||
|
@ -2077,13 +2048,9 @@
|
|||
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
|
||||
root# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
|
||||
|
||||
|
||||
|
||||
Most of the ethernet drivers were developed by Donald Becker,
|
||||
becker@CESDIS.gsfc.nasa.gov.
|
||||
|
||||
|
||||
|
||||
6.8. IPIP Encapsulation
|
||||
|
||||
Why would you want to encapsulate IP datagrams within IP datagrams? It
|
||||
|
@ -2094,15 +2061,12 @@
|
|||
|
||||
Kernel Compile Options:
|
||||
|
||||
|
||||
Networking options --->
|
||||
[*] TCP/IP networking
|
||||
[*] IP: forwarding/gatewaying
|
||||
....
|
||||
<*> IP: tunneling
|
||||
|
||||
|
||||
|
||||
IP tunnel devices are called `tunl0', `tunl1' etc.
|
||||
|
||||
"But why ?". Ok, ok. Conventional IP routing rules mandate that an IP
|
||||
|
@ -2122,8 +2086,6 @@
|
|||
|
||||
6.8.1. A tunneled network configuration.
|
||||
|
||||
|
||||
|
||||
192.168.1/24 192.168.2/24
|
||||
|
||||
- -
|
||||
|
@ -2138,8 +2100,6 @@
|
|||
| |
|
||||
- -
|
||||
|
||||
|
||||
|
||||
The diagram illustrates another possible reason to use IPIP encapsula
|
||||
tion, virtual private networking. This example presupposes that you
|
||||
have two machines each with a simple dial up internet connection. Each
|
||||
|
@ -2156,8 +2116,6 @@
|
|||
|
||||
Linux router `A' would be configured with a script like the following:
|
||||
|
||||
|
||||
|
||||
#!/bin/sh
|
||||
PATH=/sbin:/usr/sbin
|
||||
mask=255.255.255.0
|
||||
|
@ -2175,12 +2133,8 @@
|
|||
ifconfig tunl0 192.168.1.1 up
|
||||
route add -net 192.168.2.0 netmask $mask gw $remotegw tunl0
|
||||
|
||||
|
||||
|
||||
Linux router `B' would be configured with a similar script:
|
||||
|
||||
|
||||
|
||||
#!/bin/sh
|
||||
PATH=/sbin:/usr/sbin
|
||||
mask=255.255.255.0
|
||||
|
@ -2198,16 +2152,10 @@
|
|||
ifconfig tunl0 192.168.2.1 up
|
||||
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
|
||||
|
||||
|
||||
|
||||
The command:
|
||||
|
||||
|
||||
|
||||
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
|
||||
|
||||
|
||||
|
||||
reads: `Send any datagrams destined for 192.168.1.0/24 inside an IPIP
|
||||
encap datagram with a destination address of aaa.bbb.ccc.ddd'.
|
||||
|
||||
|
@ -2228,8 +2176,6 @@
|
|||
to act and behave as if it is both fully connected to the Internet and
|
||||
also part of the remote network supported by host `A':
|
||||
|
||||
|
||||
|
||||
192.168.1/24
|
||||
|
||||
-
|
||||
|
@ -2244,12 +2190,8 @@
|
|||
| also: 192.168.1.12
|
||||
-
|
||||
|
||||
|
||||
|
||||
Linux router `A' would be configured with:
|
||||
|
||||
|
||||
|
||||
#!/bin/sh
|
||||
PATH=/sbin:/usr/sbin
|
||||
mask=255.255.255.0
|
||||
|
@ -2270,12 +2212,8 @@
|
|||
# Proxy ARP for the remote host
|
||||
arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub
|
||||
|
||||
|
||||
|
||||
Linux host `B' would be configured with:
|
||||
|
||||
|
||||
|
||||
#!/bin/sh
|
||||
PATH=/sbin:/usr/sbin
|
||||
mask=255.255.255.0
|
||||
|
@ -2289,8 +2227,6 @@
|
|||
ifconfig tunl0 192.168.1.12 up
|
||||
route add -net 192.168.1.0 netmask $mask gw $remotegwtunl0
|
||||
|
||||
|
||||
|
||||
This sort of configuration is more typical of a Mobile-IP application.
|
||||
Where a single host wants to roam around the Internet and maintain a
|
||||
single usable IP address the whole time. You should refer to the
|
||||
|
@ -2340,8 +2276,6 @@
|
|||
|
||||
A typical configuration might look something like this:
|
||||
|
||||
|
||||
|
||||
- -
|
||||
\ | 192.168.1.0
|
||||
\ | /255.255.255.0
|
||||
|
@ -2354,14 +2288,10 @@
|
|||
/ | --------
|
||||
- -
|
||||
|
||||
|
||||
|
||||
Masquerading with IPFWADM
|
||||
|
||||
The most relevant commands for this configuration are:
|
||||
|
||||
|
||||
|
||||
# Network route for ethernet
|
||||
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
||||
#
|
||||
|
@ -2371,15 +2301,11 @@
|
|||
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
|
||||
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
|
||||
|
||||
|
||||
|
||||
Masquerading with IPCHAINS
|
||||
|
||||
This is similar to using IPFWADM but the command structure has
|
||||
changed:
|
||||
|
||||
|
||||
|
||||
# Network route for ethernet
|
||||
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
||||
#
|
||||
|
@ -2389,12 +2315,11 @@
|
|||
# Cause all hosts on the 192.168.1/24 network to be masqueraded.
|
||||
ipchains -A forward -s 192.168.1.0/24 -j MASQ
|
||||
|
||||
|
||||
|
||||
You can get more information on the Linux IP Masquerade feature from
|
||||
the IP Masquerade Resource Page. Also, a very detailed document about
|
||||
masquesrading is the ``IP-Masquerade mini-HOWTO'' (which also intructs
|
||||
to configure other OS's to run with a Linux masquerade server).
|
||||
|
||||
6.10. IP Transparent Proxy
|
||||
|
||||
IP transparent proxy is a feature that enables you to redirect servers
|
||||
|
@ -2418,19 +2343,13 @@
|
|||
....
|
||||
[*] IP: transparent proxy support (EXPERIMENTAL)
|
||||
|
||||
|
||||
|
||||
Configuration of the transparent proxy feature is performed using the
|
||||
ipfwadm command
|
||||
|
||||
An example that might be useful is as follows:
|
||||
|
||||
|
||||
|
||||
root# ipfwadm -I -a accept -D 0/0 telnet -r 2323
|
||||
|
||||
|
||||
|
||||
This example will cause any connection attempts to port telnet (23) on
|
||||
any host to be redirected to port 2323 on this host. If you run a
|
||||
service on that port, you could forward telnet connections, log them
|
||||
|
@ -2447,17 +2366,12 @@
|
|||
find it on the world wide web). You can choose to run transproxy on
|
||||
port 8081, and issue this command:
|
||||
|
||||
|
||||
|
||||
root# ipfwadm -I -a accept -D 0/0 80 -r 8081
|
||||
|
||||
|
||||
|
||||
The transproxy program, then, will receive all connections meant to
|
||||
reach external servers and will pass them to the local proxy after
|
||||
fixing protocol differences.
|
||||
|
||||
|
||||
6.11. IPv6
|
||||
|
||||
Just when you thought you were beginning to understand IP networking
|
||||
|
@ -2500,14 +2414,11 @@
|
|||
|
||||
Kernel Compile Options:
|
||||
|
||||
|
||||
Networking options --->
|
||||
[*] TCP/IP networking
|
||||
....
|
||||
[*] IP: multicasting
|
||||
|
||||
|
||||
|
||||
A suite of tools and some minor network configuration is required.
|
||||
Please check the Multicast-HOWTO for more information on Multicast
|
||||
support in Linux.
|
||||
|
|
|
@ -1,13 +1,26 @@
|
|||
PSTN (Public Service Telephone Network)
|
||||
<sect1 id="PSTN">
|
||||
|
||||
The telephone system that is used thoughout the U.S. and many other countries. Although never
|
||||
intended for networking, telephone lines can be used for communications for computers.
|
||||
<title>PSTN</title>
|
||||
|
||||
A modem (modulator/demodulator) is used to interface between a computer and the telephone system.
|
||||
Modems can convert data into audible tones and back. The fastest two-way modems currently available
|
||||
support a speed of 22.6 Kbps (kilobits per second).
|
||||
<para>
|
||||
PSTN (Public Service Telephone Network) is the telephone system that is used
|
||||
thoughout the U.S. and many other countries. Although never intended for
|
||||
networking, telephone lines can be used for communications for computers.
|
||||
</para>
|
||||
|
||||
Current modems advertise speeds up to 56 Kbps per second. These modems rely on digital equipment being
|
||||
used in the phone company's central office and in the facility (such as the Internet Service Provider)
|
||||
you are dialling into. The 56 Kbps speed also works in only one direction; the other direction supports
|
||||
<para>
|
||||
A modem (modulator/demodulator) is used to interface between a computer and
|
||||
the telephone system. Modems can convert data into audible tones and back.
|
||||
The fastest two-way modems currently available support a speed of 33.6 Kbps
|
||||
(kilobits per second).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Current modems advertise speeds up to 56 Kbps per second. These modems rely
|
||||
on digital equipment being used in the phone company's central office and in
|
||||
the facility (such as the Internet Service Provider) you are dialling into.
|
||||
The 56 Kbps speed also works in only one direction; the other direction supports
|
||||
33.6 Kbps.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -8,9 +8,12 @@
|
|||
in another node. MAC Address Takeover: when an IP takeover occurs, it
|
||||
should be made sure that all the nodes in the network update their ARP
|
||||
caches (the mapping between IP and MAC addresses).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
See the High-Availability HOWTO for more details:
|
||||
http://metalab.unc.edu/pub/Linux/ALPHA/linux-ha/High-Availability-
|
||||
HOWTO.html
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -4,25 +4,27 @@
|
|||
|
||||
<para>
|
||||
Rose protocol ( AF_ROSE )
|
||||
|
||||
Rose device names are `rs0', `rs1', etc. in 2.1.* kernels. Rose is
|
||||
available in the 2.1.* kernels.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<screen>
|
||||
Kernel Compile Options:
|
||||
|
||||
|
||||
Networking options --->
|
||||
[*] Amateur Radio AX.25 Level 2
|
||||
<*> Amateur Radio X.25 PLP (Rose)
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
|
||||
<para>
|
||||
The AX25, Netrom and Rose protocols are covered by the AX25-HOWTO.
|
||||
These protocols are used by Amateur Radio Operators world wide in
|
||||
packet radio experimentation.
|
||||
|
||||
Most of the work for implementation of these protocols has been done
|
||||
by Jonathon Naylor, jsn@cs.nott.ac.uk.
|
||||
packet radio experimentation. Most of the work for implementation
|
||||
of these protocols has been done by Jonathon Naylor,
|
||||
jsn@cs.nott.ac.uk.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -1,3 +1,7 @@
|
|||
<sect1 id="Routing">
|
||||
|
||||
<title>Routing</title>
|
||||
|
||||
12.3. Packets and routers
|
||||
|
||||
What the browser wants to do is send a command to the Web server on
|
||||
|
@ -6439,3 +6443,4 @@ There is a good article on configuring the BEFSR41, and its limitations, at
|
|||
[http://www.arstechnica.com/reviews/3q00/linksys/befsr41-2.html] Linksys
|
||||
EtherFast Cable/DSL Router, Model BEFSR41. It dates from August of 2000.
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -2840,9 +2840,4 @@ Samba-server provides a SMB server which can be used to provide network services
|
|||
(nmenezes@n3.com.br) and many others for whom I don't have contact
|
||||
details.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -934,4 +934,12 @@ Credits for fixes and hints are listed here, will grow sure in the future
|
|||
bugs
|
||||
* Dennis van Dok <dvandok at quicknet dot nl>: Reporting minor bugs
|
||||
|
||||
Linux-Dictionary, Binh Nguyen, http://www.tldp.org/LDP/Linux-Dictionary/html/index.html
|
||||
Linux-Filesystem-Hierarchy, Binh Nguyen, http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/index.html
|
||||
|
||||
Text-Terminal-HOWTO
|
||||
David S. Lawyer <mailto:dave@lafn.org>
|
||||
v1.36, August 2004
|
||||
|
||||
|
||||
</appendix>
|
||||
|
|
|
@ -19,10 +19,10 @@ Theoretically and practically, it does little different from the OSI model.
|
|||
However, it differs in the number of layers that it possesses and also the
|
||||
purposes of each layer. Funnily, for such a widely used protocol there seems
|
||||
to be a number of different interpretations as to its composition and the
|
||||
purpose of each layer. Even so, it is generally agreed
|
||||
that there either four or five different layers and that they are roughly
|
||||
equivalent to the same layers in the OSI Network Layer Model with the exception
|
||||
of one or two which are split and/or combined.
|
||||
purpose of each layer. Even so, it is generally agreed that there either
|
||||
four or five different layers and that they are roughly equivalent to the
|
||||
same layers in the OSI Network Layer Model with the exception of one or
|
||||
two which are split and/or combined.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
@ -2,21 +2,58 @@
|
|||
|
||||
<title>TFTP</title>
|
||||
|
||||
<para>
|
||||
Trivial File Transfer Protocol TFTP is a bare-bones protocol used by
|
||||
devices that boot from the network. It is runs on top of UDP, so it
|
||||
doesn't require a real TCP/IP stack. Misunderstanding: Many people
|
||||
describe TFTP as simply a trivial version of FTP without authentication.
|
||||
This misses the point. The purpose of TFTP is not to reduce the complexity
|
||||
of file transfer, but to reduce the complexity of the underlying TCP/IP
|
||||
stack so that it can fit inside boot ROMs. Key point: TFTP is almost
|
||||
always used with BOOTP. BOOTP first configures the device, then TFTP
|
||||
transfers the boot image named by BOOTP which is then used to boot the
|
||||
device. Key point: Many systems come with unnecessary TFTP servers. Many
|
||||
TFTP servers have bugs, like the backtracking problem or buffer overflows.
|
||||
As a consequence, many systems can be exploited with TFTP even though
|
||||
virtually nobody really uses it. Key point: A TFTP file transfer client
|
||||
is built into many operating systems (UNIX, Windows, etc.). These clients
|
||||
are often used to download rootkits when being broken into. Therefore,
|
||||
removing the TFTP client should be part of your hardening procedure.
|
||||
For further details on the TFTP protocol please see RFC's 1350, 1782,
|
||||
1783, 1784, and 1785.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Most likely, you'll interface with the TFTP protocol using the TFTP command
|
||||
line client, 'tftp', which allows users to transfer files to and from a
|
||||
remote machine. The remote host may be specified on the command line, in
|
||||
which case tftp uses host as the default host for future transfers.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Setting up TFTP is almost as easy as DHCP.
|
||||
|
||||
First install from the rpm package:
|
||||
<screen>
|
||||
# rpm -ihv tftp-server-*.rpm
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
Create a directory for the files:
|
||||
<screen>
|
||||
# mkdir /tftpboot
|
||||
# chown nobody:nobody /tftpboot
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
The directory /tftpboot is owned by user nobody, because this is the default
|
||||
user id set up by tftpd to access the files.
|
||||
user id set up by tftpd to access the files. Edit the file /etc/xinetd.d/tftp
|
||||
to look like the following:
|
||||
</para>
|
||||
|
||||
Edit the file /etc/xinetd.d/tftp to look like the following:
|
||||
<para>
|
||||
<screen>
|
||||
service tftp
|
||||
{
|
||||
socket_type = dgram
|
||||
|
@ -29,19 +66,27 @@ service tftp
|
|||
per_source = 11
|
||||
cps = 100 2
|
||||
}
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
|
||||
<para>
|
||||
The changes from the default file are the parameter disable = no (to enable
|
||||
the service) and the server argument -c. This argument allows for the
|
||||
creation of files, which is necessary if you want to save boot or disk
|
||||
images. You may want to make TFTP read only in normal operation.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Then reload xinetd:
|
||||
|
||||
<screen>
|
||||
/etc/rc.d/init.d/xinetd reload
|
||||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can use the tftp command, available from the tftp (client) rpm package,
|
||||
to test the server. At the tftp prompt, you can issue the commands put and
|
||||
get.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -18,9 +18,14 @@ Wavelan device names are `eth0', `eth1', etc.
|
|||
</screen>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The WaveLAN card is a spread spectrum wireless lan card. The card
|
||||
looks very like an ethernet card in practice and is configured in much
|
||||
the same way.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
You can get information on the Wavelan card from Wavelan.com.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
Loading…
Reference in New Issue