porting.doxygen 10.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209
  1. /**
  2. \page porting Porting to different target boards and operating systems
  3. wpa_supplicant was designed to be easily portable to different
  4. hardware (board, CPU) and software (OS, drivers) targets. It is
  5. already used with number of operating systems and numerous wireless
  6. card models and drivers. The main wpa_supplicant repository includes
  7. support for Linux, FreeBSD, and Windows. In addition, the code has been
  8. ported to number of other operating systems like VxWorks, PalmOS,
  9. Windows CE, and Windows Mobile. On the hardware
  10. side, wpa_supplicant is used on various systems: desktops, laptops,
  11. PDAs, and embedded devices with CPUs including x86, PowerPC,
  12. arm/xscale, and MIPS. Both big and little endian configurations are
  13. supported.
  14. \section ansi_c_extra Extra functions on top of ANSI C
  15. wpa_supplicant is mostly using ANSI C functions that are available on
  16. most targets. However, couple of additional functions that are common
  17. on modern UNIX systems are used. Number of these are listed with
  18. prototypes in \ref common.h (the \verbatim #ifdef CONFIG_ANSI_C_EXTRA \endverbatim
  19. block). These functions may need to be implemented or at least defined
  20. as macros to native functions in the target OS or C library.
  21. Many of the common ANSI C functions are used through a wrapper
  22. definitions in \ref os.h to allow these to be replaced easily with a
  23. platform specific version in case standard C libraries are not
  24. available. In addition, \ref os.h defines couple of common platform
  25. specific functions that are implemented in \ref os_unix.c for UNIX like
  26. targets and in \ref os_win32.c for Win32 API. If the target platform does
  27. not support either of these examples, a new os_*.c file may need to be
  28. added.
  29. Unless OS_NO_C_LIB_DEFINES is defined, the standard ANSI C and POSIX
  30. functions are used by defining the os_*() wrappers to use them
  31. directly in order to avoid extra cost in size and speed. If the target
  32. platform needs different versions of the functions, \ref os.h can be
  33. modified to define the suitable macros or alternatively,
  34. OS_NO_C_LIB_DEFINES may be defined for the build and the wrapper
  35. functions can then be implemented in a new os_*.c wrapper file.
  36. \ref common.h defines number of helper macros for handling integers of
  37. different size and byte order. Suitable version of these definitions
  38. may need to be added for the target platform.
  39. \section configuration_backend Configuration backend
  40. wpa_supplicant implements a configuration interface that allows the
  41. backend to be easily replaced in order to read configuration data from
  42. a suitable source depending on the target platform. \ref config.c
  43. implements the generic code that can be shared with all configuration
  44. backends. Each backend is implemented in its own config_*.c file.
  45. The included \ref config_file.c backend uses a text file for configuration
  46. and \ref config_winreg.c uses Windows registry. These files can be used as
  47. an example for a new configuration backend if the target platform uses
  48. different mechanism for configuration parameters. In addition,
  49. \ref config_none.c can be used as an empty starting point for building a
  50. new configuration backend.
  51. \section driver_iface_porting Driver interface
  52. Unless the target OS and driver is already supported, most porting
  53. projects have to implement a driver wrapper. This may be done by
  54. adding a new driver interface module or modifying an existing module
  55. (driver_*.c) if the new target is similar to one of them. \ref
  56. driver_wrapper "Driver wrapper implementation" describes the details
  57. of the driver interface and discusses the tasks involved in porting
  58. this part of wpa_supplicant.
  59. \section l2_packet_porting l2_packet (link layer access)
  60. wpa_supplicant needs to have access to sending and receiving layer 2
  61. (link layer) packets with two Ethertypes: EAP-over-LAN (EAPOL) 0x888e
  62. and RSN pre-authentication 0x88c7. \ref l2_packet.h defines the interfaces
  63. used for this in the core wpa_supplicant implementation.
  64. If the target operating system supports a generic mechanism for link
  65. layer access, that is likely the best mechanism for providing the
  66. needed functionality for wpa_supplicant. Linux packet socket is an
  67. example of such a generic mechanism. If this is not available, a
  68. separate interface may need to be implemented to the network stack or
  69. driver. This is usually an intermediate or protocol driver that is
  70. operating between the device driver and the OS network stack. If such
  71. a mechanism is not feasible, the interface can also be implemented
  72. directly in the device driver.
  73. The main wpa_supplicant repository includes l2_packet implementations
  74. for Linux using packet sockets (\ref l2_packet_linux.c), more portable
  75. version using libpcap/libdnet libraries (\ref l2_packet_pcap.c; this
  76. supports WinPcap, too), and FreeBSD specific version of libpcap
  77. interface (\ref l2_packet_freebsd.c).
  78. If the target operating system is supported by libpcap (receiving) and
  79. libdnet (sending), \ref l2_packet_pcap.c can likely be used with minimal or
  80. no changes. If this is not a case or a proprietary interface for link
  81. layer is required, a new l2_packet module may need to be
  82. added. Alternatively, for hostapd,
  83. struct \ref wpa_driver_ops::hapd_send_eapol() handler can
  84. be used to override the l2_packet library if the link layer access is
  85. integrated with the driver interface implementation.
  86. \section eloop_porting Event loop
  87. wpa_supplicant uses a single process/thread model and an event loop
  88. to provide callbacks on events (registered timeout, received packet,
  89. signal). eloop.h defines the event loop interface. \ref eloop.c is an
  90. implementation of such an event loop using select() and sockets. This
  91. is suitable for most UNIX/POSIX systems. When porting to other
  92. operating systems, it may be necessary to replace that implementation
  93. with OS specific mechanisms that provide similar functionality.
  94. \section ctrl_iface_porting Control interface
  95. wpa_supplicant uses a \ref ctrl_iface_page "control interface"
  96. to allow external processed
  97. to get status information and to control the operations. Currently,
  98. this is implemented with socket based communication; both UNIX domain
  99. sockets and UDP sockets are supported. If the target OS does not
  100. support sockets, this interface will likely need to be modified to use
  101. another mechanism like message queues. The control interface is
  102. optional component, so it is also possible to run wpa_supplicant
  103. without porting this part.
  104. The wpa_supplicant side of the control interface is implemented in
  105. \ref wpa_supplicant/ctrl_iface.c. Matching client side is implemented as a control
  106. interface library in \ref wpa_ctrl.c.
  107. \section entry_point Program entry point
  108. wpa_supplicant defines a set of functions that can be used to
  109. initialize main supplicant processing. Each operating system has a
  110. mechanism for starting new processing or threads. This is usually a
  111. function with a specific set of arguments and calling convention. This
  112. function is responsible on initializing wpa_supplicant.
  113. \ref wpa_supplicant/main.c includes an entry point for UNIX-like
  114. operating system, i.e., main() function that uses command line arguments
  115. for setting parameters for wpa_supplicant. When porting to other
  116. operating systems, similar OS-specific entry point implementation is
  117. needed. It can be implemented in a new file that is then linked with
  118. wpa_supplicant instead of main.o. \ref wpa_supplicant/main.c is also a
  119. good example on how the initialization process should be done.
  120. The supplicant initialization functions are defined in
  121. \ref wpa_supplicant_i.h. In most cases, the entry point function should
  122. start by fetching configuration parameters. After this, a global
  123. wpa_supplicant context is initialized with a call to
  124. \ref wpa_supplicant_init(). After this, existing network interfaces can be
  125. added with \ref wpa_supplicant_add_iface(). \ref wpa_supplicant_run() is then
  126. used to start the main event loop. Once this returns at program
  127. termination time, \ref wpa_supplicant_deinit() is used to release global
  128. context data.
  129. \ref wpa_supplicant_add_iface() and \ref wpa_supplicant_remove_iface() can be
  130. used dynamically to add and remove interfaces based on when
  131. wpa_supplicant processing is needed for them. This can be done, e.g.,
  132. when hotplug network adapters are being inserted and ejected. It is
  133. also possible to do this when a network interface is being
  134. enabled/disabled if it is desirable that wpa_supplicant processing
  135. for the interface is fully enabled/disabled at the same time.
  136. \section simple_build Simple build example
  137. One way to start a porting project is to begin with a very simple
  138. build of wpa_supplicant with WPA-PSK support and once that is
  139. building correctly, start adding features.
  140. Following command can be used to build very simple version of
  141. wpa_supplicant:
  142. \verbatim
  143. cc -o wpa_supplicant config.c eloop.c common.c md5.c rc4.c sha1.c \
  144. config_none.c l2_packet_none.c tls_none.c wpa.c preauth.c \
  145. aes_wrap.c wpa_supplicant.c events.c main_none.c drivers.c
  146. \endverbatim
  147. The end result is not really very useful since it uses empty functions
  148. for configuration parsing and layer 2 packet access and does not
  149. include a driver interface. However, this is a good starting point
  150. since the build is complete in the sense that all functions are
  151. present and this is easy to configure to a build system by just
  152. including the listed C files.
  153. Once this version can be build successfully, the end result can be
  154. made functional by adding a proper program entry point (main*.c),
  155. driver interface (driver_*.c and matching CONFIG_DRIVER_* define for
  156. registration in \ref drivers.c), configuration parser/writer (config_*.c),
  157. and layer 2 packet access implementation (l2_packet_*.c). After these
  158. components have been added, the end result should be a working
  159. WPA/WPA2-PSK enabled supplicant.
  160. After the basic functionality has been verified to work, more features
  161. can be added by linking in more files and defining C pre-processor
  162. defines. Currently, the best source of information for what options
  163. are available and which files needs to be included is in the Makefile
  164. used for building the supplicant with make. Similar configuration will
  165. be needed for build systems that either use different type of make
  166. tool or a GUI-based project configuration.
  167. */