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,8 +72,7 @@ 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
|
||||
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
|
||||
|
|
File diff suppressed because it is too large
Load Diff
|
@ -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>
|
||||
|
||||
The Frame Relay device names are `dlci00', `dlci01' etc for the DLCI
|
||||
encapsulation devices and `sdla0', `sdla1' etc for the FRAD(s).
|
||||
|
||||
<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>
|
||||
|
||||
Mike McLagan, mike.mclagan@linux.org, developed the Frame Relay
|
||||
support and configuration tools.
|
||||
|
||||
Currently the only FRAD supported are the Sangoma Technologies S502A,
|
||||
S502E and S508.
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
Note that the previous commands use sh syntax, if you use a csh
|
||||
flavour instead (like tcsh), the for loop will look different.
|
||||
|
||||
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>
|
||||
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
|
||||
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>
|
||||
|
||||
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>
|
||||
<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,96 +1,105 @@
|
|||
<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>
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
figures were last reset. You may specify a variety of rules to
|
||||
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>
|
||||
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
|
||||
figures were last reset. You may specify a variety of rules to
|
||||
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
|
||||
choose. I've picked a simple example of what might be useful to use,
|
||||
you should read the ipfwadm man page for more information.
|
||||
Scenario: You have a ethernet network that is linked to the internet
|
||||
via a PPP link. On the ethernet you have a machine that offers a
|
||||
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
|
||||
ipfwadm -A -f
|
||||
#
|
||||
# Set shortcuts
|
||||
localnet=44.136.8.96/29
|
||||
any=0/0
|
||||
# Add rules for local ethernet segment
|
||||
ipfwadm -A in -a -P tcp -D $localnet ftp-data
|
||||
ipfwadm -A out -a -P tcp -S $localnet ftp-data
|
||||
ipfwadm -A in -a -P tcp -D $localnet www
|
||||
ipfwadm -A out -a -P tcp -S $localnet www
|
||||
ipfwadm -A in -a -P tcp -D $localnet
|
||||
ipfwadm -A out -a -P tcp -S $localnet
|
||||
ipfwadm -A in -a -P udp -D $localnet
|
||||
ipfwadm -A out -a -P udp -S $localnet
|
||||
#
|
||||
# Rules for default
|
||||
ipfwadm -A in -a -P tcp -D $any ftp-data
|
||||
ipfwadm -A out -a -P tcp -S $any ftp-data
|
||||
ipfwadm -A in -a -P tcp -D $any www
|
||||
ipfwadm -A out -a -P tcp -S $any www
|
||||
ipfwadm -A in -a -P tcp -D $any
|
||||
ipfwadm -A out -a -P tcp -S $any
|
||||
ipfwadm -A in -a -P udp -D $any
|
||||
ipfwadm -A out -a -P udp -S $any
|
||||
#
|
||||
# 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>
|
||||
|
||||
|
||||
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
|
||||
choose. I've picked a simple example of what might be useful to use,
|
||||
you should read the ipfwadm man page for more information.
|
||||
Scenario: You have a ethernet network that is linked to the internet
|
||||
via a PPP link. On the ethernet you have a machine that offers a
|
||||
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.
|
||||
|
||||
You might use a command set that looks like the following, which is
|
||||
shown as a shell script:
|
||||
|
||||
|
||||
|
||||
#!/bin/sh
|
||||
#
|
||||
# Flush the accounting rules
|
||||
ipfwadm -A -f
|
||||
#
|
||||
# Set shortcuts
|
||||
localnet=44.136.8.96/29
|
||||
any=0/0
|
||||
# Add rules for local ethernet segment
|
||||
ipfwadm -A in -a -P tcp -D $localnet ftp-data
|
||||
ipfwadm -A out -a -P tcp -S $localnet ftp-data
|
||||
ipfwadm -A in -a -P tcp -D $localnet www
|
||||
ipfwadm -A out -a -P tcp -S $localnet www
|
||||
ipfwadm -A in -a -P tcp -D $localnet
|
||||
ipfwadm -A out -a -P tcp -S $localnet
|
||||
ipfwadm -A in -a -P udp -D $localnet
|
||||
ipfwadm -A out -a -P udp -S $localnet
|
||||
#
|
||||
# Rules for default
|
||||
ipfwadm -A in -a -P tcp -D $any ftp-data
|
||||
ipfwadm -A out -a -P tcp -S $any ftp-data
|
||||
ipfwadm -A in -a -P tcp -D $any www
|
||||
ipfwadm -A out -a -P tcp -S $any www
|
||||
ipfwadm -A in -a -P tcp -D $any
|
||||
ipfwadm -A out -a -P tcp -S $any
|
||||
ipfwadm -A in -a -P udp -D $any
|
||||
ipfwadm -A out -a -P udp -S $any
|
||||
#
|
||||
# List the rules
|
||||
ipfwadm -A -l -n
|
||||
#
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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>
|
||||
<screen>
|
||||
root# ipfwadm -A -l -n
|
||||
IP accounting rules
|
||||
pkts bytes dir prot source destination ports
|
||||
|
@ -110,15 +119,16 @@
|
|||
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)
|
||||
|
||||
|
||||
6.4. IP Accounting (for Linux-2.2)
|
||||
|
||||
The new accounting code is accessed via ``IP Firewall Chains''. See
|
||||
the IP chains home page for more information. Among other things,
|
||||
you'll now need to use ipchains instead of ipfwadm to configure your
|
||||
filters. (From Documentation/Changes in the latest kernel sources).
|
||||
The new accounting code is accessed via ``IP Firewall Chains''. See
|
||||
the IP chains home page for more information. Among other things,
|
||||
you'll now need to use ipchains instead of ipfwadm to configure your
|
||||
filters. (From Documentation/Changes in the latest kernel sources).
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
|
@ -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,9 +24,11 @@ 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
|
||||
service. One way is to use a device called a `Terminal Adaptor' which
|
||||
plugs into the Network Terminating Unit that you telecommunications
|
||||
carrier will have installed when you got your ISDN service and
|
||||
presents a number of serial interfaces. One of those interfaces is
|
||||
|
@ -62,44 +41,61 @@ 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
|
||||
[ ] Support audio via ISDN
|
||||
< > ICN 2B and 4B support
|
||||
< > PCBIT-D support
|
||||
< > Teles/NICCY1016PC/Creatix 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>
|
||||
|
|
|
@ -3,14 +3,17 @@
|
|||
<title>Redundant-Networking</title>
|
||||
|
||||
<para>
|
||||
IP Address Takeover (IPAT). When a network adapter card fails, its IP
|
||||
address should be taken by a working network card in the same node or
|
||||
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).
|
||||
IP Address Takeover (IPAT). When a network adapter card fails, its IP
|
||||
address should be taken by a working network card in the same node or
|
||||
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>
|
||||
|
||||
See the High-Availability HOWTO for more details:
|
||||
http://metalab.unc.edu/pub/Linux/ALPHA/linux-ha/High-Availability-
|
||||
HOWTO.html
|
||||
<para>
|
||||
See the High-Availability HOWTO for more details:
|
||||
http://metalab.unc.edu/pub/Linux/ALPHA/linux-ha/High-Availability-
|
||||
HOWTO.html
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</sect1>
|
||||
|
|
|
@ -2,27 +2,29 @@
|
|||
|
||||
<title>Rose</title>
|
||||
|
||||
<para>
|
||||
<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.
|
||||
</para>
|
||||
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
|
||||
|
@ -6438,4 +6442,5 @@ FAQ; it's mostly Windows stuff, but a few of the war stories may be useful.
|
|||
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>
|
||||
|
|
|
@ -1,22 +1,59 @@
|
|||
<sect1 id="TFTP">
|
||||
|
||||
<title>TFTP</title>
|
||||
<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.
|
||||
|
||||
Edit the file /etc/xinetd.d/tftp to look like the following:
|
||||
user id set up by tftpd to access the files. Edit the file /etc/xinetd.d/tftp
|
||||
to look like the following:
|
||||
</para>
|
||||
|
||||
<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