summaryrefslogtreecommitdiffstats
path: root/notFinishedCode/Report/test.tex.backup
diff options
context:
space:
mode:
authorRefik Hadzialic2011-10-09 17:36:59 +0200
committerRefik Hadzialic2011-10-09 17:36:59 +0200
commitb45e39d9c323473556517406fcf459aa476adf9d (patch)
tree5dde4ae217c767d47133ab74bec17ce79b2b5238 /notFinishedCode/Report/test.tex.backup
parentMerge branch 'master' of lab.ks.uni-freiburg.de:lsfks/projekte/gsm-selftest (diff)
downloadgsm-selftest-b45e39d9c323473556517406fcf459aa476adf9d.tar.gz
gsm-selftest-b45e39d9c323473556517406fcf459aa476adf9d.tar.xz
gsm-selftest-b45e39d9c323473556517406fcf459aa476adf9d.zip
Continued to work on the report!
Diffstat (limited to 'notFinishedCode/Report/test.tex.backup')
-rw-r--r--notFinishedCode/Report/test.tex.backup87
1 files changed, 68 insertions, 19 deletions
diff --git a/notFinishedCode/Report/test.tex.backup b/notFinishedCode/Report/test.tex.backup
index b54cbe6..73c65bd 100644
--- a/notFinishedCode/Report/test.tex.backup
+++ b/notFinishedCode/Report/test.tex.backup
@@ -102,41 +102,49 @@ Prof. Dr. Gerhard Schneider\\ \vspace{1\baselineskip} Supervisors: \\ Konrad Mei
Before we had started working on our project, we had to analyze the overall network to come up with test cases that contain the highest information content. The next step in our procedure was to implement our ideas into a working piece of software.
Gradually we implemented a bit-by-bit of the final software. Every single step was accompanied by testing and validation procedures. At the end we connected all the ``black-boxes'' into one big piece of software. We have fulfilled our requests and goals and made a fully working and operable test software. Despite developing a working software, all the way along we thought about the simplicity of the usage of the software. In the following chapters we will describe in more detail our approach and how each subsystem works.
\newpage
-\section{Software concept} % chapter 2
+\section{Software requests} % chapter 2
\newpage
\section{Database design}
\newpage
-\section{Introduction} % section 2.1
+\section{Software design} % section 2.1
\subsection{Usage} % subsection 2.1.1
\newpage
-\section{Design}
-\begin{figure}[hb!]
+\section{Hardware Design}
+In our team project we had not the option to choose the hardware however we were lucky to have
+two BeagleBoards which were supplied by Konrad and Dennis.
+Since one of the project goals was to save as much money as it was possible we had tried to use some of the leftovers in the lab.
+
+\begin{figure}[ht!]
\centering
\includegraphics[width=130mm]{bb.jpg}
\caption[]{BeagleBoard, a linux-on-chip board where our controller software runs the GSM device }
\end{figure}
+Our first attempt was
\newpage
-\section{Protocol}
+\section{Communication protocol}
-\begin{figure}[hb!]
+\begin{figure}[ht!]
\centering
- \includegraphics[width=130mm]{protocolCommunicationHandler.png}
+ \includegraphics[width=140mm]{protocolCommunicationHandler.png}
\caption[]{Flowchart of the protocol, on the handler side}
\end{figure}
-\begin{figure}[hb!]
+\begin{figure}[ht!]
\centering
- \includegraphics[width=130mm]{protocolCommunicationcControllerReceiver.png}
+ \includegraphics[width=140mm]{protocolCommunicationcControllerReceiver.png}
\caption[]{Flowchart of the protocol, on the controller side for the caller}
\end{figure}
-\begin{figure}[hb!]
+\begin{figure}[ht!]
\centering
- \includegraphics[width=130mm]{protocolCommunicationcControllerCaller.png}
+ \includegraphics[width=140mm]{protocolCommunicationcControllerCaller.png}
\caption[]{Flowchart of the protocol, on the controller side for the receiver}
\end{figure}
-%\newpage
+\clearpage
+\newpage
+
+
\section{Security and safety of the system}
\large Safety and security of the software plays a major role in our project.
It is of vital importance that only as few as possible people have access to our test system since the resulting data could be exploited to plan an attack
@@ -235,7 +243,7 @@ refik@ubuntu:/etc/apache2$ sudo mkdir ssl
cp server.key /etc/apache2/ssl
cp server.crt /etc/apache2/ssl
\end{lstlisting}
-Then we enabled SSL by typing in \emph{a2enmod ssl}, ``it is simply a general purpose utility to establish a symlink between a module in \emph{/etc/apache2/mods-available} to \emph{/etc/apache2/mods-enabled} (or give a message to the effect that a given module does not exist or that it is already symlinked for loading)'' \cite{https}.
+\par Then we enabled SSL by typing in \emph{a2enmod ssl}, ``it is simply a general purpose utility to establish a symlink between a module in \emph{/etc/apache2/mods-available} to \emph{/etc/apache2/mods-enabled} (or give a message to the effect that a given module does not exist or that it is already symlinked for loading)'' \cite{https}.
\begin{lstlisting}
refik@ubuntu:/etc/apache2/ssl$ sudo a2enmod ssl
Enabling module ssl.
@@ -286,7 +294,7 @@ In our last configuration step we had to edit \emph{default-ssl} file to define
refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl
\end{lstlisting}
\newpage
-\par The following part had to be found and modified according to our locations:
+\par The following part of the file had to be found and modified according to our locations:
\begin{lstlisting}
SSLEngine on
@@ -301,7 +309,7 @@ SSLEngine on
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
\end{lstlisting}
-Finally we had configured our server and can proceed with the restart of the apache web server.
+\par Finally we had configured our server and can proceed with the restart of the apache web server. We created a test web site \emph{/var/www-ssl/index.php} and navigated our browser to \emph{https://localhost}. The test was successful!
\begin{lstlisting}
refik@ubuntu:/etc/apache2/sites-available$ sudo /etc/init.d/apache2 restart
* Restarting web server apache2 [Sat Oct 08 21:52:51 2011] [warn] _default_ VirtualHost overlap on port 443, the first has precedence
@@ -315,13 +323,51 @@ refik@ubuntu:/etc/apache2/sites-available$
\newpage
\section{Web page}
-
-\begin{figure}[hb!]
+\large One of the requests of our team project was to build a test system that could be started from the web site.
+Since we used the Open Source platform to base our project on, it was certain we will use it for the web site as well.
+The dynamic parts of the web site were programmed using PHP and JavaScript. The GUI was done using CSS.
+The web site opens TCP/IP sessions between itself and the Python test software. Due reasons explained in the section above,
+a test user needs first to enter his username and password to acccess the web site. Then a test user can manually select what type of tests he wants to perform or he can select already defined test,
+like the simple, smart or full test. (Describe here these three type of tests.)
+Data about the performing tests are inserted into the database only in the case if the mutex lock for the web site can be obtained\footnote{The mutex lock will be explained in the next subsection.}.
+This way we can avoid inserting data about the test in case there is already a test user on the website performing some tests on the system.
+\subsection{Communication between the web page and the test software}
+Our first idea was that the PHP file starts the test software.
+However, parts of our test software open new terminal windows and
+since PHP has restrictions for starting GUI applications our approach was condemned for a failure at the start.
+We had to deal with this problem and our solution to it was to write a little Python script that will run in background and start our
+test software when required. Once a person starts the test over the web site, it automatically connects to the Python script over an TCP/IP socket.
+Before being able to start the test software one needs first to obtain the mutex lock on the web site and to check if there is a mutex lock for the test software running.
+Using this approach we can ensure that only one user at the time can be on the web site and run only one instance of the test software.
+In the next step we send the Python script a message to start the test software. The test software obtains a mutex lock as well.
+When the test software is started the web page checks if a software lock is obtained.
+Once it is obtained we can proceed with creating a new socket connection between the web site and the test software.
+Our TCP/IP communication between the web site and the test software is not encrypted since both the web page and the test software run on the same server computer.
+The mutex locks are freed after the tests are performed. Our test software has a timeout timer in case that the web site hangs or somehow the socket connection breaks
+where it automatically shuts down.
+\subsection{Results on the web page}
+All the performed test results are displayed on the web site. The results are displayed in real time after each selected test case is performed.
+After all the test cases have been performed a topological picture is generated which represents the current state of the system, this can bee seen in the following figure.
+Afterwards, when the result picture is generated, the test user can easily see what is wrong in the system. Various icons represent different subsystems.
+Reading the test results is simple as looking at the icons and identifying if they have: a green plus signs (i.e. working properly), a red minus sign (i.e. not working properly) and a yellow exclamation mark (i.e. it was not tested).
+
+\begin{itemize}
+\item Triangles represent BTS stations
+\item Cellphones represent the external networks (E-Plus, Vodaphone, T-Mobile and O2)
+\item Telephone represents the landline and a telephone with a mortarboard the University telephone network
+\item Servers represent the OpenBSC and LsfKs-Asterisk
+\item Two monitors represent the SIP system
+\end{itemize}
+
+\par The inference mechanism works as following: if a test case works, we can conclude that the subsystems connected inbetween the two ends are working properly as well.
+We use the pChart library\footnote{It is under the GNU GPLv3 license and our project is nonprofit!} to generate the topological picture of our telecommunication system \cite{pChart}.
+\begin{figure}[ht!]
\centering
- \includegraphics[width=100mm]{resultsImage.png}
+ \includegraphics[width=120mm]{resultsImage.png}
\caption[]{Result image showing working, defected and not tested subsystems}
\end{figure}
-
+\par On the right side of the result picture the test user can immediatelly identify the network operability in percentage\footnote{The test user has to take into account that this percantage is only valid if a full test is performed.}. Bellow the network operability statistics are the ping results statistics located.
+If one of the fields is red it means the subsystem is not online or cannot be seen by our server computer where the test software is located.
\newpage
\section{Conclusion}
\newpage
@@ -339,6 +385,9 @@ Hypothesis}, preprint (2003), available at
\bibitem{https} P. Bramscher, \emph{Creating Certificate Authorities and self-signed SSL certificates}, accessed on 05.09.2011, available at
\url{http://www.tc.umn.edu/~brams006/selfsign.html}.
+\bibitem{pChart} \emph{pChart}, accessed on 15.08.2011, available at
+\url{http://http://www.pchart.net/}.
+
%bibliography end
\end{thebibliography}