43 lines
3.2 KiB
TeX
43 lines
3.2 KiB
TeX
\documentclass[../review_3.tex]{subfiles}
|
|
\graphicspath{{\subfix{../img/}}}
|
|
\begin{document}
|
|
|
|
\chapter{Bug-Review}\thispagestyle{fancy}
|
|
|
|
In diesem Bug-Review werden verschiedene Fehler gesammelt. Dabei wird auf die Datei, in der sie auftreten, auf eine Beschreibung und eine Kategorisierung eingegangen. Major Bugs sind versionsverhindernd, Critical Bugs können auch zur Arbeitsunfähigkeit anderer führen und Minor Bugs haben eine geringe Auswirkung und somit eine niedrige Priorität.
|
|
|
|
\begin{longtable} [h] {p{3cm} p{6cm} p{2cm} l}
|
|
\toprule
|
|
\textbf{Datei} & \textbf{Beschreibung} & \textbf{Kategorie} & \textbf{Status} \\
|
|
\midrule
|
|
\endhead
|
|
|
|
PacketInfoIpv4Icmp &
|
|
Wenn von einem Paket die Header extrahiert werden sollte (\texttt{fill\_info}), wurdr zuerst der \texttt{mbuf} in der \texttt{PacketInfo} verlinkt, dann IP version (IPv4) und Layer 4 Protokol (ICMP) ermittelt. Danach wurde die \texttt{PaketInfo} in die entsprechende protokollspezifische \texttt{PacketInfo} gecastet. Auf dieser verwandelten \texttt{PacketInfo} wird \texttt{set\_ip\_hdr} ausgeführt und es kam zum Segmentation-Fault, der im Abbruch des Threads mündete. Diesen Fehler gab es, weil die \texttt{PacketInfo} nicht richtig gesetzt wurde, d. h. der \texttt{PacketContainer} erhielt bei der Initialisierung leere \texttt{PacketInfos}. Beim Polling wurden dann die \texttt{mbufs} verlinkt und die \texttt{PacketInfos} wurden erstellt, aber nicht richtig gespeichert, sodass sie noch die initialen enthielten. Durch Veränderung der Übergabe eines Pointes konnte dieser Bug behoben werden. &
|
|
Critical Bug &
|
|
Geschlossen \\
|
|
|
|
Initializer &
|
|
Die maximale Anzahl an Threads ist 16. Das stellt kein Problem dar, weil nur 12 Threads benötigt werden. mlx5\_pci: port 1 empty mbuf pool; mlx5\_pci: port 1 Rx queue allocation failed: Cannot allocate memory. Dieser Fehler tritt beim Ausführen von rte\_eth\_dev\_start(port) auf. Womöglich handelt es sich dabei um ein Mempool Problem. Dieses Problem wurde umgangen und stellt kein großes Hindernis dar. & Minor Bug & Geschlossen \\
|
|
|
|
Attacker &
|
|
Bei diesem Fehler handelt es sich um ein Speicherleck, weil Objekte angelegt wurden, die schließlich aber nicht korrekt gelöscht worden. Dieses Problem wurde bei Verschlankung des Attackers behoben, denn diese Objekte wurden dann nicht mehr benötigt. &
|
|
Critical Bug &
|
|
Geschlossen \\
|
|
|
|
PacketContainer &
|
|
Auch diese Fehler war ein Speicherleak. Durch das Hinzufügen eines spezialisierten Destruktors für die konkreten PacketInfos konnte auch dieses Problem behoben werden. &
|
|
Major Bug &
|
|
Geschlossen \\
|
|
|
|
Treatment &
|
|
Beim Verbindungsaufbau zwischen AEGIS sowie dem Server Bob wurde zwar das SYN erzeugt, allerdings kam dies nie auf einem der verbundenen Rechner an. Das Problem lag hier darin, dass das Architekturmuster mit getrennten Funktionen des Treatments für die unterschiedliche Richtung der Pakete die selbst erzeugten Pakete teilweise selbst noch einmal durch die Methode des Treatments für die Gegenrichtung behandelt wurden. Dies sorgte für den Verlust des erzeugten Paketes. Der Fehler wurde behoben und stellt nun kein Problem mehr dar. &
|
|
Major Bug &
|
|
Geschlossen \\
|
|
|
|
\bottomrule
|
|
|
|
\end{longtable}
|
|
|
|
\end{document}
|