Removing Wifi documentation after learning more about IwIP
This commit is contained in:
parent
2b3da7d987
commit
8df47b4934
3 changed files with 7 additions and 53 deletions
|
@ -55,52 +55,6 @@ After analyzing existing solutions following firewall parameters were implemente
|
||||||
|
|
||||||
A port can be a maximum of 65565, therefore cannot be of type \verb|uint16_t| but \verb|uint32_t|. Target as well as protocol are enums for the available options. To block a range of ports, there is a \verb|port_from| and \verb|port_to|. The firewall will store all the rules as linked list to dynamically add and remove rules.
|
A port can be a maximum of 65565, therefore cannot be of type \verb|uint16_t| but \verb|uint32_t|. Target as well as protocol are enums for the available options. To block a range of ports, there is a \verb|port_from| and \verb|port_to|. The firewall will store all the rules as linked list to dynamically add and remove rules.
|
||||||
|
|
||||||
\subsection{WiFi Events}
|
|
||||||
|
|
||||||
To intercept network packages there is a need to somehow get notified when a new package arrived that needs to be analyzed. Based on the firewall rules, it can pass, gets dropped or rejected.
|
|
||||||
|
|
||||||
Available ESP32 WiFi Events can be seen in figure \ref*{fig:WiFi Events}. None of those events support reading incoming packages.
|
|
||||||
|
|
||||||
\begin{figure}[H]
|
|
||||||
\begin{center}
|
|
||||||
\includegraphics[height=0.9\textheight]{wifi-events}
|
|
||||||
\caption{WiFi Events}
|
|
||||||
\label{fig:WiFi Events}
|
|
||||||
\end{center}
|
|
||||||
\end{figure}
|
|
||||||
|
|
||||||
\cite[cf.][]{espressif-wifi}
|
|
||||||
|
|
||||||
\subsection{WiFi Buffer Usage}
|
|
||||||
|
|
||||||
Looking at the usage of the DMA buffer (Figure \ref{fig:WiFi Buffer}) of the driver we can see where we have to check for received packages.
|
|
||||||
|
|
||||||
\begin{figure}[H]
|
|
||||||
\begin{center}
|
|
||||||
\includegraphics[width=0.8\textwidth]{wifi-buffer}
|
|
||||||
\caption{WiFi Buffer}
|
|
||||||
\label{fig:WiFi Buffer}
|
|
||||||
\end{center}
|
|
||||||
\end{figure}
|
|
||||||
|
|
||||||
\cite[cf.][]{espressif-wifi}
|
|
||||||
|
|
||||||
\subsection{Wi-Fi Sniffer Mode}
|
|
||||||
|
|
||||||
Esp32 can be setup in a ``sniffer mode''. Following packets can be dumped to the application:
|
|
||||||
|
|
||||||
\begin{list}{-}{}
|
|
||||||
\item 802.11 Management frame.
|
|
||||||
\item 802.11 Data frame, including MPDU, AMPDU, and AMSDU.
|
|
||||||
\item 802.11 MIMO frame, for MIMO frame, the sniffer only dumps the length of the frame.
|
|
||||||
\item 802.11 Control frame.
|
|
||||||
\item 802.11 CRC error frame.
|
|
||||||
\end{list}
|
|
||||||
|
|
||||||
The same can be done with the esp8266 as described in this article:
|
|
||||||
|
|
||||||
\href{https://carvesystems.com/news/writing-a-simple-esp8266-based-sniffer/}{https://carvesystems.com/news/writing-a-simple-esp8266-based-sniffer/}
|
|
||||||
|
|
||||||
\newpage
|
\newpage
|
||||||
|
|
||||||
\subsection{IwIP}
|
\subsection{IwIP}
|
||||||
|
@ -136,8 +90,8 @@ if (ip4_addr4_16_val(iphdr->src) == 211)
|
||||||
Following output can be seen when sending a ping from the machine with IP-Address \verb|10.93.0.211| to the esp. ICMP is therefore marked with protocol 1.
|
Following output can be seen when sending a ping from the machine with IP-Address \verb|10.93.0.211| to the esp. ICMP is therefore marked with protocol 1.
|
||||||
|
|
||||||
\begin{verbatim}
|
\begin{verbatim}
|
||||||
I (97535) PROTO: 1
|
I (x) PROTO: 1
|
||||||
I (97535) IP: 10 93 0 211
|
I (x) IP: 10 93 0 211
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
|
|
||||||
Sending a UDP or TCP package to the ESP (IP-Address: \verb|10.93.0.246|) can be done by executing the python code in the repository.
|
Sending a UDP or TCP package to the ESP (IP-Address: \verb|10.93.0.246|) can be done by executing the python code in the repository.
|
||||||
|
@ -150,16 +104,16 @@ Sending a UDP or TCP package to the ESP (IP-Address: \verb|10.93.0.246|) can be
|
||||||
Following output can be registered.
|
Following output can be registered.
|
||||||
|
|
||||||
\begin{verbatim}
|
\begin{verbatim}
|
||||||
I (1777105) PROTO: 6
|
I (x) PROTO: 6
|
||||||
I (1777105) IP: 10 93 0 211
|
I (x) IP: 10 93 0 211
|
||||||
I (1779825) PROTO: 17
|
I (x) PROTO: 17
|
||||||
I (1779825) IP: 10 93 0 211
|
I (x) IP: 10 93 0 211
|
||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
|
|
||||||
Looking at the printed protocols this means 6 == "TCP" and 17 == "UDP".
|
Looking at the printed protocols this means 6 == "TCP" and 17 == "UDP".
|
||||||
|
|
||||||
\subsubsection{Using Hook}
|
\subsubsection{Using Hook}
|
||||||
|
|
||||||
|
After learning the protocols that need to be filtered and looked out for, a hook needs to be registered in order to filter the packets based on our rules.
|
||||||
|
|
||||||
\subsection{Benchmark}
|
\subsection{Benchmark}
|
||||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
Before Width: | Height: | Size: 178 KiB |
Reference in a new issue