| 85 | [[Image(p2.png)]] [[BR]] |
| 86 | |
| 87 | Though the packet sockets API provides a mechanism using which we can develop this module, it has the following drawbacks: |
| 88 | * Type demultiplexing is the only filtering function provided by the sockets API whereas our requirements are for a much wider variety of filters. |
| 89 | * It is comparatively much less portable across architectures. |
| 90 | * It forces the application developer to deal with system-specific details. |
| 91 | * It is time-consuming considering the amount of functionality that needs to be added. |
| 92 | |
| 93 | Design choice II and the drawbacks of the packet sockets API lead us to the choice of using public-domain shared libraries that provide APIs for frame injection and capture. |
| 94 | |
| 95 | The choice of using these particular libraries was motivated by the stable nature of the executables, the open-source nature of the source code, their active maintenance and the presence of mailing lists and tutorials. In addition, these libraries have been thoroughly tested by a wide variety of open-source and commercial products. They were written primarily because of the drawbacks of the packet sockets API and their advantages include: |
| 96 | * Providing the user with high-level and simplified interface and hiding the complexity of underlying system from application programmer. |
| 97 | * Portability across multiple architectures. |
| 98 | |
| 99 | The figure below shows how the framework will be built on top of the libnet~\cite{Libnet+doc} and libpcap~\cite{Libpcap+doc} libraries, which in turn will be used in the lowest module. This diagram also shows how the envisioned framework will co-exist in parallel with the TCP/UDP sockets API, which uses the networking protocols implemented in the kernel. |
| 100 | |
| 101 | [[Image(p3.png)]] [[BR]] |
| 102 | |
| 103 | The rest of the report will discuss the lowest module, implemented as the shared library, \textbf{Libmac~\cite{Libmac+manual}}. |