Next: , Previous: Library, Up: Top


3 FAQ

3.1 What systems does WiPal support?

WiPal was mostly designed using standard C++ and portable libraries. It however uses a few GCC extensions. Yet WiPal should run fine on most systems (e.g. GNU/Linux, WhateverBSD, Mac OS, Windows, ...).

WiPal is however exclusively tested on Debian GNU/Linux (amd64 and, to a lower extent, powerpc). Which means you might experience problems on other systems, which the developers might not be aware of. In this case, please give feedback to them so they can fix it. Anyway, there should be no major obstacle to WiPal's portability.

3.2 What are WiPal's requirements?

WiPal needs:

3.3 How do I install WiPal?

WiPal's packaging follows the GNU conventions. An installation documentation is provided in the INSTALL file in the package's root directory. However, with a standard system, the following commands should do the trick:

     mkdir _build
     cd _build
     ../configure
     make
     make install-strip
     make check

On some systems, you might have to customize the configure script's invocation. e.g.:

     mkdir _build
     cd _build
     ../configure CPPFLAGS=-I/foo/bar/libgmp
     make
     make install-strip
     make check

3.4 Are there any options to optimize WiPal when building it?

You might want to compile WiPal with the NDEBUG preprocessor symbol defined. If you use GCC you might also want to use its -O3 option. You can do that by running configure with the following options:

     ./configure CPPFLAGS=-DNDEBUG CXXFLAGS=-O3

3.5 Gee! WiPal's compilation takes long and requires a lot of memory!

WiPal heavily uses static C++ mechanisms and a full build requires instantiating many templates. This results in a long build process that requires much memory. You may disable some template instantiations to have a faster and lighter build process. This will however remove some features at the end. You may invoke configure with the following options:

--enable-linktypes=LT1:LT2:...
will only enable the listed PCAP link types when compiling WiPal. The available link types are:
IEEE802_11
raw IEEE 802.11 frames,
IEEE802_11_RADIO
Radiotap headers,
IEEE802_11_RADIO_AVS
AVS headers,
PRISM_HEADER
Prism headers,
EN10MB
Ethernet II.

--enable-attributes=A1:A2:...
will only enable the listed unique frame attributes (see Unique frames) when compiling WiPal. The list's first attribute specifier is the default one (when -a is not provided on the command line). Available attributes are:

If you know you are going to need only one PCAP link type (e.g. Prism headers), and you do not want to test various attributes, a good choice might be:

     ./configure --enable-linktypes=PRISM_HEADER --enable-attributes=hsh_80211

which will only instantiate one template configuration for each WiPal utility.

3.6 Do WiPal's tools have a verbose mode to report extra information about their operation?

There is no such options that can be activated dynamically. You might want however to compile WiPal with the WP_ENABLE_INFO preprocessor symbol defined. This will enable the printing of some extra information in some tools as they run (e.g. number of processed frames, synchronization error, etc.). Invoke the configure script with the following option:

     ./configure CPPFLAGS=-DWP_ENABLE_INFO

Note however that this may slow some tools down and may require more memory.

3.7 You say WiPal is flexible and customizable. Is there a way to customize WiPal's tools beyond the options they propose?

Yes! But this requires recompiling WiPal's tools, and sometimes modifying a few lines of their source code.

3.8 configure complains it did not find library X?

Either library X is not installed on your system, either your system is not properly configured, so the library cannot be found.

You may use the CPPFLAGS and LDFLAGS variables to correct this behavior.

e.g., run

     ./configure CPPFLAGS=-I/custom/path/include \
                 LDFLAGS=-L/custom/path/lib

3.9 configure complains it found library X's headers, but is unable to link?

Most probably library X is installed but its binaries are in a non-standard place. Use the LDFLAGS variable as described previously.

3.10 configure complains library X's headers are unusable, despite successful linking?

Most probably library X is installed but its headers are in a non-standard place. Use the CPPFLAGS variable as described previously.

3.11 Do you have a list of WiPal's bugs?

No. We are not aware of any serious bug in WiPal. We take a special care at testing WiPal with an automated test suite. Do not hesitate to report unknown bugs to the package's maintainers. We will hunt them.

With some tools, you might however encounter some strange behaviors when providing invalid inputs (e.g. running wipal-find-data-dups a:b with b having a link type different from a). Consider that as a “feature”! ;-)

3.12 I have found a bug, what should I do?

Report it to the package's maintainers.

3.13 I would really love having feature X implemented!

Give feedback to the package's maintainers about the features you want. We might not have the time to implement them, yet it is important for us to know when important features are missing.

Regarding features you miss, you are greatly encouraged to contribute to WiPal. Again, contact the package's maintainers so they can help you implement new features.

3.14 I have a question this file did not answer!

Mail the package's maintainers.