diff --git a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml index b643f39108..4b20df6640 100644 --- a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml @@ -21,7 +21,8 @@ - How to set up &ieee; 802.11 and &bluetooth; devices. + How to set up &ieee; 802.11 and &bluetooth; + devices. @@ -29,11 +30,13 @@ - How to set up network booting on a diskless machine. + How to set up network booting on a diskless + machine. - How to set up network PXE booting with an NFS root file system. + How to set up network PXE booting with an NFS root file + system. @@ -62,7 +65,8 @@ - Understand the basics of the /etc/rc scripts. + Understand the basics of the + /etc/rc scripts. @@ -70,13 +74,13 @@ - Know how to configure and install a new FreeBSD kernel - (). + Know how to configure and install a new FreeBSD kernel + (). - Know how to install additional third-party - software (). + Know how to install additional third-party + software (). @@ -85,18 +89,20 @@ - - Coranth - Gryphon + + Coranth + Gryphon Contributed by - + + Gateways and Routes routing gateway subnet + For one machine to be able to find another over a network, there must be a mechanism in place to describe how to get from one to the other. This is called @@ -111,14 +117,13 @@ bit more about default routes later on. There are also three types of gateways: individual hosts, interfaces (also called links), and Ethernet hardware addresses (MAC - addresses). - + addresses). An Example - To illustrate different aspects of routing, we will use the - following example from netstat: + To illustrate different aspects of routing, we will use + the following example from netstat: &prompt.user; netstat -r Routing tables @@ -137,8 +142,9 @@ host2.example.com link#1 UC 0 0 default route The first two lines specify the default route (which we - will cover in the next - section) and the localhost route. + will cover in the + next section) + and the localhost route. loopback device The interface (Netif column) that this @@ -150,8 +156,8 @@ host2.example.com link#1 UC 0 0 started. - Ethernet - MAC address + Ethernet + MAC address The next thing that stands out are the addresses beginning with 0:e0:. These are Ethernet @@ -169,24 +175,28 @@ host2.example.com link#1 UC 0 0 based upon a shortest path determination. subnet - FreeBSD will also add subnet routes for the local subnet (10.20.30.255 is the broadcast address for the - subnet 10.20.30, and example.com is the domain name associated - with that subnet). The designation link#1 refers - to the first Ethernet card in the machine. You will notice no - additional interface is specified for those. - Both of these groups (local network hosts and local subnets) have - their routes automatically configured by a daemon called - routed. If this is not run, then only - routes which are statically defined (i.e., entered explicitly) will - exist. + FreeBSD will also add subnet routes for the local subnet + (10.20.30.255 is the broadcast + address for the subnet + 10.20.30, and + example.com is the domain + name associated with that subnet). The designation + link#1 refers to the first Ethernet card in + the machine. You will notice no additional interface is + specified for those. - The host1 line refers to our host, which it - knows by Ethernet address. Since we are the sending host, FreeBSD - knows to use the loopback interface (lo0) - rather than sending it out over the Ethernet interface. + Both of these groups (local network hosts and local + subnets) have their routes automatically configured by a + daemon called routed. If this is + not run, then only routes which are statically defined (i.e., + entered explicitly) will exist. + + The host1 line refers to our host, + which it knows by Ethernet address. Since we are the sending + host, FreeBSD knows to use the loopback interface + (lo0) rather than sending it out over + the Ethernet interface. The two host2 lines are an example of what happens when we use an &man.ifconfig.8; alias (see the @@ -199,8 +209,9 @@ host2.example.com link#1 UC 0 0 hosts on the local network will simply have a link#1 line for such routes. - The final line (destination subnet 224) deals - with multicasting, which will be covered in another section. + The final line (destination subnet + 224) deals with multicasting, + which will be covered in another section. Finally, various attributes of each route can be seen in the Flags column. Below is a short table @@ -219,14 +230,15 @@ host2.example.com link#1 UC 0 0 H - Host: The route destination is a single host. + Host: The route destination is a single + host. G - Gateway: Send anything for this destination on to this - remote system, which will figure out from there where to send - it. + Gateway: Send anything for this destination on to + this remote system, which will figure out from there + where to send it. @@ -237,15 +249,16 @@ host2.example.com link#1 UC 0 0 C - Clone: Generates a new route based upon this route for - machines we connect to. This type of route is normally used - for local networks. + Clone: Generates a new route based upon this + route for machines we connect to. This type of route + is normally used for local networks. W - WasCloned: Indicated a route that was auto-configured - based upon a local area network (Clone) route. + WasCloned: Indicated a route that was + auto-configured based upon a local area network + (Clone) route. @@ -262,27 +275,29 @@ host2.example.com link#1 UC 0 0 Default Routes default route - When the local system needs to make a connection to a remote host, - it checks the routing table to determine if a known path exists. If - the remote host falls into a subnet that we know how to reach (Cloned - routes), then the system checks to see if it can connect along that - interface. - If all known paths fail, the system has one last option: the - default route. This route is a special type of gateway - route (usually the only one present in the system), and is always - marked with a c in the flags field. For hosts on a - local area network, this gateway is set to whatever machine has a - direct connection to the outside world (whether via PPP link, - DSL, cable modem, T1, or another network interface). + When the local system needs to make a connection to a + remote host, it checks the routing table to determine if a + known path exists. If the remote host falls into a subnet + that we know how to reach (Cloned routes), then the system + checks to see if it can connect along that interface. - If you are configuring the default route for a machine which - itself is functioning as the gateway to the outside world, then the - default route will be the gateway machine at your Internet Service - Provider's (ISP) site. + If all known paths fail, the system has one last option: + the default route. This route is a special + type of gateway route (usually the only one present in the + system), and is always marked with a c in + the flags field. For hosts on a local area network, this + gateway is set to whatever machine has a direct connection to + the outside world (whether via PPP link, DSL, cable modem, T1, + or another network interface). - Let us look at an example of default routes. This is a common - configuration: + If you are configuring the default route for a machine + which itself is functioning as the gateway to the outside + world, then the default route will be the gateway machine at + your Internet Service Provider's (ISP) site. + + Let us look at an example of default routes. This is a + common configuration: @@ -303,7 +318,8 @@ host2.example.com link#1 UC 0 0 a local area network to another gateway computer through an external interface to the ISPs Internet feed. - The default routes for each of your machines will be: + The default routes for each of your machines will + be: @@ -332,22 +348,24 @@ host2.example.com link#1 UC 0 0 A common question is Why (or how) would we set - the T1-GW to be the default gateway for - Local1, rather than the ISP server it is - connected to?. + the T1-GW to be the default gateway for + Local1, rather than the ISP server it is + connected to?. - Remember, since the PPP interface is using an address on the ISP's - local network for your side of the connection, routes for any other - machines on the ISP's local network will be automatically generated. - Hence, you will already know how to reach the T1-GW - machine, so there is no need for the intermediate step - of sending traffic to the ISP server. + Remember, since the PPP interface is using an address on + the ISP's local network for your side of the connection, + routes for any other machines on the ISP's local network will + be automatically generated. Hence, you will already know how + to reach the T1-GW machine, so there is no + need for the intermediate step of sending traffic to the ISP + server. - It is common to use the address X.X.X.1 as the gateway address for your local - network. So (using the same example), if your local class-C address - space was 10.20.30 and your ISP was - using 10.9.9 then the default routes + It is common to use the address + X.X.X.1 as the gateway address + for your local network. So (using the same example), if your + local class-C address space was + 10.20.30 and your ISP was using + 10.9.9 then the default routes would be: @@ -363,6 +381,7 @@ host2.example.com link#1 UC 0 0 Local2 (10.20.30.2) Local1 (10.20.30.1) + Local1 (10.20.30.1, 10.9.9.30) T1-GW (10.9.9.1) @@ -372,9 +391,9 @@ host2.example.com link#1 UC 0 0 You can easily define the default route via the - /etc/rc.conf file. In our example, on the - Local2 machine, we added the following line - in /etc/rc.conf: + /etc/rc.conf file. In our example, on + the Local2 machine, we added the following + line in /etc/rc.conf: defaultrouter="10.20.30.1" @@ -391,12 +410,13 @@ host2.example.com link#1 UC 0 0 Dual Homed Hosts dual homed hosts - There is one other type of configuration that we should cover, and - that is a host that sits on two different networks. Technically, any - machine functioning as a gateway (in the example above, using a PPP - connection) counts as a dual-homed host. But the term is really only - used to refer to a machine that sits on two local-area - networks. + + There is one other type of configuration that we should + cover, and that is a host that sits on two different networks. + Technically, any machine functioning as a gateway (in the + example above, using a PPP connection) counts as a dual-homed + host. But the term is really only used to refer to a machine + that sits on two local-area networks. In one case, the machine has two Ethernet cards, each having an address on the separate subnets. Alternately, the @@ -406,16 +426,16 @@ host2.example.com link#1 UC 0 0 if there is one physical network segment, but two logically separate subnets. - Either way, routing tables are set up so that each subnet knows - that this machine is the defined gateway (inbound route) to the other - subnet. This configuration, with the machine acting as a router - between the two subnets, is often used when we need to implement - packet filtering or firewall security in either or both - directions. + Either way, routing tables are set up so that each subnet + knows that this machine is the defined gateway (inbound route) + to the other subnet. This configuration, with the machine + acting as a router between the two subnets, is often used when + we need to implement packet filtering or firewall security in + either or both directions. If you want this machine to actually forward packets - between the two interfaces, you need to tell FreeBSD to enable - this ability. See the next section for more details on how + between the two interfaces, you need to tell FreeBSD to enable + this ability. See the next section for more details on how to do this. @@ -436,7 +456,8 @@ host2.example.com link#1 UC 0 0 This option will set the &man.sysctl.8; variable net.inet.ip.forwarding to 1. If you should need to stop routing - temporarily, you can reset this to 0 temporarily. + temporarily, you can reset this to 0 + temporarily. BGP RIP @@ -448,8 +469,9 @@ host2.example.com link#1 UC 0 0 version 2) and IRDP. Support for BGP v4, OSPF v2, and other sophisticated routing protocols is available with the net/zebra package. - Commercial products such as &gated; are also available for more - complex network routing solutions. + Commercial products such as &gated; + are also available for more complex network routing + solutions. @@ -505,14 +527,15 @@ host2.example.com link#1 UC 0 0 In this scenario, RouterA is our &os; machine that is acting as a router to the rest of the - Internet. It has a default route set to 10.0.0.1 which allows it to connect - with the outside world. We will assume that + Internet. It has a default route set to + 10.0.0.1 which allows it to + connect with the outside world. We will assume that RouterB is already configured properly and knows how to get wherever it needs to go. (This is simple in this picture. Just add a default route on - RouterB using 192.168.1.1 as the gateway.) + RouterB using + 192.168.1.1 as the + gateway.) If we look at the routing table for RouterA we would see something like the @@ -530,12 +553,13 @@ default 10.0.0.1 UGS 0 49378 xl0 With the current routing table RouterA will not be able to reach our Internal Net 2. It does not - have a route for 192.168.2.0/24. One way to alleviate - this is to manually add the route. The following command - would add the Internal Net 2 network to - RouterA's routing table using 192.168.1.2 as the next hop: + have a route for + 192.168.2.0/24. One way to + alleviate this is to manually add the route. The following + command would add the Internal Net 2 network to + RouterA's routing table using + 192.168.1.2 as the next + hop: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 @@ -571,17 +595,18 @@ route_internalnet2="-net 192.168.2.0/24 192.168.1.2" &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 - so we need "-net 192.168.2.0/24 192.168.1.2". + so we need "-net 192.168.2.0/24 + 192.168.1.2". As said above, we can have more than one string in - static_routes. This allows us to - create multiple static routes. The following lines shows - an example of adding static routes for the 192.168.0.0/24 and 192.168.1.0/24 networks on an imaginary - router: + static_routes. This allows us to create + multiple static routes. The following lines shows an + example of adding static routes for the + 192.168.0.0/24 and + 192.168.1.0/24 networks on an + imaginary router: - static_routes="net1 net2" + static_routes="net1 net2" route_net1="-net 192.168.0.0/24 192.168.0.1" route_net2="-net 192.168.1.0/24 192.168.1.1" @@ -589,58 +614,67 @@ route_net2="-net 192.168.1.0/24 192.168.1.1" Routing Propagation + routing propagation - We have already talked about how we define our routes to the - outside world, but not about how the outside world finds us. + We have already talked about how we define our routes to + the outside world, but not about how the outside world finds + us. - We already know that routing tables can be set up so that all - traffic for a particular address space (in our examples, a class-C - subnet) can be sent to a particular host on that network, which will - forward the packets inbound. + We already know that routing tables can be set up so that + all traffic for a particular address space (in our examples, a + class-C subnet) can be sent to a particular host on that + network, which will forward the packets inbound. - When you get an address space assigned to your site, your service - provider will set up their routing tables so that all traffic for your - subnet will be sent down your PPP link to your site. But how do sites - across the country know to send to your ISP? + When you get an address space assigned to your site, your + service provider will set up their routing tables so that all + traffic for your subnet will be sent down your PPP link to + your site. But how do sites across the country know to send + to your ISP? - There is a system (much like the distributed DNS information) that - keeps track of all assigned address-spaces, and defines their point of - connection to the Internet Backbone. The Backbone are - the main trunk lines that carry Internet traffic across the country, - and around the world. Each backbone machine has a copy of a master - set of tables, which direct traffic for a particular network to a - specific backbone carrier, and from there down the chain of service - providers until it reaches your network. + There is a system (much like the distributed DNS + information) that keeps track of all assigned address-spaces, + and defines their point of connection to the Internet + Backbone. The Backbone are the main trunk + lines that carry Internet traffic across the country, and + around the world. Each backbone machine has a copy of a + master set of tables, which direct traffic for a particular + network to a specific backbone carrier, and from there down + the chain of service providers until it reaches your + network. - It is the task of your service provider to advertise to the - backbone sites that they are the point of connection (and thus the - path inward) for your site. This is known as route + It is the task of your service provider to advertise to + the backbone sites that they are the point of connection (and + thus the path inward) for your site. This is known as route propagation. Troubleshooting - - traceroute - - Sometimes, there is a problem with routing propagation, and some - sites are unable to connect to you. Perhaps the most useful command - for trying to figure out where routing is breaking down is the - &man.traceroute.8; command. It is equally useful if you cannot seem - to make a connection to a remote machine (i.e., &man.ping.8; - fails). - The &man.traceroute.8; command is run with the name of the remote - host you are trying to connect to. It will show the gateway hosts - along the path of the attempt, eventually either reaching the target - host, or terminating because of a lack of connection. + + traceroute + + + Sometimes, there is a problem with routing propagation, + and some sites are unable to connect to you. Perhaps the most + useful command for trying to figure out where routing is + breaking down is the &man.traceroute.8; command. It is + equally useful if you cannot seem to make a connection to a + remote machine (i.e., &man.ping.8; fails). + + The &man.traceroute.8; command is run with the name of the + remote host you are trying to connect to. It will show the + gateway hosts along the path of the attempt, eventually either + reaching the target host, or terminating because of a lack of + connection. For more information, see the manual page for - &man.traceroute.8;. + &man.traceroute.8;. Multicast Routing + multicast routing @@ -657,19 +691,19 @@ route_net2="-net 192.168.1.0/24 192.168.1.1" options MROUTING In addition, the multicast routing daemon, &man.mrouted.8; - must be configured to set up tunnels and DVMRP via + must be configured to set up tunnels and + DVMRP via /etc/mrouted.conf. More details on multicast configuration may be found in the manual page for &man.mrouted.8;. - The &man.mrouted.8; multicast routing daemon - implements the - DVMRP multicast routing protocol, which has - largely been replaced by &man.pim.4; in many multicast - installations. &man.mrouted.8; and the related &man.map-mbone.8; and - &man.mrinfo.8; utilities - are available in the &os; Ports Collection as + The &man.mrouted.8; multicast routing daemon implements + the DVMRP multicast routing protocol, + which has largely been replaced by &man.pim.4; in many + multicast installations. &man.mrouted.8; and the related + &man.map-mbone.8; and &man.mrinfo.8; utilities are available + in the &os; Ports Collection as net/mrouted. @@ -720,8 +754,8 @@ route_net2="-net 192.168.1.0/24 192.168.1.1" another wireless station messages must go through the AP. In the second form of network there is no master and stations communicate directly. This form of network is termed an IBSS - and is commonly known as an ad-hoc - network. + and is commonly known as an + ad-hoc network. 802.11 networks were first deployed in the 2.4GHz band using protocols defined by the &ieee; 802.11 and 802.11b @@ -811,10 +845,11 @@ route_net2="-net 192.168.1.0/24 192.168.1.1" support layer that handles chip-specific functions (&man.ath.hal.4;), and an algorithm for selecting which of several possible rates for transmitting frames - (ath_rate_sample here). When this support is loaded as kernel - modules, these dependencies are automatically handled for - you. If, instead of an Atheros device, you had another device - you would select the module for that device; e.g.: + (ath_rate_sample here). When this support is loaded as + kernel modules, these dependencies are automatically handled + for you. If, instead of an Atheros device, you had another + device you would select the module for that device; + e.g.: if_wi_load="YES" @@ -829,25 +864,23 @@ route_net2="-net 192.168.1.0/24 192.168.1.1" found in the &os; Hardware Notes. Copies of these notes for various releases and architectures are available on the Release - Information page of the &os; Web site. - If a native &os; driver - for your wireless device does not exist, it may be - possible to directly use the &windows; driver with the - help of the NDIS driver + url="http://www.FreeBSD.org/releases/index.html">Release + Information page of the &os; Web site. If a + native &os; driver for your wireless device does not + exist, it may be possible to directly use the &windows; + driver with the help of the + NDIS driver wrapper. - Under &os; 7.X, with a device driver you need to also bring - in the 802.11 networking support required by the driver. - For the &man.ath.4; driver these are at least the &man.wlan.4;, - wlan_scan_ap and - wlan_scan_sta - modules; the &man.wlan.4; module is automatically loaded with the - wireless device driver, the remaining modules must be loaded - at boot time via the /boot/loader.conf - file: + Under &os; 7.X, with a device driver you need to + also bring in the 802.11 networking support required by the + driver. For the &man.ath.4; driver these are at least the + &man.wlan.4;, wlan_scan_ap and + wlan_scan_sta modules; the &man.wlan.4; + module is automatically loaded with the wireless device + driver, the remaining modules must be loaded at boot time + via the /boot/loader.conf file: wlan_scan_ap_load="YES" wlan_scan_sta_load="YES" @@ -856,17 +889,16 @@ wlan_scan_sta_load="YES" base &man.wlan.4; driver which is dynamically loaded with the adapter driver. - With that, you will need the modules - that implement cryptographic support for the security - protocols you intend to use. These are intended to be - dynamically loaded on demand by the &man.wlan.4; module but - for now they must be manually configured. The following - modules are available: &man.wlan.wep.4;, &man.wlan.ccmp.4; - and &man.wlan.tkip.4;. Both &man.wlan.ccmp.4; and - &man.wlan.tkip.4; drivers are only needed if you intend to - use the WPA and/or 802.11i security protocols. If your - network does not use encryption, - you will not need &man.wlan.wep.4; support. To + With that, you will need the modules that implement + cryptographic support for the security protocols you intend + to use. These are intended to be dynamically loaded on + demand by the &man.wlan.4; module but for now they must be + manually configured. The following modules are available: + &man.wlan.wep.4;, &man.wlan.ccmp.4; and &man.wlan.tkip.4;. + Both &man.wlan.ccmp.4; and &man.wlan.tkip.4; drivers are + only needed if you intend to use the WPA and/or 802.11i + security protocols. If your network does not use + encryption, you will not need &man.wlan.wep.4; support. To load these modules at boot time, add the following lines to /boot/loader.conf: @@ -1049,9 +1081,9 @@ freebsdap 00:11:95:c3:0d:ac 1 54M -83:96 100 EPS WPA This section provides a simple example of how to make the wireless network adapter work in &os; without encryption. After you are familiar with these concepts, - we strongly recommend using WPA to set up your - wireless network. + we strongly recommend using + WPA to set up + your wireless network. There are three basic steps to configure a wireless network: selecting an access point, authenticating your @@ -1133,7 +1165,7 @@ ifconfig_wlan0="mode 11g ssid your_ssid_ will use open authentication which is the default setting. Next most common setup is WPA-PSK, also known as WPA Personal, which is described below. + linkend="network-wireless-wpa-wpa-psk">below. If you have an &apple; &airport; Extreme base @@ -1154,8 +1186,8 @@ ifconfig_wlan0="authmode shared wepmode on weptxkey 1 crack the key. If WEP must be used (e.g., for compatibility with legacy devices) it is better to use WEP with open authentication. More - information regarding WEP can be found in the . + information regarding WEP can be found in the + . @@ -1198,8 +1230,8 @@ wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 dlinkap network in our case). The bssid 00:13:46:49:41:76 part is the MAC address of your access point; the - authmode OPEN part informs you that the - communication is not encrypted. + authmode OPEN part informs you that + the communication is not encrypted. @@ -1222,16 +1254,16 @@ ifconfig_wlan0="inet 192.168.1.100 netmask WPA (Wi-Fi Protected Access) is a security protocol used together with 802.11 networks to address the lack of - proper authentication and the weakness of WEP. WPA leverages - the 802.1X authentication protocol and uses one of several - ciphers instead of WEP for data integrity. The only - cipher required by WPA is TKIP (Temporary Key Integrity - Protocol). TKIP is a cipher that extends the basic RC4 - cipher used by WEP by adding integrity checking, tamper - detection, and measures for responding to any detected - intrusions. TKIP is designed to work on legacy hardware - with only software modification; it represents a + proper authentication and the weakness of + WEP. WPA + leverages the 802.1X authentication protocol and uses one + of several ciphers instead of WEP for data integrity. The + only cipher required by WPA is TKIP (Temporary Key + Integrity Protocol). TKIP is a cipher that extends the + basic RC4 cipher used by WEP by adding integrity checking, + tamper detection, and measures for responding to any + detected intrusions. TKIP is designed to work on legacy + hardware with only software modification; it represents a compromise that improves security but is still not entirely immune to attack. WPA also specifies the AES-CCMP cipher as an alternative to TKIP and that is @@ -1345,7 +1377,7 @@ wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 If /etc/rc.conf has an - ifconfig_wlan0 entry with the + ifconfig_wlan0 entry with the DHCP string (like ifconfig_wlan0="DHCP"), dhclient will be launched @@ -1431,8 +1463,8 @@ wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 - Here, we use RSN (&ieee; 802.11i) protocol, i.e., - WPA2. + Here, we use RSN (&ieee; 802.11i) protocol, + i.e., WPA2. @@ -1600,16 +1632,16 @@ wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 WPA with EAP-PEAP - PEAPv0/EAP-MSCHAPv2 is the most common PEAP method. - In the rest of this document, we will use the PEAP term - to refer to that method. + PEAPv0/EAP-MSCHAPv2 is the most common PEAP + method. In the rest of this document, we will use the + PEAP term to refer to that method. - + PEAP (Protected EAP) has been designed as an alternative to EAP-TTLS, and is the most used EAP standard after EAP-TLS. In other words, if you have a - network with mixed OSes, PEAP should be the - most supported standard after EAP-TLS. + network with mixed OSes, PEAP should be the most + supported standard after EAP-TLS. PEAP is similar to EAP-TTLS: it uses a server-side certificate to authenticate clients by creating an @@ -1663,13 +1695,13 @@ wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 This field contains the parameters for the - first phase of authentication (the TLS - tunnel). According to the authentication server - used, you will have to specify a specific label - for authentication. Most of the time, the label - will be client EAP encryption which - is set by using peaplabel=0. - More information can be found in the + first phase of authentication (the TLS tunnel). + According to the authentication server used, you + will have to specify a specific label for + authentication. Most of the time, the label will be + client EAP encryption which is set by + using peaplabel=0. More + information can be found in the &man.wpa.supplicant.conf.5; manual page. @@ -1726,11 +1758,12 @@ wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 + The weptxkey means which WEP - key will be used in the transmission. Here we used the - third key. This must match the setting in the access - point. If you do not have any idea of which key is - used by the access point, try + key will be used in the transmission. Here we used + the third key. This must match the setting in the + access point. If you do not have any idea of which + key is used by the access point, try 1 (i.e., the first key) for this value. @@ -1744,8 +1777,8 @@ wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 than the first key. - You must replace - the 0x3456789012 with the key + You must replace the + 0x3456789012 with the key configured for use on the access point. @@ -1782,8 +1815,8 @@ Associated with 00:13:46:49:41:76 IBSS mode, also called ad-hoc mode, is designed for point to point connections. For example, to establish an ad-hoc network between the machine A and the machine - B, we will just need to choose two IP addresses - and a SSID. + B, we will just need to choose two IP + addresses and a SSID. On the box A: @@ -1826,16 +1859,16 @@ Associated with 00:13:46:49:41:76 country US ecm authmode OPEN privacy OFF txpower 21.5 scanvalid 60 protmode CTS wme burst - Both A and B are now - ready to exchange information. + Both A and B are now + ready to exchange information. &os; Host Access Points &os; can act as an Access Point (AP) which eliminates the - need to buy a hardware AP or run an ad-hoc network. This can be - particularly useful when your &os; machine is acting as a + need to buy a hardware AP or run an ad-hoc network. This can + be particularly useful when your &os; machine is acting as a gateway to another network (e.g., the Internet). @@ -1845,13 +1878,13 @@ Associated with 00:13:46:49:41:76 kernel must be configured with the appropriate wireless networking support for your wireless card. You also have to add support for the security protocols you intend to - use. For more details, see . + use. For more details, see + . The use of the NDIS driver wrapper and the &windows; - drivers do not currently allow AP operation. Only - native &os; wireless drivers support AP mode. + drivers do not currently allow AP operation. Only native + &os; wireless drivers support AP mode. Once wireless networking support is loaded, you can @@ -1964,8 +1997,8 @@ freebsdap 00:11:95:c3:0d:ac 1 54M -66:-96 100 ES WME Before trying to configure hostapd, be sure you have done - the basic settings introduced in the . + the basic settings introduced in the + . WPA-PSK @@ -2023,8 +2056,8 @@ wpa_pairwise=CCMP TKIP The wpa field enables WPA and specifies which WPA authentication protocol will be - required. A value of 1 configures the - AP for WPA-PSK. + required. A value of 1 configures + the AP for WPA-PSK. @@ -2061,7 +2094,7 @@ wpa_pairwise=CCMP TKIP &prompt.root /etc/rc.d/hostapd forcestart - &prompt.root; ifconfig wlan0 + &prompt.root; ifconfig wlan0 wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2290 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::211:95ff:fec3:dac%ath0 prefixlen 64 scopeid 0x4 @@ -2071,12 +2104,13 @@ wpa_pairwise=CCMP TKIP ssid freebsdap channel 1 bssid 00:11:95:c3:0d:ac authmode WPA2/802.11i privacy MIXED deftxkey 2 TKIP 2:128-bit txpowmax 36 protmode CTS dtimperiod 1 bintval 100 - The Access Point is running, the clients can now be - associated with it, see for more details. It is - possible to see the stations associated with the AP using - the ifconfig wlan0 list - sta command. + The Access Point is running, the clients can now be + associated with it, see + for more details. + It is possible to see the stations associated with the AP + using the ifconfig + wlan0 list sta + command. @@ -2129,8 +2163,8 @@ wpa_pairwise=CCMP TKIP country US ecm authmode OPEN privacy ON deftxkey 3 wepkey 3:40-bit txpower 21.5 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs - From another wireless machine, it is possible to initiate - a scan to find the AP: + From another wireless machine, it is possible to + initiate a scan to find the AP: &prompt.root; ifconfig wlan0 create wlandev ath0 &prompt.root; ifconfig wlan0 up scan @@ -2147,20 +2181,23 @@ freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 EPS Using Both Wired and Wireless Connection - Wired connection provides better performance and reliability, - while wireless connection provides flexibility and mobility, - users of laptop computers usually want to combine these together - and roam seamlessly between the two. + Wired connection provides better performance and + reliability, while wireless connection provides flexibility + and mobility, users of laptop computers usually want to + combine these together and roam seamlessly between the + two. - On &os;, it is possible to combine two or even more network - interfaces together in a failover fashion, that - is, to use the most preferred and available connection from a - group of network interfaces, and have the operating system - switch automatically when the link state changes. + On &os;, it is possible to combine two or even more + network interfaces together in a failover + fashion, that is, to use the most preferred and available + connection from a group of network interfaces, and have the + operating system switch automatically when the link state + changes. - We will cover link aggregation and failover in - where an example for using both wired and wireless connection - is also provided at . + We will cover link aggregation and failover in + where an example for + using both wired and wireless connection is also provided at + . @@ -2234,56 +2271,61 @@ freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 EPS - - Pav - Lucistnik - Written by - + + Pav + Lucistnik + Written by +
pav@FreeBSD.org
- - + + + Bluetooth Bluetooth Introduction - Bluetooth is a wireless technology for creating personal networks - operating in the 2.4 GHz unlicensed band, with a range of 10 meters. - Networks are usually formed ad-hoc from portable devices such as - cellular phones, handhelds and laptops. Unlike the other popular - wireless technology, Wi-Fi, Bluetooth offers higher level service - profiles, e.g., FTP-like file servers, file pushing, voice transport, - serial line emulation, and more. - The Bluetooth stack in &os; is implemented using the Netgraph - framework (see &man.netgraph.4;). A broad variety of Bluetooth USB - dongles is supported by the &man.ng.ubt.4; driver. The Broadcom BCM2033 - chip based Bluetooth devices are supported via the &man.ubtbcmfw.4; and - &man.ng.ubt.4; drivers. The 3Com Bluetooth PC Card 3CRWB60-A is - supported by the &man.ng.bt3c.4; driver. Serial and UART based - Bluetooth devices are supported via &man.sio.4;, &man.ng.h4.4; - and &man.hcseriald.8;. This section describes the use of the USB - Bluetooth dongle. + Bluetooth is a wireless technology for creating personal + networks operating in the 2.4 GHz unlicensed band, with a + range of 10 meters. Networks are usually formed ad-hoc from + portable devices such as cellular phones, handhelds and + laptops. Unlike the other popular wireless technology, Wi-Fi, + Bluetooth offers higher level service profiles, e.g., FTP-like + file servers, file pushing, voice transport, serial line + emulation, and more. + + The Bluetooth stack in &os; is implemented using the + Netgraph framework (see &man.netgraph.4;). A broad variety of + Bluetooth USB dongles is supported by the &man.ng.ubt.4; + driver. The Broadcom BCM2033 chip based Bluetooth devices are + supported via the &man.ubtbcmfw.4; and &man.ng.ubt.4; drivers. + The 3Com Bluetooth PC Card 3CRWB60-A is supported by the + &man.ng.bt3c.4; driver. Serial and UART based Bluetooth + devices are supported via &man.sio.4;, &man.ng.h4.4; and + &man.hcseriald.8;. This section describes the use of the USB + Bluetooth dongle. Plugging in the Device - By default Bluetooth device drivers are available as kernel modules. - Before attaching a device, you will need to load the driver into the - kernel: + + By default Bluetooth device drivers are available as + kernel modules. Before attaching a device, you will need to + load the driver into the kernel: &prompt.root; kldload ng_ubt - If the Bluetooth device is present in the system during system - startup, load the module from - /boot/loader.conf: + If the Bluetooth device is present in the system during + system startup, load the module from + /boot/loader.conf: ng_ubt_load="YES" - Plug in your USB dongle. The output similar to the following will - appear on the console (or in syslog): + Plug in your USB dongle. The output similar to the + following will appear on the console (or in syslog): ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 @@ -2291,10 +2333,10 @@ ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, wMaxPacketSize=49, nframes=6, buffer size=294 The /etc/rc.d/bluetooth script - is used to start and stop the Bluetooth stack. It is a good - idea to stop the stack before unplugging the device, but it is not - (usually) fatal. When starting the stack, you will receive output similar - to the following: + is used to start and stop the Bluetooth stack. It is a good + idea to stop the stack before unplugging the device, but it is + not (usually) fatal. When starting the stack, you will + receive output similar to the following: &prompt.root; /etc/rc.d/bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a @@ -2308,38 +2350,40 @@ Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8 - HCI Host Controller Interface (HCI) - Host Controller Interface (HCI) provides a command interface to the - baseband controller and link manager, and access to hardware status and - control registers. This interface provides a uniform method of accessing - the Bluetooth baseband capabilities. HCI layer on the Host exchanges - data and commands with the HCI firmware on the Bluetooth hardware. - The Host Controller Transport Layer (i.e., physical bus) driver provides - both HCI layers with the ability to exchange information with each - other. + Host Controller Interface (HCI) provides a command + interface to the baseband controller and link manager, and + access to hardware status and control registers. This + interface provides a uniform method of accessing the Bluetooth + baseband capabilities. HCI layer on the Host exchanges data + and commands with the HCI firmware on the Bluetooth hardware. + The Host Controller Transport Layer (i.e., physical bus) + driver provides both HCI layers with the ability to exchange + information with each other. A single Netgraph node of type hci is - created for a single Bluetooth device. The HCI node is normally - connected to the Bluetooth device driver node (downstream) and - the L2CAP node (upstream). All HCI operations must be performed - on the HCI node and not on the device driver node. Default name - for the HCI node is devicehci. - For more details refer to the &man.ng.hci.4; manual page. + created for a single Bluetooth device. The HCI node is + normally connected to the Bluetooth device driver node + (downstream) and the L2CAP node (upstream). All HCI + operations must be performed on the HCI node and not on the + device driver node. Default name for the HCI node is + devicehci. For more details refer to the + &man.ng.hci.4; manual page. - One of the most common tasks is discovery of Bluetooth devices in - RF proximity. This operation is called inquiry. - Inquiry and other HCI related operations are done with the - &man.hccontrol.8; utility. The example below shows how to find out - which Bluetooth devices are in range. You should receive the list of - devices in a few seconds. Note that a remote device will only answer - the inquiry if it put into discoverable - mode. + One of the most common tasks is discovery of Bluetooth + devices in RF proximity. This operation is called + inquiry. Inquiry and other HCI related + operations are done with the &man.hccontrol.8; utility. The + example below shows how to find out which Bluetooth devices + are in range. You should receive the list of devices in a few + seconds. Note that a remote device will only answer the + inquiry if it put into discoverable + mode. &prompt.user; hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 @@ -2352,78 +2396,85 @@ Inquiry result #0 Clock offset: 0x78ef Inquiry complete. Status: No error [00] - BD_ADDR is unique address of a Bluetooth - device, similar to MAC addresses of a network card. This address - is needed for further communication with a device. It is possible - to assign human readable name to a BD_ADDR. - The /etc/bluetooth/hosts file contains information - regarding the known Bluetooth hosts. The following example shows how - to obtain human readable name that was assigned to the remote - device: + BD_ADDR is unique address of a + Bluetooth device, similar to MAC addresses of a network card. + This address is needed for further communication with a + device. It is possible to assign human readable name to a + BD_ADDR. The /etc/bluetooth/hosts file + contains information regarding the known Bluetooth hosts. The + following example shows how to obtain human readable name that + was assigned to the remote device: &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39 - If you perform an inquiry on a remote Bluetooth device, it will - find your computer as your.host.name (ubt0). The name - assigned to the local device can be changed at any time. + If you perform an inquiry on a remote Bluetooth device, it + will find your computer as + your.host.name (ubt0). The name assigned to the + local device can be changed at any time. - The Bluetooth system provides a point-to-point connection (only two - Bluetooth units involved), or a point-to-multipoint connection. In the - point-to-multipoint connection the connection is shared among several - Bluetooth devices. The following example shows how to obtain the list - of active baseband connections for the local device: + The Bluetooth system provides a point-to-point connection + (only two Bluetooth units involved), or a point-to-multipoint + connection. In the point-to-multipoint connection the + connection is shared among several Bluetooth devices. The + following example shows how to obtain the list of active + baseband connections for the local device: &prompt.user; hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN - A connection handle is useful when termination - of the baseband connection is required. Note, that it is normally not - required to do it by hand. The stack will automatically terminate - inactive baseband connections. + A connection handle is useful when + termination of the baseband connection is required. Note, + that it is normally not required to do it by hand. The stack + will automatically terminate inactive baseband + connections. &prompt.root; hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16] - Refer to hccontrol help for a complete listing - of available HCI commands. Most of the HCI commands do not require - superuser privileges. - + Refer to hccontrol help for a complete + listing of available HCI commands. Most of the HCI commands + do not require superuser privileges. L2CAP - Logical Link Control and Adaptation Protocol (L2CAP) + Logical Link Control and Adaptation Protocol + (L2CAP) - Logical Link Control and Adaptation Protocol (L2CAP) provides - connection-oriented and connectionless data services to upper layer - protocols with protocol multiplexing capability and segmentation and - reassembly operation. L2CAP permits higher level protocols and - applications to transmit and receive L2CAP data packets up to 64 - kilobytes in length. + Logical Link Control and Adaptation Protocol (L2CAP) + provides connection-oriented and connectionless data services + to upper layer protocols with protocol multiplexing capability + and segmentation and reassembly operation. L2CAP permits + higher level protocols and applications to transmit and + receive L2CAP data packets up to 64 kilobytes in + length. - L2CAP is based around the concept of channels. - Channel is a logical connection on top of baseband connection. Each - channel is bound to a single protocol in a many-to-one fashion. Multiple - channels can be bound to the same protocol, but a channel cannot be - bound to multiple protocols. Each L2CAP packet received on a channel is - directed to the appropriate higher level protocol. Multiple channels - can share the same baseband connection. + L2CAP is based around the concept of + channels. Channel is a logical + connection on top of baseband connection. Each channel is + bound to a single protocol in a many-to-one fashion. Multiple + channels can be bound to the same protocol, but a channel + cannot be bound to multiple protocols. Each L2CAP packet + received on a channel is directed to the appropriate higher + level protocol. Multiple channels can share the same baseband + connection. - A single Netgraph node of type l2cap is - created for a single Bluetooth device. The L2CAP node is normally - connected to the Bluetooth HCI node (downstream) and Bluetooth sockets - nodes (upstream). Default name for the L2CAP node is - devicel2cap. For more details refer to the - &man.ng.l2cap.4; manual page. + A single Netgraph node of type l2cap + is created for a single Bluetooth device. The L2CAP node is + normally connected to the Bluetooth HCI node (downstream) and + Bluetooth sockets nodes (upstream). Default name for the + L2CAP node is devicel2cap. For more details + refer to the &man.ng.l2cap.4; manual page. - A useful command is &man.l2ping.8;, which can be used to ping - other devices. Some Bluetooth implementations might not return all of - the data sent to them, so 0 bytes in the following - example is normal. + A useful command is &man.l2ping.8;, which can be used to + ping other devices. Some Bluetooth implementations might not + return all of the data sent to them, so + 0 bytes in the following example is + normal. &prompt.root; l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 @@ -2431,10 +2482,10 @@ Reason: Connection terminated by local host [0x16] 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 - The &man.l2control.8; utility is used to perform various operations - on L2CAP nodes. This example shows how to obtain the list of logical - connections (channels) and the list of baseband connections for the - local device: + The &man.l2control.8; utility is used to perform various + operations on L2CAP nodes. This example shows how to obtain + the list of logical connections (channels) and the list of + baseband connections for the local device: &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: @@ -2445,10 +2496,10 @@ L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN - Another diagnostic tool is &man.btsockstat.1;. It does a job - similar to as &man.netstat.1; does, but for Bluetooth network-related - data structures. The example below shows the same logical connection as - &man.l2control.8; above. + Another diagnostic tool is &man.btsockstat.1;. It does a + job similar to as &man.netstat.1; does, but for Bluetooth + network-related data structures. The example below shows the + same logical connection as &man.l2control.8; above. &prompt.user; btsockstat Active L2CAP sockets @@ -2460,60 +2511,65 @@ c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN - RFCOMM RFCOMM Protocol - The RFCOMM protocol provides emulation of serial ports over the - L2CAP protocol. The protocol is based on the ETSI standard TS 07.10. - RFCOMM is a simple transport protocol, with additional provisions for - emulating the 9 circuits of RS-232 (EIATIA-232-E) serial ports. The - RFCOMM protocol supports up to 60 simultaneous connections (RFCOMM - channels) between two Bluetooth devices. + The RFCOMM protocol provides emulation of serial ports + over the L2CAP protocol. The protocol is based on the ETSI + standard TS 07.10. RFCOMM is a simple transport protocol, + with additional provisions for emulating the 9 circuits of + RS-232 (EIATIA-232-E) serial ports. The RFCOMM protocol + supports up to 60 simultaneous connections (RFCOMM channels) + between two Bluetooth devices. - For the purposes of RFCOMM, a complete communication path involves - two applications running on different devices (the communication - endpoints) with a communication segment between them. RFCOMM is intended - to cover applications that make use of the serial ports of the devices - in which they reside. The communication segment is a Bluetooth link from - one device to another (direct connect). + For the purposes of RFCOMM, a complete communication path + involves two applications running on different devices (the + communication endpoints) with a communication segment between + them. RFCOMM is intended to cover applications that make use + of the serial ports of the devices in which they reside. The + communication segment is a Bluetooth link from one device to + another (direct connect). - RFCOMM is only concerned with the connection between the devices in - the direct connect case, or between the device and a modem in the - network case. RFCOMM can support other configurations, such as modules - that communicate via Bluetooth wireless technology on one side and - provide a wired interface on the other side. + RFCOMM is only concerned with the connection between the + devices in the direct connect case, or between the device and + a modem in the network case. RFCOMM can support other + configurations, such as modules that communicate via Bluetooth + wireless technology on one side and provide a wired interface + on the other side. - In &os; the RFCOMM protocol is implemented at the Bluetooth sockets - layer. + In &os; the RFCOMM protocol is implemented at the + Bluetooth sockets layer. pairing Pairing of Devices - By default, Bluetooth communication is not authenticated, and any - device can talk to any other device. A Bluetooth device (for example, - cellular phone) may choose to require authentication to provide a - particular service (for example, Dial-Up service). Bluetooth - authentication is normally done with PIN codes. - A PIN code is an ASCII string up to 16 characters in length. User is - required to enter the same PIN code on both devices. Once user has - entered the PIN code, both devices will generate a - link key. After that the link key can be stored - either in the devices themselves or in a persistent storage. Next time - both devices will use previously generated link key. The described - above procedure is called pairing. Note that if - the link key is lost by any device then pairing must be repeated. + By default, Bluetooth communication is not authenticated, + and any device can talk to any other device. A Bluetooth + device (for example, cellular phone) may choose to require + authentication to provide a particular service (for example, + Dial-Up service). Bluetooth authentication is normally done + with PIN codes. A PIN code is an ASCII + string up to 16 characters in length. User is required to + enter the same PIN code on both devices. Once user has + entered the PIN code, both devices will generate a + link key. After that the link key can be + stored either in the devices themselves or in a persistent + storage. Next time both devices will use previously generated + link key. The described above procedure is called + pairing. Note that if the link key is + lost by any device then pairing must be repeated. - The &man.hcsecd.8; daemon is responsible for handling of all - Bluetooth authentication requests. The default configuration file is - /etc/bluetooth/hcsecd.conf. An example section for - a cellular phone with the PIN code arbitrarily set to - 1234 is shown below: + The &man.hcsecd.8; daemon is responsible for handling of + all Bluetooth authentication requests. The default + configuration file is + /etc/bluetooth/hcsecd.conf. An example + section for a cellular phone with the PIN code arbitrarily set + to 1234 is shown below: device { bdaddr 00:80:37:29:19:a4; @@ -2522,66 +2578,73 @@ c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN - There is no limitation on PIN codes (except length). Some devices - (for example Bluetooth headsets) may have a fixed PIN code built in. - The switch forces the &man.hcsecd.8; daemon to stay - in the foreground, so it is easy to see what is happening. Set the - remote device to receive pairing and initiate the Bluetooth connection - to the remote device. The remote device should say that pairing was - accepted, and request the PIN code. Enter the same PIN code as you - have in hcsecd.conf. Now your PC and the remote - device are paired. Alternatively, you can initiate pairing on the remote - device. + There is no limitation on PIN codes (except length). Some + devices (for example Bluetooth headsets) may have a fixed PIN + code built in. The switch forces the + &man.hcsecd.8; daemon to stay in the foreground, so it is easy + to see what is happening. Set the remote device to receive + pairing and initiate the Bluetooth connection to the remote + device. The remote device should say that pairing was + accepted, and request the PIN code. Enter the same PIN code + as you have in hcsecd.conf. Now your PC + and the remote device are paired. Alternatively, you can + initiate pairing on the remote device. The following line can be added to the /etc/rc.conf file to have - hcsecd started automatically on system - start: + hcsecd started automatically on + system start: hcsecd_enable="YES" The following is a sample of the - hcsecd daemon output: + hcsecd daemon output: -hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 + hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 - SDP + Service Discovery Protocol (SDP) - The Service Discovery Protocol (SDP) provides the means for client - applications to discover the existence of services provided by server - applications as well as the attributes of those services. The attributes - of a service include the type or class of service offered and the - mechanism or protocol information needed to utilize the service. - SDP involves communication between a SDP server and a SDP client. - The server maintains a list of service records that describe the - characteristics of services associated with the server. Each service - record contains information about a single service. A client may - retrieve information from a service record maintained by the SDP server - by issuing a SDP request. If the client, or an application associated - with the client, decides to use a service, it must open a separate - connection to the service provider in order to utilize the service. - SDP provides a mechanism for discovering services and their attributes, - but it does not provide a mechanism for utilizing those services. + The Service Discovery Protocol (SDP) provides the means + for client applications to discover the existence of services + provided by server applications as well as the attributes of + those services. The attributes of a service include the type + or class of service offered and the mechanism or protocol + information needed to utilize the service. - Normally, a SDP client searches for services based on some desired - characteristics of the services. However, there are times when it is - desirable to discover which types of services are described by an SDP - server's service records without any a priori information about the - services. This process of looking for any offered services is called - browsing. - - The Bluetooth SDP server &man.sdpd.8; and command line client - &man.sdpcontrol.8; are included in the standard &os; installation. - The following example shows how to perform a SDP browse query. + SDP involves communication between a SDP server and a SDP + client. The server maintains a list of service records that + describe the characteristics of services associated with the + server. Each service record contains information about a + single service. A client may retrieve information from a + service record maintained by the SDP server by issuing a SDP + request. If the client, or an application associated with the + client, decides to use a service, it must open a separate + connection to the service provider in order to utilize the + service. SDP provides a mechanism for discovering services + and their attributes, but it does not provide a mechanism for + utilizing those services. + + Normally, a SDP client searches for services based on some + desired characteristics of the services. However, there are + times when it is desirable to discover which types of services + are described by an SDP server's service records without any a + priori information about the services. This process of + looking for any offered services is called + browsing. + + The Bluetooth SDP server &man.sdpd.8; and command line + client &man.sdpcontrol.8; are included in the standard &os; + installation. The following example shows how to perform a + SDP browse query. &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse Record Handle: 00000000 @@ -2607,120 +2670,138 @@ Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0 - ... and so on. Note that each service has a list of attributes - (RFCOMM channel for example). Depending on the service you might need to - make a note of some of the attributes. Some Bluetooth implementations do - not support service browsing and may return an empty list. In this case - it is possible to search for the specific service. The example below - shows how to search for the OBEX Object Push (OPUSH) service: + ... and so on. Note that each service has a list of + attributes (RFCOMM channel for example). Depending on the + service you might need to make a note of some of the + attributes. Some Bluetooth implementations do not support + service browsing and may return an empty list. In this case + it is possible to search for the specific service. The + example below shows how to search for the OBEX Object Push + (OPUSH) service: &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH - Offering services on &os; to Bluetooth clients is done with the - &man.sdpd.8; server. The following line can - be added to the /etc/rc.conf file: + Offering services on &os; to Bluetooth clients is done + with the &man.sdpd.8; server. The following line can be added + to the /etc/rc.conf file: sdpd_enable="YES" - Then the sdpd daemon can be started with: + Then the sdpd daemon can be + started with: &prompt.root; /etc/rc.d/sdpd start - The local server application that wants to provide Bluetooth - service to the remote clients will register service with the local - SDP daemon. The example of such application is &man.rfcomm.pppd.8;. - Once started it will register Bluetooth LAN service with the local - SDP daemon. + The local server application that wants to provide + Bluetooth service to the remote clients will register service + with the local SDP daemon. The example of such application is + &man.rfcomm.pppd.8;. Once started it will register Bluetooth + LAN service with the local SDP daemon. - The list of services registered with the local SDP server can be - obtained by issuing SDP browse query via local control channel: + The list of services registered with the local SDP server + can be obtained by issuing SDP browse query via local control + channel: &prompt.root; sdpcontrol -l browse - - Dial-Up Networking (DUN) and Network Access with PPP (LAN) - Profiles + Dial-Up Networking (DUN) and Network Access with PPP + (LAN) Profiles - The Dial-Up Networking (DUN) profile is mostly used with modems - and cellular phones. The scenarios covered by this profile are the - following: + The Dial-Up Networking (DUN) profile is mostly used with + modems and cellular phones. The scenarios covered by this + profile are the following: - use of a cellular phone or modem by a computer as - a wireless modem for connecting to a dial-up Internet access server, - or using other dial-up services; + + use of a cellular phone or modem by a computer as a + wireless modem for connecting to a dial-up Internet access + server, or using other dial-up services; + - use of a cellular phone or modem by a computer to - receive data calls. + + use of a cellular phone or modem by a computer to + receive data calls. + - Network Access with PPP (LAN) profile can be used in the following - situations: + Network Access with PPP (LAN) profile can be used in the + following situations: - LAN access for a single Bluetooth device; - + + LAN access for a single Bluetooth device; + - LAN access for multiple Bluetooth devices; - + + LAN access for multiple Bluetooth devices; + - PC to PC (using PPP networking over serial cable - emulation). + + PC to PC (using PPP networking over serial cable + emulation). + In &os; both profiles are implemented with &man.ppp.8; and - &man.rfcomm.pppd.8; - a wrapper that converts RFCOMM Bluetooth - connection into something PPP can operate with. Before any profile - can be used, a new PPP label in the /etc/ppp/ppp.conf - must be created. Consult &man.rfcomm.pppd.8; manual page for examples. - + &man.rfcomm.pppd.8; - a wrapper that converts RFCOMM Bluetooth + connection into something PPP can operate with. Before any + profile can be used, a new PPP label in the + /etc/ppp/ppp.conf must be created. + Consult &man.rfcomm.pppd.8; manual page for examples. - In the following example &man.rfcomm.pppd.8; will be used to open - RFCOMM connection to remote device with BD_ADDR 00:80:37:29:19:a4 on - DUN RFCOMM channel. The actual RFCOMM channel number will be obtained - from the remote device via SDP. It is possible to specify RFCOMM channel - by hand, and in this case &man.rfcomm.pppd.8; will not perform SDP - query. Use &man.sdpcontrol.8; to find out RFCOMM - channel on the remote device. + In the following example &man.rfcomm.pppd.8; will be used + to open RFCOMM connection to remote device with BD_ADDR + 00:80:37:29:19:a4 on DUN RFCOMM channel. The actual RFCOMM + channel number will be obtained from the remote device via + SDP. It is possible to specify RFCOMM channel by hand, and in + this case &man.rfcomm.pppd.8; will not perform SDP query. Use + &man.sdpcontrol.8; to find out RFCOMM channel on the remote + device. &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup - In order to provide Network Access with PPP (LAN) service the - &man.sdpd.8; server must be running. A new entry for LAN clients must - be created in the /etc/ppp/ppp.conf file. Consult - &man.rfcomm.pppd.8; manual page for examples. Finally, start RFCOMM PPP - server on valid RFCOMM channel number. The RFCOMM PPP server will - automatically register Bluetooth LAN service with the local SDP daemon. - The example below shows how to start RFCOMM PPP server. + In order to provide Network Access with PPP (LAN) service + the &man.sdpd.8; server must be running. A new entry for LAN + clients must be created in the + /etc/ppp/ppp.conf file. Consult + &man.rfcomm.pppd.8; manual page for examples. Finally, start + RFCOMM PPP server on valid RFCOMM channel number. The RFCOMM + PPP server will automatically register Bluetooth LAN service + with the local SDP daemon. The example below shows how to + start RFCOMM PPP server. &prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-server - OBEX + OBEX Object Push (OPUSH) Profile - OBEX is a widely used protocol for simple file transfers between - mobile devices. Its main use is in infrared communication, where it is - used for generic file transfers between notebooks or PDAs, - and for sending business cards or calendar entries between cellular - phones and other devices with PIM applications. - The OBEX server and client are implemented as a third-party package - obexapp, which is available as - comms/obexapp port. + OBEX is a widely used protocol for simple file transfers + between mobile devices. Its main use is in infrared + communication, where it is used for generic file transfers + between notebooks or PDAs, and for sending business cards or + calendar entries between cellular phones and other devices + with PIM applications. - OBEX client is used to push and/or pull objects from the OBEX server. - An object can, for example, be a business card or an appointment. - The OBEX client can obtain RFCOMM channel number from the remote device - via SDP. This can be done by specifying service name instead of RFCOMM - channel number. Supported service names are: IrMC, FTRN and OPUSH. - It is possible to specify RFCOMM channel as a number. Below is an - example of an OBEX session, where device information object is pulled - from the cellular phone, and a new object (business card) is pushed - into the phone's directory. + The OBEX server and client are implemented as a + third-party package obexapp, which + is available as comms/obexapp port. + + OBEX client is used to push and/or pull objects from the + OBEX server. An object can, for example, be a business card + or an appointment. The OBEX client can obtain RFCOMM channel + number from the remote device via SDP. This can be done by + specifying service name instead of RFCOMM channel number. + Supported service names are: IrMC, FTRN and OPUSH. It is + possible to specify RFCOMM channel as a number. Below is an + example of an OBEX session, where device information object is + pulled from the cellular phone, and a new object (business + card) is pushed into the phone's directory. &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get telecom/devinfo.txt devinfo-t39.txt @@ -2730,88 +2811,94 @@ Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20) - In order to provide OBEX Object Push service, - &man.sdpd.8; server must be running. A root folder, where all incoming - objects will be stored, must be created. The default path to the root - folder is /var/spool/obex. Finally, start OBEX - server on valid RFCOMM channel number. The OBEX server will - automatically register OBEX Object Push service with the local SDP - daemon. The example below shows how to start OBEX server. + In order to provide OBEX Object Push service, &man.sdpd.8; + server must be running. A root folder, where all incoming + objects will be stored, must be created. The default path to + the root folder is /var/spool/obex. + Finally, start OBEX server on valid RFCOMM channel number. + The OBEX server will automatically register OBEX Object Push + service with the local SDP daemon. The example below shows + how to start OBEX server. &prompt.root; obexapp -s -C 10 Serial Port Profile (SPP) - The Serial Port Profile (SPP) allows Bluetooth devices to perform - RS232 (or similar) serial cable emulation. The scenario covered by this - profile deals with legacy applications using Bluetooth as a cable - replacement, through a virtual serial port abstraction. - The &man.rfcomm.sppd.1; utility implements the Serial Port profile. - A pseudo tty is used as a virtual serial port abstraction. The example - below shows how to connect to a remote device Serial Port service. - Note that you do not have to specify a RFCOMM channel - - &man.rfcomm.sppd.1; can obtain it from the remote device via SDP. - If you would like to override this, specify a RFCOMM channel on the - command line. + The Serial Port Profile (SPP) allows Bluetooth devices to + perform RS232 (or similar) serial cable emulation. The + scenario covered by this profile deals with legacy + applications using Bluetooth as a cable replacement, through a + virtual serial port abstraction. + + The &man.rfcomm.sppd.1; utility implements the Serial Port + profile. A pseudo tty is used as a virtual serial port + abstraction. The example below shows how to connect to a + remote device Serial Port service. Note that you do not have + to specify a RFCOMM channel - &man.rfcomm.sppd.1; can obtain + it from the remote device via SDP. If you would like to + override this, specify a RFCOMM channel on the command + line. &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... - Once connected, the pseudo tty can be used as serial port: + Once connected, the pseudo tty can be used as serial + port: &prompt.root; cu -l ttyp6 - Troubleshooting - A Remote Device Cannot Connect - Some older Bluetooth devices do not support role switching. - By default, when &os; is accepting a new connection, it tries to - perform a role switch and become master. Devices, which do not - support this will not be able to connect. Note that role switching is - performed when a new connection is being established, so it is not - possible to ask the remote device if it does support role switching. - There is a HCI option to disable role switching on the local - side: + A Remote Device Cannot Connect + + Some older Bluetooth devices do not support role + switching. By default, when &os; is accepting a new + connection, it tries to perform a role switch and become + master. Devices, which do not support this will not be able + to connect. Note that role switching is performed when a + new connection is being established, so it is not possible + to ask the remote device if it does support role switching. + There is a HCI option to disable role switching on the local + side: &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 - - Something is Going Wrong, Can I See What Exactly is Happening? - Yes, you can. Use the third-party package - hcidump, which is available as - comms/hcidump port. - The hcidump utility is similar to - &man.tcpdump.1;. It can be used to display the content of the Bluetooth - packets on the terminal and to dump the Bluetooth packets to a - file. + Something is Going Wrong, Can I See What Exactly is + Happening? + + Yes, you can. Use the third-party package + hcidump, which is available as + comms/hcidump port. The + hcidump utility is similar to + &man.tcpdump.1;. It can be used to display the content of + the Bluetooth packets on the terminal and to dump the + Bluetooth packets to a file. - - - + Andrew Thompson Written by - + Bridging Introduction + IP subnet bridge It is sometimes useful to divide one physical network @@ -2823,12 +2910,13 @@ rfcomm_sppd[94692]: Starting on /dev/ttyp6... interface cards can act as a bridge. The bridge works by learning the MAC layer addresses - (Ethernet addresses) of the devices on each of its network interfaces. - It forwards traffic between two networks only when its source and - destination are on different networks. + (Ethernet addresses) of the devices on each of its network + interfaces. It forwards traffic between two networks only + when its source and destination are on different + networks. - In many respects, a bridge is like an Ethernet switch with very - few ports. + In many respects, a bridge is like an Ethernet switch with + very few ports. @@ -2851,11 +2939,13 @@ rfcomm_sppd[94692]: Starting on /dev/ttyp6... Filtering/Traffic Shaping Firewall + firewall NAT A common situation is where firewall functionality is - needed without routing or network address translation (NAT). + needed without routing or network address translation + (NAT). An example is a small company that is connected via DSL or ISDN to their ISP. They have a 13 globally-accessible IP @@ -2866,17 +2956,17 @@ rfcomm_sppd[94692]: Starting on /dev/ttyp6... router DSL ISDN - A bridge-based firewall can be configured and dropped into the - path just downstream of their DSL/ISDN router without any IP - numbering issues. + A bridge-based firewall can be configured and dropped + into the path just downstream of their DSL/ISDN router + without any IP numbering issues. Network Tap A bridge can join two network segments and be used to - inspect all Ethernet frames that pass between them. This can - either be from using &man.bpf.4;/&man.tcpdump.1; on the + inspect all Ethernet frames that pass between them. This + can either be from using &man.bpf.4;/&man.tcpdump.1; on the bridge interface or by sending a copy of all frames out an additional interface (span port). @@ -2982,6 +3072,7 @@ ifconfig_fxp1="up" Firewalling + firewall When packet filtering is enabled, bridged packets will @@ -3051,7 +3142,7 @@ bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1 role designated state forwarding The line root id 00:01:02:4b:d4:50 priority 32768 - ifcost 400000 port 4 shows that the root bridge is + ifcost 400000 port 4 shows that the root bridge is 00:01:02:4b:d4:50 as above and has a path cost of 400000 from this bridge, the path to the root bridge is via port 4 which is @@ -3111,21 +3202,21 @@ bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1 Sticky Interfaces If a bridge member interface is marked as sticky then - dynamically learned address entries are treated at static once - entered into the forwarding cache. Sticky entries are never - aged out of the cache or replaced, even if the address is seen - on a different interface. This gives the benefit of static - address entries without the need to pre-populate the + dynamically learned address entries are treated at static + once entered into the forwarding cache. Sticky entries are + never aged out of the cache or replaced, even if the address + is seen on a different interface. This gives the benefit of + static address entries without the need to pre-populate the forwarding table, clients learnt on a particular segment of the bridge can not roam to another segment. Another example of using sticky addresses would be to combine the bridge with VLANs to create a router where customer networks are isolated without wasting IP address - space. Consider that CustomerA is on - vlan100 and CustomerB is on + space. Consider that + CustomerA is on + vlan100 and + CustomerB is on vlan101. The bridge has the address 192.168.0.1 and is also an internet router. @@ -3133,11 +3224,11 @@ bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1 &prompt.root; ifconfig bridge0 addm vlan100 sticky vlan100 addm vlan101 sticky vlan101 &prompt.root; ifconfig bridge0 inet 192.168.0.1/24 - Both clients see 192.168.0.1 as their default gateway - and since the bridge cache is sticky they can not spoof the - MAC address of the other customer to intercept their - traffic. + Both clients see + 192.168.0.1 as their default + gateway and since the bridge cache is sticky they can not + spoof the MAC address of the other customer to intercept + their traffic. Any communication between the VLANs can be blocked using private interfaces (or a firewall): @@ -3157,8 +3248,9 @@ bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1 with unknown source addresses are dropped until an existing host cache entry expires or is removed. - The following example sets the maximum number of Ethernet - devices for CustomerA on + The following example sets the maximum number of + Ethernet devices for + CustomerA on vlan100 to 10. &prompt.root; ifconfig bridge0 ifmaxaddr vlan100 10 @@ -3175,19 +3267,19 @@ bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1 On the bridge machine uncomment the begemotSnmpdModulePath."bridge" = - "/usr/lib/snmp_bridge.so" line from + "/usr/lib/snmp_bridge.so" line from /etc/snmp.config and start the - bsnmpd daemon. Other + bsnmpd daemon. Other configuration such as community names and access lists may need to be modified. See &man.bsnmpd.1; and &man.snmp.bridge.3; for more information. The following examples use the - Net-SNMP software (net-mgmt/net-snmp) to query a - bridge, the net-mgmt/bsnmptools port can also - be used. From the SNMP client host add to + Net-SNMP software + (net-mgmt/net-snmp) to + query a bridge, the + net-mgmt/bsnmptools port + can also be used. From the SNMP client host add to $HOME/.snmp/snmp.conf the following lines to import the bridge MIB definitions in to Net-SNMP: @@ -3254,11 +3346,11 @@ BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2 - + Andrew Thompson Written by - + Link Aggregation and Failover @@ -3272,80 +3364,86 @@ BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2 Introduction - The &man.lagg.4; interface allows aggregation of multiple network - interfaces as one virtual interface for the purpose of providing - fault-tolerance and high-speed links. + + The &man.lagg.4; interface allows aggregation of multiple + network interfaces as one virtual interface for the purpose of + providing fault-tolerance and high-speed links. Operating Modes - - Failover - - - Sends and receives traffic only through the master port. If the - master port becomes unavailable, the next active port is used. The - first interface added is the master port; any interfaces added after - that are used as failover devices. If failover to a non-master port - occurs, the original port will become master when it becomes - available again. - - - - &cisco; Fast ðerchannel; - - - &cisco; Fast ðerchannel; (FEC), is a static setup and does not - negotiate aggregation with the peer or exchange frames to monitor the - link. If the switch supports LACP then that should be used - instead. - - FEC balances outgoing traffic across the active ports based on hashed - protocol header information and accepts incoming traffic from any - active port. The hash includes the Ethernet source and destination - address, and, if available, the VLAN tag, and the IPv4/IPv6 source - and destination address. - + + Failover + + Sends and receives traffic only through the master + port. If the master port becomes unavailable, the next + active port is used. The first interface added is the + master port; any interfaces added after that are used as + failover devices. If failover to a non-master port + occurs, the original port will become master when it + becomes available again. + - LACP + + &cisco; Fast ðerchannel; + + &cisco; Fast ðerchannel; (FEC), is a static setup + and does not negotiate aggregation with the peer or + exchange frames to monitor the link. If the switch + supports LACP then that should be used instead. - - The &ieee; 802.3ad Link Aggregation Control Protocol - (LACP) and the Marker Protocol. LACP will negotiate a set of - aggregable links with the peer in to one or more Link Aggregated - Groups (LAG). Each LAG is composed of ports of the same speed, set to - full-duplex operation. The traffic will be balanced across the ports - in the LAG with the greatest total speed, in most cases there will - only be one LAG which contains all ports. In the event of changes in - physical connectivity, Link Aggregation will quickly converge to a - new configuration. - - LACP balances outgoing traffic across the active ports based on hashed - protocol header information and accepts incoming traffic from any - active port. The hash includes the Ethernet source and destination - address, and, if available, the VLAN tag, and the IPv4/IPv6 source - and destination address. - + FEC balances outgoing traffic + across the active ports based on hashed protocol header + information and accepts incoming traffic from any active + port. The hash includes the Ethernet source and + destination address, and, if available, the VLAN tag, + and the IPv4/IPv6 source and destination address. + - Loadbalance + + LACP + + The &ieee; 802.3ad Link Aggregation Control Protocol + (LACP) and the Marker Protocol. LACP will negotiate a + set of aggregable links with the peer in to one or more + Link Aggregated Groups (LAG). Each LAG is composed of + ports of the same speed, set to full-duplex operation. + The traffic will be balanced across the ports in the LAG + with the greatest total speed, in most cases there will + only be one LAG which contains all ports. In the event + of changes in physical connectivity, Link Aggregation + will quickly converge to a new configuration. - - This is an alias of FEC mode. - - + LACP balances outgoing traffic + across the active ports based on hashed protocol header + information and accepts incoming traffic from any active + port. The hash includes the Ethernet source and + destination address, and, if available, the VLAN tag, + and the IPv4/IPv6 source and destination address. + + - Round-robin + + Loadbalance + + This is an alias of FEC + mode. + + - - Distributes outgoing traffic using a round-robin scheduler - through all active ports and accepts incoming traffic from any active - port. This mode violates Ethernet Frame ordering and should be - used with caution. - + + Round-robin + + Distributes outgoing traffic using a round-robin + scheduler through all active ports and accepts incoming + traffic from any active port. This mode violates + Ethernet Frame ordering and should be used with + caution. + @@ -3356,14 +3454,16 @@ BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2 LACP Aggregation with a &cisco; Switch - This example connects two interfaces on a &os; machine to the - switch as a single load balanced and fault tolerant link. More interfaces - can be added to increase throughput and fault tolerance. Since frame - ordering is mandatory on Ethernet links then any traffic between two - stations always flows over the same physical link limiting the maximum - speed to that of one interface. The transmit algorithm attempts to use as - much information as it can to distinguish different traffic flows and - balance across the available interfaces. + This example connects two interfaces on a &os; machine + to the switch as a single load balanced and fault tolerant + link. More interfaces can be added to increase throughput + and fault tolerance. Since frame ordering is mandatory on + Ethernet links then any traffic between two stations always + flows over the same physical link limiting the maximum speed + to that of one interface. The transmit algorithm attempts + to use as much information as it can to distinguish + different traffic flows and balance across the available + interfaces. On the &cisco; switch add the FastEthernet0/1 and @@ -3379,8 +3479,9 @@ BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2 channel-protocol lacp Create the &man.lagg.4; interface using - fxp0 and fxp1, - and bring the interfaces up with the IP Address of + fxp0 and + fxp1, and bring the interfaces up + with the IP Address of 10.0.0.3/24: &prompt.root; ifconfig fxp0 up @@ -3389,14 +3490,14 @@ BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2 &prompt.root; ifconfig lagg0 up laggproto lacp laggport fxp0 laggport fxp1 10.0.0.3/24 View the interface status by running: - + &prompt.root; ifconfig lagg0 - - Ports marked as - ACTIVE are part of the active aggregation group - that has been negotiated with the remote switch and traffic will be - transmitted and received. Use the verbose output of &man.ifconfig.8; - to view the LAG identifiers. + + Ports marked as ACTIVE are part of + the active aggregation group that has been negotiated with + the remote switch and traffic will be transmitted and + received. Use the verbose output of &man.ifconfig.8; to + view the LAG identifiers. lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8<VLAN_MTU> @@ -3407,8 +3508,8 @@ BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2 laggport: fxp1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> laggport: fxp0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING> - To see the port status on the switch, use show - lacp neighbor: + To see the port status on the switch, use + show lacp neighbor: switch# show lacp neighbor Flags: S - Device is requesting Slow LACPDUs @@ -3427,8 +3528,9 @@ Fa0/2 SA 32768 0005.5d71.8db8 29s 0x146 0x4 0x3DFor more detail use the show lacp neighbor detail command. - To retain this configuration across reboots, the following - entries can be added to /etc/rc.conf: + To retain this configuration across reboots, the + following entries can be added to + /etc/rc.conf: ifconfig_fxp0="up" ifconfig_fxp1="up" @@ -3436,15 +3538,18 @@ cloned_interfaces="lagg0" ifconfig_lagg0="laggproto lacp laggport fxp0 laggport fxp1 10.0.0.3/24" + Failover Mode - Failover mode can be used to switch over to a secondary interface if - the link is lost on the master interface. Bring the underlying - physical interfaces up. Create the &man.lagg.4; interface, using + Failover mode can be used to switch over to a secondary + interface if the link is lost on the master interface. + Bring the underlying physical interfaces up. Create the + &man.lagg.4; interface, using fxp0 as the master interface and - fxp1 as the secondary interface and assign - an IP Address of 10.0.0.15/24: + fxp1 as the secondary interface + and assign an IP Address of + 10.0.0.15/24: &prompt.root; ifconfig fxp0 up &prompt.root; ifconfig fxp1 up @@ -3452,8 +3557,8 @@ ifconfig_lagg0="laggproto lacp lag &prompt.root; ifconfig lagg0 up laggproto failover laggport fxp0 laggport fxp1 10.0.0.15/24 The interface will look something like this, the major - differences will be the MAC address and the - device names: + differences will be the MAC address and + the device names: &prompt.root; ifconfig lagg0 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 @@ -3468,12 +3573,14 @@ lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 150 Traffic will be transmitted and received on fxp0. If the link is lost on - fxp0 then fxp1 will - become the active link. If the link is restored on the master - interface then it will once again become the active link. + fxp0 then + fxp1 will become the active link. + If the link is restored on the master interface then it will + once again become the active link. - To retain this configuration across reboots, the following - entries can be added to /etc/rc.conf: + To retain this configuration across reboots, the + following entries can be added to + /etc/rc.conf: ifconfig_fxp0="up" ifconfig_fxp1="up" @@ -3481,29 +3588,33 @@ cloned_interfaces="lagg0" ifconfig_lagg0="laggproto failover laggport fxp0 laggport fxp1 10.0.0.15/24" - - Failover Mode Between Wired and Wireless Interfaces - For laptop users, it is usually desirable to make wireless as a - secondary interface, which is to be used when the wired connection - is not available. With &man.lagg.4;, it is possible to use one - IP address, prefer the wired connection for both performance and - security reasons, while maintaining the ability to transfer data - over the wireless connection. + + Failover Mode Between Wired and Wireless + Interfaces + + For laptop users, it is usually desirable to make + wireless as a secondary interface, which is to be used when + the wired connection is not available. With &man.lagg.4;, + it is possible to use one IP address, prefer the wired + connection for both performance and security reasons, while + maintaining the ability to transfer data over the wireless + connection. In this setup, we will need to override the underlying - wireless interface's MAC address to match the &man.lagg.4;'s, - which is inherited from the master interface being used, the - wired interface. + wireless interface's MAC address to match + the &man.lagg.4;'s, which is inherited from the master + interface being used, the wired interface. In this setup, we will treat the wired interface, - bge0, as the master, and the wireless - interface, - wlan0, as the failover interface. The - wlan0 was created from - iwn0 which we will set up with - the wired connection's MAC address. The first step would be - to obtain the MAC address from the wired interface: + bge0, as the master, and the + wireless interface, wlan0, as the + failover interface. The wlan0 + was created from iwn0 which we + will set up with the wired connection's + MAC address. The first step would be to + obtain the MAC address from the wired + interface: &prompt.root; ifconfig bge0 bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 @@ -3514,10 +3625,11 @@ bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 media: Ethernet autoselect (1000baseT <full-duplex>) status: active - You can replace the bge0 to match - your reality, and will get a different ether - line which is the MAC address of your wired interface. Now, - we change the underlying wireless interface, + You can replace the bge0 to + match your reality, and will get a different + ether line which is the + MAC address of your wired interface. + Now, we change the underlying wireless interface, iwn0: &prompt.root; ifconfig iwn0 ether 00:21:70:da:ae:37 @@ -3527,18 +3639,18 @@ bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 &prompt.root; ifconfig wlan0 create wlandev iwn0 ssid my_router up - Bring the bge0 interface up. Create - the &man.lagg.4; interface with bge0 - as master, and failover to wlan0 if - necessary: + Bring the bge0 interface up. + Create the &man.lagg.4; interface with + bge0 as master, and failover to + wlan0 if necessary: &prompt.root; ifconfig bge0 up &prompt.root; ifconfig lagg0 create &prompt.root; ifconfig lagg0 up laggproto failover laggport bge0 laggport wlan0 The interface will look something like this, the major - differences will be the MAC address and the - device names: + differences will be the MAC address and + the device names: &prompt.root; ifconfig lagg0 lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 @@ -3550,12 +3662,14 @@ lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 150 laggport: wlan0 flags=0<> laggport: bge0 flags=5<MASTER,ACTIVE> - Then start the DHCP client to obtain an IP address: + Then start the DHCP client to obtain an IP + address: &prompt.root; dhclient lagg0 - To retain this configuration across reboots, the following - entries can be added to /etc/rc.conf: + To retain this configuration across reboots, the + following entries can be added to + /etc/rc.conf: ifconfig_bge0="up" ifconfig_iwn0="ether 00:21:70:da:ae:37" @@ -3571,11 +3685,11 @@ ifconfig_lagg0="laggproto failover - - Jean-François - Dockès - Updated by - + + Jean-François + Dockès + Updated by + @@ -3590,104 +3704,116 @@ ifconfig_lagg0="laggproto failover diskless workstation diskless operation - A FreeBSD machine can boot over the network and operate without a - local disk, using file systems mounted from an NFS server. No system - modification is necessary, beyond standard configuration files. - Such a system is relatively easy to set up because all the necessary elements + A FreeBSD machine can boot over the network and operate + without a local disk, using file systems mounted from an + NFS server. No system modification is + necessary, beyond standard configuration files. Such a system + is relatively easy to set up because all the necessary elements are readily available: + - There are at least two possible methods to load the kernel over - the network: + There are at least two possible methods to load the + kernel over the network: + - PXE: The &intel; Preboot eXecution - Environment system is a form of smart boot ROM built into some - networking cards or motherboards. See &man.pxeboot.8; for more - details. + PXE: The &intel; Preboot + eXecution Environment system is a form of smart boot ROM + built into some networking cards or motherboards. See + &man.pxeboot.8; for more details. + - The Etherboot - port (net/etherboot) produces - ROM-able code to boot kernels over the network. The - code can be either burnt into a boot PROM on a network - card, or loaded from a local floppy (or hard) disk - drive, or from a running &ms-dos; system. Many network - cards are supported. + The Etherboot port + (net/etherboot) + produces ROM-able code to boot kernels over the network. + The code can be either burnt into a boot PROM on a + network card, or loaded from a local floppy (or hard) + disk drive, or from a running &ms-dos; system. Many + network cards are supported. - + A sample script - (/usr/share/examples/diskless/clone_root) eases - the creation and maintenance of the workstation's root file system - on the server. The script will probably require a little - customization but it will get you started very quickly. + (/usr/share/examples/diskless/clone_root) + eases the creation and maintenance of the workstation's root + file system on the server. The script will probably require + a little customization but it will get you started very + quickly. - Standard system startup files exist in /etc - to detect and support a diskless system startup. + Standard system startup files exist in + /etc to detect and support a diskless + system startup. - Swapping, if needed, can be done either to an NFS file or to - a local disk. + Swapping, if needed, can be done either to an + NFS file or to a local disk. There are many ways to set up diskless workstations. Many elements are involved, and most can be customized to suit local - taste. The following will describe variations on the setup of a complete system, - emphasizing simplicity and compatibility with the - standard FreeBSD startup scripts. The system described has the - following characteristics: + taste. The following will describe variations on the setup of a + complete system, emphasizing simplicity and compatibility with + the standard FreeBSD startup scripts. The system described has + the following characteristics: - The diskless workstations use a shared - read-only / file system, and a shared + The diskless workstations use a shared read-only + / file system, and a shared read-only /usr. - The root file system is a copy of a - standard FreeBSD root (typically the server's), with some - configuration files overridden by ones specific to diskless - operation or, possibly, to the workstation they belong to. - The parts of the root which have to be - writable are overlaid with &man.md.4; file systems. Any changes - will be lost when the system reboots. + + The root file system is a copy of a standard FreeBSD + root (typically the server's), with some configuration files + overridden by ones specific to diskless operation or, + possibly, to the workstation they belong to. + + The parts of the root which have to be writable are + overlaid with &man.md.4; file systems. Any changes will be + lost when the system reboots. + The kernel is transferred and loaded either with - Etherboot or PXE - as some situations may mandate the use of either method. + Etherboot or + PXE as some situations may mandate the + use of either method. - As described, this system is insecure. It should - live in a protected area of a network, and be untrusted by - other hosts. + + As described, this system is insecure. It should live in + a protected area of a network, and be untrusted by other + hosts. - All the information in this section has been tested - using &os; 5.2.1-RELEASE. + All the information in this section has been tested using + &os; 5.2.1-RELEASE. Background Information Setting up diskless workstations is both relatively straightforward and prone to errors. These are sometimes - difficult to diagnose for a number of reasons. For example: + difficult to diagnose for a number of reasons. For + example: - Compile time options may determine different behaviors at - runtime. + Compile time options may determine different behaviors + at runtime. - Error messages are often cryptic or totally absent. + Error messages are often cryptic or totally + absent. @@ -3697,70 +3823,79 @@ ifconfig_lagg0="laggproto failover Several operations need to be performed for a successful bootstrap: - + - The machine needs to obtain initial parameters such as its IP - address, executable filename, server name, root path. This is - done using the DHCP or BOOTP protocols. - DHCP is a compatible extension of BOOTP, and - uses the same port numbers and basic packet format. + The machine needs to obtain initial parameters such as + its IP address, executable filename, server name, root + path. This is done using the DHCP or + BOOTP protocols. DHCP is a compatible + extension of BOOTP, and uses the same port numbers and + basic packet format. - It is possible to configure a system to use only BOOTP. - The &man.bootpd.8; server program is included in the base &os; - system. + It is possible to configure a system to use only + BOOTP. The &man.bootpd.8; server program is included in + the base &os; system. - However, DHCP has a number of advantages - over BOOTP (nicer configuration files, possibility of using - PXE, plus many others not directly related to - diskless operation), and we will describe mainly a - DHCP configuration, with equivalent examples - using &man.bootpd.8; when possible. The sample configuration will - use the ISC DHCP software package - (release 3.0.1.r12 was installed on the test server). + However, DHCP has a number of + advantages over BOOTP (nicer configuration files, + possibility of using PXE, plus many + others not directly related to diskless operation), and we + will describe mainly a DHCP + configuration, with equivalent examples using + &man.bootpd.8; when possible. The sample configuration + will use the ISC DHCP software + package (release 3.0.1.r12 was installed on the test + server). - The machine needs to transfer one or several programs to local - memory. Either TFTP or NFS - are used. The choice between TFTP and - NFS is a compile time option in several places. - A common source of error is to specify filenames for the wrong - protocol: TFTP typically transfers all files from - a single directory on the server, and would expect filenames - relative to this directory. NFS needs absolute - file paths. + The machine needs to transfer one or several programs + to local memory. Either TFTP or + NFS are used. The choice between + TFTP and NFS is a + compile time option in several places. A common source of + error is to specify filenames for the wrong protocol: + TFTP typically transfers all files from + a single directory on the server, and would expect + filenames relative to this directory. + NFS needs absolute file paths. - The possible intermediate bootstrap programs and the kernel - need to be initialized and executed. There are several important - variations in this area: + The possible intermediate bootstrap programs and the + kernel need to be initialized and executed. There are + several important variations in this area: - PXE will load &man.pxeboot.8;, which is - a modified version of the &os; third stage loader. The - &man.loader.8; will obtain most parameters necessary to system - startup, and leave them in the kernel environment before - transferring control. It is possible to use a - GENERIC kernel in this case. + + PXE will load &man.pxeboot.8;, + which is a modified version of the &os; third stage + loader. The &man.loader.8; will obtain most + parameters necessary to system startup, and leave them + in the kernel environment before transferring control. + It is possible to use a GENERIC + kernel in this case. - Etherboot, will directly - load the kernel, with less preparation. You will need to - build a kernel with specific options. + Etherboot, will + directly load the kernel, with less preparation. You + will need to build a kernel with specific + options. - PXE and Etherboot - work equally well; however, because kernels - normally let the &man.loader.8; do more work for them, - PXE is the preferred method. + PXE and + Etherboot work equally well; + however, because kernels normally let the &man.loader.8; + do more work for them, PXE is the + preferred method. - If your BIOS and network cards support - PXE, you should probably use it. + If your BIOS and network cards + support PXE, you should probably use + it. @@ -3776,29 +3911,33 @@ ifconfig_lagg0="laggproto failover Setup Instructions - Configuration Using <application>ISC DHCP</application> - - DHCP - diskless operation - + Configuration Using <application>ISC + DHCP</application> - The ISC DHCP server can answer - both BOOTP and DHCP requests. + + DHCP + diskless operation + - ISC DHCP - 4.2 is not part of the base - system. You will first need to install the - net/isc-dhcp42-server port or the - corresponding package. + The ISC DHCP server can + answer both BOOTP and DHCP + requests. - Once ISC DHCP is installed, it - needs a configuration file to run (normally named - /usr/local/etc/dhcpd.conf). Here follows - a commented example, where host margaux - uses Etherboot and host - corbieres uses PXE: + ISC DHCP 4.2 is not part of + the base system. You will first need to install the + net/isc-dhcp42-server + port or the corresponding package. - + Once ISC DHCP is installed, + it needs a configuration file to run (normally named + /usr/local/etc/dhcpd.conf). Here + follows a commented example, where host + margaux uses + Etherboot and host + corbieres uses + PXE: + + default-lease-time 600; max-lease-time 7200; authoritative; @@ -3829,75 +3968,84 @@ subnet 192.168.4.0 netmask 255.255.255.0 { } - - This option tells - dhcpd to send the value in the - host declarations as the hostname for the - diskless host. An alternate way would be to add an - option host-name - margaux inside the - host declarations. - + + + This option tells dhcpd + to send the value in the host + declarations as the hostname for the diskless host. + An alternate way would be to add an option + host-name + margaux inside + the host declarations. + - The - next-server directive designates - the TFTP or NFS server to - use for loading loader or kernel file (the default is to use - the same host as the - DHCP server). - + + The next-server directive + designates the TFTP or + NFS server to use for loading + loader or kernel file (the default is to use the same + host as the DHCP server). + - The - filename directive defines the file that - Etherboot or PXE - will load for the next execution step. It must be specified - according to the transfer method used. - Etherboot can be compiled to use - NFS or TFTP. The &os; - port configures NFS by default. - PXE uses TFTP, which is - why a relative filename is used here (this may depend on the - TFTP server configuration, but would be - fairly typical). Also, PXE loads - pxeboot, not the kernel. There are other - interesting possibilities, like loading - pxeboot from a &os; CD-ROM - /boot directory (as - &man.pxeboot.8; can load a GENERIC kernel, - this makes it possible to use PXE to boot - from a remote CD-ROM). - - - The - root-path option defines the path to - the root file system, in usual NFS notation. - When using PXE, it is possible to leave off - the host's IP as long as you do not enable the kernel option - BOOTP. The NFS server will then be - the same as the TFTP one. - - + + The filename directive + defines the file that + Etherboot or + PXE will load for the next execution + step. It must be specified according to the transfer + method used. Etherboot can + be compiled to use NFS or + TFTP. The &os; port configures + NFS by default. + PXE uses TFTP, + which is why a relative filename is used here (this may + depend on the TFTP server + configuration, but would be fairly typical). Also, + PXE loads + pxeboot, not the kernel. There are + other interesting possibilities, like loading + pxeboot from a &os; CD-ROM + /boot directory + (as &man.pxeboot.8; can load a + GENERIC kernel, this makes it + possible to use PXE to boot from a + remote CD-ROM). + + + The root-path option defines + the path to the root file system, in usual + NFS notation. When using + PXE, it is possible to leave off the + host's IP as long as you do not enable the kernel option + BOOTP. The NFS server will then be + the same as the TFTP one. + + + - Configuration Using BOOTP - - BOOTP - diskless operation - + Configuration Using BOOTP - Here follows an equivalent bootpd - configuration (reduced to one client). This would be found in - /etc/bootptab. + + BOOTP + diskless operation + - Please note that Etherboot - must be compiled with the non-default option - NO_DHCP_SUPPORT in order to use BOOTP, - and that PXE needs DHCP. The only - obvious advantage of bootpd is - that it exists in the base system. + Here follows an equivalent + bootpd configuration (reduced to + one client). This would be found in + /etc/bootptab. - + Please note that Etherboot + must be compiled with the non-default option + NO_DHCP_SUPPORT in order to use BOOTP, + and that PXE needs + DHCP. The only obvious advantage of + bootpd is that it exists in the + base system. + + .def100:\ :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ :sm=255.255.255.0:\ @@ -3919,69 +4067,76 @@ margaux:ha=0123456789ab:tc=.def100 Etherboot - Etherboot's Web - site contains - - extensive documentation mainly intended for Linux + Etherboot's Web + site contains + extensive documentation mainly intended for Linux systems, but nonetheless containing useful information. The following will just outline how you would use Etherboot on a FreeBSD system. - You must first install the net/etherboot package or port. + You must first install the + net/etherboot package or + port. You can change the Etherboot - configuration (i.e., to use TFTP instead of - NFS) by editing the Config - file in the Etherboot source + configuration (i.e., to use TFTP instead + of NFS) by editing the + Config file in the + Etherboot source directory. - For our setup, we shall use a boot floppy. For other methods - (PROM, or &ms-dos; program), please refer to the + For our setup, we shall use a boot floppy. For other + methods (PROM, or &ms-dos; program), please refer to the Etherboot documentation. - To make a boot floppy, insert a floppy in the drive on the - machine where you installed Etherboot, - then change your current directory to the src - directory in the Etherboot tree and + To make a boot floppy, insert a floppy in the drive on + the machine where you installed + Etherboot, then change your + current directory to the src directory + in the Etherboot tree and type: &prompt.root; gmake bin32/devicetype.fd0 - devicetype depends on the type of - the Ethernet card in the diskless workstation. Refer to the - NIC file in the same directory to determine the - right devicetype. - + devicetype depends on the + type of the Ethernet card in the diskless workstation. + Refer to the NIC file in the same + directory to determine the right + devicetype. Booting with <acronym>PXE</acronym> - By default, the &man.pxeboot.8; loader loads the kernel via - NFS. It can be compiled to use + By default, the &man.pxeboot.8; loader loads the kernel + via NFS. It can be compiled to use TFTP instead by specifying the LOADER_TFTP_SUPPORT option in /etc/make.conf. See the comments in - /usr/share/examples/etc/make.conf - for instructions. + /usr/share/examples/etc/make.conf for + instructions. There are two other make.conf - options which may be useful for setting up a serial console diskless - machine: BOOT_PXELDR_PROBE_KEYBOARD, and + options which may be useful for setting up a serial console + diskless machine: + BOOT_PXELDR_PROBE_KEYBOARD, and BOOT_PXELDR_ALWAYS_SERIAL. - To use PXE when the machine starts, you will - usually need to select the Boot from network - option in your BIOS setup, or type a function key - during the PC initialization. + To use PXE when the machine starts, + you will usually need to select the Boot from + network option in your BIOS + setup, or type a function key during the PC + initialization. - Configuring the <acronym>TFTP</acronym> and <acronym>NFS</acronym> Servers + Configuring the <acronym>TFTP</acronym> and + <acronym>NFS</acronym> Servers TFTP @@ -3996,65 +4151,79 @@ margaux:ha=0123456789ab:tc=.def100 Etherboot configured to use TFTP, you need to enable tftpd on the file server: - - - Create a directory from which tftpd - will serve the files, e.g., /tftpboot. - - - Add this line to your + + + Create a directory from which + tftpd will serve the files, + e.g., /tftpboot. + + + + Add this line to your /etc/inetd.conf: tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot - It appears that at least some PXE versions want - the TCP version of TFTP. In this case, add a second line, - replacing dgram udp with stream - tcp. + + It appears that at least some + PXE versions want the + TCP version of + TFTP. In this case, add a second + line, replacing dgram udp with + stream tcp. - + + - Tell inetd to reread its configuration - file. The must be in - the /etc/rc.conf file for this - command to execute correctly: + Tell inetd to reread its + configuration file. The + must be in the + /etc/rc.conf file for this command + to execute correctly: + &prompt.root; /etc/rc.d/inetd restart - + You can place the tftpboot directory anywhere on the server. Make sure that the location is set in both inetd.conf and dhcpd.conf. - In all cases, you also need to enable NFS and export the - appropriate file system on the NFS server. + In all cases, you also need to enable + NFS and export the appropriate file + system on the NFS server. + + + + Add this to + /etc/rc.conf: - - - Add this to /etc/rc.conf: nfs_server_enable="YES" - + - - Export the file system where the diskless root directory - is located by adding the following to - /etc/exports (adjust the volume mount - point and replace margaux corbieres - with the names of the diskless workstations): + + Export the file system where the diskless root + directory is located by adding the following to + /etc/exports (adjust the volume + mount point and replace margaux + corbieres with the names of the diskless + workstations): /data/misc -alldirs -ro margaux corbieres - + + - Tell mountd to reread its configuration - file. If you actually needed to enable NFS in - /etc/rc.conf - at the first step, you probably want to reboot instead. + Tell mountd to reread its + configuration file. If you actually needed to enable + NFS in + /etc/rc.conf at the first step, you + probably want to reboot instead. + &prompt.root; /etc/rc.d/mountd restart - - + @@ -4065,9 +4234,10 @@ margaux:ha=0123456789ab:tc=.def100 kernel configuration - If using Etherboot, you need to - create a kernel configuration file for the diskless client - with the following options (in addition to the usual ones): + If using Etherboot, you need + to create a kernel configuration file for the diskless + client with the following options (in addition to the usual + ones): options BOOTP # Use BOOTP to obtain IP address/hostname @@ -4075,44 +4245,48 @@ options BOOTP_NFSROOT # NFS mount root file system using BOOTP info You may also want to use BOOTP_NFSV3, - BOOT_COMPAT and BOOTP_WIRED_TO - (refer to NOTES). + BOOT_COMPAT and + BOOTP_WIRED_TO (refer to + NOTES). - These option names are historical and slightly misleading as - they actually enable indifferent use of DHCP and - BOOTP inside the kernel (it is also possible to force strict BOOTP - or DHCP use). + These option names are historical and slightly + misleading as they actually enable indifferent use of + DHCP and BOOTP inside the kernel (it is + also possible to force strict BOOTP or + DHCP use). Build the kernel (see ), - and copy it to the place specified - in dhcpd.conf. + and copy it to the place specified in + dhcpd.conf. - When using PXE, building a kernel with the - above options is not strictly necessary (though suggested). - Enabling them will cause more DHCP requests to be - issued during kernel startup, with a small risk of inconsistency - between the new values and those retrieved by &man.pxeboot.8; in some - special cases. The advantage of using them is that the host name - will be set as a side effect. Otherwise you will need to set the - host name by another method, for example in a client-specific - rc.conf file. + When using PXE, building a kernel + with the above options is not strictly necessary (though + suggested). Enabling them will cause more + DHCP requests to be issued during + kernel startup, with a small risk of inconsistency between + the new values and those retrieved by &man.pxeboot.8; in + some special cases. The advantage of using them is that + the host name will be set as a side effect. Otherwise you + will need to set the host name by another method, for + example in a client-specific rc.conf + file. In order to be loadable with - Etherboot, a kernel needs to have - the device hints compiled in. You would typically set the - following option in the configuration file (see the - NOTES configuration comments file): + Etherboot, a kernel needs to + have the device hints compiled in. You would typically + set the following option in the configuration file (see + the NOTES configuration comments + file): hints "GENERIC.hints" - - Preparing the Root Filesystem + Preparing the Root Filesystem root file system @@ -4125,12 +4299,13 @@ options BOOTP_NFSROOT # NFS mount root file system using BOOTP info dhcpd.conf. - Using <command>make world</command> to Populate Root + Using <command>make world</command> to Populate + Root - This method is quick and - will install a complete virgin system (not only the root file system) - into DESTDIR. - All you have to do is simply execute the following script: + This method is quick and will install a complete + virgin system (not only the root file system) into + DESTDIR. All you have to do is simply + execute the following script: #!/bin/sh export DESTDIR=/data/misc/diskless @@ -4155,56 +4330,59 @@ cd /usr/src/etc; make distribution <acronym>NFS</acronym> Swap - The kernel does not support enabling NFS - swap at boot time. Swap must be enabled by the startup scripts, - by mounting a writable file system and creating and enabling a - swap file. To create a swap file of appropriate size, you can do - like this: + The kernel does not support enabling + NFS swap at boot time. Swap must be + enabled by the startup scripts, by mounting a writable + file system and creating and enabling a swap file. To + create a swap file of appropriate size, you can do like + this: &prompt.root; dd if=/dev/zero of=/path/to/swapfile bs=1k count=1 oseek=100000 - To enable it you have to add the following line to your - rc.conf: + To enable it you have to add the following line to + your rc.conf: swapfile=/path/to/swapfile - + Miscellaneous Issues - - Running with a Read-only <filename>/usr</filename> + Running with a Read-only + <filename>/usr</filename> diskless operation /usr read-only - If the diskless workstation is configured to run X, you - will have to adjust the XDM configuration file, which puts - the error log on /usr by default. + If the diskless workstation is configured to run X, + you will have to adjust the + XDM configuration file, which + puts the error log on /usr by + default. + Using a Non-FreeBSD Server - When the server for the root file system is not running FreeBSD, - you will have to create the root file system on a - FreeBSD machine, then copy it to its destination, using - tar or cpio. - In this situation, there are sometimes - problems with the special files in /dev, - due to differing major/minor integer sizes. A solution to this - problem is to export a directory from the non-FreeBSD server, - mount this directory onto a FreeBSD machine, and - use &man.devfs.5; to allocate device nodes transparently for - the user. + When the server for the root file system is not + running FreeBSD, you will have to create the root file + system on a FreeBSD machine, then copy it to its + destination, using tar or + cpio. + In this situation, there are sometimes problems with + the special files in /dev, due to + differing major/minor integer sizes. A solution to this + problem is to export a directory from the non-FreeBSD + server, mount this directory onto a FreeBSD machine, and + use &man.devfs.5; to allocate device nodes transparently + for the user. - - @@ -4223,209 +4401,226 @@ cd /usr/src/etc; make distribution PXE Booting with an NFS Root File System - The &intel; Preboot eXecution Environment (PXE) - allows booting the operating system over the network. - PXE support is usually provided in the - BIOS of modern motherboards, where - it can be enabled in the BIOS settings + The &intel; Preboot eXecution Environment + (PXE) allows booting the operating system + over the network. PXE support is usually + provided in the BIOS of modern motherboards, + where it can be enabled in the BIOS settings which enable booting from the network. A fully functioning PXE setup also requires properly configured - DHCP and TFTP servers. + DHCP and TFTP + servers. When the host computer boots, it receives information over DHCP about where to obtain the initial boot - loader via TFTP. After the host computer receives this information, - it downloads the boot loader via TFTP, and then - executes the boot loader. This is documented in section 2.2.1 of the - Preboot Execution Environment (PXE) Specification. - In &os;, the boot loader retrieved during the PXE + loader via TFTP. After the host computer receives this + information, it downloads the boot loader via + TFTP, and then executes the boot loader. + This is documented in section 2.2.1 of the Preboot + Execution Environment (PXE) Specification. In &os;, + the boot loader retrieved during the PXE process is /boot/pxeboot. After /boot/pxeboot executes, the &os; kernel is loaded, and the rest of the &os; bootup sequence proceeds. - Refer to for more information about - the &os; booting process. + Refer to for more information about the + &os; booting process. - Setting Up the <command>chroot</command> Environment for the NFS Root File System + Setting Up the <command>chroot</command> Environment for + the NFS Root File System - - - Choose a directory which will have a &os; installation - which will be NFS mountable. For example, a directory such - as /b/tftpboot/FreeBSD/install can be used. + + + Choose a directory which will have a &os; + installation which will be NFS mountable. For example, a + directory such as + /b/tftpboot/FreeBSD/install can be + used. &prompt.root; export NFSROOTDIR=/b/tftpboot/FreeBSD/install &prompt.root; mkdir -p ${NFSROOTDIR} - + - - Enable the NFS server by following the instructions in - . - + + Enable the NFS server by following the instructions + in . + - - Export the directory via NFS by adding the following to - /etc/exports: + + Export the directory via NFS by adding the following + to /etc/exports: - /b -ro -alldirs - + /b -ro -alldirs + - - Restart the NFS server: + + Restart the NFS server: - &prompt.root; /etc/rc.d/nfsd restart - + &prompt.root; /etc/rc.d/nfsd restart + - - Enable &man.inetd.8; by following the steps outlined in - . - + + Enable &man.inetd.8; by following the steps outlined + in . + - - Add the following line to - /etc/inetd.conf: + + Add the following line to + /etc/inetd.conf: - tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /b/tftpboot - + tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /b/tftpboot + - - Restart inetd: + + Restart inetd: - &prompt.root; /etc/rc.d/inetd restart - + &prompt.root; /etc/rc.d/inetd restart + - - Rebuild the &os; kernel and userland: + + Rebuild the &os; kernel and + userland: - &prompt.root; cd /usr/src + &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel - + - - Install &os; into the directory mounted over + + Install &os; into the directory mounted over NFS: - + &prompt.root; make installworld DESTDIR=${NFSROOTDIR} &prompt.root; make installkernel DESTDIR=${NFSROOTDIR} &prompt.root; make distribution DESTDIR=${NFSROOTDIR} - - + + - - Test that the TFTP server works and - can download the boot loader which will be obtained via PXE: + + Test that the TFTP server works and + can download the boot loader which will be obtained + via PXE: - + &prompt.root; tftp localhost tftp> get FreeBSD/install/boot/pxeboot Received 264951 bytes in 0.1 seconds - - + + - - Edit ${NFSROOTDIR}/etc/fstab and create an entry - to mount the root file system over NFS: + + Edit ${NFSROOTDIR}/etc/fstab and + create an entry to mount the root file system over + NFS: - + # Device Mountpoint FSType Options Dump Pass myhost.example.com:/b/tftpboot/FreeBSD/install / nfs ro 0 0 - + - Replace myhost.example.com - with the hostname or IP address of your NFS - server. In this example, the root file system is mounted - "read-only" in order to prevent NFS - clients from potentially deleting the contents of the root - file system. - + Replace + myhost.example.com with the + hostname or IP address of your NFS + server. In this example, the root file system is mounted + "read-only" in order to prevent NFS + clients from potentially deleting the contents of the root + file system. + - - Set the root password in the &man.chroot.8; - environment. - &prompt.root; chroot ${NFSROOTDIR} + + Set the root password in the &man.chroot.8; + environment. + + &prompt.root; chroot ${NFSROOTDIR} &prompt.root; passwd - This will set the root password for client machines - which are PXE booting. - - - Enable ssh root logins for client machines which are - PXE booting by editing - ${NFSROOTDIR}/etc/ssh/sshd_config - and enabling the PermitRootLogin option. - This is documented in &man.sshd.config.5;. - + This will set the root password for client + machines which are PXE + booting. + - - Perform other customizations of the &man.chroot.8; - environment in ${NFSROOTDIR}. These customizations could - include things like adding packages with &man.pkg.add.1;, - editing the password file with &man.vipw.8;, or editing - &man.amd.conf.5; maps for automounting. For example: + + Enable ssh root logins for client machines which are + PXE booting by editing + ${NFSROOTDIR}/etc/ssh/sshd_config and + enabling the PermitRootLogin option. + This is documented in &man.sshd.config.5;. + - + + Perform other customizations of the &man.chroot.8; + environment in ${NFSROOTDIR}. These customizations could + include things like adding packages with &man.pkg.add.1;, + editing the password file with &man.vipw.8;, or editing + &man.amd.conf.5; maps for automounting. For + example: + + &prompt.root; chroot ${NFSROOTDIR} &prompt.root; pkg_add -r bash - - - + + + - - Configuring Memory File Systems Used by <filename>/etc/rc.initdiskless</filename> + + Configuring Memory File Systems Used by + <filename>/etc/rc.initdiskless</filename> - If you boot from an NFS root volume, - /etc/rc - detects that you booted over NFS and runs the - /etc/rc.initdiskless script. - Read the comments in this script to understand what is going on. - We need to make /etc and - /var memory backed - file systems because these directories need to be writable, but - the NFS root directory is read-only. + If you boot from an NFS root volume, + /etc/rc detects that you booted over NFS + and runs the /etc/rc.initdiskless script. + Read the comments in this script to understand what is going + on. We need to make /etc and + /var memory backed file systems because + these directories need to be writable, but the NFS root + directory is read-only. - + &prompt.root; chroot ${NFSROOTDIR} &prompt.root; mkdir -p conf/base &prompt.root; tar -c -v -f conf/base/etc.cpio.gz --format cpio --gzip etc &prompt.root; tar -c -v -f conf/base/var.cpio.gz --format cpio --gzip var - When the system boots, memory file systems for - /etc and /var - will be created and mounted, and the contents of the - cpio.gz files will be copied into them. - + When the system boots, memory file systems for + /etc and /var will + be created and mounted, and the contents of the + cpio.gz files will be copied into + them. + - - Setting up the DHCP Server + + Setting up the DHCP Server - PXE requires a TFTP server and a - DHCP server to be set up. The - DHCP server does not necessarily need - to be the same machine as the TFTP server, - but it needs to be accessible in your network. + PXE requires a TFTP server and a + DHCP server to be set up. The + DHCP server does not necessarily need to be + the same machine as the TFTP server, but it + needs to be accessible in your network. - - - Install the DHCP server by following - the instructions documented at . - Make sure that /etc/rc.conf - and /usr/local/etc/dhcpd.conf - are correctly configured. - + + + Install the DHCP server by + following the instructions documented at + . Make sure that + /etc/rc.conf and + /usr/local/etc/dhcpd.conf are + correctly configured. + - - In /usr/local/etc/dhcpd.conf, configure - the next-server, filename, - and option root-path settings, - to specify your TFTP server IP address, - the path to /boot/pxeboot in - TFTP, and the path to the NFS - root file system. Here is a sample dhcpd.conf - setup: + + In /usr/local/etc/dhcpd.conf, + configure the next-server, + filename, and + option root-path settings, to specify + your TFTP server IP address, the path + to /boot/pxeboot in + TFTP, and the path to the + NFS root file system. Here is a sample + dhcpd.conf setup: - + subnet 192.168.0.0 netmask 255.255.255.0 { range 192.168.0.2 192.168.0.3 ; option subnet-mask 255.255.255.0 ; @@ -4445,46 +4640,48 @@ subnet 192.168.0.0 netmask 255.255.255.0 { option root-path "192.168.0.1:/b/tftpboot/FreeBSD/install/" ; } - - - - + + + + - - Configuring the PXE Client and Debugging Connection Problems + + Configuring the PXE Client and Debugging Connection + Problems - - - When the client machine boots up, enter the - BIOS configuration menu. Configure the - BIOS to boot from the network. If all your - previous configuration steps are correct, then everything should - "just work". - + + + When the client machine boots up, enter the + BIOS configuration menu. Configure the + BIOS to boot from the network. If all + your previous configuration steps are correct, then + everything should "just work". + - - Use the net/wireshark - port to debug the DHCP and TFTP - network traffic to look for any problems. - + + Use the + net/wireshark port to + debug the DHCP and + TFTP network traffic to look for any + problems. + - - Make sure that the pxeboot file can - be retrieved by TFTP. On your - TFTP server, look in - /var/log/xferlog to ensure that the - pxeboot file is being retrieved from - the correct location. To test the configuration from - dhcpd.conf above: + + Make sure that the pxeboot file + can be retrieved by TFTP. On your + TFTP server, look in + /var/log/xferlog to ensure that the + pxeboot file is being retrieved from + the correct location. To test the configuration from + dhcpd.conf above: - &prompt.root; tftp 192.168.0.1 + &prompt.root; tftp 192.168.0.1 tftp> get FreeBSD/install/boot/pxeboot Received 264951 bytes in 0.1 seconds - Read &man.tftpd.8; and &man.tftp.1;. The - BUGS sections in these pages - document some limitations with - TFTP. + Read &man.tftpd.8; and &man.tftp.1;. The + BUGS sections in these pages document + some limitations with TFTP. @@ -4496,11 +4693,12 @@ Received 264951 bytes in 0.1 seconds - Read the code in src/sys/boot/i386/libi386/pxe.c - to understand how the pxeboot loader sets - variables like boot.nfsroot.server and - boot.nfsroot.path. These variables are then - used in the NFS diskless root mount code in + Read the code in + src/sys/boot/i386/libi386/pxe.c to + understand how the pxeboot loader + sets variables like boot.nfsroot.server + and boot.nfsroot.path. These variables + are then used in the NFS diskless root mount code in src/sys/nfsclient/nfs_diskless.c. @@ -4518,68 +4716,70 @@ Received 264951 bytes in 0.1 seconds ISDN - A good resource for information on ISDN technology and hardware is - Dan Kegel's ISDN - Page. + A good resource for information on ISDN technology and + hardware is + Dan + Kegel's ISDN Page. A quick simple road map to ISDN follows: - If you live in Europe you might want to investigate the ISDN card - section. + If you live in Europe you might want to investigate the + ISDN card section. - If you are planning to use ISDN primarily to connect to the - Internet with an Internet Provider on a dial-up non-dedicated basis, - you might look into Terminal Adapters. This will give you the - most flexibility, with the fewest problems, if you change - providers. + If you are planning to use ISDN primarily to connect to + the Internet with an Internet Provider on a dial-up + non-dedicated basis, you might look into Terminal Adapters. + This will give you the most flexibility, with the fewest + problems, if you change providers. - If you are connecting two LANs together, or connecting to the - Internet with a dedicated ISDN connection, you might consider - the stand alone router/bridge option. + If you are connecting two LANs together, or connecting + to the Internet with a dedicated ISDN connection, you might + consider the stand alone router/bridge option. - Cost is a significant factor in determining what solution you will - choose. The following options are listed from least expensive to most - expensive. + Cost is a significant factor in determining what solution + you will choose. The following options are listed from least + expensive to most expensive. - - - Hellmuth - Michaelis - Contributed by - - + + + Hellmuth + Michaelis + Contributed by + + ISDN Cards - ISDN - cards + ISDN + cards FreeBSD's ISDN implementation supports only the DSS1/Q.931 - (or Euro-ISDN) standard using passive cards. Some active cards - are supported where the firmware - also supports other signaling protocols; this also includes the - first supported Primary Rate (PRI) ISDN card. + (or Euro-ISDN) standard using passive cards. Some active + cards are supported where the firmware also supports other + signaling protocols; this also includes the first supported + Primary Rate (PRI) ISDN card. - The isdn4bsd software allows you to connect - to other ISDN routers using either IP over raw HDLC or by using - synchronous PPP: either by using kernel PPP with isppp, a - modified &man.sppp.4; driver, or by using userland &man.ppp.8;. By using - userland &man.ppp.8;, channel bonding of two or more ISDN - B-channels is possible. A telephone answering machine - application is also available as well as many utilities such as - a software 300 Baud modem. + The isdn4bsd software allows + you to connect to other ISDN routers using either IP over raw + HDLC or by using synchronous PPP: either by using kernel PPP + with isppp, a modified &man.sppp.4; driver, + or by using userland &man.ppp.8;. By using userland + &man.ppp.8;, channel bonding of two or more ISDN B-channels is + possible. A telephone answering machine application is also + available as well as many utilities such as a software 300 + Baud modem. Some growing number of PC ISDN cards are supported under FreeBSD and the reports show that it is successfully used all @@ -4587,28 +4787,27 @@ Received 264951 bytes in 0.1 seconds The passive ISDN cards supported are mostly the ones with the Infineon (formerly Siemens) ISAC/HSCX/IPAC ISDN chipsets, - but also ISDN cards with chips from Cologne Chip (ISA bus only), - PCI cards with Winbond W6692 chips, some cards with the - Tiger300/320/ISAC chipset combinations and some vendor specific - chipset based cards such as the AVM Fritz!Card PCI V.1.0 and the - AVM Fritz!Card PnP. + but also ISDN cards with chips from Cologne Chip (ISA bus + only), PCI cards with Winbond W6692 chips, some cards with the + Tiger300/320/ISAC chipset combinations and some vendor + specific chipset based cards such as the AVM Fritz!Card PCI + V.1.0 and the AVM Fritz!Card PnP. Currently the active supported ISDN cards are the AVM B1 (ISA and PCI) BRI cards and the AVM T1 PCI PRI cards. For documentation on isdn4bsd, - have a look at - the homepage of - isdn4bsd which also has pointers to hints, erratas and - much more documentation such as the homepage of + isdn4bsd which also has pointers to hints, erratas + and much more documentation such as the isdn4bsd handbook. In case you are interested in adding support for a - different ISDN protocol, a currently unsupported ISDN PC card or - otherwise enhancing isdn4bsd, please - get in touch with &a.hm;. + different ISDN protocol, a currently unsupported ISDN PC card + or otherwise enhancing isdn4bsd, + please get in touch with &a.hm;. For questions regarding the installation, configuration and troubleshooting isdn4bsd, a @@ -4618,33 +4817,38 @@ Received 264951 bytes in 0.1 seconds ISDN Terminal Adapters - Terminal adapters (TA), are to ISDN what modems are to regular - phone lines. - modem - Most TA's use the standard Hayes modem AT command set, and can be - used as a drop in replacement for a modem. + Terminal adapters (TA), are to ISDN what modems are to + regular phone lines. - A TA will operate basically the same as a modem except connection - and throughput speeds will be much faster than your old modem. You - will need to configure PPP exactly the same - as for a modem setup. Make sure you set your serial speed as high as + modem + Most TA's use the standard Hayes modem AT command set, and + can be used as a drop in replacement for a modem. + + A TA will operate basically the same as a modem except + connection and throughput speeds will be much faster than your + old modem. You will need to configure + PPP exactly the same as for a modem + setup. Make sure you set your serial speed as high as possible. + PPP The main advantage of using a TA to connect to an Internet - Provider is that you can do Dynamic PPP. As IP address space becomes - more and more scarce, most providers are not willing to provide you - with a static IP anymore. Most stand-alone routers are not able to - accommodate dynamic IP allocation. + Provider is that you can do Dynamic PPP. As IP address space + becomes more and more scarce, most providers are not willing + to provide you with a static IP anymore. Most stand-alone + routers are not able to accommodate dynamic IP + allocation. - TA's completely rely on the PPP daemon that you are running for - their features and stability of connection. This allows you to - upgrade easily from using a modem to ISDN on a FreeBSD machine, if you - already have PPP set up. However, at the same time any problems you - experienced with the PPP program and are going to persist. + TA's completely rely on the PPP daemon that you are + running for their features and stability of connection. This + allows you to upgrade easily from using a modem to ISDN on a + FreeBSD machine, if you already have PPP set up. However, at + the same time any problems you experienced with the PPP + program and are going to persist. - If you want maximum stability, use the kernel PPP option, not the userland PPP. + If you want maximum stability, use the kernel + PPP option, not the + userland PPP. The following TA's are known to work with FreeBSD: @@ -4658,45 +4862,47 @@ Received 264951 bytes in 0.1 seconds - Most other TA's will probably work as well, TA vendors try to make - sure their product can accept most of the standard modem AT command - set. + Most other TA's will probably work as well, TA vendors try + to make sure their product can accept most of the standard + modem AT command set. The real problem with external TA's is that, like modems, you need a good serial card in your computer. You should read the FreeBSD Serial + url="&url.articles.serial-uart;/index.html">FreeBSD Serial Hardware tutorial for a detailed understanding of serial devices, and the differences between asynchronous and synchronous serial ports. - A TA running off a standard PC serial port (asynchronous) limits - you to 115.2 Kbs, even though you have a 128 Kbs connection. - To fully utilize the 128 Kbs that ISDN is capable of, - you must move the TA to a synchronous serial card. + A TA running off a standard PC serial port (asynchronous) + limits you to 115.2 Kbs, even though you have a + 128 Kbs connection. To fully utilize the 128 Kbs + that ISDN is capable of, you must move the TA to a synchronous + serial card. - Do not be fooled into buying an internal TA and thinking you have - avoided the synchronous/asynchronous issue. Internal TA's simply have - a standard PC serial port chip built into them. All this will do is - save you having to buy another serial cable and find another empty - electrical socket. + Do not be fooled into buying an internal TA and thinking + you have avoided the synchronous/asynchronous issue. Internal + TA's simply have a standard PC serial port chip built into + them. All this will do is save you having to buy another + serial cable and find another empty electrical socket. - A synchronous card with a TA is at least as fast as a stand-alone - router, and with a simple 386 FreeBSD box driving it, probably more - flexible. + A synchronous card with a TA is at least as fast as a + stand-alone router, and with a simple 386 FreeBSD box driving + it, probably more flexible. - The choice of synchronous card/TA v.s. stand-alone router is largely a - religious issue. There has been some discussion of this in - the mailing lists. We suggest you search the archives for + The choice of synchronous card/TA v.s. stand-alone router + is largely a religious issue. There has been some discussion + of this in the mailing lists. We suggest you search the + archives for the complete discussion. Stand-alone ISDN Bridges/Routers + - ISDN + ISDN stand-alone bridges/routers ISDN bridges or routers are not at all specific to FreeBSD @@ -4704,8 +4910,8 @@ Received 264951 bytes in 0.1 seconds description of routing and bridging technology, please refer to a networking reference book. - In the context of this section, the terms router and bridge will - be used interchangeably. + In the context of this section, the terms router and + bridge will be used interchangeably. As the cost of low end ISDN routers/bridges comes down, it will likely become a more and more popular choice. An ISDN @@ -4739,13 +4945,14 @@ Received 264951 bytes in 0.1 seconds 10 base 2 Network uses a bus based topology with 10 base 2 - Ethernet (thinnet). Connect router to network cable with - AUI/10BT transceiver, if necessary. + Ethernet (thinnet). Connect router to + network cable with AUI/10BT transceiver, if + necessary. - - - - + + + + ---Sun workstation @@ -4757,16 +4964,16 @@ Received 264951 bytes in 0.1 seconds Stand-alone router | ISDN BRI line - + 10 Base 2 Ethernet - If your home/branch office is only one computer you can use a - twisted pair crossover cable to connect to the stand-alone router - directly. + If your home/branch office is only one computer you can + use a twisted pair crossover cable to connect to the + stand-alone router directly. @@ -4774,12 +4981,13 @@ ISDN BRI line 10 base T Network uses a star topology with 10 base T Ethernet - (Twisted Pair). + (Twisted Pair). - - - - + + + + -------Novell Server @@ -4801,13 +5009,13 @@ ISDN BRI line - One large advantage of most routers/bridges is that they allow you - to have 2 separate independent PPP connections to - 2 separate sites at the same time. This is not - supported on most TA's, except for specific (usually expensive) models - that - have two serial ports. Do not confuse this with channel bonding, MPP, - etc. + One large advantage of most routers/bridges is that they + allow you to have 2 separate independent + PPP connections to 2 separate sites at the + same time. This is not supported on most + TA's, except for specific (usually expensive) models that have + two serial ports. Do not confuse this with channel bonding, + MPP, etc. This can be a very useful feature if, for example, you have an dedicated ISDN connection at your office and would @@ -4820,69 +5028,80 @@ ISDN BRI line more bandwidth. IPX/SPX - An Ethernet bridge will also allow you to transmit more than just - IP traffic. You can also send IPX/SPX or whatever other protocols you - use. + An Ethernet bridge will also allow you to transmit more + than just IP traffic. You can also send IPX/SPX or whatever + other protocols you use. - - Chern - Lee - Contributed by - + + Chern + Lee + Contributed by + Network Address Translation Overview + - natd + natd - FreeBSD's Network Address Translation daemon, commonly known as - &man.natd.8; is a daemon that accepts incoming raw IP packets, - changes the source to the local machine and re-injects these packets - back into the outgoing IP packet stream. &man.natd.8; does this by changing - the source IP address and port such that when data is received back, - it is able to determine the original location of the data and forward - it back to its original requester. - Internet connection sharing - NAT - The most common use of NAT is to perform what is commonly known as - Internet Connection Sharing. + FreeBSD's Network Address Translation daemon, commonly + known as &man.natd.8; is a daemon that accepts incoming raw IP + packets, changes the source to the local machine and + re-injects these packets back into the outgoing IP packet + stream. &man.natd.8; does this by changing the source IP + address and port such that when data is received back, it is + able to determine the original location of the data and + forward it back to its original requester. + + + Internet connection sharing + + + NAT + + The most common use of NAT is to perform what is commonly + known as Internet Connection Sharing. Setup - Due to the diminishing IP space in IPv4, and the increased number - of users on high-speed consumer lines such as cable or DSL, people are - increasingly in need of an Internet Connection Sharing solution. The - ability to connect several computers online through one connection and - IP address makes &man.natd.8; a reasonable choice. - Most commonly, a user has a machine connected to a cable or DSL - line with one IP address and wishes to use this one connected computer to - provide Internet access to several more over a LAN. + Due to the diminishing IP space in IPv4, and the increased + number of users on high-speed consumer lines such as cable or + DSL, people are increasingly in need of an Internet Connection + Sharing solution. The ability to connect several computers + online through one connection and IP address makes + &man.natd.8; a reasonable choice. - To do this, the FreeBSD machine on the Internet must act as a - gateway. This gateway machine must have two NICs—one for connecting - to the Internet router, the other connecting to a LAN. All the - machines on the LAN are connected through a hub or switch. + Most commonly, a user has a machine connected to a cable + or DSL line with one IP address and wishes to use this one + connected computer to provide Internet access to several more + over a LAN. + + To do this, the FreeBSD machine on the Internet must act + as a gateway. This gateway machine must have two + NICs—one for connecting to the Internet router, the + other connecting to a LAN. All the machines on the LAN are + connected through a hub or switch. - There are many ways to get a LAN connected to the Internet - through a &os; gateway. This example will only cover a - gateway with at least two NICs. + There are many ways to get a LAN connected to the + Internet through a &os; gateway. This example will only + cover a gateway with at least two NICs. - - - + + + _______ __________ ________ @@ -4894,7 +5113,7 @@ ISDN BRI line | | | Client A | |__________| - + Network Layout @@ -4902,10 +5121,10 @@ ISDN BRI line A setup like this is commonly used to share an Internet - connection. One of the LAN machines is - connected to the Internet. The rest of the machines access - the Internet through that gateway - machine. + connection. One of the LAN machines is + connected to the Internet. The rest of the machines access + the Internet through that gateway + machine. @@ -4917,26 +5136,28 @@ ISDN BRI line Boot Loader Configuration The kernel features for network address translation with - &man.natd.8; are not enabled in the GENERIC - kernel, but they can be preloaded at boot time, by adding a couple of - options to /boot/loader.conf: + &man.natd.8; are not enabled in the + GENERIC kernel, but they can be preloaded + at boot time, by adding a couple of options to + /boot/loader.conf: ipfw_load="YES" ipdivert_load="YES" - Additionally, - the net.inet.ip.fw.default_to_accept tunable + Additionally, the + net.inet.ip.fw.default_to_accept tunable option may be set to 1: net.inet.ip.fw.default_to_accept="1" - It is a very good idea to set this option during the first - attempts to setup a firewall and NAT gateway. This way the default - policy of &man.ipfw.8; will be allow ip from any to - any instead of the less permissive deny ip from - any to any, and it will be slightly more difficult to get - locked out of the system right after a reboot. + It is a very good idea to set this option during the + first attempts to setup a firewall and NAT gateway. This + way the default policy of &man.ipfw.8; will be + allow ip from any to any instead of the + less permissive deny ip from any to any, + and it will be slightly more difficult to get locked out of + the system right after a reboot. @@ -4944,18 +5165,20 @@ ipdivert_load="YES" Kernel Configuration - kernel + kernel configuration When modules are not an option or if it is preferrable to - build all the required features into the running kernel, the - following options must be in the kernel configuration - file: + build all the required features into the running kernel, the + following options must be in the kernel configuration + file: options IPFIREWALL options IPDIVERT - Additionally, at choice, the following may also be suitable: + Additionally, at choice, the following may also be + suitable: + options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE @@ -4974,45 +5197,46 @@ natd_interface="fxp0" - - Sets up the machine to act as a gateway. Running - sysctl net.inet.ip.forwarding=1 would - have the same effect. + + Sets up the machine to act as a gateway. Running + sysctl net.inet.ip.forwarding=1 would + have the same effect. - - Enables the firewall rules in - /etc/rc.firewall at boot. + + Enables the firewall rules in + /etc/rc.firewall at boot. - - This specifies a predefined firewall ruleset that - allows anything in. See - /etc/rc.firewall for additional - types. + + This specifies a predefined firewall ruleset that + allows anything in. See + /etc/rc.firewall for additional + types. - - Indicates which interface to forward packets through - (the interface connected to the Internet). + + Indicates which interface to forward packets through + (the interface connected to the Internet). - - Any additional configuration options passed to - &man.natd.8; on boot. + + Any additional configuration options passed to + &man.natd.8; on boot. Having the previous options defined in - /etc/rc.conf would run - natd -interface fxp0 at boot. This can also - be run manually. + /etc/rc.conf would run + natd -interface fxp0 at boot. This can + also be run manually. It is also possible to use a configuration file for - &man.natd.8; when there are too many options to pass. In this - case, the configuration file must be defined by adding the - following line to /etc/rc.conf: + &man.natd.8; when there are too many options to pass. In + this case, the configuration file must be defined by adding + the following line to + /etc/rc.conf: natd_flags="-f /etc/natd.conf" @@ -5030,109 +5254,121 @@ redirect_port tcp 192.168.0.3:80 80 Each machine and interface behind the LAN should be - assigned IP address numbers in the private network space as - defined by RFC 1918 - and have a default gateway of the natd machine's internal IP - address. + assigned IP address numbers in the private network space as + defined by + RFC + 1918 and have a default gateway of the + natd machine's internal IP + address. For example, client A and - B behind the LAN have IP addresses of 192.168.0.2 and 192.168.0.3, while the natd machine's - LAN interface has an IP address of 192.168.0.1. Client A - and B's default gateway must be set to that - of the natd machine, 192.168.0.1. The natd machine's - external, or Internet interface does not require any special - modification for &man.natd.8; to work. + B behind the LAN have IP addresses of + 192.168.0.2 and + 192.168.0.3, while the natd + machine's LAN interface has an IP address of + 192.168.0.1. Client + A and B's default gateway + must be set to that of the natd + machine, 192.168.0.1. The + natd machine's external, or + Internet interface does not require any special modification + for &man.natd.8; to work. Port Redirection - The drawback with &man.natd.8; is that the LAN clients are not accessible - from the Internet. Clients on the LAN can make outgoing connections to - the world but cannot receive incoming ones. This presents a problem - if trying to run Internet services on one of the LAN client machines. - A simple way around this is to redirect selected Internet ports on the - natd machine to a LAN client. - + The drawback with &man.natd.8; is that the LAN clients are + not accessible from the Internet. Clients on the LAN can make + outgoing connections to the world but cannot receive incoming + ones. This presents a problem if trying to run Internet + services on one of the LAN client machines. A simple way + around this is to redirect selected Internet ports on the + natd machine to a LAN + client. - For example, an IRC server runs on client A, and a web server runs - on client B. For this to work properly, connections received on ports - 6667 (IRC) and 80 (web) must be redirected to the respective machines. - + For example, an IRC server runs on client + A, and a web server runs on client + B. For this to work properly, connections + received on ports 6667 (IRC) and 80 (web) must be redirected + to the respective machines. The must be passed to - &man.natd.8; with the proper options. The syntax is as follows: + &man.natd.8; with the proper options. The syntax is as + follows: + -redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]aliasPORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]] In the above example, the argument should be: - -redirect_port tcp 192.168.0.2:6667 6667 + -redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 - - This will redirect the proper tcp ports to the - LAN client machines. - + This will redirect the proper tcp + ports to the LAN client machines. - The argument can be used to indicate port - ranges over individual ports. For example, tcp - 192.168.0.2:2000-3000 2000-3000 would redirect - all connections received on ports 2000 to 3000 to ports 2000 - to 3000 on client A. + The argument can be used + to indicate port ranges over individual ports. For example, + tcp 192.168.0.2:2000-3000 2000-3000 + would redirect all connections received on ports 2000 to 3000 + to ports 2000 to 3000 on client A. These options can be used when directly running - &man.natd.8;, placed within the - natd_flags="" option in - /etc/rc.conf, - or passed via a configuration file. + &man.natd.8;, placed within the + natd_flags="" option in + /etc/rc.conf, or passed via a + configuration file. - For further configuration options, consult &man.natd.8; + For further configuration options, consult + &man.natd.8; Address Redirection + address redirection Address redirection is useful if several IP addresses are - available, yet they must be on one machine. With this, - &man.natd.8; can assign each LAN client its own external IP address. - &man.natd.8; then rewrites outgoing packets from the LAN clients - with the proper external IP address and redirects - all traffic incoming on that particular IP address back to - the specific LAN client. This is also known as static NAT. - For example, the IP addresses 128.1.1.1, - 128.1.1.2, and - 128.1.1.3 belong to the natd gateway - machine. 128.1.1.1 can be used - as the natd gateway machine's external IP address, while - 128.1.1.2 and - 128.1.1.3 are forwarded back to LAN - clients A and B. + available, yet they must be on one machine. With this, + &man.natd.8; can assign each LAN client its own external IP + address. &man.natd.8; then rewrites outgoing packets from the + LAN clients with the proper external IP address and redirects + all traffic incoming on that particular IP address back to the + specific LAN client. This is also known as static NAT. For + example, the IP addresses + 128.1.1.1, + 128.1.1.2, and + 128.1.1.3 belong to the + natd gateway machine. + 128.1.1.1 can be used as the + natd gateway machine's external IP + address, while 128.1.1.2 and + 128.1.1.3 are forwarded back to + LAN clients A and B. - The syntax is as follows: + The syntax is as + follows: -redirect_address localIP publicIP - - - - localIP - The internal IP address of the LAN client. - - - publicIP - The external IP address corresponding to the LAN client. - - - + + + + localIP + The internal IP address of the LAN + client. + + + + publicIP + The external IP address corresponding to the LAN + client. + + + In the example, this argument would read: @@ -5140,14 +5376,17 @@ redirect_port tcp 192.168.0.3:80 80 -redirect_address 192.168.0.2 128.1.1.2 -redirect_address 192.168.0.3 128.1.1.3 - Like , these arguments are also placed within - the natd_flags="" option of /etc/rc.conf, or passed via a configuration file. With address - redirection, there is no need for port redirection since all data - received on a particular IP address is redirected. - - The external IP addresses on the natd machine must be active and aliased - to the external interface. Look at &man.rc.conf.5; to do so. + Like , these arguments are + also placed within the natd_flags="" option + of /etc/rc.conf, or passed via a + configuration file. With address redirection, there is no + need for port redirection since all data received on a + particular IP address is redirected. + The external IP addresses on the + natd machine must be active and + aliased to the external interface. Look at &man.rc.conf.5; to + do so. @@ -5178,9 +5417,9 @@ redirect_port tcp 192.168.0.3:80 80 Creating a Parallel Cable You can purchase a parallel cable at most computer supply - stores. If you cannot do that, or you just want to know how - it is done, the following table shows how to make one out of a normal parallel - printer cable. + stores. If you cannot do that, or you just want to know how + it is done, the following table shows how to make one out of a + normal parallel printer cable. Wiring a Parallel Cable for Networking @@ -5189,13 +5428,9 @@ redirect_port tcp 192.168.0.3:80 80 A-name - A-End - B-End - Descr. - Post/Bit @@ -5204,15 +5439,11 @@ redirect_port tcp 192.168.0.3:80 80 DATA0 -ERROR - 2 15 - 15 2 - Data - 0/0x01 1/0x08 @@ -5220,15 +5451,11 @@ redirect_port tcp 192.168.0.3:80 80 DATA1 +SLCT - 3 13 - 13 3 - Data - 0/0x02 1/0x10 @@ -5236,15 +5463,11 @@ redirect_port tcp 192.168.0.3:80 80 DATA2 +PE - 4 12 - 12 4 - Data - 0/0x04 1/0x20 @@ -5252,15 +5475,11 @@ redirect_port tcp 192.168.0.3:80 80 DATA3 -ACK - 5 10 - 10 5 - Strobe - 0/0x08 1/0x40 @@ -5268,28 +5487,20 @@ redirect_port tcp 192.168.0.3:80 80 DATA4 BUSY - 6 11 - 11 6 - Data - 0/0x10 1/0x80 GND - 18-25 - 18-25 - GND - - @@ -5300,17 +5511,16 @@ BUSY Setting Up PLIP - First, you have to get a laplink cable. - Then, confirm that both computers have a kernel with &man.lpt.4; driver + First, you have to get a laplink cable. Then, confirm + that both computers have a kernel with &man.lpt.4; driver support: &prompt.root; grep lp /var/run/dmesg.boot lpt0: <Printer> on ppbus0 lpt0: Interrupt-driven port - The parallel port must be an interrupt driven port, - you should have lines similar to the - following in your in the + The parallel port must be an interrupt driven port, you + should have lines similar to the following in your in the /boot/device.hints file: hint.ppc.0.at="isa" @@ -5328,24 +5538,27 @@ plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 Plug the laplink cable into the parallel interface on both computers. - Configure the network interface parameters on both - sites as root. For example, if you want to connect - the host host1 with another machine host2: + Configure the network interface parameters on both sites + as root. For example, if you want to + connect the host host1 with another machine + host2: host1 <-----> host2 IP Address 10.0.0.1 10.0.0.2 - Configure the interface on host1 by doing: + Configure the interface on host1 by + doing: &prompt.root; ifconfig plip0 10.0.0.1 10.0.0.2 - Configure the interface on host2 by doing: + Configure the interface on host2 by + doing: &prompt.root; ifconfig plip0 10.0.0.2 10.0.0.1 - You now should have a working connection. Please read the - manual pages &man.lp.4; and &man.lpt.4; for more details. + manual pages &man.lp.4; and &man.lpt.4; for more + details. You should also add both hosts to /etc/hosts: @@ -5357,7 +5570,7 @@ IP Address 10.0.0.1 10.0.0.2 To confirm the connection works, go to each host and ping the other. For example, on host1: - &prompt.root; ifconfig plip0 + &prompt.root; ifconfig plip0 plip0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 &prompt.root; netstat -r @@ -5397,36 +5610,37 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms - - Brad - Davis - Extended by - + + Brad + Davis + Extended by + - IPv6 - IPv6 (also known as IPng IP next generation) is - the new version of the well known IP protocol (also known as + + IPv6 (also known as IPng IP next generation) + is the new version of the well known IP protocol (also known as IPv4). Like the other current *BSD systems, - FreeBSD includes the KAME IPv6 reference implementation. - So your FreeBSD system comes with all you will need to experiment with IPv6. - This section focuses on getting IPv6 configured and running. + FreeBSD includes the KAME IPv6 reference implementation. So + your FreeBSD system comes with all you will need to experiment + with IPv6. This section focuses on getting IPv6 configured and + running. In the early 1990s, people became aware of the rapidly - diminishing address space of IPv4. Given the expansion rate of the - Internet there were two major concerns: + diminishing address space of IPv4. Given the expansion rate of + the Internet there were two major concerns: - Running out of addresses. Today this is not so much of a concern - anymore since RFC1918 private address space + Running out of addresses. Today this is not so much of + a concern anymore since RFC1918 private address space (10.0.0.0/8, 172.16.0.0/12, and - 192.168.0.0/16) - and Network Address Translation (NAT) are - being employed. + 192.168.0.0/16) and Network + Address Translation (NAT) are being + employed. @@ -5439,29 +5653,33 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms - 128 bit address space. In other words theoretically there are - 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses - available. This means there are approximately - 6.67 * 10^27 IPv6 addresses per square meter on our planet. + 128 bit address space. In other words theoretically + there are + 340,282,366,920,938,463,463,374,607,431,768,211,456 + addresses available. This means there are approximately + 6.67 * 10^27 IPv6 addresses per square meter on our + planet. - Routers will only store network aggregation addresses in their routing - tables thus reducing the average space of a routing table to 8192 - entries. + Routers will only store network aggregation addresses in + their routing tables thus reducing the average space of a + routing table to 8192 entries. - There are also lots of other useful features of IPv6 such as: + There are also lots of other useful features of IPv6 such + as: Address autoconfiguration (RFC2462) + url="http://www.ietf.org/rfc/rfc2462.txt">RFC2462) - Anycast addresses (one-out-of many) + Anycast addresses (one-out-of + many) @@ -5490,7 +5708,8 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms - IPv6 overview at playground.sun.com + IPv6 overview at playground.sun.com @@ -5500,24 +5719,29 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Background on IPv6 Addresses - There are different types of IPv6 addresses: Unicast, Anycast and - Multicast. - Unicast addresses are the well known addresses. A packet sent - to a unicast address arrives exactly at the interface belonging to - the address. + There are different types of IPv6 addresses: Unicast, + Anycast and Multicast. - Anycast addresses are syntactically indistinguishable from unicast - addresses but they address a group of interfaces. The packet destined for - an anycast address will arrive at the nearest (in router metric) - interface. Anycast addresses may only be used by routers. + Unicast addresses are the well known addresses. A packet + sent to a unicast address arrives exactly at the interface + belonging to the address. - Multicast addresses identify a group of interfaces. A packet destined - for a multicast address will arrive at all interfaces belonging to the - multicast group. + Anycast addresses are syntactically indistinguishable from + unicast addresses but they address a group of interfaces. The + packet destined for an anycast address will arrive at the + nearest (in router metric) interface. Anycast addresses may + only be used by routers. - The IPv4 broadcast address (usually xxx.xxx.xxx.255) is expressed - by multicast addresses in IPv6. + Multicast addresses identify a group of interfaces. A + packet destined for a multicast address will arrive at all + interfaces belonging to the multicast group. + + + The IPv4 broadcast address (usually + xxx.xxx.xxx.255) is expressed + by multicast addresses in IPv6. +
Reserved IPv6 Addresses @@ -5551,17 +5775,17 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms ::00:xx:xx:xx:xx + role="ip6addr">::00:xx:xx:xx:xx 96 bits embedded IPv4 The lower 32 bits are the IPv4 address. Also called IPv4 compatible IPv6 - address + address ::ff:xx:xx:xx:xx + role="ip6addr">::ff:xx:xx:xx:xx 96 bits IPv4 mapped IPv6 address The lower 32 bits are the IPv4 address. @@ -5570,7 +5794,7 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms fe80:: - feb:: + role="ip6addr">feb:: 10 bits link-local cf. loopback address in IPv4 @@ -5578,7 +5802,7 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms fec0:: - fef:: + role="ip6addr">fef:: 10 bits site-local   @@ -5607,27 +5831,33 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Reading IPv6 Addresses - The canonical form is represented as: x:x:x:x:x:x:x:x, each + + The canonical form is represented as: + x:x:x:x:x:x:x:x, each x being a 16 Bit hex value. For example - FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 + FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 Often an address will have long substrings of all zeros - therefore one such substring per address can be abbreviated by ::. - Also up to three leading 0s per hexquad can be omitted. - For example fe80::1 - corresponds to the canonical form - fe80:0000:0000:0000:0000:0000:0000:0001. + therefore one such substring per address can be abbreviated by + ::. Also up to three leading 0s + per hexquad can be omitted. For example + fe80::1 corresponds to the + canonical form fe80:0000:0000:0000:0000:0000:0000:0001. A third form is to write the last 32 Bit part in the well known (decimal) IPv4 style with dots . as separators. For example 2002::10.0.0.1 corresponds to the (hexadecimal) canonical representation - 2002:0000:0000:0000:0000:0000:0a00:0001 - which in turn is equivalent to - writing 2002::a00:1. + 2002:0000:0000:0000:0000:0000:0a00:0001 + which in turn is equivalent to writing + 2002::a00:1. - By now the reader should be able to understand the following: + By now the reader should be able to understand the + following: &prompt.root; ifconfig @@ -5638,19 +5868,21 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms media: Ethernet autoselect (100baseTX ) status: active - fe80::200:21ff:fe03:8e1%rl0 - is an auto configured link-local address. It is generated from the MAC - address as part of the auto configuration. + fe80::200:21ff:fe03:8e1%rl0 + is an auto configured link-local address. It is generated + from the MAC address as part of the auto configuration. For further information on the structure of IPv6 addresses see RFC3513. + url="http://www.ietf.org/rfc/rfc3513.txt">RFC3513. Getting Connected - Currently there are four ways to connect to other IPv6 hosts and networks: + Currently there are four ways to connect to other IPv6 + hosts and networks: @@ -5665,11 +5897,13 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Tunnel via 6-to-4 (RFC3068) + url="http://www.ietf.org/rfc/rfc3068.txt">RFC3068) - Use the net/freenet6 port if you are on a dial-up connection. + Use the + net/freenet6 port if + you are on a dial-up connection. @@ -5677,125 +5911,131 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms DNS in the IPv6 World - There used to be two types of DNS records for IPv6. The IETF - has declared A6 records obsolete. AAAA records are the standard - now. + There used to be two types of DNS records for IPv6. The + IETF has declared A6 records obsolete. AAAA records are the + standard now. - Using AAAA records is straightforward. Assign your hostname to the new - IPv6 address you just received by adding: + Using AAAA records is straightforward. Assign your + hostname to the new IPv6 address you just received by + adding: MYHOSTNAME AAAA MYIPv6ADDR - To your primary zone DNS file. In case you do not serve your own - DNS zones ask your DNS provider. - Current versions of bind (version 8.3 and 9) - and dns/djbdns (with the IPv6 patch) - support AAAA records. + To your primary zone DNS file. In case you do not serve + your own DNS zones ask your + DNS provider. Current versions of + bind (version 8.3 and 9) and + dns/djbdns (with the IPv6 + patch) support AAAA records. - Applying the Needed Changes to <filename>/etc/rc.conf</filename> + Applying the Needed Changes to + <filename>/etc/rc.conf</filename> IPv6 Client Settings - These settings will help you configure a machine that will be on - your LAN and act as a client, not a router. To have &man.rtsol.8; - autoconfigure your interface on boot all you need to add is: + These settings will help you configure a machine that + will be on your LAN and act as a client, not a router. To + have &man.rtsol.8; autoconfigure your interface on boot all + you need to add is: ipv6_enable="YES" - To statically assign an IP address such as - 2001:471:1f11:251:290:27ff:fee0:2093, to your - fxp0 interface, add: + To statically assign an IP address such as 2001:471:1f11:251:290:27ff:fee0:2093, + to your fxp0 interface, add: ipv6_ifconfig_fxp0="2001:471:1f11:251:290:27ff:fee0:2093" To assign a default router of - 2001:471:1f11:251::1 - add the following to /etc/rc.conf: + 2001:471:1f11:251::1 add the + following to /etc/rc.conf: ipv6_defaultrouter="2001:471:1f11:251::1" - IPv6 Router/Gateway Settings - This will help you take the directions that your tunnel provider has - given you and convert it into settings that will persist through reboots. - To restore your tunnel on startup use something like the following in + This will help you take the directions that your tunnel + provider has given you and convert it into settings that + will persist through reboots. To restore your tunnel on + startup use something like the following in /etc/rc.conf: - List the Generic Tunneling interfaces that will be configured, for - example gif0: + List the Generic Tunneling interfaces that will be + configured, for example + gif0: gif_interfaces="gif0" To configure the interface with a local endpoint of - MY_IPv4_ADDR to a remote endpoint of - REMOTE_IPv4_ADDR: + MY_IPv4_ADDR to a remote endpoint + of REMOTE_IPv4_ADDR: gifconfig_gif0="MY_IPv4_ADDR REMOTE_IPv4_ADDR" - To apply the IPv6 address you have been assigned for use as your - IPv6 tunnel endpoint, add: + To apply the IPv6 address you have been assigned for use + as your IPv6 tunnel endpoint, add: ipv6_ifconfig_gif0="MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR" - Then all you have to do is set the default route for IPv6. This is - the other side of the IPv6 tunnel: + Then all you have to do is set the default route for + IPv6. This is the other side of the IPv6 tunnel: ipv6_defaultrouter="MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR" - IPv6 Tunnel Settings - If the server is to route IPv6 between the rest of your network - and the world, the following /etc/rc.conf - setting will also be needed: + If the server is to route IPv6 between the rest of your + network and the world, the following + /etc/rc.conf setting will also be + needed: ipv6_gateway_enable="YES" - Router Advertisement and Host Auto Configuration - This section will help you setup &man.rtadvd.8; to advertise the - IPv6 default route. + This section will help you setup &man.rtadvd.8; to + advertise the IPv6 default route. - To enable &man.rtadvd.8; you will need the following in your - /etc/rc.conf: + To enable &man.rtadvd.8; you will need the following in + your /etc/rc.conf: rtadvd_enable="YES" - It is important that you specify the interface on which to do - IPv6 router solicitation. For example to tell &man.rtadvd.8; to use - fxp0: + It is important that you specify the interface on which to + do IPv6 router solicitation. For example to tell + &man.rtadvd.8; to use fxp0: rtadvd_interfaces="fxp0" Now we must create the configuration file, - /etc/rtadvd.conf. Here is an example: + /etc/rtadvd.conf. Here is an + example: fxp0:\ :addrs#1:addr="2001:471:1f11:246::":prefixlen#64:tc=ether: - Replace fxp0 with the interface you - are going to be using. + Replace fxp0 with the interface + you are going to be using. - Next, replace 2001:471:1f11:246:: - with the prefix of your allocation. + Next, replace + 2001:471:1f11:246:: with the + prefix of your allocation. - If you are dedicated a /64 subnet - you will not need to change anything else. Otherwise, you will need to - change the prefixlen# to the correct value. - - + If you are dedicated a /64 + subnet you will not need to change anything else. Otherwise, + you will need to change the prefixlen# to + the correct value. + @@ -5824,16 +6064,20 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms Fully Meshed Configurations - The first method to set up a CLIP with - PVCs is to connect each machine to each other machine in the - network via a dedicated PVC. While this is simple to + The first method to set up a CLIP + with PVCs is to connect each machine to each other machine + in the network via a dedicated PVC. While this is simple to configure it tends to become impractical for a larger number of machines. The example supposes that we have four - machines in the network, each connected to the ATM network - with an ATM adapter card. The first step is the planning of - the IP addresses and the ATM connections between the - machines. We use the following: + machines in the network, each connected to the + ATM + network with an + ATM + adapter card. The first step is the planning of the IP + addresses and the + ATM + connections between the machines. We use the + following: @@ -5849,22 +6093,26 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms hostA - 192.168.173.1 + 192.168.173.1 hostB - 192.168.173.2 + 192.168.173.2 hostC - 192.168.173.3 + 192.168.173.3 hostD - 192.168.173.4 + 192.168.173.4 @@ -5886,32 +6134,38 @@ round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms - hostA - hostB + hostA - + hostB 0.100 - hostA - hostC + hostA - + hostC 0.101 - hostA - hostD + hostA - + hostD 0.102 - hostB - hostC + hostB - + hostC 0.103 - hostB - hostD + hostB - + hostD 0.104 - hostC - hostD + hostC - + hostD 0.105 @@ -5930,9 +6184,10 @@ hostD&prompt.root; ifconfig hatm0 192.168.173.4 upassuming that the ATM interface is hatm0 on all hosts. Now the PVCs - need to be configured on hostA (we assume that - they are already configured on the ATM switches, you need to - consult the manual for the switch on how to do this). + need to be configured on hostA (we assume + that they are already configured on the ATM switches, you + need to consult the manual for the switch on how to do + this).hostA&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr hostA&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr @@ -5961,10 +6216,10 @@ hostD&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/s or in the &man.atmconfig.8; manual page. The same configuration can also be done via - /etc/rc.conf. - For hostA this would look like: + /etc/rc.conf. For + hostA this would look like: -network_interfaces="lo0 hatm0" + network_interfaces="lo0 hatm0" ifconfig_hatm0="inet 192.168.173.1 up" natm_static_routes="hostB hostC hostD" route_hostB="192.168.173.2 hatm0 0 100 llc/snap ubr" @@ -5989,88 +6244,94 @@ route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr" + Common Address Redundancy Protocol (CARP) - CARP - Common Address Redundancy Protocol + + CARP + + + Common Address Redundancy Protocol + The Common Address Redundancy Protocol, or CARP allows multiple hosts to share the same IP address. In some configurations, this may - be used for availability or load balancing. Hosts may use separate - IP addresses as well, as in the example provided - here. + be used for availability or load balancing. Hosts may use + separate IP addresses as well, as in the + example provided here. To enable support for CARP, the &os; - kernel must be rebuilt as described in with the following option: + kernel must be rebuilt as described in + with the following option: device carp - Alternatively, the if_carp.ko module can - be loaded at boot time. Add the following line to the + Alternatively, the if_carp.ko module + can be loaded at boot time. Add the following line to the /boot/loader.conf: if_carp_load="YES" - CARP functionality should now be available - and may be tuned via several sysctl + CARP functionality should now be + available and may be tuned via several sysctl OIDs: - - - OID - Description - - + + + OID + Description + + - - - net.inet.carp.allow - Accept incoming CARP packets. + + + net.inet.carp.allow + Accept incoming CARP packets. Enabled by default. - + - - net.inet.carp.preempt - This option downs all of the CARP - interfaces on the host when one of them goes down. - Disabled by default - + + net.inet.carp.preempt + This option downs all of the + CARP interfaces on the host when one + of them goes down. Disabled by default + - - net.inet.carp.log - A value of 0 disables any logging. - A Value of 1 enables logging of bad - CARP packets. Values greater than - 1 enables logging of state changes for - the CARP interfaces. The default value - is 1. - + + net.inet.carp.log + A value of 0 disables any + logging. A Value of 1 enables + logging of bad CARP packets. Values + greater than 1 enables logging of + state changes for the CARP + interfaces. The default value is + 1. + - - net.inet.carp.arpbalance - Balance local network traffic using + + net.inet.carp.arpbalance + Balance local network traffic using ARP. Disabled by default. - + - - net.inet.carp.suppress_preempt - A read only OID showing the status - of preemption suppression. Preemption can be suppressed - if link on an interface is down. A value of + + net.inet.carp.suppress_preempt + A read only OID showing the + status of preemption suppression. Preemption can be + suppressed if link on an interface is down. A value of 0, means that preemption is not suppressed. Every problem increments this OID. - - + + - The CARP devices themselves may be created - via the ifconfig command: + The CARP devices themselves may be + created via the ifconfig command:&prompt.root; ifconfig carp0 create @@ -6083,26 +6344,27 @@ route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr"Using CARP for Server Availability (CARP)One use of CARP, as noted above, is for - server availability. This example will provide failover support - for three hosts, all with unique IP - addresses and providing the same web content. These machines will - act in conjunction with a Round Robin DNS - configuration. The failover machine will have two additional - CARP interfaces, one for each of the content - server's IPs. When a failure occurs, the - failover server should pick up the failed machine's - IP address. This means the failure should - go completely unnoticed to the user. The failover server - requires identical content and services as the other content - servers it is expected to pick up load for. + server availability. This example will provide failover + support for three hosts, all with unique IP + addresses and providing the same web content. These machines + will act in conjunction with a Round Robin + DNS configuration. The failover machine + will have two additional CARP interfaces, + one for each of the content server's IPs. + When a failure occurs, the failover server should pick up the + failed machine's IP address. This means + the failure should go completely unnoticed to the user. The + failover server requires identical content and services as the + other content servers it is expected to pick up load + for.The two machines should be configured identically other than their issued hostnames and VHIDs. This example calls these machines hosta.example.org and hostb.example.org respectively. First, the - required lines for a CARP configuration have - to be added to rc.conf. For + required lines for a CARP configuration + have to be added to rc.conf. For hosta.example.org, the rc.conf file should contain the following lines: @@ -6121,18 +6383,19 @@ cloned_interfaces="carp0" ifconfig_carp0="vhid 2 pass testpass 192.168.1.51/24" - It is very important that the passwords, specified by the - option to ifconfig, - are identical. The carp devices will - only listen to and accept advertisements from machines with the - correct password. The VHID must also be + It is very important that the passwords, specified by + the option to + ifconfig, are identical. The + carp devices will only listen to + and accept advertisements from machines with the correct + password. The VHID must also be different for each machine. - The third machine, - provider.example.org, should be prepared so that - it may handle failover from either host. This machine will require - two carp devices, one to handle each + The third machine, provider.example.org, + should be prepared so that it may handle failover from either + host. This machine will require two + carp devices, one to handle each host. The appropriate rc.conf configuration lines will be similar to the following: @@ -6143,12 +6406,12 @@ ifconfig_carp0="vhid 1 advskew 100 pass testpass 192.168.1.50/24" ifconfig_carp1="vhid 2 advskew 100 pass testpass 192.168.1.51/24" Having the two carp devices will - allow provider.example.org to notice and pick + allow provider.example.org to notice and pick up the IP address of either machine should it stop responding. - The default &os; kernel may have + The default &os; kernel may have preemption enabled. If so, provider.example.org may not relinquish the IP address back to the original content @@ -6163,12 +6426,13 @@ ifconfig_carp1="vhid 2 advskew 100 pass testpass 192.168.1.51/24" - At this point, CARP should be completely - enabled and available for testing. For testing, either networking has - to be restarted or the machines need to be rebooted. + At this point, CARP should be + completely enabled and available for testing. For testing, + either networking has to be restarted or the machines need to + be rebooted. More information is always available in the &man.carp.4; - manual page. + manual page.