[ Pobierz całość w formacie PDF ]
6.2.1 Wireless Kernel Configuration
In order to use wireless NICs, the kernel must be configured to support your
wireless networking card. The process of compiling an OpenBSD kernel is
outside the scope of this book. For more information on compiling a custom
OpenBSD kernel, see http://www.openbsd.org/faq/faq5.html and the
options(4) manual page.
When compiling an OpenBSD kernel, there are two different files that you
may need to edit in order to add or remove all of the required options. The
first configuration file, /usr/src/sys/conf/GENERIC, contains options that are
common across all the architectures OpenBSD can run on. OpenBSD has
been ported to many platforms, including i386, Sparc, PowerPC, and VAX.
Some options, such as firewalling and IPv6 support, are shared between all
the platforms, and therefore when you change an option in
/usr/src/sys/conf/GENERIC, it will be reflected in any kernel you build for
any platform.
The second file is the platform-specific file found in /usr/src/sys/arch/
type>/conf/. The is whatever architecture you're running on,
which in most cases is i386. There is a GENERIC file in the architecture
specific directory. You may edit this file directly or copy it to a new name,
such as the hostname of your machine in all caps, for editing.
Your wireless card will probably be either PCI-based or PCMCIA-based.
Add the appropriate options and devices to your architecture-specific
configuration file:
# PCI PCMCIA controllers
pcic* at pci? dev? function ?
# PCMCIA bus support
pcmcia* at pcic? controller ? socket ?
pcmcia* at tcic? controller ? socket ?
You must then add the proper devices for your particular wireless card. The
wi driver works with Prism II-based cards as well as Hermes cards such as
the Orinoco Silver. The an driver works with the Cisco wireless cards. Add
the correct driver for your card. Note that there are different configuration
lines depending on whether your card is PCI or PCMCIA based:
wi* at pci? dev ? function ? #
WaveLAN IEEE 802.11DS
wi* at pcmcia? function ? #
WaveLAN IEEE 802.11DS
an* at pci? dev ? function ? #
Aironet IEEE 802.11DS
an* at pcmcia? function ? #
Aironet IEEE 802.11DS
Now that you have support for your wireless cards, remove support for
anything you do not need. For example, the GENERIC configuration file has
many SCSI controllers and ISA network cards turned on by default.
Comment out any devices you do not have. Once you have stripped down
both the architecture-specific configuration file and the global file, compile
your kernel according to the instructions on the OpenBSD web site. Verify
your machine is operating as you expect it to. Once you have a functioning,
bare-bones kernel, continue on to the security-specific configuration.
6.2.2 Security Kernel Configuration
The OpenBSD development teams place security above almost all else.
Because of this, there are many security-specific options that you can and
should compile into your kernel. Most of these options are in the global
kernel configuration file that is found in /usr/src/sys/conf/GENERIC.
OpenBSD has a cryptographic framework that allows drivers to hook into
cryptographic services provided by the kernel. The IPsec implementation
relies heavily upon the cryptographic framework. If you plan on using IPsec,
enable this support with the following option:
option CRYPTO # Cryptographic
framework
If you plan to use IPsec to secure your traffic, you will need to compile in
IPsec support:
option IPSEC # IPsec
OpenBSD's firewall is provided a mechanism called packet filter (pf ). pf
provides a device (/dev/pf ) to allow userland control of the firewall.
Through /dev/pf you can issue ioctl calls to add and remove rulesets, gather
statistics on the firewall, and enable or disable the firewall completely.
Through the use of pflog, pf can also provide packets to userland processes
through a pseudo-interface called pflog. A firewall ruleset can log all denied
packets to a pflog interface (such as pflog0) and a sniffer program such as
tcpdump can monitor all the logged traffic. You should enable both pf and
pflog:
pseudo-device pf 1 # packet filter
pseudo-device pflog 1 # pf log if
Finally, you should enable the ability to promiscuously sniff traffic from
local interfaces. This ability can help greatly in debugging network problems
and in using network-monitoring tools. This is accomplished through the use
of a Berkeley Packet Filter (bpfilter). bpfilter will create a certain number of
devices that will limit the number of connections processes can make to
promiscuous interfaces. For example, if you have four different interfaces,
then you will probably want four bpfilter instances so you can sniff on all
interfaces at once:
pseudo-device bpfilter 4 # packet filter
6.2.3 Card Configuration
There are several different ways to manipulate the wireless network card
once the system is online. For Prism II and Hermes-based cards, the
wicontrol utility can be used to configure wireless specific parameters. For
Cisco Aironet cards the ancontrol utility is used instead. Some wireless
capability has been added for all chipsets into the standard ifconfig utility.
However you choose to configure your wireless network, you must be sure
you configure your IP-specific parameters as well.
The following parameters are the more commonly used features of
wicontrol. For a complete list, please see the wicontrol manual page.
interface
This is the interface that wicontrol should operate on. If no interface is
specified, wi0 is assumed. If no other flags are passed to wicontrol,
wicontrol will print out the existing configuration and statistics of the
interface.
-n network name
This parameter specifies the name of the service set to join. In
infrastructure mode, this would be the ESSID and in IBSS mode this
would be the SSID of the network you wish to join. An empty string
instructs the card to associate to the strongest available service set.
-s station name
The station name is the value your station is to be known by on the
network. Certain diagnostic and monitoring utilities will attempt to
determine the station name in an effort to uniquely identify the end
host. This is not required and should not be set.
-f channel
This parameter indicates what channel the card should use to
communicate with the access point. This value must be the same as
the access point's channel or else association will not be possible. If
no channel is specified, the card will scan all channels in an attempt to
find an available access point.
-p port type
This specifies the type of network to join. A value of 1 or bss will
cause the card to only associate to infrastructure mode access points.
[ Pobierz całość w formacie PDF ]