man的中文翻译是啥_百度知道博客访问： 516430
博文数量： 497
博客积分： 7865
博客等级： 少将
技术积分： 5738
注册时间：
时光荏苒..
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： LINUX
18.2.6.1.&Connecting NetBSD with BSD or Linux
The easiest case is when both machines run NetBSD: making a connection with the SLIP protocol is very easy. On the first machine write the following commands: # slattach /dev/tty00
# ifconfig sl0 inet 192.168.1.1 192.168.1.2
On the second machine write the following commands: # slattach /dev/tty00
# ifconfig sl0 inet 192.168.1.2 192.168.1.1
Now you can test the connection with ping; for example, on the second PC write: # ping 192.168.1.1
If everything worked there is now an active network connection between the two machines and ftp, telnet and other similar commands can be executed. The textual aliases of the machines can be written in the /etc/hosts file.
In the previous example both PC's used the first serial port (/dev/tty0). Substitute the appropriate device if you are using another port.
IP addresses like 192.168.x.x are reserved for “internal” networks. The first PC has address 192.168.1.1 and the second 192.168.1.2.
To achieve a faster connection the -s speed option to slattach can be specified.
ftp can be used to transfer files only if inetd is active and the ftpd server is enabled.
if one of the two PC's runs Linux, the commands are slightly different (on the Linux machine only). If the Linux machine gets the 192.168.1.2 address, the following commands are needed: # slattach -p slip -s 115200 /dev/ttyS0 &
# ifconfig sl0 192.168.1.2 pointopoint 192.168.1.1 up
# route add 192.168.1.1 dev sl0
Don't forget the “&” in the first command.
11.2. 练习
[更新时间] 21:19:36 [字数]35103
18.2.&Practice
18.2.1.&A walk through the kernel configuration
Before we dive into configuring various aspects of network setup, we want to walk through the necessary bits that have to or can be present in the kernel. See
for more details on compiling the kernel, we will concentrate on the configuration of the kernel here. We will take the i386/GENERIC config file as an example here. Config files for other platforms should contain similar information, the comments in the config files give additional hints. Besides the information given here, each kernel option is also documented in the
manpage, and there is usually a manpage for each driver too, e.g. .
The first line of each config file shows the version. It can be used to compare against other versions via CVS, or when reporting bugs. options
# NTP phase/frequency locked loop
If you want to run the Network Time Protocol (NTP), this option can be enabled for maximum precision. If the option is not present, NTP will still work. See
for more information. file-system
# Network File System client
If you want to use another machine's hard disk via the Network File System (NFS), this option is needed. Section&18.3.3, “Network File System (NFS)” gives more information on NFS. options
# Network File System server
This option includes the server side of the NFS remote file sharing protocol. Enable if you want to allow other machines to use your hard disk. Section&18.3.3, “Network File System (NFS)” contains more information on NFS. #options
# packet forwarding
If you want to setup a router that forwards packets between networks or network interfaces, setting this option is needed. If doesn't only switch on packet forwarding, but also increases some buffers. See
for details. options
# IP + ICMP + TCP + UDP
This enables the TCP/IP code in the kernel. Even if you don't want/use networking, you will still need this for machine-internal communication of subsystems like the X Window System. See
for more details. options
If you want to use IPv6, this is your option. If you don't want IPv6, which is part of NetBSD since the 1.5 release, you can remove/comment out that option. See the
manpage and
for more information on the next generation Internet protocol. #options
# IP security
Includes support for the IPsec protocol, including key and policy management, authentication and compression. This option can be used without the previous option INET6, if you just want to use IPsec with IPv4, which is possible. See
for more information. #options
# IP security ( define w/IPSEC)
This option is needed in addition to IPSEC if encryption is wanted in IPsec. #options
# IP multicast routing
If multicast services like the MBone services should be routed, this option needs to be included. Note that the routing itself is controlled by the
daemon. options
# XNS tunneling over IP
These options enables the Xerox Network Systems(TM) protocol family. It's not related to the TCP/IP protocol stack, and in rare use today. The
manpage has some details. options
# OSI tunneling over IP
These options include the OSI protocol stack, that was said for a long time to be the future of networking. It's mostly history these days. :-) See the
manpage for more information. options
CCITT,LLC,HDLC
These options enable the X.25 protocol set for transmission of data over serial lines. It is/was used mostly in conjunction with the OSI protocols and in WAN networking. options
# AppleTalk networking protocols
Include support for the AppleTalk protocol stack. Userland server programs are needed to make use of that. See pkgsrc/net/netatalk and pkgsrc/net/netatalk-asun for such packages. More information on the AppleTalk protocol and protocol stack are available in the
manpage. options
PPP_BSDCOMP
# BSD-Compress compression support for PPP
PPP_DEFLATE
# Deflate compression support for PPP
PPP_FILTER
# Active filter support for PPP (requires bpf)
These options tune various aspects of the Point-to-Point protocol. The first two determine the compression algorithms used and available, while the third one enables code to filter some packets. options
PFIL_HOOKS
packet filter hooks
IPFILTER_LOG
log support
These options enable firewalling in NetBSD, using IPfilter. See the
manpages for more information on operation of IPfilter, and
for a configuration example. # Compatibility with 4.2BSD implementation of TCP/IP.
Not recommended.
TCP_COMPAT_42
This option is only needed if you have machines on the network that still run 4.2BSD or a network stack derived from it. If you've got one or more 4.2BSD-systems on your network, you've to pay attention to set the right broadcast-address, as 4.2BSD has a bug in its networking code, concerning the broadcast address. This bug forces you to set all host-bits in the broadcast-address to “0”. The TCP_COMPAT_42 option helps you ensuring this. options
NFS_BOOT_DHCP,NFS_BOOT_BOOTPARAM
These options enable lookup of data via DHCP or the BOOTPARAM protocol if the kernel is told to use a NFS root file system. See the
manpage for more information. # Kernel root file system and dump configuration.
root on ? type ?
root on sd0a type ffs
root on ? type nfs
These lines tell where the kernel looks for it's root file system, and which filesystem type it is expected to have. If you want to make a kernel that uses a NFS root filesystem via the tlp0 interface, you can do this with “root on tlp0 type nfs”. If a ? is used instead of a device/type, the kernel tries to figure one out on it's own. # ISA serial interfaces
at isa? port 0x3f8 irq 4
# Standard PC serial ports
at isa? port 0x2f8 irq 3
at isa? port 0x3e8 irq 5
If you want to use PPP or SLIP, you will need some serial (com) interfaces. Others with attachment on USB, PCMCIA or PUC will do as well. # Network Interfaces
This rather long list contains all sort of network drivers. Please pick the one that matches your hardware, according to the comments. For most drivers, there's also a manual page available, e.g. , , etc. # MII/PHY support
This section lists media independent interfaces for network cards. Pick one that matches your hardware. If in doubt, enable them all and see what the kernel picks. See the
manpage for more information. # USB Ethernet adapters
at uhub? port ?
# ADMtek AN986 Pegasus based adapters
at uhub? port ?
# CATC USB-EL1201A based adapters
at uhub? port ?
# Kawasaki LSI KL5KUSB101B based adapters
USB-ethernet adapters only have about 2MBit/s bandwidth, but they are very convenient to use. Of course this needs other USB related options which we won't cover here, as well as the necessary hardware. See the corresponding manpages for more information. # network pseudo-devices
pseudo-device
# Berkeley packet filter
This pseudo-device allows sniffing packets of all sorts. It's needed for tcpdump, but also rarpd and some other applications that need to know about network traffic. See
for more information. pseudo-device
# IP filter (firewall) and NAT
This one enables the IPfilter's packet filtering kernel interface used for firewalling, NAT (IP Masquerading) etc. See
for more information. pseudo-device
# network loopback
This is the “lo0” software loopback network device which is used by some programs these days, as well as for routing things. Should not be omitted. See
for more details. pseudo-device
# Point-to-Point Protocol
If you want to use PPP either over a serial interface or ethernet (PPPoE), you will need this option. See
for details on this interface. pseudo-device
# Serial Line IP
Serial Line IP is a simple encapsulation for IP over (well :) serial lines. It does not include negotiation of IP addresses and other options, which is the reason that it's not in widespread use today any more. See . pseudo-device
# Starmode Radio IP (Metricom)
If you happen to have one of the old Metricon Ricochet packet radio wireless network devices, use this pseudo-device to use it. See the
manpage for detailed information. pseudo-device
# network tunneling over tty
This network device can be used to tunnel network packets to a device file, /dev/tun*. Packets routed to the tun0 interface can be read from /dev/tun0, and data written to /dev/tun0 will be sent out the tun0 network interface. This can be used to implement e.g. QoS routing in userland. See
for details. pseudo-device
# generic L3 over IP tunnel
The GRE encapsulation can be used to tunnel arbitrary layer 3 packets over IP, e.g. to implement VPNs. See
for more. pseudo-device
# IP Encapsulation within IP (RFC 2003)
Another IP-in-IP encapsulation device, with a different encapsulation format. See the
manpage for details. pseudo-device
# IPv[46] over IPv[46] tunnel (RFC 1933)
Using the GIF interface allows to tunnel e.g. IPv6 over IPv4, which can be used to get IPv6 connectivity if no IPv6-capable uplink (ISP) is available. Other mixes of operations are possible, too. See the
manpage for some examples. #pseudo-device
# IPv[46] tcp relay translation i/f
The faith interface captures IPv6 TCP traffic, for implementing userland IPv6-to-IPv4 TCP relays e.g. for protocol transitions. See the
manpage for more details on this device. #pseudo-device
# 6to4 IPv6 over IPv4 encapsulation
This add a network device that can be used to tunnel IPv6 over IPv4 without setting up a configured tunnel before. The source address of outgoing packets contains the IPv4 address, which allows routing replies back via IPv4. See the
manpage and
for more details. pseudo-device
# IEEE 802.1q encapsulation
This interface provides support for IEEE 802.1Q Virtual LANs, which allows tagging Ethernet frames with a “vlan” ID. Using properly configured switches (that also have to support VLAN, of course), this can be used to build virtual LANs where one set of machines doesn't see traffic from the other (broadcast and other). The
manpage tells more about this.
18.2.2.&Overview of the network configuration files
The following is a list of the files used to configure the network. The usage of these files, some of which have already been met the first chapters, will be described in the following sections.
/etc/hosts
Local hosts database file. Each line contains information regarding a known host and contains the internet address, the host's name and the aliases. Small networks can be configured using only the hosts file, without a name server.
/etc/resolv.conf
This file specifies how the routines which provide access to the Internet Domain Name System should operate. Generally it contains the addresses of the name servers.
/etc/ifconfig.xxx
This file is used for the automatic configuration of the network card at boot.
/etc/mygate
Contains the IP address of the gateway.
/etc/nsswitch.conf
Name service switch configuration file. It controls how a process looks up various databases containing information regarding hosts, users, groups, etc. Specifically, this file defines the order to look up the databases. For example, the line: hosts:
specifies that the hosts database comes from two sources, files (the local /etc/hosts file) and DNS, (the Internet Domain Name System) and that the local files are searched before the DNS.
It is usually not necessary to modify this file.
18.2.3.&Connecting to the Internet with a modem
There are many types of Internet connections: this section explains how to connect to a provider using a modem over a telephone line using the PPP protocol, a very common setup. In order to have a working connection, the following steps must be done:
Get the necessary information from the provider.
Edit the file /etc/resolv.conf and check /etc/nsswitch.conf.
Create the directories /etc/ppp and /etc/ppp/peers if they don't exist.
Create the connection script, the chat file and the pppd options file.
Created the user-password authentication file.
Judging from the previous list it looks like a complicated procedure that requires a lot of work. Actually, the single steps are very easy: it's just a matter of modifying, creating or simply checking some small text files. In the following example it will be assumed that the modem is connected to the second serial port /dev/tty01 (COM2 in DOS).
A few words on the difference between com, COM and tty. For NetBSD, “com” is the name of the serial port driver (the one that is displayed by dmesg) and “tty” is the name of the port. Since numbering starts at 0, com0 is the driver for the first serial port, named tty00. In the DOS world, instead, COM1 refers to the first serial port (usually located at (0x3f8), COM2 to the second, and so on. Therefore COM1 (DOS) corresponds to /dev/tty00 (NetBSD).
Besides external modems connected to COM ports (using /dev/tty0[012] on i386, /dev/tty[ab] on sparc, ...) modems on USB (/dev/ttyU*) and pcmcia/cardbus (/dev/tty0[012]) can be used.
18.2.3.1.&Getting the connection information
The first thing to do is ask the provider the necessary information for the connection, which means:
The phone number of the nearest POP.
The authentication method to be used.
The username and password for the connection.
The IP addresses of the name servers.
18.2.3.2.&resolv.conf and nsswitch.conf
The /etc/resolv.conf file must be configured using the information supplied by the provider, especially the addresses of the DNS. In this example the two DNS will be "194.109.123.2" and "191.200.4.52".
Example&18.1.&resolv.confnameserver 194.109.123.2
nameserver 191.200.4.52
And now an example of the /etc/nsswitch.conf file.
Example&18.2.&nsswitch.conf# /etc/nsswitch.conf
group_compat:
files [notfound=return] nis
passwd_compat: nis
The defaults of doing hostname lookups via /etc/hosts followed by the DNS works fine and there's usually no need to modify this.
18.2.3.3.&Creating the directories for pppd
The directories /etc/ppp and /etc/ppp/peers will contain the configuration files for the PPP connection. After a fresh install of NetBSD they don't exist and must be created (chmod 700). # mkdir /etc/ppp
# mkdir /etc/ppp/peers
18.2.3.4.&Connection script and chat file
The connection script will be used as a parameter on the pppd it is located in /etc/ppp/peers and has usually the name of the provider. For example, if the provider's name is BigNet and your user name for the connection to the provider is alan, an example connection script could be:
Example&18.3.&Connection script# /etc/ppp/peers/bignet
connect '/usr/sbin/chat -v -f /etc/ppp/peers/bignet.chat'
remotename bignet.it
In the previous example, the script specifies a chat file to be used for the connection. The options in the script are detailed in the
If you are experiencing connection problems, add the following two lines to the connection script debug
You will get a log of the operations performed when the system tries to connect. See , .
The connection script calls the chat application to deal with the physical connection (modem initialization, dialing, ...) The parameters to chat can be specified inline in the connection script, but it is better to put them in a separate file. If, for example, the telephone number of the POP to call is 02 , an example chat script could be:
Example&18.4.&Chat file# /etc/ppp/peers/bignet.chat
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
CONNECT ''
If you have problems with the chat file, you can try connecting manually to the POP with the
program and verify the exact strings that you are receiving.
18.2.3.5.&Authentication
During authentication each of the two systems verifies the identity of the other system, although in practice you are not supposed to authenticate the provider, but only to be verified by him, using one of the following methods:
Most providers use a PAP/CHAP authentication.
18.2.3.5.1.&PAP/CHAP authentication
The authentication information (speak: password) is stored in the /etc/ppp/pap-secrets for PAP and in /etc/ppp/chap-secrets for CHAP. The lines have the following format: user * password
For example: alan * pZY9o
For security reasons the pap-secrets and chap-secrets files should be owned by root and have permissions “600”. # chown root /etc/ppp/pap-secrets
# chown root /etc/ppp/chap-secrets
# chmod 600 /etc/ppp/pap-secrets
# chmod 600 /etc/ppp/chap-secrets
18.2.3.5.2.&Login authentication
This type of authentication is n if the provider uses login authentication, user name and password must be supplied in the chat file instead of the PAP/CHAP files, because the chat file simulates an interactive login. In this case, set up appropriate permissions for the chat file.
The following is an example chat file with login authentication:
Example&18.5.&Chat file with login# /etc/ppp/peers/bignet.chat
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
CONNECT ''
TIMEOUT 50
ogin: alan
ssword: pZY9o
18.2.3.6.&pppd options
The only thing left to do is the creation of the pppd options file, which is /etc/ppp/options (chmod 644).
Example&18.6.&/etc/ppp/options/dev/tty01
defaultroute
noipdefault
man page for the meaning of the options.
18.2.3.7.&Testing the modem
Before activating the link it is a good idea to make a quick modem test, in order to verify that the physical connection and the communication with the modem works. For the test the
program can be used, as in the following example.
Create the file /etc/uucp/port with the following lines: type modem
port modem
device /dev/tty01
speed 115200
(substitute the correct device in place of /dev/tty01).
Write the command cu -p modem to start sending commands to the modem. For example: # cu -p modem
Connected.
Disconnected.
In the previous example the reset command (ATZ) was sent to the modem, which replied with OK: the communication works. To exit , write ~ (tilde) followed by . (dot), as in the example.
If the modem doesn't work, check that it is connected to the correct port (i.e. you are using the right port with . Cables are a frequent cause of trouble, too.
When you start
and a message saying “Permission denied” appears, check who is the owner of the /dev/tty## device, it must be "uucp". For example: $ ls -l /dev/tty00
crw-------
8, 0 Mar 22 20:39 /dev/tty00
If the owner is root, the following happens: $ ls -l /dev/tty00
crw-------
8, 0 Mar 22 20:39 /dev/tty00
$ cu -p modem
cu: open (/dev/tty00): Permission denied
cu: All matching ports in use
18.2.3.8.&Activating the link
At last everything is ready to connect to the provider with the following command: # pppd call bignet
where bignet is the name of the already described connection script. To see the connection messages of pppd, give the following command: # tail -f /var/log/messages
To disconnect, do a kill -HUP of pppd.
# pkill -HUP pppd
18.2.3.9.&Using a script for connection and disconnection
When the connection works correctly, it's time to write a couple of scripts to avoid repeating the commands every time. These two scripts can be named, for example, ppp-start and ppp-stop.
ppp-start is used to connect to the provider:
Example&18.7.&ppp-start#!/bin/sh
MODEM=tty01
POP=bignet
if [ -f /var/spool/lock/LCK..$MODEM ]; then
echo ppp is already running...
pppd call $POP
tail -f /var/log/messages
ppp-stop is used to close the connection:
Example&18.8.&ppp-stop#!/bin/sh
MODEM=tty01
if [ -f /var/spool/lock/LCK..$MODEM ]; then
echo -f killing pppd...
kill -HUP `cat /var/spool/lock/LCK..$MODEM`
echo ppp is not active
The two scripts take advantage of the fact that when pppd is active, it creates the file LCK..tty01 in the /var/spool/lock directory. This file contains the process ID (pid) of the pppd process.
The two scripts must be executable: # chmod u+x ppp-start ppp-stop
18.2.3.10.&Running commands after dialin
If you find yourself to always run the same set of commands each time you dial in, you can put them in a script /etc/ppp/ip-up which will be called by
after successful dial-in. Likewise, before the connection is closed down, /etc/ppp/ip-down is executed. Both scripts are expected to be executable. See
for more details.
18.2.4.&Creating a small home network
Networking is one of the main strengths of Unix and NetBSD is no exception: networking is both powerful and easy to set up and inexpensive too, because there is no need to buy additional software to communicate or to build a server. Section&18.3.1, “Setting up an Internet gateway with IPNAT” explains how to configure a NetBSD machine to act as a gateway for a network: with IPNAT all the hosts of the network can reach the Internet with a single connection to a provider made by the gateway machine. The only thing to be checked before creating the network is to buy network cards supported by NetBSD (check the INSTALL.* files for a list of supported devices).
First, the network cards must be installed and connected to a hub, switch or directly (see Figure&18.7, “Network with gateway”).
Next, check that the network cards are recognized by the kernel, studying the output of the dmesg command. In the following example the kernel recognized correctly an NE2000 clone: ...
ne0 at isa0 port 0x280-0x29f irq 9
ne0: NE2000 Ethernet
ne0: Ethernet address 00:c2:dd:c1:d1:21
If the card is not recognized by the kernel, check that it is enabled in the kernel configuration file and then that the card's IRQ matches the one that the kernel expects. For example, this is the isa NE2000 line in th the kernel expects the card to be at IRQ 9. ...
ne0 at isa? port 0x280 irq 9 # NE[12]000 ethernet cards
If the card's configuration is different, it will probably not be found at boot. In this case, either change the line in the kernel configuration file and compile a new kernel or change the card's setup (usually through a setup disk or, for old cards, a jumper on the card).
The following command shows the network card's current configuration: # ifconfig ne0
ne0: flags=8822 mtu 1500
address: 00:50:ba:aa:a7:7f
media: Ethernet autoselect (10baseT)
inet6 fe80::250:baff:feaa:a77f%ne0 prefixlen 64 scopeid 0x1
The software configuration of the network card is very easy. The IP address “192.168.1.1” is assigned to the card. # ifconfig ne0 inet 192.168.1.1 netmask 0xffffff00
Note that the networks 10.0.0.0/8 and 192.168.0.0/16 are reserved for private networks, which is what we're setting up here.
Repeating the previous command now gives a different result: # ifconfig ne0
ne0: flags=8863 mtu 1500
address: 00:50:ba:aa:a7:7f
media: Ethernet autoselect (10baseT)
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::250:baff:feaa:a77f%ne0 prefixlen 64 scopeid 0x1
The output of ifconfig has now changed: the IP address is now printed and there are two new flags, “UP” and “RUNNING” If the interface isn't “UP”, it will not be used by the system to send packets.
The host was given the IP address 192.168.1.1, which belongs to the set of addresses reserved for internal networks which are not reachable from the Internet. The configuration is finished an if there is another active host on the network, a ping can be tried. For example, if 192.168.1.2 is the address of the active host: # ping 192.168.1.2
PING ape (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=1.286 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=0.649 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=0.681 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=255 time=0.656 ms
----ape PING Statistics----
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.649/0.818/1.286/0.312 ms
With the current setup, at the next boot it will be necessary to repeat the configuration of the network card. In order to avoid repeating the card's configuration at each boot, add the following lines to /etc/rc.conf: auto_ifconfig=yes
ifconfig_ne0="inet 192.168.1.1 netmask 0xffffff00"
In this example the variable ifconfig_ne0 was set because the network card was recognized as ne0 if you are using a different adapter, substitute the appropriate name in place of ne0.
At the next boot the network card will be configured automatically.
If you have a router that is connected to the internet, you can use it as default router, which will handle all your packets. To do so, set defaultroute to the router's IP address in /etc/rc.conf: defaultroute=192.168.0.254
Be sure to use the default router's IP address instead of name, in case your DNS server is beyond the default router. In that case, the DNS server couldn't be reached to resolve the default router's hostname and vice versa, creating a chicken-and-egg problem.
To reach hosts on your local network, and assuming you really have very few hosts, adjust /etc/hosts to contain the addresses of all the hosts belonging to the internal network. For example:
Example&18.9.&/etc/hosts#
# Host Database
# This file should contain the addresses and aliases
# for local hosts that share this file.
# It is used only for "ifconfig" and other operations
# before the nameserver is started.
# RFC 1918 specifies that these networks are "internal".
# 10.0.0.0
10.255.255.255
# 172.16.0.0
172.31.255.255
# 192.168.0.0 192.168.255.255
192.168.1.1
ape.insetti.net ape
192.168.1.2
vespa.insetti.net vespa
192.168.1.0
insetti.net
If you are dialed in via an Internet Service Provider, or if you have a local Domain Name Server (DNS) running, you may want to use it to resolve hostnames to IP addresses, possibly in addition to /etc/hosts, which would only know your own hosts. To configure a machine as DNS client, you need to edit /etc/resolv.conf, and enter the DNS server's address, in addition to an optional domain name that will be appended to hosts with no domain, in order to create a FQDN for resolving. Assuming your DNS server's IP address is 192.168.1.2 and it is setup to serve for "home.net", put the following into /etc/resolv.conf: # /etc/resolv.conf
domain home.net
nameserver 192.168.1.2
The /etc/nsswitch.conf file should be checked as explained in Example&18.2, “nsswitch.conf”.
Summing up, to configure the network the following must be done: the network adapters must be installed and physically connected. Next they must be configured (with ifconfig) and, finally, the file /etc/rc.conf must be modified to configure the interface and possibly default router, and /etc/resolv.conf and /etc/nsswitch.confshould be adjusted if DNS should be used. This type of network management is sufficient for small networks without sophisticated needs.
18.2.5.&A common LAN setup
The small home network discussed in the previous section contained many items that were configured manually. In bigger LANs that are centrally managed, one can expect Internet connectivity being available via some router, a DNS server being available, and most important, a DHCP server which hands out IP addresses to clients on request. To make a NetBSD client run in such an environment, it's usually enough to set dhclient=yes
in /etc/rc.conf, and the IP address will be set automatically, /etc/resolv.conf will be created and routing setup to the default router.
18.2.6.&Connecting two PCs through a serial line
If you need to transfer files between two PCs which are not networked there is a simple solution which is particularly handy when copying the files to a floppy is not practical: the two machines can be networked with a serial cable (a null modem cable). The following sections describe some configurations.
18.2.6.1.&Connecting NetBSD with BSD or Linux
The easiest case is when both machines run NetBSD: making a connection with the SLIP protocol is very easy. On the first machine write the following commands: # slattach /dev/tty00
# ifconfig sl0 inet 192.168.1.1 192.168.1.2
On the second machine write the following commands: # slattach /dev/tty00
# ifconfig sl0 inet 192.168.1.2 192.168.1.1
Now you can test the connection with ping; for example, on the second PC write: # ping 192.168.1.1
If everything worked there is now an active network connection between the two machines and ftp, telnet and other similar commands can be executed. The textual aliases of the machines can be written in the /etc/hosts file.
In the previous example both PC's used the first serial port (/dev/tty0). Substitute the appropriate device if you are using another port.
IP addresses like 192.168.x.x are reserved for “internal” networks. The first PC has address 192.168.1.1 and the second 192.168.1.2.
To achieve a faster connection the -s speed option to slattach can be specified.
ftp can be used to transfer files only if inetd is active and the ftpd server is enabled.
if one of the two PC's runs Linux, the commands are slightly different (on the Linux machine only). If the Linux machine gets the 192.168.1.2 address, the following commands are needed: # slattach -p slip -s 115200 /dev/ttyS0 &
# ifconfig sl0 192.168.1.2 pointopoint 192.168.1.1 up
# route add 192.168.1.1 dev sl0
Don't forget the “&” in the first command.
18.2.6.2.&Connecting NetBSD and Windows NT
NetBSD and Windows NT can be (almost) easily networked with a serial null modem cable. Basically what needs to be done is to create a “Remote Access” connection under Windows NT and to start pppd on NetBSD.
Start pppd as root after having created a .ppprc in /root. Use the following example as a template. connect '/usr/sbin/chat -v CLIENT CLIENTSERVER'
nodefaultroute
:192.168.1.2
The meaning of the first line will be explained l 192.168.1.2 is the IP address that will be assigned by NetBSD to the Windows NT tty00 is the serial port used for the connection (first serial port).
On the NT side a null modem device must be installed from the Control Panel (Modem icon) and a Remote Access connection using this modem must be created. The null modem driver is standard under Windows NT 4 but it's not a 100% null modem: when the link is activated, NT sends the string CLIENT and expects to receive the answer CLIENTSERVER. This is the meaning of the first line of the .ppprc file: chat must answer to NT when the connection is activated or the connection will fail.
In the configuration of the Remote Access connection the following must be specified: use the null modem, telephone number “1” (it's not used, anyway), PPP server, enable only TCP/IP protocol, use IP address and namservers from the server (NetBSD in this case). Select the hardware control flow and set the port to N1.
Now everything is ready to activate the connection.
Connect the serial ports of the two machines with the null modem cable.
Launch pppd on NetBSD. To see the messages of pppd: tail -f /var/log/messages).
Activate the Remote Access connection on Windows NT.
18.2.6.3.&Connecting NetBSD and Windows 95
The setup for Windows 95 is similar to the one for Windows NT: Remote Access on Windows 95 and the PPP server on NetBSD will be used. Most (if not all) Windows 95 releases don't have the null modem driver, which makes things a little more complicated. The easiest solution is to find one of the available null modem drivers on the Internet (it's a small .INF file) and repeat the same steps as for Windows NT. The only difference is that the first line of the .ppprc file (the one that calls chat) can be removed.
If you can't find a real null modem driver for Windows 95 it's still possible to use a little trick:
Create a Remote Access connection like the one described in Section&18.2.6.2, “Connecting NetBSD and Windows NT” but using the “Standard Modem”.
In .ppprc substitute the line that calls chat with the following line connect '/usr/sbin/chat -v ATH OK AT OK ATE0V1 OK AT OK ATDT CONNECT'
Activate the connection as described in Section&18.2.6.2, “Connecting NetBSD and Windows NT”.
In this way the chat program, called when the connection is activated, emulates what Windows 95 thinks is a standard modem, returning to Windows 95 the same answers that a standard modem would return. Whenever Windows 95 sends a modem command string, chat returns OK.
& 本页地址：/book/05.html
阅读(632) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。