Use correct syntax markup for shell
Approved by: carlavilla
This commit is contained in:
Li-Wen Hsu
parent
55c95407aa
commit
a9a9e66105
666 changed files with 17924 additions and 17924 deletions
|
|
@ -81,7 +81,7 @@ This section provides an overview of routing basics. It then demonstrates how to
|
|||
|
||||
To view the routing table of a FreeBSD system, use man:netstat[1]:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% netstat -r
|
||||
Routing tables
|
||||
|
|
@ -167,7 +167,7 @@ defaultrouter="10.20.30.1"
|
|||
|
||||
It is also possible to manually add the route using `route`:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# route add default 10.20.30.1
|
||||
....
|
||||
|
|
@ -203,7 +203,7 @@ In this scenario, `RouterA` is a FreeBSD machine that is acting as a router to t
|
|||
|
||||
Before adding any static routes, the routing table on `RouterA` looks like this:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% netstat -nr
|
||||
Routing tables
|
||||
|
|
@ -218,7 +218,7 @@ default 10.0.0.1 UGS 0 49378 xl0
|
|||
|
||||
With the current routing table, `RouterA` does not have a route to the `192.168.2.0/24` network. The following command adds the `Internal Net 2` network to ``RouterA``'s routing table using `192.168.1.2` as the next hop:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# route add -net 192.168.2.0/24 192.168.1.2
|
||||
....
|
||||
|
|
@ -299,14 +299,14 @@ Connecting a computer to an existing wireless network is a very common situation
|
|||
. Obtain the SSID (Service Set Identifier) and PSK (Pre-Shared Key) for the wireless network from the network administrator.
|
||||
. Identify the wireless adapter. The FreeBSD [.filename]#GENERIC# kernel includes drivers for many common wireless adapters. If the wireless adapter is one of those models, it will be shown in the output from man:ifconfig[8]:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% ifconfig | grep -B3 -i wireless
|
||||
....
|
||||
+
|
||||
On FreeBSD 11 or higher, use this command instead:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% sysctl net.wlan.devices
|
||||
....
|
||||
|
|
@ -334,7 +334,7 @@ ifconfig_wlan0="WPA SYNCDHCP"
|
|||
|
||||
. Restart the computer, or restart the network service to connect to the network:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service netif restart
|
||||
....
|
||||
|
|
@ -398,7 +398,7 @@ With this information in the kernel configuration file, recompile the kernel and
|
|||
|
||||
Information about the wireless device should appear in the boot messages, like this:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
ath0: <Atheros 5212> mem 0x88000000-0x8800ffff irq 11 at device 0.0 on cardbus1
|
||||
ath0: [ITHREAD]
|
||||
|
|
@ -411,14 +411,14 @@ Since the regulatory situation is different in various parts of the world, it is
|
|||
|
||||
The available region definitions can be found in [.filename]#/etc/regdomain.xml#. To set the data at runtime, use `ifconfig`:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 regdomain ETSI country AT
|
||||
....
|
||||
|
||||
To persist the settings, add it to [.filename]#/etc/rc.conf#:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# sysrc create_args_wlan0="country AT regdomain ETSI"
|
||||
....
|
||||
|
|
@ -433,7 +433,7 @@ Infrastructure (BSS) mode is the mode that is typically used. In this mode, a nu
|
|||
|
||||
To scan for available networks, use man:ifconfig[8]. This request may take a few moments to complete as it requires the system to switch to each available wireless frequency and probe for available access points. Only the superuser can initiate a scan:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 create wlandev ath0
|
||||
# ifconfig wlan0 up scan
|
||||
|
|
@ -473,7 +473,7 @@ The output of a scan request lists each BSS/IBSS network found. Besides listing
|
|||
|
||||
One can also display the current list of known networks with:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 list scan
|
||||
....
|
||||
|
|
@ -551,14 +551,14 @@ ifconfig_wlan0="DHCP"
|
|||
|
||||
The wireless interface is now ready to bring up:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service netif start
|
||||
....
|
||||
|
||||
Once the interface is running, use man:ifconfig[8] to see the status of the interface [.filename]#ath0#:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0
|
||||
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
|
||||
|
|
@ -624,7 +624,7 @@ ifconfig_wlan0="WPA DHCP"
|
|||
|
||||
Then, bring up the interface:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service netif start
|
||||
Starting wpa_supplicant.
|
||||
|
|
@ -648,7 +648,7 @@ wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
|
|||
|
||||
Or, try to configure the interface manually using the information in [.filename]#/etc/wpa_supplicant.conf#:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
|
||||
Trying to associate with 00:11:95:c3:0d:ac (SSID='freebsdap' freq=2412 MHz)
|
||||
|
|
@ -659,7 +659,7 @@ CTRL-EVENT-CONNECTED - Connection to 00:11:95:c3:0d:ac completed (auth) [id=0 id
|
|||
|
||||
The next operation is to launch man:dhclient[8] to get the IP address from the DHCP server:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# dhclient wlan0
|
||||
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
|
||||
|
|
@ -685,7 +685,7 @@ If [.filename]#/etc/rc.conf# has an `ifconfig_wlan0="DHCP"` entry, man:dhclient[
|
|||
|
||||
If DHCP is not possible or desired, set a static IP address after man:wpa_supplicant[8] has authenticated the station:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 inet 192.168.0.100 netmask 255.255.255.0
|
||||
# ifconfig wlan0
|
||||
|
|
@ -703,7 +703,7 @@ wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
|
|||
|
||||
When DHCP is not used, the default gateway and the nameserver also have to be manually set:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# route add default your_default_router
|
||||
# echo "nameserver your_DNS_server" >> /etc/resolv.conf
|
||||
|
|
@ -755,7 +755,7 @@ ifconfig_wlan0="WPA DHCP"
|
|||
|
||||
The next step is to bring up the interface:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service netif start
|
||||
Starting wpa_supplicant.
|
||||
|
|
@ -814,7 +814,7 @@ ifconfig_wlan0="WPA DHCP"
|
|||
|
||||
The next step is to bring up the interface:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service netif start
|
||||
Starting wpa_supplicant.
|
||||
|
|
@ -881,7 +881,7 @@ ifconfig_wlan0="WPA DHCP"
|
|||
|
||||
Then, bring up the interface:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service netif start
|
||||
Starting wpa_supplicant.
|
||||
|
|
@ -909,7 +909,7 @@ Wired Equivalent Privacy (WEP) is part of the original 802.11 standard. There is
|
|||
|
||||
WEP can be set up using man:ifconfig[8]:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 create wlandev ath0
|
||||
# ifconfig wlan0 inet 192.168.1.100 netmask 255.255.255.0 \
|
||||
|
|
@ -940,7 +940,7 @@ network={
|
|||
|
||||
Then:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
|
||||
Trying to associate with 00:13:46:49:41:76 (SSID='dlinkap' freq=2437 MHz)
|
||||
|
|
@ -953,7 +953,7 @@ IBSS mode, also called ad-hoc mode, is designed for point to point connections.
|
|||
|
||||
On `A`:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 create wlandev ath0 wlanmode adhoc
|
||||
# ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap
|
||||
|
|
@ -972,7 +972,7 @@ The `adhoc` parameter indicates that the interface is running in IBSS mode.
|
|||
|
||||
`B` should now be able to detect `A`:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 create wlandev ath0 wlanmode adhoc
|
||||
# ifconfig wlan0 up scan
|
||||
|
|
@ -982,7 +982,7 @@ The `adhoc` parameter indicates that the interface is running in IBSS mode.
|
|||
|
||||
The `I` in the output confirms that `A` is in ad-hoc mode. Now, configure `B` with a different IP address:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 inet 192.168.0.2 netmask 255.255.255.0 ssid freebsdap
|
||||
# ifconfig wlan0
|
||||
|
|
@ -1015,7 +1015,7 @@ The NDIS driver wrapper for Windows(R) drivers does not currently support AP ope
|
|||
|
||||
Once wireless networking support is loaded, check if the wireless device supports the host-based access point mode, also known as hostap mode:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 create wlandev ath0
|
||||
# ifconfig wlan0 list caps
|
||||
|
|
@ -1027,14 +1027,14 @@ This output displays the card's capabilities. The `HOSTAP` word confirms that th
|
|||
|
||||
The wireless device can only be put into hostap mode during the creation of the network pseudo-device, so a previously created device must be destroyed first:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 destroy
|
||||
....
|
||||
|
||||
then regenerated with the correct option before setting the other parameters:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 create wlandev ath0 wlanmode hostap
|
||||
# ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 ssid freebsdap mode 11g channel 1
|
||||
|
|
@ -1042,7 +1042,7 @@ then regenerated with the correct option before setting the other parameters:
|
|||
|
||||
Use man:ifconfig[8] again to see the status of the [.filename]#wlan0# interface:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0
|
||||
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
||||
|
|
@ -1072,7 +1072,7 @@ Although it is not recommended to run an AP without any authentication or encryp
|
|||
|
||||
Once the AP is configured, initiate a scan from another wireless machine to find the AP:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 create wlandev ath0
|
||||
# ifconfig wlan0 up scan
|
||||
|
|
@ -1082,7 +1082,7 @@ freebsdap 00:11:95:c3:0d:ac 1 54M -66:-96 100 ES WME
|
|||
|
||||
The client machine found the AP and can be associated with it:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 inet 192.168.0.2 netmask 255.255.255.0 ssid freebsdap
|
||||
# ifconfig wlan0
|
||||
|
|
@ -1144,12 +1144,12 @@ wpa_pairwise=CCMP <.>
|
|||
|
||||
The next step is to start man:hostapd[8]:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service hostapd forcestart
|
||||
....
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0
|
||||
wlan0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
||||
|
|
@ -1174,7 +1174,7 @@ It is not recommended to use WEP for setting up an AP since there is no authenti
|
|||
|
||||
The wireless device can now be put into hostap mode and configured with the correct SSID and IP address:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 create wlandev ath0 wlanmode hostap
|
||||
# ifconfig wlan0 inet 192.168.0.1 netmask 255.255.255.0 \
|
||||
|
|
@ -1186,7 +1186,7 @@ The wireless device can now be put into hostap mode and configured with the corr
|
|||
|
||||
Use man:ifconfig[8] to see the status of the [.filename]#wlan0# interface:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0
|
||||
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
||||
|
|
@ -1201,7 +1201,7 @@ Use man:ifconfig[8] to see the status of the [.filename]#wlan0# interface:
|
|||
|
||||
From another wireless machine, it is now possible to initiate a scan to find the AP:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 create wlandev ath0
|
||||
# ifconfig wlan0 up scan
|
||||
|
|
@ -1230,7 +1230,7 @@ Debugging support is provided by man:wpa_supplicant[8]. Try running this utility
|
|||
* Once the system can associate with the access point, diagnose the network configuration using tools like man:ping[8].
|
||||
* There are many lower-level debugging tools. Debugging messages can be enabled in the 802.11 protocol support layer using man:wlandebug[8]. For example, to enable console messages related to scanning for access points and the 802.11 protocol handshakes required to arrange communication:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# wlandebug -i wlan0 +scan+auth+debug+assoc
|
||||
net.wlan.0.debug: 0 => 0xc80000<assoc,auth,scan>
|
||||
|
|
@ -1251,7 +1251,7 @@ Many cellphones provide the option to share their data connection over USB (ofte
|
|||
|
||||
Before attaching a device, load the appropriate driver into the kernel:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# kldload if_urndis
|
||||
# kldload if_cdce
|
||||
|
|
@ -1262,7 +1262,7 @@ Once the device is attached ``ue``_0_ will be available for use like a normal ne
|
|||
|
||||
To make this change permanent and load the driver as a module at boot time, place the appropriate line of the following in [.filename]#/boot/loader.conf#:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
if_urndis_load="YES"
|
||||
if_cdce_load="YES"
|
||||
|
|
@ -1282,7 +1282,7 @@ The Bluetooth stack in FreeBSD is implemented using the man:netgraph[4] framewor
|
|||
|
||||
Before attaching a device, determine which of the above drivers it uses, then load the driver. For example, if the device uses the man:ng_ubt[4] driver:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# kldload ng_ubt
|
||||
....
|
||||
|
|
@ -1296,7 +1296,7 @@ ng_ubt_load="YES"
|
|||
|
||||
Once the driver is loaded, plug in the USB dongle. If the driver load was successful, output similar to the following should appear on the console and in [.filename]#/var/log/messages#:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
|
||||
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
|
||||
|
|
@ -1306,7 +1306,7 @@ ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3,
|
|||
|
||||
To start and stop the Bluetooth stack, use its startup script. It is a good idea to stop the stack before unplugging the device. Starting the bluetooth stack might require man:hcsecd[8] to be started. When starting the stack, the output should be similar to the following:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service bluetooth start ubt0
|
||||
BD_ADDR: 00:02:72:00:d4:1a
|
||||
|
|
@ -1328,7 +1328,7 @@ The Host Controller Interface (HCI) provides a uniform method for accessing Blue
|
|||
|
||||
One of the most common tasks is discovery of Bluetooth devices within RF proximity. This operation is called _inquiry_. Inquiry and other HCI related operations are done using man:hccontrol[8]. The example below shows how to find out which Bluetooth devices are in range. The list of devices should be displayed in a few seconds. Note that a remote device will only answer the inquiry if it is set to _discoverable_ mode.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% hccontrol -n ubt0hci inquiry
|
||||
Inquiry result, num_responses=1
|
||||
|
|
@ -1344,7 +1344,7 @@ Inquiry complete. Status: No error [00]
|
|||
|
||||
The `BD_ADDR` is the unique address of a Bluetooth device, similar to the MAC address of a network card. This address is needed for further communication with a device and it is possible to assign a human readable name to a `BD_ADDR`. Information regarding the known Bluetooth hosts is contained in [.filename]#/etc/bluetooth/hosts#. The following example shows how to obtain the human readable name that was assigned to the remote device:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4
|
||||
BD_ADDR: 00:80:37:29:19:a4
|
||||
|
|
@ -1357,7 +1357,7 @@ Remote devices can be assigned aliases in [.filename]#/etc/bluetooth/hosts#. Mor
|
|||
|
||||
The Bluetooth system provides a point-to-point connection between two Bluetooth units, or a point-to-multipoint connection which is shared among several Bluetooth devices. The following example shows how to create a connection to a remote device:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% hccontrol -n ubt0hci create_connection BT_ADDR
|
||||
....
|
||||
|
|
@ -1366,7 +1366,7 @@ The Bluetooth system provides a point-to-point connection between two Bluetooth
|
|||
|
||||
The following example shows how to obtain the list of active baseband connections for the local device:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% hccontrol -n ubt0hci read_connection_list
|
||||
Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State
|
||||
|
|
@ -1375,7 +1375,7 @@ Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State
|
|||
|
||||
A _connection handle_ is useful when termination of the baseband connection is required, though it is normally not required to do this by hand. The stack will automatically terminate inactive baseband connections.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# hccontrol -n ubt0hci disconnect 41
|
||||
Connection handle: 41
|
||||
|
|
@ -1431,7 +1431,7 @@ In FreeBSD, these profiles are implemented with man:ppp[8] and the man:rfcomm_pp
|
|||
|
||||
In this example, man:rfcomm_pppd[8] is used to open a connection to a remote device with a `BD_ADDR` of `00:80:37:29:19:a4` on a DUNRFCOMM channel:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup
|
||||
....
|
||||
|
|
@ -1440,7 +1440,7 @@ The actual channel number will be obtained from the remote device using the SDP
|
|||
|
||||
In order to provide network access with the PPPLAN service, man:sdpd[8] must be running and a new entry for LAN clients must be created in [.filename]#/etc/ppp/ppp.conf#. Consult man:rfcomm_pppd[8] for examples. Finally, start the RFCOMMPPP server on a valid RFCOMM channel number. The RFCOMMPPP server will automatically register the Bluetooth LAN service with the local SDP daemon. The example below shows how to start the RFCOMMPPP server.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# rfcomm_pppd -s -C 7 -l rfcomm-server
|
||||
....
|
||||
|
|
@ -1459,7 +1459,7 @@ In FreeBSD, a netgraph L2CAP node is created for each Bluetooth device. This nod
|
|||
|
||||
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.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# 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
|
||||
|
|
@ -1470,7 +1470,7 @@ A useful command is man:l2ping[8], which can be used to ping other devices. Some
|
|||
|
||||
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:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% l2control -a 00:02:72:00:d4:1a read_channel_list
|
||||
L2CAP channels:
|
||||
|
|
@ -1484,7 +1484,7 @@ Remote BD_ADDR Handle Flags Pending State
|
|||
|
||||
Another diagnostic tool is man:btsockstat[1]. It is similar to man:netstat[1], but for Bluetooth network-related data structures. The example below shows the same logical connection as man:l2control[8] above.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% btsockstat
|
||||
Active L2CAP sockets
|
||||
|
|
@ -1518,7 +1518,7 @@ Normally, a SDP client searches for services based on some desired characteristi
|
|||
|
||||
The Bluetooth SDP server, man:sdpd[8], and command line client, man:sdpcontrol[8], are included in the standard FreeBSD installation. The following example shows how to perform a SDP browse query.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% sdpcontrol -a 00:01:03:fc:6e:ec browse
|
||||
Record Handle: 00000000
|
||||
|
|
@ -1546,7 +1546,7 @@ Bluetooth Profile Descriptor List:
|
|||
|
||||
Note that each service has a list of attributes, such as the RFCOMM channel. Depending on the service, the user might need to make 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:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH
|
||||
....
|
||||
|
|
@ -1560,7 +1560,7 @@ sdpd_enable="YES"
|
|||
|
||||
Then the man:sdpd[8] daemon can be started with:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service sdpd start
|
||||
....
|
||||
|
|
@ -1569,7 +1569,7 @@ The local server application that wants to provide a Bluetooth service to remote
|
|||
|
||||
The list of services registered with the local SDP server can be obtained by issuing a SDP browse query via the local control channel:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# sdpcontrol -l browse
|
||||
....
|
||||
|
|
@ -1582,7 +1582,7 @@ The OBEX server and client are implemented by obexapp, which can be installed us
|
|||
|
||||
The OBEX client is used to push and/or pull objects from the OBEX server. An example object is a business card or an appointment. The OBEX client can obtain the RFCOMM channel number from the remote device via SDP. This can be done by specifying the service name instead of the RFCOMM channel number. Supported service names are: `IrMC`, `FTRN`, and `OPUSH`. It is also possible to specify the RFCOMM channel as a number. Below is an example of an OBEX session where the device information object is pulled from the cellular phone, and a new object, the business card, is pushed into the phone's directory.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% obexapp -a 00:80:37:29:19:a4 -C IrMC
|
||||
obex> get telecom/devinfo.txt devinfo-t39.txt
|
||||
|
|
@ -1595,7 +1595,7 @@ Success, response: OK, Success (0x20)
|
|||
|
||||
In order to provide the OPUSH service, man:sdpd[8] must be running and a root folder, where all incoming objects will be stored, must be created. The default path to the root folder is [.filename]#/var/spool/obex#. Finally, start the OBEX server on a valid RFCOMM channel number. The OBEX server will automatically register the OPUSH service with the local SDP daemon. The example below shows how to start the OBEX server.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# obexapp -s -C 10
|
||||
....
|
||||
|
|
@ -1606,7 +1606,7 @@ The Serial Port Profile (SPP) allows Bluetooth devices to perform serial cable e
|
|||
|
||||
In FreeBSD, man:rfcomm_sppd[1] implements SPP and a pseudo tty is used as a virtual serial port abstraction. The example below shows how to connect to a remote device's serial port service. A RFCOMM channel does not have to be specified as man:rfcomm_sppd[1] can obtain it from the remote device via SDP. To override this, specify a RFCOMM channel on the command line.
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# rfcomm_sppd -a 00:07:E0:00:0B:CA -t
|
||||
rfcomm_sppd[94692]: Starting on /dev/pts/6...
|
||||
|
|
@ -1615,7 +1615,7 @@ rfcomm_sppd[94692]: Starting on /dev/pts/6...
|
|||
|
||||
Once connected, the pseudo tty can be used as serial port:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# cu -l /dev/pts/6
|
||||
....
|
||||
|
|
@ -1632,7 +1632,7 @@ cu -l $PTS
|
|||
|
||||
By default, when FreeBSD is accepting a new connection, it tries to perform a role switch and become master. Some older Bluetooth devices which do not support role switching will not be able to connect. Since role switching is performed when a new connection is being established, it is not possible to ask the remote device if it supports role switching. However, there is a HCI option to disable role switching on the local side:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# hccontrol -n ubt0hci write_node_role_switch 0
|
||||
....
|
||||
|
|
@ -1678,7 +1678,7 @@ In FreeBSD, man:if_bridge[4] is a kernel module which is automatically loaded by
|
|||
|
||||
The bridge is created using interface cloning. To create the bridge interface:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig bridge create
|
||||
bridge0
|
||||
|
|
@ -1694,7 +1694,7 @@ When a bridge interface is created, it is automatically assigned a randomly gene
|
|||
|
||||
Next, specify which network interfaces to add as members of the bridge. For the bridge to forward packets, all member interfaces and the bridge need to be up:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig bridge0 addm fxp0 addm fxp1 up
|
||||
# ifconfig fxp0 up
|
||||
|
|
@ -1713,7 +1713,7 @@ ifconfig_fxp1="up"
|
|||
|
||||
If the bridge host needs an IP address, set it on the bridge interface, not on the member interfaces. The address can be set statically or via DHCP. This example sets a static IP address:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig bridge0 inet 192.168.0.1/24
|
||||
....
|
||||
|
|
@ -1735,7 +1735,7 @@ The Rapid Spanning Tree Protocol (RSTP or 802.1w) provides backwards compatibili
|
|||
|
||||
STP can be enabled on member interfaces using man:ifconfig[8]. For a bridge with [.filename]#fxp0# and [.filename]#fxp1# as the current interfaces, enable STP with:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig bridge0 stp fxp0 stp fxp1
|
||||
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
||||
|
|
@ -1755,7 +1755,7 @@ This bridge has a spanning tree ID of `00:01:02:4b:d4:50` and a priority of `327
|
|||
|
||||
Another bridge on the network also has STP enabled:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
||||
ether 96:3d:4b:f1:79:7a
|
||||
|
|
@ -1782,7 +1782,7 @@ A private interface does not forward any traffic to any other port that is also
|
|||
span::
|
||||
A span port transmits a copy of every Ethernet frame received by the bridge. The number of span ports configured on a bridge is unlimited, but if an interface is designated as a span port, it cannot also be used as a regular bridge port. This is most useful for snooping a bridged network passively on another host connected to one of the span ports of the bridge. For example, to send a copy of all frames out the interface named [.filename]#fxp4#:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig bridge0 span fxp4
|
||||
....
|
||||
|
|
@ -1792,7 +1792,7 @@ If a bridge member interface is marked as sticky, dynamically learned address en
|
|||
+
|
||||
An example of using sticky addresses is to combine the bridge with VLANs in order to isolate customer networks without wasting IP address space. Consider that `CustomerA` is on `vlan100`, `CustomerB` is on `vlan101`, and the bridge has the address `192.168.0.1`:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig bridge0 addm vlan100 sticky vlan100 addm vlan101 sticky vlan101
|
||||
# ifconfig bridge0 inet 192.168.0.1/24
|
||||
|
|
@ -1802,7 +1802,7 @@ In this example, both clients see `192.168.0.1` as their default gateway. Since
|
|||
+
|
||||
Any communication between the VLANs can be blocked using a firewall or, as seen in this example, private interfaces:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig bridge0 private vlan100 private vlan101
|
||||
....
|
||||
|
|
@ -1813,14 +1813,14 @@ The number of unique source MAC addresses behind an interface can be limited. On
|
|||
+
|
||||
The following example sets the maximum number of Ethernet devices for `CustomerA` on `vlan100` to 10:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig bridge0 ifmaxaddr vlan100 10
|
||||
....
|
||||
|
||||
Bridge interfaces also support monitor mode, where the packets are discarded after man:bpf[4] processing and are not processed or forwarded further. This can be used to multiplex the input of two or more interfaces into a single man:bpf[4] stream. This is useful for reconstructing the traffic for network taps that transmit the RX/TX signals out through two separate interfaces. For example, to read the input from four network interfaces as one stream:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig bridge0 addm fxp0 addm fxp1 addm fxp2 addm fxp3 monitor up
|
||||
# tcpdump -i bridge0
|
||||
|
|
@ -1846,7 +1846,7 @@ bsnmpd_enable="YES"
|
|||
|
||||
Then, start man:bsnmpd[1]:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service bsnmpd start
|
||||
....
|
||||
|
|
@ -1861,7 +1861,7 @@ mibs +BRIDGE-MIB:RSTP-MIB:BEGEMOT-MIB:BEGEMOT-BRIDGE-MIB
|
|||
|
||||
To monitor a single bridge using the IETF BRIDGE-MIB (RFC4188):
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% snmpwalk -v 2c -c public bridge1.example.com mib-2.dot1dBridge
|
||||
BRIDGE-MIB::dot1dBaseBridgeAddress.0 = STRING: 66:fb:9b:6e:5c:44
|
||||
|
|
@ -1885,7 +1885,7 @@ The `dot1dStpTopChanges.0` value is two, indicating that the STP bridge topology
|
|||
|
||||
To monitor multiple bridge interfaces, the private BEGEMOT-BRIDGE-MIB can be used:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% snmpwalk -v 2c -c public bridge1.example.com
|
||||
enterprises.fokus.begemot.begemotBridge
|
||||
|
|
@ -1906,7 +1906,7 @@ BEGEMOT-BRIDGE-MIB::begemotBridgeStpDesignatedRoot."bridge2" = Hex-STRING: 80 00
|
|||
|
||||
To change the bridge interface being monitored via the `mib-2.dot1dBridge` subtree:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
% snmpset -v 2c -c private bridge1.example.com
|
||||
BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2
|
||||
|
|
@ -1947,7 +1947,7 @@ Frame ordering is mandatory on Ethernet links and any traffic between two statio
|
|||
|
||||
On the Cisco(R) switch, add the _FastEthernet0/1_ and _FastEthernet0/2_ interfaces to channel group _1_:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
interface FastEthernet0/1
|
||||
channel-group 1 mode active
|
||||
|
|
@ -1960,7 +1960,7 @@ interface FastEthernet0/2
|
|||
|
||||
On the FreeBSD system, create the man:lagg[4] interface using the physical interfaces _fxp0_ and _fxp1_ and bring the interfaces up with an IP address of _10.0.0.3/24_:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig fxp0 up
|
||||
# ifconfig fxp1 up
|
||||
|
|
@ -1970,7 +1970,7 @@ On the FreeBSD system, create the man:lagg[4] interface using the physical inter
|
|||
|
||||
Next, verify the status of the virtual interface:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig lagg0
|
||||
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
||||
|
|
@ -1988,7 +1988,7 @@ Ports marked as `ACTIVE` are part of the LAG that has been negotiated with the r
|
|||
|
||||
To see the port status on the Cisco(R) switch:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
switch# show lacp neighbor
|
||||
Flags: S - Device is requesting Slow LACPDUs
|
||||
|
|
@ -2026,7 +2026,7 @@ ifconfig_lagg0="laggproto lacp laggport fxp0 laggport fxp1 10.0.0.3/24"
|
|||
|
||||
Failover mode can be used to switch over to a secondary interface if the link is lost on the master interface. To configure failover, make sure that the underlying physical interfaces are up, then create the man:lagg[4] interface. In this example, _fxp0_ is the master interface, _fxp1_ is the secondary interface, and the virtual interface is assigned an IP address of _10.0.0.15/24_:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig fxp0 up
|
||||
# ifconfig fxp1 up
|
||||
|
|
@ -2036,7 +2036,7 @@ Failover mode can be used to switch over to a secondary interface if the link is
|
|||
|
||||
The virtual interface should look something like this:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig lagg0
|
||||
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
||||
|
|
@ -2085,7 +2085,7 @@ If the driver for the wireless interface is not loaded in the `GENERIC` or custo
|
|||
|
||||
In this example, the Ethernet interface, _re0_, is the master and the wireless interface, _wlan0_, is the failover. The _wlan0_ interface was created from the _ath0_ physical wireless interface, and the Ethernet interface will be configured with the MAC address of the wireless interface. First, determine the MAC address of the wireless interface:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0
|
||||
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
||||
|
|
@ -2103,21 +2103,21 @@ wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
|||
|
||||
Replace _wlan0_ to match the system's wireless interface name. The `ether` line will contain the MAC address of the specified interface. Now, change the MAC address of the Ethernet interface:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig re0 ether b8:ee:65:5b:32:59
|
||||
....
|
||||
|
||||
Bring the wireless interface up (replacing _FR_ with your own 2-letter country code), but do not set an IP address:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig wlan0 create wlandev ath0 country FR ssid my_router up
|
||||
....
|
||||
|
||||
Make sure the _re0_ interface is up, then create the man:lagg[4] interface with _re0_ as master with failover to _wlan0_:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig re0 up
|
||||
# ifconfig lagg0 create
|
||||
|
|
@ -2126,7 +2126,7 @@ Make sure the _re0_ interface is up, then create the man:lagg[4] interface with
|
|||
|
||||
The virtual interface should look something like this:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig lagg0
|
||||
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
||||
|
|
@ -2142,7 +2142,7 @@ lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
|
|||
|
||||
Then, start the DHCP client to obtain an IP address:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# dhclient lagg0
|
||||
....
|
||||
|
|
@ -2190,7 +2190,7 @@ The steps shown in this section configure the built-in NFS and TFTP servers. The
|
|||
[.procedure]
|
||||
. Create the root directory which will contain a FreeBSD installation to be NFS mounted:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# export NFSROOTDIR=/b/tftpboot/FreeBSD/install
|
||||
# mkdir -p ${NFSROOTDIR}
|
||||
|
|
@ -2212,7 +2212,7 @@ nfs_server_enable="YES"
|
|||
|
||||
. Start the NFS server:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service nfsd start
|
||||
....
|
||||
|
|
@ -2238,7 +2238,7 @@ Some PXE versions require the TCP version of TFTP. In this case, uncomment the s
|
|||
|
||||
. Start man:inetd[8]:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service inetd start
|
||||
....
|
||||
|
|
@ -2246,7 +2246,7 @@ Some PXE versions require the TCP version of TFTP. In this case, uncomment the s
|
|||
. Install the base system into [.filename]#${NFSROOTDIR}#, either by decompressing the official archives or by rebuilding the FreeBSD kernel and userland (refer to crossref:cutting-edge[makeworld,“Updating FreeBSD from Source”] for more detailed instructions, but do not forget to add `DESTDIR=_${NFSROOTDIR}_` when running the `make installkernel` and `make installworld` commands.
|
||||
. Test that the TFTP server works and can download the boot loader which will be obtained via PXE:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# tftp localhost
|
||||
tftp> get FreeBSD/install/boot/pxeboot
|
||||
|
|
@ -2264,7 +2264,7 @@ myhost.example.com:/b/tftpboot/FreeBSD/install / nfs ro
|
|||
Replace _myhost.example.com_ with the hostname or IP address of the 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 PXE environment for client machines which are PXE booting :
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# chroot ${NFSROOTDIR}
|
||||
# passwd
|
||||
|
|
@ -2275,7 +2275,7 @@ Replace _myhost.example.com_ with the hostname or IP address of the NFS server.
|
|||
|
||||
When booting from an NFS root volume, [.filename]#/etc/rc# detects the NFS boot and runs [.filename]#/etc/rc.initdiskless#. In this case, [.filename]#/etc# and [.filename]#/var# need to be memory backed file systems so that these directories are writable but the NFS root directory is read-only:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# chroot ${NFSROOTDIR}
|
||||
# mkdir -p conf/base
|
||||
|
|
@ -2331,7 +2331,7 @@ dhcpd_enable="YES"
|
|||
|
||||
Then start the DHCP service:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# service isc-dhcpd start
|
||||
....
|
||||
|
|
@ -2361,7 +2361,7 @@ image::pxe-nfs.png[]
|
|||
+
|
||||
. On the TFTP server, read [.filename]#/var/log/xferlog# to ensure that [.filename]#pxeboot# is being retrieved from the correct location. To test this example configuration:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# tftp 192.168.0.1
|
||||
tftp> get FreeBSD/install/boot/pxeboot
|
||||
|
|
@ -2371,7 +2371,7 @@ Received 264951 bytes in 0.1 seconds
|
|||
The `BUGS` sections in man:tftpd[8] and man:tftp[1] document some limitations with TFTP.
|
||||
. Make sure that the root file system can be mounted via NFS. To test this example configuration:
|
||||
+
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# mount -t nfs 192.168.0.1:/b/tftpboot/FreeBSD/install /mnt
|
||||
....
|
||||
|
|
@ -2415,7 +2415,7 @@ A third form is to write the last 32 bits using the well known IPv4 notation. Fo
|
|||
|
||||
To view a FreeBSD system's IPv6 address, use man:ifconfig[8]:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig
|
||||
....
|
||||
|
|
@ -2628,7 +2628,7 @@ carp_load="YES"
|
|||
|
||||
To load the module now without rebooting:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# kldload carp
|
||||
....
|
||||
|
|
@ -2674,7 +2674,7 @@ Having two CARPVHIDs configured means that `hostc.example.org` will notice if ei
|
|||
====
|
||||
If the original master server becomes available again, `hostc.example.org` will not release the virtual IP address back to it automatically. For this to happen, preemption has to be enabled. The feature is disabled by default, it is controlled via the man:sysctl[8] variable `net.inet.carp.preempt`. The administrator can force the backup server to return the IP address to the master:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig em0 vhid 1 state backup
|
||||
....
|
||||
|
|
@ -2699,7 +2699,7 @@ if_carp_load="YES"
|
|||
|
||||
To load the module now without rebooting:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# kldload carp
|
||||
....
|
||||
|
|
@ -2713,7 +2713,7 @@ device carp
|
|||
|
||||
Next, on each host, create a CARP device:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig carp0 create
|
||||
....
|
||||
|
|
@ -2753,7 +2753,7 @@ ifconfig_carp1="vhid 2 advskew 100 pass testpass 192.168.1.51/24"
|
|||
====
|
||||
Preemption is disabled in the [.filename]#GENERIC# FreeBSD kernel. If preemption has been enabled with a custom kernel, `hostc.example.org` may not release the IP address back to the original content server. The administrator can force the backup server to return the IP address to the master with the command:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig carp0 down && ifconfig carp0 up
|
||||
....
|
||||
|
|
@ -2774,7 +2774,7 @@ When configuring a VLAN, a couple pieces of information must be known. First, wh
|
|||
|
||||
To configure VLANs at run time, with a NIC of `em0` and a VLAN tag of `5` the command would look like this:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig em0.5 create vlan 5 vlandev em0 inet 192.168.20.20/24
|
||||
....
|
||||
|
|
@ -2798,14 +2798,14 @@ It is useful to assign a symbolic name to an interface so that when the associat
|
|||
|
||||
To configure VLAN `5`, on the NIC `em0`, assign the interface name `cameras`, and assign the interface an IP address of `_192.168.20.20_` with a `24`-bit prefix, use this command:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig em0.5 create vlan 5 vlandev em0 name cameras inet 192.168.20.20/24
|
||||
....
|
||||
|
||||
For an interface named `video`, use the following:
|
||||
|
||||
[source,bash]
|
||||
[source,shell]
|
||||
....
|
||||
# ifconfig video.5 create vlan 5 vlandev video name cameras inet 192.168.20.20/24
|
||||
....
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue