10.1.1. A walk throught the kernel configuration

This section (A walk throught the kernel configuration) has been contributed by Hubert Feyrer <hubert@feyrer.de>.

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 Chapter 7 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 options(4) manpage, and there is usually a manpage for each driver too, e.g. tlp(4).

      #       $NetBSD: GENERIC,v 1.354.2.15 2001/05/06 15:18:54 he Exp $      

The first line of each config file shows the version, which is 1.354.2.15 here. It can be used to compare against other versions via CVS, or when reporting bugs.

options         NTP             # 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 ntpd(8) for more information.

file-system     NFS             # Network File System client      

If you want to use another machine's harddisk via the Network File System (NFS), this option is needed. Section 10.2.2 gives more information on NFS.

options         NFSSERVER       # 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 harddisk. Section 10.2.2 contains more information on NFS.

#options        GATEWAY         # 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 options(4) for details.

options         INET            # 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 inet(4) for more details.

options         INET6           # IPV6      

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 inet6(4) manpage and Section 9.1.7 for more information on the next generation Internet protocol.

#options        IPSEC           # 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 ipsec(4) for more information.

#options        IPSEC_ESP       # IP security (encryption part; define w/IPSEC)      

This option is needed in addition to IPSEC if encryption is wanted in IPsec.

#options        MROUTING        # 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 mrouted(8) daemon.

options         NS              # XNS
#options        NSIP            # 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 ns(4) manpage has some details.

options         ISO,TPIP        # OSI
#options        EON             # 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 iso(4) manpage for more information.

options         CCITT,LLC,HDLC  # X.25      

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         NETATALK        # 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 stackk are available in the atalk(4) manpage.

options         PPP_BSDCOMP     # BSD-Compress compression support for PPP
options         PPP_DEFLATE     # Deflate compression support for PPP
options         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      # pfil(9) packet filter hooks
options         IPFILTER_LOG    # ipmon(8) log support      

These options enable firewalling in NetBSD, using IPfilter. See the ipf(4) and ipf(8) manpages for more information on operation of IPfilter, and Section 10.2.1.1 for a configuration example.

# Compatibility with 4.2BSD implementation of TCP/IP.  Not recommended.
#options        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 diskless(8) manpage for more information.

# Kernel root file system and dump configuration.
config          netbsd  root on ? type ?
#config         netbsd  root on sd0a type ffs
#config         netbsd  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
com0    at isa? port 0x3f8 irq 4        # Standard PC serial ports
com1    at isa? port 0x2f8 irq 3
com2    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. tlp(4), ne(4), 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 mii(4) manpage for more information.

# USB Ethernet adapters
aue*    at uhub? port ?         # ADMtek AN986 Pegasus based adapters
cue*    at uhub? port ?         # CATC USB-EL1201A based adapters
kue*    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   bpfilter        8       # 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 bpf(4) for more information.

pseudo-device   ipfilter                # IP filter (firewall) and NAT      

This one enables the IPfilter's packet filtering kernel interface used for firewalling, NAT (IP Masquerading) etc. See ipf(4) and Section 10.2.1.1 for more information.

pseudo-device   loop                    # 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 omited. See lo(4) for more details.

pseudo-device   ppp             2       # Point-to-Point Protocol      

If you want to use PPP either over a serial interface or ethernet (PPPoE), you will need this option. See ppp(4) for details on this interface.

pseudo-device   sl              2       # 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 sl(4).

pseudo-device   strip           2       # 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 strip(4) manpage for detailled information.

pseudo-device   tun             2       # 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 tun(4) for details.

pseudo-device   gre             2       # 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 gre(4) for more.

pseudo-device   ipip            2       # IP Encapsulation within IP (RFC 2003)      

Another IP-in-IP encapsulation device, with a different encapsulation format. See the ipip(4) manpage for details.

pseudo-device   gif             4       # 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 gif(4) manpage for some examples.

#pseudo-device  faith           1       # 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 faith(4) manpage for more details on this device.

#pseudo-device  stf             1       # 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 stf(4) manpage and Section 10.2.4 for more details.

pseudo-device   vlan                    # 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 switchens (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 vlan(4) manpage tells more about this.

10.1.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.

10.1.3. Connecting to the Internet

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:

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.)

nameserver 194.109.123.2
  nameserver 191.200.4.52
  #lookup file bind          

# /etc/nsswitch.conf
  group:         compat
  group_compat:  nis
  hosts:         files dns 
  netgroup:      files [notfound=return] nis
  networks:      files
  passwd:        compat
  passwd_compat: nis          

# /etc/ppp/peers/bignet
connect '/usr/sbin/chat -v -f /etc/ppp/peers/bignet.chat'
noauth
user alan
remotename bignet.it          

# /etc/ppp/peers/bignet.chat
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
REPORT CONNECT
SAY "Calling BigNet"
'' ATDT0299999999
CONNECT ''	  

user * password          

alan * pZY9o          

# /etc/ppp/peers/bignet.chat
ABORT BUSY
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
'' ATDT0299999999
CONNECT ''
TIMEOUT 50
ogin: alan
ssword: pZY9o            

/dev/tty01
lock
crtscts
57600
modem
defaultroute
noipdefault          

# pppd call bignet        

# tail -f /var/log/messages        

#!/bin/sh
MODEM=tty01
POP=bignet
if [ -f /var/spool/lock/LCK..$MODEM ]; then
  echo ppp is already running...
else
  pppd call $POP
  tail -f /var/log/messages
fi          

#!/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 done
else
  echo ppp is not active
fi          

# chmod u+x ppp-up ppp-down        

10.1.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 10.2.1 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 file for a list of supported devices.)

First, the network cards must be installed and connected to a hub, switch or directly (see Figure 10-1.)

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 the configuration file; 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<BROADCAST,NOTRAILERS,SIMPLEX,MULTICAST> mtu 1500 media: Ethernet 10base2      

The software configuration of the network card is very easy. The IP address "192.168.1.1" (which is reserved for internal networks) is assigned to the card.

# ifconfig ne0 inet 192.168.1.1 netmask 0xffffff00      

Repeating the previous command now gives a different result:

# ifconfig ne0
ne0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
          media: Ethernet 10base2
          inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255      

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 and must now be tested; 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
  ^C
  ----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, two things need to be done: first, create the file /etc/ifconfig.ne0 containing the following line:

inet 192.168.1.1 netmask 0xffffff00      

Next, in the /etc/rc.conf file, set the following option

auto_ifconfig=YES      

At the next boot the network card will be configured automatically.

The /etc/hosts file is a database of IP addresses and textual aliases: it should contain the addresses of all the hosts belonging to the internal network. For example:

#     $NetBSD: hosts,v 1.4 1997/01/09 05:33:14 mikel Exp $
#
# 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.
#
#
127.0.0.1             localhost
#
# 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        

The /etc/nsswitch.conf should be modified as explained in Example 10-2.

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 /etc/hosts and /etc/nsswitch.conf files must be modified. This type of network management in very simplified and is suited only for small networks without sophisticated needs.

10.1.5. 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.

# slattach /dev/tty00
  # ifconfig sl0 inet 192.168.1.1 192.168.1.2
        

# slattach /dev/tty00
  # ifconfig sl0 inet 192.168.1.2 192.168.1.1
        

# ping 192.168.1.1        

connect '/usr/sbin/chat -v CLIENT CLIENTSERVER'
  local
  tty00  
  115200
  crtscts
  lock   
  noauth
  nodefaultroute
  :192.168.1.2        

10.2.1. IPNAT

The mysterious acronym IPNAT hides the Internet Protocol Network Address Translation, which enables the routing of an internal network on a real network (Internet.) This means that with only one "real" IP, static or dynamic, belonging to a gateway running IPNAT, it is possible to create simultaneous connections to the Internet for all the hosts of the internal network.

Some usage examples of IPNAT can be found in the subdirectory /usr/share/examples/ipf: look at the files BASIC.NAT and nat-setup.

The setup for the example described in this section is detailed in Figure 10-1: host 1 can connect to the Internet calling a provider with a modem and getting a dynamic IP address. host 2 and host 3 can't communicate with the Internet with a normal setup: IPNAT allows them to do it: host 1 will act as a gateway for hosts 2 and 3.

# sysctl net.inet.ip.forwarding
  net.inet.ip.forwarding = 1        

map ppp0 192.168.1.0/24 -> 0/32 proxy port ftp ftp/tcp
map ppp0 192.168.1.0/24 -> 0/32 portmap tcp/udp 40000:60000
map ppp0 192.168.1.0/24 -> 0/32        

#!/bin/sh
# /etc/ppp/ip-up
/etc/rc.d/ipnat forcestart        

#!/bin/sh
# /etc/ppp/ip-down
/etc/rc.d/ipnat forcestop        

# chmod u+x ip-up ip-down        

# route add default 192.168.1.1        

10.2.2. NFS

Now that the network is working it is possible to share files and directories over the network using NFS. From the point of view of file sharing, the computer which gives access to its files and directories is called the server, and the computer using these files and directories is the client. A computer can be client and server at the same time.

• A kernel must be compiled with the appropriate options for the client and the server (the options are easy to find in the kernel configuration file. See Section 10.1.1 for more information on NFS related kernel options.

• The server must enable its RPC services in /etc/inetd.conf.

• In /etc/rc.conf the server must enable the inetd and portmap daemons and the nfs_server option.

• In /etc/rc.conf the client must enable inetd and nfs_client.

• The server must list the exported directories in /etc/exports and then run the command kill -HUP `cat /var/run/mountd.pid.

A client host can access a remote directory through NFS if:

• The server host exports the directory.

• The client host mounts the remote directory with the command mount server:/xx/yy /mnt

The mount command has a rich set of options for remote directories which are not very intuitive (to say the least.)

/dev/ra0a on /
  /dev/ra0f on /usr
  /dev/ra1a on /usr/src
  /dev/ra2a on /export        

buzz:/export/cli?/root on /
  buzz:/export/common/usr on /usr
  buzz:/usr/src on /usr/src        

# /etc/exports
  /usr/src -network 123.45.67.0 -mask 255.255.255.0
  /export  -alldirs -maproot=root -network 123.45.67.0 -mask 255.255.255.0        

buzz:/export/cli?/root / nfs rw
  buzz:/export/common/usr /usr nfs rw,nodev,nosuid
  buzz:/usr/src /usr/src rw,nodev,nosuid        

10.2.3. Setting up /net with amd

% showmount -e wuarchive.wustl.edu
  Exports list on wuarchive.wustl.edu:
  /export/home                       onc.wustl.edu 
  /export/local                      onc.wustl.edu 
  /export/adm/log                    onc.wustl.edu 
  /usr                               onc.wustl.edu 
  /                                  onc.wustl.edu 
  /archive                           Everyone        

% cd /net/wuarchive.wustl.edu/archive/systems/unix/NetBSD        

10.2.4. IPv6 Connectivity & Transition via 6to4

This section will concentrate on how to get network connectivity for IPv6 and - as that's still not easy to get native today - talk in length about the alternatives to native IPv6 connectivity as a transitional method until native IPv6 peers are available.

Finding an ISP that offers IPv6 natively needs quite some luck. What you need next is a router that will be able to handle the traffic. To date, not all router manufacturers offer IPv6 support for their machines, and even if they do, it's unlikely that they offer hardware accelerated IPv6 routing or switching. A rather cheap alternative to the router hardware commonly in use today is using a standard PC and configure it as a router, e.g. by using some Linux or BSD derived operating system like NetBSD, and use software like Zebra for handling the routing protocols. This solution is rather common today for sites that want IPv6 connectivity today. The drawbacks are that you need an ISP that supports IPv6, and that you need dedicated uplink only for IPv6.

If this is not an option for you, you can still get IPv6 connectivity by using tunnels. Instead of talking IPv6 on the wire, the IPv6 packets are encapsulated in IPv4 packets, as shown in Figure 10-2. Using existing IPv4 infrastructure, the encapsulated packets are sent to a IPv6-capable uplink that will then remove the encapsulation, and forward the IPv6 packets via native IPv6.

When using tunnels, there are two possibilities. One is to use a so-called "configured" tunnel, the other is called an "automatic" tunnel. A "configured" tunnel is one that required preparation from both ends of the tunnel, usually connected with some kind of registration to exchange setup information. An example for such a configured tunnel is the IPv6-over-IPv4 encapsulation described in [RFC1933], and that's implemented e.g. by the gif(4) device found in NetBSD.

An "automatic" tunnel consists of a public server that has some kind of IPv6 connectivity, e.g. via 6Bone. That server has made it's connectivity data public, and also runs a tunneling protocol that does not require an explicit registration of the sites using it as uplink. A well-used example of such a protocol is the 6to4 mechanism described in [RFC3056], and that is implemented in the stf(4) device found in NetBSD's. Another mechanism that does not require registration of IPv6-information is the 6over4 mechanism, which implements transporting of IPv6 over a multicast-enabled IPv4 network, instead of e.g. ethernet or FDDI. 6over4 is documented in [RFC2529]. It's main drawback is that you do need existing multicast infrastructure. If you don't have that, setting it up is about as much effort as setting up a configured IPv6 tunnel directly, so it's usually not worth bothering in that case.

options INET6                 # IPv6  pseudo-device stf             # 6to4 IPv6 over IPv4 encapsulation

# ifconfig stf0 inet6 2002:3ee0:3972:1::1 prefixlen 16 alias  (local) 

# route add -inet6 default 2002:cdb2:5ac2::1 (remote)

# /sbin/ping6 www.kame.net

ifconfig ne0 inet6 alias 2002:3ee0:3972:2:1234:56ff:fe78:9abc	

# sysctl -w net.inet6.ip6.forwarding=1 

# rtadvd