ref: 57be7fd6448bcbf4b593ede501d404e0d33e5f27
dir: /fqa6.ms/
.\" This troff source is processed to create all forms of the
.\" 9FRONT DASH 1 book and the http://fqa.9front.org website.
.\" NOTE: Purely experimental. Methods employed may change.
.\" troff -ms -mpictures fqa6.ms | page
.\" htmlroff -u -ms -mhtml fqa6.ms >fqa6.html
.de FG \" .FG <basename>
.ie h .html - <img src="\\$1.\\$2" />
.el .BP \\$1.ps
.br
..
.po 1i \" page offset (from left)
.fp 1 R LucidaSans
.fp 2 I LucidaSansI
.fp 3 B LucidaSansB
.fp 4 BI LucidaSansI
.fp 5 CW LucidaCW
.paragraph 0
.margin 0
.HTML "FQA 6 - Networking
.html - <style type="text/css">body{font-size:10pt}; a{font-size:10pt}</style>
.html - <a href="fqa.html">FQA INDEX</a> |
.html - <a href="fqa5.html">FQA 5 - Building The System From Source</a> |
.html - <a href="fqa7.html">FQA 7 - System Management</a>
.html - <hr />
.SH
.LG
.ihtml h1 <h1>
FQA 6 - Networking
.ihtml h1
.NL
.R
.html - <a href="fqa6.html">html</a> |
.html - <a href="fqa6.pdf">pdf</a> |
.html - <a href="fqa6.ms">troff</a>
.FG networking jpg
.html - <a name="6.1" />
.ihtml h2 <h2>
.SH
6.1 - Before we go any further
.R
.ihtml h2
Plan 9's approach to networking is unusual: most operations comprise reading and writing ("composing") byte streams ("files"). For the bulk of this document, it helps if you have read and at least partially understood
.ihtml a <a href="fqa0.html#0.1">
.I
FQA 0.1 - What is Plan 9?
.R
.ihtml a
Next, read:
.ihtml a <a href="http://doc.cat-v.org/plan_9/4th_edition/papers/net/">
.I
The Organization of Networks in Plan 9
.R
.ihtml a
If you are working with applications such as web servers, FTP servers, and mail servers, you may benefit greatly by
.ihtml a <a href="http://www.rfc-editor.org/rfc.html">
reading the RFCs.
.ihtml a
.B Note:
A script for downloading all the RFCs is located in
.ihtml a <a href="http://git.9front.org/plan9front/plan9front/HEAD/lib/rfc/grabrfc/f.html">
.CW /lib/rfc/grabrfc .
.ihtml a
It copies the files into
.CW /lib/rfc/ ,
and it may take hours for the script to run to completion.
.html - <a name="6.2" />
.ihtml h2 <h2>
.SH
6.2 - Network configuration
.R
.ihtml h2
Basic networking is initially configured by the installation process. However, more complex settings or services may be desired. In Plan 9, network configuration is organized in
.CW ndb ,
the network database.
From
.ihtml a <a href="http://man.9front.org/6/ndb">
.CW ndb(6):
.ihtml a
.ihtml ul <ul>
.QS
The network database consists of files describing machines
known to the local installation and machines known publicly.
The files comprise multi-line tuples made up of
attribute/value pairs of the form attr=value or sometimes
just attr. Each line starting without white space starts a
new tuple. Lines starting with # are comments.
The file /lib/ndb/local is the root of the database. Other
files are included in the database if a tuple with an
attribute-value pair of attribute database and no value
exists in /lib/ndb/local. Within the database tuple, each
pair with attribute file identifies a file to be included in
the database. The files are searched in the order they
appear. For example:
database=
file=/lib/ndb/common
file=/lib/ndb/local
file=/lib/ndb/global
declares the database to be composed of the three files
/lib/ndb/common, /lib/ndb/local, and /lib/ndb/global. By
default, /lib/ndb/local is searched before the others. How-
ever, /lib/ndb/local may be included in the database to
redefine its ordering.
Within tuples, pairs on the same line bind tighter than
pairs on different lines.
.QE
.ihtml ul
As mentioned, the installer adds basic information about the machine to the file
.CW /lib/ndb/local ,
based on the questions asked during the installation. This file may be edited to modify or expand the definition of the local network.
.html - <a name="6.2.1" />
.ihtml h3 <h3>
.SH
6.2.1 - Host name
.R
.ihtml h3
Each machine on the network receives a corresponding section in
.CW ndb .
The host name (hereafter referred to as
.CW sysname )
is assigned by setting the
.CW sys=
tuple:
.P1
sys=x301
.P2
The resulting
.CW sysname
is used by the
.CW /rc/bin/termrc
and
.CW /rc/bin/cpurc
startup scripts, which in turn call upon any additional configuration that may exist in
.CW /cfg/$sysname/ .
(Look at the scripts to see how they deal with
.CW /cfg .)
.html - <a name="6.2.2" />
.ihtml h3 <h3>
.SH
6.2.2 - Identifying and setting up your network interfaces
.R
.ihtml h3
Network interfaces are recognized by their MAC addresses, which are identified to
.CW ndb
using the
.CW ether=
tuple:
.P1
sys=x301 ether=00226811f7dd
.P2
Additional tuples in the same grouping will be used to configure the interface in question.
.html - <a name="6.2.2.1" />
.ihtml h4 <h4>
.SH
6.2.2.1 - WiFi
.R
.ihtml h4
The following sections provide information pertaining to specific chipsets.
Read:
.ihtml a <a href="http://man.9front.org/8/plan9.ini">
.CW plan9.ini(8) ,
.ihtml a
.ihtml a <a href="fqa3.html#3.2">
.I
FQA Section 3.2 - Known Working Hardware
.R
.ihtml a
.html - <a name="6.2.2.1.1" />
.ihtml h5 <h5>
.SH
6.2.2.1.1 - Interfaces
.R
.ihtml h5
.html - <a name="6.2.2.1.1.1" />
.ihtml h5 <h5>
.SH
6.2.2.1.1.1 - wavelan
.R
.ihtml h5
Lucent Wavelan (Orinoco) IEEE 802.11b and compatible PCMCIA cards. Compatible cards include the Dell TrueMobile 1150 and the Linksys Instant Wireless Network PC Card. Port and IRQ defaults are 0x180 and 3 respectively.
These cards take a number of unique options to aid in identifying the card correctly on the 802.11b network. The network may be ad hoc or managed (i.e. use an access point):
.CW
mode=[adhoc, managed]
.R
and defaults to managed. The 802.11b network to attach to (managed mode) or identify as (ad hoc mode), is specified by
.CW essid=string
and defaults to a null string. The card station name is given by
.CW station=string
and defaults to Plan 9 STA. The channel to use is given by
.CW channel=number
where number lies in the range 1 to 16 inclusive; the channel is normally negotiated automatically.
If the card is capable of encryption, the following options may be used:
.CW
crypt=[off, on]
.R
and defaults to on.
.CW keyN=string
sets the encryption key N (where N is in the range 1 to 4 inclusive) to string; this will also set the transmit key to N (see below). There are two formats for string which depend on the length of the string. If it is exactly 5 or 13 characters long it is assumed to be an alphanumeric key; if it is exactly 10 or 26 characters long the key is assumed to be in hex format (without a leading 0x). The lengths are checked, as is the format of a hex key.
.CW txkey=number
sets the transmit key to use to be number in the range 1 to 4 inclusive. If it is desired to exclude or include unencrypted packets
.CW
clear=[off, on]
.R
configures reception and defaults to inclusion.
The defaults are intended to match the common case of a managed network with encryption and a typical entry would only require, for example
.CW
essid=left-armpit key1=afish key2=calledraawaru
.R
if the port and IRQ defaults are used. These options may be set after boot by writing to the device's ctl file using a space as the separator between option and value, e.g.
.CW
echo 'key2 1d8f65c9a52d83c8e4b43f94af' >/net/ether0/0/ctl
.R
Card-specific power management may be enabled/disabled by
.CW
pm=[on, off]
.R
.html - <a name="6.2.2.1.1.2" />
.ihtml h5 <h5>
.SH
6.2.2.1.1.2 - wavelanpci
.R
.ihtml h5
PCI Ethernet adapters that use the same Wavelan programming interface. Currently the only tested cards are those based on the Intersil Prism 2.5 chipset.
.html - <a name="6.2.2.1.1.3" />
.ihtml h5 <h5>
.SH
6.2.2.1.1.3 - iwl
.R
.ihtml h5
Intel Wireless WiFi Link mini PCI-Express adapters require firmware from
.ihtml a <a href="http://firmware.openbsd.org/firmware/">
http://firmware.openbsd.org/firmware/iwn-firmware*.tgz
.ihtml a
to be present on attach in
.CW /lib/firmware
or
.CW /boot .
To select the access point, the
.CW essid=
and
.CW bssid=
parameters can be specified at boot or set during runtime like:
.P1
echo essid left-armpit >/net/ether1/clone
.P2
If both
.CW essid=
and
.CW bssid=
.R
are specified, both must match. Scan results appear in the
.CW ifstats
file and can be read out like:
.P1
cat /net/ether1/ifstats
.P2
Ad-hoc mode or WEP encryption is currently not supported. To enable WPA/WPA2 encryption, see
.ihtml a <a href="http://man.9front.org/8/wpa">
.CW wpa(8)
.ihtml a
for details.
.html - <a name="6.2.2.1.1.4" />
.ihtml h5 <h5>
.SH
6.2.2.1.1.4 - rt2860
.R
.ihtml h5
Ralink Technology PCI/PCI-Express wireless adapters require firmware from
.ihtml a <a href="http://firmware.openbsd.org/firmware/">
http://firmware.openbsd.org/firmware/ral-firmware*.tgz
.ihtml a
to be present on attach in
.CW /lib/firmware
or
.CW /boot .
See the
.ihtml a <a href="fqa6.html#6.2.2.1.3">
iwl
.ihtml a
section above for configuration details.
.html - <a name="6.2.2.1.1.5" />
.ihtml h5 <h5>
.SH
6.2.2.1.1.5 - wpi
.R
.ihtml h5
Intel PRO Wireless 3945abg PCI/PCI-Express wireless adapters require firmware from
.ihtml a <a href="http://firmware.openbsd.org/firmware/">
http://firmware.openbsd.org/firmware/*/wpi-firmware*.tgz
.ihtml a
to be present on attach in
.CW /lib/firmware
or
.CW /boot .
See the
.ihtml a <a href="fqa6.html#6.2.2.1.1.3">
iwl
.ihtml a
section above for configuration details.
.html - <a name="6.2.2.1.2" />
.ihtml h5 <h5>
.SH
6.2.2.1.2 - WPA
.R
.ihtml h5
WPA1/TKIP and WPA2/CCMP are supported with the use of the
.ihtml a <a href="http://man.9front.org/8/wpa">
.CW wpa(8)
.ihtml a
command.
Read:
.ihtml a <a href="http://man.9front.org/8/wpa">
.CW wpa(8)
.ihtml a
.html - <a name="6.2.2.1.3" />
.ihtml h5 <h5>
.SH
6.2.2.1.3 - WiFi Roaming
.R
.ihtml h5
A script can be used to dynamically re-associate with available wifi access points:
.ihtml a <a href="http://plan9.stanleylieber.com/rc/wifiroam">
http://plan9.stanleylieber.com/rc/wifiroam
.ihtml a
Example usage:
.P1
@{wifiroam attwifi | aux/statusmsg -k wifiroam} &
.P2
.html - <a name="6.2.2.1.4" />
.ihtml h5 <h5>
.SH
6.2.2.1.4 - WiFi Debug
.R
.ihtml h5
For cards that use the wifi layer, debug prints (\fBnote:\fR will appear on the console) may be enabled with:
.P1
echo debug >\'#l0/ether0/clone\'
# change this to suit if wifi interface is not #l0
.P2
or by adding
.CW debug=1
to the interface definition in
.CW plan9.ini .
Read:
.ihtml a <a href="http://man.9front.org/8/plan9.ini">
.CW plan9.ini(8)
.ihtml a
.html - <a name="6.2.3" />
.ihtml h3 <h3>
.SH
6.2.3 - IP address
.R
.ihtml h3
The
.CW ip=
tuple is used to associate an IP address with the machine:
.P1
sys=x301 ether=00226811f7dd ip=192.168.0.31
.P2
If no
.CW ip=
tuple is present, the boot scripts will attempt to bring up the interface using DHCP (see below).
.html - <a name="6.2.4" />
.ihtml h3 <h3>
.SH
6.2.4 - Default gateway
.R
.ihtml h3
The default gateway is configured using the
.CW ipgw=
tuple, usually under an
.CW ipnet=
section that defines default settings for an entire subnet:
.P1
ipnet=9front ip=192.168.0.0 ipmask=255.255.255.0 ipgw=192.168.0.1
.P2
but it may also be specified on a per-machine basis:
.P1
sys=x301 ether=00226811f7dd ip=192.168.0.31 ipgw=192.168.0.1
.P2
.B Note:
Tuples included in the definition of a machine supercede those defined for the network to which the machine belongs.
.html - <a name="6.2.5" />
.ihtml h3 <h3>
.SH
6.2.5 - DNS Resolution
.R
.ihtml h3
DNS resolvers may be specified using the
.CW dns=
tuple, and may be configured for an entire network:
.P1
ipnet=9front ip=192.168.0.0 ipmask=255.255.255.0 ipgw=192.168.0.1
dns=192.168.0.1
.P2
or on a per-machine basis:
.P1
sys=x301 ether=00226811f7dd ip=192.168.0.31 dns=192.168.0.1
.P2
These changes will take effect after a reboot. To configure a DNS resolver on the fly, it is possible to manually edit
.CW /net/ndb :
.P1
ip=192.168.0.31 ipmask=255.255.255.0 ipgw=192.168.0.1
sys=x301
dom=x301.9front
dns=192.168.0.1
# add or modify dns= lines to associate the DNS
# server 192.168.0.1 with the running system
.P2
.B Note:
.CW /net/ndb
is a synthetic file that represents the current operating state. It does not persist across reboots, and is only pre-populated when system networking was configured via DHCP.
Changes to a blank
.CW /net/ndb
file will match on the
.CW ip=
tuple.
Read:
.ihtml a <a href="http://man.9front.org/3/ip">
.CW ip(3)
.ihtml a
Finally, to turn on debug in
.CW dns :
.P1
echo -n debug >/net/dns
.P2
.html - <a name="6.2.5.1" />
.ihtml h4 <h4>
.SH
6.2.5.1 - Caching DNS server
.R
.ihtml h4
To run a caching DNS server, modify
.CW /cfg/$sysname/termrc
or
.CW /cfg/$sysname/cpurc
(whichever is appropriate) to include the following:
.P1
ndb/dns -rs
.P2
The caching DNS server will be started at boot time.
Next, modify
.CW /lib/ndb/local
such that the desired machines will use the IP address of the new caching DNS server as their DNS server, either by changing the
.CW dns=
tuple under the
.CW ipnet
of the corresponding network or by adding a
.CW dns=
tuple to the line of each desired machine.
Read:
.ihtml a <a href="http://man.9front.org/6/ndb">
.CW ndb(6)
.ihtml a
and
.ihtml a <a href="http://man.9front.org/8/ndb">
.CW ndb(8)
.ihtml a
.html - <a name="6.2.5.2" />
.ihtml h4 <h4>
.SH
6.2.5.2 - DNS authoritative name server
.R
.ihtml h4
An authoritative domain name record, with associated reverse-lookup and sub-domains, looks like this:
.P1
dom=bell-labs.co soa=
refresh=10800 ttl=10800
# serial is automatically maintained if omitted
serial=2012110732
ns=ns5.he.net
ns=ns4.he.net
ns=ns3.he.net
ns=ns2.he.net
ns=nm.iawtp.com
ns=pp.iawtp.com
ns=mars2.iawtp.com
dnsslave=slave.dns.he.net
[email protected]
mx=pp.inri.net pref=5
mx=nm.inri.net pref=10
mx=mars2.inri.net pref=15
txt="v=spf1 mx -all"
dom=125.191.107.in-addr.arpa soa=
refresh=3600 ttl=3600
ns=nm.iawtp.com
dom=bell-labs.co ip=107.191.125.208
dom=www.bell-labs.co cname=bell-labs.co
.P2
An FQDN may be assigned to an existing machine by adding the
.CW dom=
tuple to its definition:
.P1
sys=x301 dom=x301.bell-labs.co ether=00226811f7dd ip=192.168.0.31
.P2
.B Note:
The dnsslave entries specify slave DNS servers that should be notified when the domain changes. The notification service also requires the
.CW -n
flag:
.P1
ndb/dns -nrs
.P2
Read:
.ihtml a <a href="http://man.9front.org/8/ndb">
.CW ndb(8)
.ihtml a
.html - <a name="6.2.5.2.1" />
.ihtml h4 <h4>
.SH
6.2.5.2.1 - Troubleshooting DNS authoritative name server
.R
.ihtml h4
An online tool that evaluates the DNS configuration of a given domain name is available at:
.ihtml a <a href="https://intodns.com">
.CW https://intodns.com
.ihtml a
.html - <a name="6.2.6" />
.ihtml h3 <h3>
.SH
6.2.6 - Network-wide configuration
.R
.ihtml h3
Settings for an entire network subnet may be defined under an
.CW ipnet=
tuple:
.P1
ipnet=9front ip=192.168.0.0 ipmask=255.255.255.0
ipgw=192.168.0.1
auth=192.168.0.2
authdom=9front
fs=192.168.0.3
cpu=192.168.0.4
dns=192.168.0.1
dnsdomain=9front
smtp=192.168.0.4
# ethernet/wifi router
sys=onoff dom=onoff.9front ip=192.168.0.1
# auth server
sys=auth dom=auth.9front ether=00d059b6dac8 ip=192.168.0.2
bootf=/386/9bootpxe
# cpu server
sys=cpu dom=cpu.9front ether=001125149137 ip=192.168.0.4
bootf=/386/9bootpxe
# file server
sys=fs dom=fs.9front ether=001641360117 ip=192.168.0.3
# terminal
sys=x301 dom=x301.9front ether=00226811f7dd ip=192.168.0.31
bootf=/386/9bootpxe
.P2
.html - <a name="6.2.7" />
.ihtml h3 <h3>
.SH
6.2.7 - Activating the changes
.R
.ihtml h3
.html - <a name="6.2.7.1" />
.ihtml h4 <h4>
.SH
6.2.7.1 - NIC
.R
.ihtml h4
Network interfaces are automatically initialized at boot time. To make a manual change without rebooting, use the
.ihtml a <a href="http://man.9front.org/8/ipconfig">
ipconfig(8)
.ihtml a
command:
.P1
ip/ipconfig -g 192.168.0.1 ether /net/ether0 \e
192.168.0.31 255.255.255.0
.P2
.html - <a name="6.2.7.2" />
.ihtml h4 <h4>
.SH
6.2.7.2 - cs
.R
.ihtml h4
To refresh the network database
.B NOW
after changing
.CW /lib/ndb/local :
.P1
echo -n refresh > /net/cs
.P2
.html - <a name="6.2.7.3" />
.ihtml h4 <h4>
.SH
6.2.7.3 - dns
.R
.ihtml h4
.P1
echo -n refresh > /net/dns
.P2
.html - <a name="6.2.8" />
.ihtml h3 <h3>
.SH
6.2.8 - Verifying network settings
.R
.ihtml h3
.P1
% cat /net/ndb
ip=192.168.0.31 ipmask=255.255.255.0 ipgw=192.168.0.1
sys=x301
dom=x301.9front
auth=192.168.0.2
dns=192.168.0.1
.P2
.html - <a name="6.2.8.1" />
.ihtml h4 <h4>
.SH
6.2.8.1 - Checking routes
.R
.ihtml h4
.P1
% cat /net/iproute
0.0.0.0 /96 192.168.0.1 4 none -
192.168.0.0 /120 192.168.0.0 4i ifc 0
192.168.0.0 /128 192.168.0.0 4b ifc -
192.168.0.31 /128 192.168.0.31 4u ifc 0
192.168.0.255 /128 192.168.0.255 4b ifc -
255.255.255.255 /128 255.255.255.255 4b ifc 0
.P2
.html - <a name="6.2.8.1.1" />
.ihtml h5 <h5>
.SH
6.2.8.1.1 - Adding static routes
.R
.ihtml h5
Route requests for
.CW 192.168.1.0/24
through the gateway
.CW 192.168.0.99
(which itself must already be accessible via the existing network configuration):
.P1
echo \'add 192.168.1.0 255.255.255.0 192.168.0.99\' >/net/iproute
.P2
.B Note:
Manual configurations such as this may be added to optional boot scripts created in
.CW /cfg/$sysname/ .
Read:
.ihtml a <a href="http://man.9front.org/3/ip">
.CW ip(3)
.ihtml a
.html - <a name="6.2.9" />
.ihtml h3 <h3>
.SH
6.2.9 - Setting up your 9front box as a forwarding gateway
.R
.ihtml h3
Read:
.ihtml a <a href="http://man.9front.org/3/ip">
.CW ip(3)
.ihtml a
.html - <a name="6.2.10" />
.ihtml h3 <h3>
.SH
6.2.10 - Setting up aliases on an interface
.R
.ihtml h3
Read:
.ihtml a <a href="http://man.9front.org/3/ip">
.CW ip(3)
.ihtml a
.html - <a name="6.3" />
.ihtml h2 <h2>
.SH
6.3 - How do I filter and firewall with 9front?
.R
.ihtml h2
No.
.html - <a name="6.4" />
.ihtml h2 <h2>
.SH
6.4 - Dynamic Host Configuration Protocol (DHCP)
.R
.ihtml h2
.html - <a name="6.4.1" />
.ihtml h3 <h3>
.SH
6.4.1 - DHCP client
.R
.ihtml h3
In
.CW /lib/ndb/local ,
if no
.CW ip=
tuple is present in the machine's definition, the boot scripts will attempt to obtain an IP address via DHCP.
To obtain a DHCP lease manually:
.P1
ip/ipconfig
.P2
Read:
.ihtml a <a href="http://man.9front.org/8/ipconfig">
.CW ipconfig(8)
.ihtml a
.html - <a name="6.4.2" />
.ihtml h3 <h3>
.SH
6.4.2 - DHCP server
.R
.ihtml h3
From
.ihtml a <a href="http://man.9front.org/8/dhcpd">
.CW dhcpd(8):
.ihtml a
.P1
Dhcpd runs the BOOTP and DHCP protocols. Clients use these
protocols to obtain configuration information. This infor-
mation comes from attribute/value pairs in the network data-
base (see ndb(6) and ndb(8)). DHCP requests are honored both
for static addresses found in the NDB and for dynamic
addresses listed in the command line. DHCP requests are
honored if either:
- there exists an NDB entry containing both the ethernet
address of the requester and an IP address on the originat-
ing network or subnetwork.
- a free dynamic address exists on the originating network
or subnetwork.
A BOOTP request is honored if all of the following are true:
- there exists an NDB entry containing both the ethernet
address of the requester and an IP address on the originat-
ing network or subnetwork.
- the entry contains a bootf= attribute
- the file in the bootf= attribute is readable.
Dynamic addresses are specified on the command line as a
list of addresses and number pairs. For example,
ip/dhcpd 10.1.1.12 10 10.2.1.70 12
directs dhcpd to return dynamic addresses 10.1.1.12 through
10.1.1.21 inclusive and 10.2.1.70 through 10.2.1.81 inclu-
sive.
Dhcpd maintains a record of all dynamic addresses in the
directory /lib/ndb/dhcp, one file per address. If multiple
servers have access to this common directory, they will cor-
rectly coordinate their actions.
Attributes come from either the NDB entry for the system,
the entry for its subnet, or the entry for its network. The
system entry has precedence, then the subnet, then the net-
work. The NDB attributes used are:
ip the IP address
ipmask the IP mask
ipgw the default IP gateway
dom the domain name of the system
fs the default Plan 9 file server
auth the default Plan 9 authentication server
dns a domain name server
ntp a network time protocol server
time a time server
wins a NETBIOS name server
www a World Wide Web proxy
pop3 a POP3 mail server
smtp an SMTP mail server
bootf the default boot file; see ndb(6)
Dhcpd will answer BOOTP requests only if it has been specif-
ically targeted or if it has read access to the boot file
for the requester. That means that the requester must spec-
ify a boot file in the request or one has to exist in NDB
for dhcpd to answer. Dhcpd will answer all DHCP requests
for which it can associate an IP address with the requester.
.P2
To configure a DHCP server on your system:
.P1
mkdir /lib/ndb/dhcp
.P2
and then modify
.CW /cfg/$sysname/cpurc
or
.CW /cfg/$sysname/termrc
(whichever is appropriate) to start
.CW dhcpd
and
.CW tftpd
at boot time:
.P1
ip/dhcpd
.P2
Read:
.ihtml a <a href="http://man.9front.org/8/dhcpd">
.CW dhcpd(8)
.ihtml a
.html - <a name="6.5" />
.ihtml h2 <h2>
.SH
6.5 - PPP
.R
.ihtml h2
Read:
.ihtml a <a href="https://9p.io/wiki/plan9/Dialup_modem_config/fqa.html">
Dailup modem config
.ihtml a
at the Bell Labs Plan 9 wiki.
.html - <a name="6.6" />
.ihtml h2 <h2>
.SH
6.6 - Setting up a network bridge in 9front
.R
.ihtml h2
Read:
.ihtml a <a href="http://man.9front.org/3/bridge">
.CW bridge(3)
.ihtml a
and
.ihtml a <a href="http://man.9front.org/3/ip">
.CW ip(3)
.ihtml a
.html - <a name="6.7" />
.ihtml h2 <h2>
.SH
6.7 - How do I boot from the network?
.R
.ihtml h2
First, read
.ihtml a <a href="fqa7.html#7.3.3">
.I
FQA 7.3.3 - Setting up a listener for network connections.
.R
.ihtml a
The file server should already be running a listener, and an auth server should already be configured and running on the network.
.html - <a name="6.7.1" />
.ihtml h3 <h3>
.SH
6.7.1 - How do I tcp boot?
.R
.ihtml h3
It is possible to boot from local media and then mount the root file system over the network. At the
.CW bootargs
prompt, type
.CW tls
(the old
.CW tcp
boot option will still work but is not recommended because the connection will not be encrypted).
At this point,
.CW ip/ipconfig
will determine network parameters using DHCP. When file (\f(CWfs\fR) or authentication (\f(CWauth\fR) server IP addresses could not be determined over DHCP then the boot process will prompt for those. When prompted for a
.CW user ,
enter a valid username and password that has already been configured on the auth server. The machine should then proceed to mount its root file system from the file server.
.B Note:
Values for
.CW fs
and
.CW auth
may be added to
.CW plan9.ini .
Read:
.ihtml a <a href="http://man.9front.org/8/plan9.ini">
.CW plan9.ini(8)
.ihtml a
.html - <a name="6.7.1.1" />
.ihtml h4 <h4>
.SH
6.7.1.1 - Passing arguments to ipconfig at the bootargs prompt
.R
.ihtml h4
When a DHCP server is not available, you may still tcp boot by configuring networking manually at the
.CW bootargs
prompt. Everything after
.CW tcp!
is passed as arguments to the
.CW ipconfig
command.
At the prompt:
.P1
bootargs is (tcp, tls, il, local!device) [tcp]
.P2
enter something like the following:
.P1
tls!-g 192.168.0.1 ether /net/ether0 192.168.0.23 255.255.255.0
.P2
where
.CW 192.168.0.1
is the gateway,
.CW 192.168.0.23
is the static IP address and
.CW 255.255.255.0
the subnet mask.
Read:
.ihtml a <a href="http://man.9front.org/8/ipconfig">
.CW ipconfig(8)
.ihtml a
.html - <a name="6.7.2" />
.ihtml h3 <h3>
.SH
6.7.2 - How do I boot using PXE?
.R
.ihtml h3
It is also possible to PXE boot a system.
On the file server, add the following lines to
.CW /cfg/$sysname/cpurc
to start
.CW dhcpd
and
.CW tftpd
at boot time:
.P1
ip/dhcpd
ip/tftpd
.P2
Add an entry for
.CW tftp
under the appropriate
.CW ipnet=
tuple in
.CW /lib/ndb/local :
.P1
ipnet=9front ip=192.168.0.0 ipmask=255.255.255.0 ipgw=192.168.0.1
auth=192.168.0.2
authdom=9front
cpu=192.168.0.4
dns=192.168.0.1
dnsdomain=9front
smtp=192.168.0.4
tftp=192.168.0.3
.P2
Reboot the file server:
.P1
fshalt -r
.P2
To configure machines that will PXE boot from the file server, edit
.CW /lib/ndb/local
on the file server and add a
.CW bootf=
(boot file) tuple to the line representing each machine:
.P1
sys=x301 dom=x301.9front ether=00226811f7dd ip=192.168.0.31
bootf=/386/9bootpxe
.P2
For the system
.CW x301
we would then create a file
.CW /cfg/pxe/00226811f7dd
on the file server to serve as its
.CW plan9.ini :
.P1
bootfile=/386/9pc
bootargs=tls
nobootprompt=tls
auth=192.168.0.2
fs=192.168.0.3
mouseport=ps2intellimouse
monitor=vesa
vgasize=1440x900x32
*acpi=1
user=sl
.P2
.B Note:
The
.CW user=
parameter refers to a single username that has been added both to the file server (for file permissions) as well as to the auth server (for network authentication).
If a file matching the remote system's MAC address is not found under
.CW /cfg/pxe/ ,
the file
.CW /cfg/pxe/default
(if it exists) will be used instead.
Finally, boot the desired remote systems via PXE. When prompted for a
.CW user ,
enter a valid username and password that has already been configured on the auth server. The remote system should now proceed to boot from the file server.
.html - <hr />
.html - <a href="fqa.html">FQA INDEX</a> |
.html - <a href="fqa5.html">FQA 5 - Building The System From Source</a> |
.html - <a href="fqa7.html">FQA 7 - System Management</a>