From 9f9fae05e16848503a93c14c12c33222de3482a7 Mon Sep 17 00:00:00 2001 From: Refik Hadzialic Date: Wed, 9 Nov 2011 16:10:02 +0100 Subject: Report relocating! --- documenting/Report/BigPicture_new.png | Bin 0 -> 126202 bytes documenting/Report/BigPicture_new1.png | Bin 0 -> 136384 bytes documenting/Report/ClientClass.png | Bin 0 -> 10718 bytes documenting/Report/DBRelationship.png | Bin 0 -> 64566 bytes documenting/Report/First.png | Bin 0 -> 408402 bytes documenting/Report/Second.png | Bin 0 -> 455939 bytes documenting/Report/ServerHandlerClass.png | Bin 0 -> 7930 bytes documenting/Report/Third.png | Bin 0 -> 382478 bytes documenting/Report/Tri-report.doc | Bin 0 -> 55296 bytes documenting/Report/activityControllerEdited.png | Bin 0 -> 33657 bytes documenting/Report/activity_diagram.png | Bin 0 -> 152591 bytes documenting/Report/bb.jpg | Bin 0 -> 100471 bytes documenting/Report/classDiagram.png | Bin 0 -> 92031 bytes documenting/Report/controllerclass.png | Bin 0 -> 21495 bytes documenting/Report/dbClass.png | Bin 0 -> 22411 bytes documenting/Report/devconf.png | Bin 0 -> 54332 bytes documenting/Report/initTestClass.png | Bin 0 -> 8963 bytes documenting/Report/logging.png | Bin 0 -> 5963 bytes documenting/Report/logo.svg | 15 + documenting/Report/ping.png | Bin 0 -> 4129 bytes .../Report/protocolCommunicationHandler.png | Bin 0 -> 69838 bytes .../protocolCommunicationcControllerCaller.png | Bin 0 -> 45087 bytes .../protocolCommunicationcControllerReceiver.png | Bin 0 -> 44459 bytes documenting/Report/protocolRedesign.png | Bin 0 -> 5180 bytes documenting/Report/resultsImage.png | Bin 0 -> 59169 bytes documenting/Report/resultterminal.png | Bin 0 -> 24344 bytes documenting/Report/serialPort.png | Bin 0 -> 16604 bytes documenting/Report/serverClass.png | Bin 0 -> 7821 bytes documenting/Report/sshTunnel.png | Bin 0 -> 18810 bytes documenting/Report/sshTunnelClass.png | Bin 0 -> 8853 bytes documenting/Report/terminalCommand.png | Bin 0 -> 88885 bytes documenting/Report/test.aux | 150 +++ documenting/Report/test.log | 641 +++++++++ documenting/Report/test.out | 58 + documenting/Report/test.pdf | Bin 0 -> 5058627 bytes documenting/Report/test.tex | 1376 +++++++++++++++++++ documenting/Report/test.tex.backup | 1360 +++++++++++++++++++ documenting/Report/test.tex.bak | 1326 +++++++++++++++++++ documenting/Report/test.tex~ | 1397 ++++++++++++++++++++ documenting/Report/test.toc | 59 + documenting/Report/test_Use_case.png | Bin 0 -> 299296 bytes documenting/Report/titlepic.sty | 76 ++ documenting/Report/trueTable.png | Bin 0 -> 6534 bytes documenting/Report/uniLogo1.jpg | Bin 0 -> 56865 bytes documenting/Report/uniLogo2.png | Bin 0 -> 296644 bytes documenting/Report/usbDetectClass.png | Bin 0 -> 11421 bytes documenting/Report/webpageReport.png | Bin 0 -> 112597 bytes documenting/Report/website1.png | Bin 0 -> 463898 bytes documenting/Report/website2.png | Bin 0 -> 489975 bytes documenting/Report/website3.png | Bin 0 -> 389426 bytes documenting/Report/website4.png | Bin 0 -> 350899 bytes documenting/Report/website6.png | Bin 0 -> 95087 bytes 52 files changed, 6458 insertions(+) create mode 100644 documenting/Report/BigPicture_new.png create mode 100644 documenting/Report/BigPicture_new1.png create mode 100644 documenting/Report/ClientClass.png create mode 100644 documenting/Report/DBRelationship.png create mode 100644 documenting/Report/First.png create mode 100644 documenting/Report/Second.png create mode 100644 documenting/Report/ServerHandlerClass.png create mode 100644 documenting/Report/Third.png create mode 100644 documenting/Report/Tri-report.doc create mode 100644 documenting/Report/activityControllerEdited.png create mode 100644 documenting/Report/activity_diagram.png create mode 100644 documenting/Report/bb.jpg create mode 100644 documenting/Report/classDiagram.png create mode 100644 documenting/Report/controllerclass.png create mode 100644 documenting/Report/dbClass.png create mode 100644 documenting/Report/devconf.png create mode 100644 documenting/Report/initTestClass.png create mode 100644 documenting/Report/logging.png create mode 100644 documenting/Report/logo.svg create mode 100644 documenting/Report/ping.png create mode 100644 documenting/Report/protocolCommunicationHandler.png create mode 100644 documenting/Report/protocolCommunicationcControllerCaller.png create mode 100644 documenting/Report/protocolCommunicationcControllerReceiver.png create mode 100644 documenting/Report/protocolRedesign.png create mode 100644 documenting/Report/resultsImage.png create mode 100644 documenting/Report/resultterminal.png create mode 100644 documenting/Report/serialPort.png create mode 100644 documenting/Report/serverClass.png create mode 100644 documenting/Report/sshTunnel.png create mode 100644 documenting/Report/sshTunnelClass.png create mode 100644 documenting/Report/terminalCommand.png create mode 100644 documenting/Report/test.aux create mode 100644 documenting/Report/test.log create mode 100644 documenting/Report/test.out create mode 100644 documenting/Report/test.pdf create mode 100644 documenting/Report/test.tex create mode 100644 documenting/Report/test.tex.backup create mode 100644 documenting/Report/test.tex.bak create mode 100644 documenting/Report/test.tex~ create mode 100644 documenting/Report/test.toc create mode 100644 documenting/Report/test_Use_case.png create mode 100644 documenting/Report/titlepic.sty create mode 100644 documenting/Report/trueTable.png create mode 100644 documenting/Report/uniLogo1.jpg create mode 100644 documenting/Report/uniLogo2.png create mode 100644 documenting/Report/usbDetectClass.png create mode 100644 documenting/Report/webpageReport.png create mode 100644 documenting/Report/website1.png create mode 100644 documenting/Report/website2.png create mode 100644 documenting/Report/website3.png create mode 100644 documenting/Report/website4.png create mode 100644 documenting/Report/website6.png (limited to 'documenting') diff --git a/documenting/Report/BigPicture_new.png b/documenting/Report/BigPicture_new.png new file mode 100644 index 0000000..cb70576 Binary files /dev/null and b/documenting/Report/BigPicture_new.png differ diff --git a/documenting/Report/BigPicture_new1.png b/documenting/Report/BigPicture_new1.png new file mode 100644 index 0000000..cf81c92 Binary files /dev/null and b/documenting/Report/BigPicture_new1.png differ diff --git a/documenting/Report/ClientClass.png b/documenting/Report/ClientClass.png new file mode 100644 index 0000000..9df72cc Binary files /dev/null and b/documenting/Report/ClientClass.png differ diff --git a/documenting/Report/DBRelationship.png b/documenting/Report/DBRelationship.png new file mode 100644 index 0000000..bca5f6d Binary files /dev/null and b/documenting/Report/DBRelationship.png differ diff --git a/documenting/Report/First.png b/documenting/Report/First.png new file mode 100644 index 0000000..3dd2fdc Binary files /dev/null and b/documenting/Report/First.png differ diff --git a/documenting/Report/Second.png b/documenting/Report/Second.png new file mode 100644 index 0000000..b99fc07 Binary files /dev/null and b/documenting/Report/Second.png differ diff --git a/documenting/Report/ServerHandlerClass.png b/documenting/Report/ServerHandlerClass.png new file mode 100644 index 0000000..cfd4985 Binary files /dev/null and b/documenting/Report/ServerHandlerClass.png differ diff --git a/documenting/Report/Third.png b/documenting/Report/Third.png new file mode 100644 index 0000000..4bdf503 Binary files /dev/null and b/documenting/Report/Third.png differ diff --git a/documenting/Report/Tri-report.doc b/documenting/Report/Tri-report.doc new file mode 100644 index 0000000..5b00f7d Binary files /dev/null and b/documenting/Report/Tri-report.doc differ diff --git a/documenting/Report/activityControllerEdited.png b/documenting/Report/activityControllerEdited.png new file mode 100644 index 0000000..bf22102 Binary files /dev/null and b/documenting/Report/activityControllerEdited.png differ diff --git a/documenting/Report/activity_diagram.png b/documenting/Report/activity_diagram.png new file mode 100644 index 0000000..0f4fdd2 Binary files /dev/null and b/documenting/Report/activity_diagram.png differ diff --git a/documenting/Report/bb.jpg b/documenting/Report/bb.jpg new file mode 100644 index 0000000..1118f4c Binary files /dev/null and b/documenting/Report/bb.jpg differ diff --git a/documenting/Report/classDiagram.png b/documenting/Report/classDiagram.png new file mode 100644 index 0000000..3bcae96 Binary files /dev/null and b/documenting/Report/classDiagram.png differ diff --git a/documenting/Report/controllerclass.png b/documenting/Report/controllerclass.png new file mode 100644 index 0000000..22dfec5 Binary files /dev/null and b/documenting/Report/controllerclass.png differ diff --git a/documenting/Report/dbClass.png b/documenting/Report/dbClass.png new file mode 100644 index 0000000..e18ece1 Binary files /dev/null and b/documenting/Report/dbClass.png differ diff --git a/documenting/Report/devconf.png b/documenting/Report/devconf.png new file mode 100644 index 0000000..76a3ab8 Binary files /dev/null and b/documenting/Report/devconf.png differ diff --git a/documenting/Report/initTestClass.png b/documenting/Report/initTestClass.png new file mode 100644 index 0000000..1ff20e4 Binary files /dev/null and b/documenting/Report/initTestClass.png differ diff --git a/documenting/Report/logging.png b/documenting/Report/logging.png new file mode 100644 index 0000000..bf39f7a Binary files /dev/null and b/documenting/Report/logging.png differ diff --git a/documenting/Report/logo.svg b/documenting/Report/logo.svg new file mode 100644 index 0000000..e128a45 --- /dev/null +++ b/documenting/Report/logo.svg @@ -0,0 +1,15 @@ + + + + + diff --git a/documenting/Report/ping.png b/documenting/Report/ping.png new file mode 100644 index 0000000..b7d0e3b Binary files /dev/null and b/documenting/Report/ping.png differ diff --git a/documenting/Report/protocolCommunicationHandler.png b/documenting/Report/protocolCommunicationHandler.png new file mode 100644 index 0000000..984ff1d Binary files /dev/null and b/documenting/Report/protocolCommunicationHandler.png differ diff --git a/documenting/Report/protocolCommunicationcControllerCaller.png b/documenting/Report/protocolCommunicationcControllerCaller.png new file mode 100644 index 0000000..7a1cb70 Binary files /dev/null and b/documenting/Report/protocolCommunicationcControllerCaller.png differ diff --git a/documenting/Report/protocolCommunicationcControllerReceiver.png b/documenting/Report/protocolCommunicationcControllerReceiver.png new file mode 100644 index 0000000..17462b9 Binary files /dev/null and b/documenting/Report/protocolCommunicationcControllerReceiver.png differ diff --git a/documenting/Report/protocolRedesign.png b/documenting/Report/protocolRedesign.png new file mode 100644 index 0000000..70af9c0 Binary files /dev/null and b/documenting/Report/protocolRedesign.png differ diff --git a/documenting/Report/resultsImage.png b/documenting/Report/resultsImage.png new file mode 100644 index 0000000..3eb4d7a Binary files /dev/null and b/documenting/Report/resultsImage.png differ diff --git a/documenting/Report/resultterminal.png b/documenting/Report/resultterminal.png new file mode 100644 index 0000000..9e53f7a Binary files /dev/null and b/documenting/Report/resultterminal.png differ diff --git a/documenting/Report/serialPort.png b/documenting/Report/serialPort.png new file mode 100644 index 0000000..4ed398b Binary files /dev/null and b/documenting/Report/serialPort.png differ diff --git a/documenting/Report/serverClass.png b/documenting/Report/serverClass.png new file mode 100644 index 0000000..a6914a4 Binary files /dev/null and b/documenting/Report/serverClass.png differ diff --git a/documenting/Report/sshTunnel.png b/documenting/Report/sshTunnel.png new file mode 100644 index 0000000..3b8e8ae Binary files /dev/null and b/documenting/Report/sshTunnel.png differ diff --git a/documenting/Report/sshTunnelClass.png b/documenting/Report/sshTunnelClass.png new file mode 100644 index 0000000..de522f0 Binary files /dev/null and b/documenting/Report/sshTunnelClass.png differ diff --git a/documenting/Report/terminalCommand.png b/documenting/Report/terminalCommand.png new file mode 100644 index 0000000..98bc2ec Binary files /dev/null and b/documenting/Report/terminalCommand.png differ diff --git a/documenting/Report/test.aux b/documenting/Report/test.aux new file mode 100644 index 0000000..f5bf6ae --- /dev/null +++ b/documenting/Report/test.aux @@ -0,0 +1,150 @@ +\relax +\ifx\hyper@anchor\@undefined +\global \let \oldcontentsline\contentsline +\gdef \contentsline#1#2#3#4{\oldcontentsline{#1}{#2}{#3}} +\global \let \oldnewlabel\newlabel +\gdef \newlabel#1#2{\newlabelxx{#1}#2} +\gdef \newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}} +\AtEndDocument{\let \contentsline\oldcontentsline +\let \newlabel\oldnewlabel} +\else +\global \let \hyper@last\relax +\fi + +\select@language{english} +\@writefile{toc}{\select@language{english}} +\@writefile{lof}{\select@language{english}} +\@writefile{lot}{\select@language{english}} +\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction and Motivation}{4}{section.1}} +\citation{network} +\citation{network} +\@writefile{toc}{\contentsline {section}{\numberline {2}Requirements}{5}{section.2}} +\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces }}{5}{figure.1}} +\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Logical and algorithmic requirements}{5}{subsection.2.1}} +\citation{python} +\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces }}{6}{figure.2}} +\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Software requirements}{6}{subsection.2.2}} +\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces }}{7}{figure.3}} +\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Hardware requirements}{8}{subsection.2.3}} +\@writefile{toc}{\contentsline {section}{\numberline {3}Database design}{9}{section.3}} +\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces }}{11}{figure.4}} +\citation{wiki} +\@writefile{toc}{\contentsline {section}{\numberline {4}Software design}{12}{section.4}} +\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces }}{12}{figure.5}} +\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces }}{14}{figure.6}} +\citation{mysqlManual} +\citation{wiki} +\citation{wiki} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Database access}{15}{subsection.4.1}} +\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces }}{15}{figure.7}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Controlling the cell phones}{15}{subsection.4.2}} +\citation{socket} +\citation{wiki} +\@writefile{lof}{\contentsline {figure}{\numberline {8}{\ignorespaces }}{16}{figure.8}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.3}Client and Server class}{16}{subsection.4.3}} +\citation{wiki} +\@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces }}{17}{figure.9}} +\@writefile{lof}{\contentsline {figure}{\numberline {10}{\ignorespaces }}{17}{figure.10}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.4}Ping class}{17}{subsection.4.4}} +\citation{wiki} +\citation{wiki} +\@writefile{lof}{\contentsline {figure}{\numberline {11}{\ignorespaces }}{18}{figure.11}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.5}Data logging}{18}{subsection.4.5}} +\@writefile{lof}{\contentsline {figure}{\numberline {12}{\ignorespaces }}{18}{figure.12}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.6}SSH Tunnel Class}{18}{subsection.4.6}} +\@writefile{lof}{\contentsline {figure}{\numberline {13}{\ignorespaces }}{18}{figure.13}} +\citation{wiki} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.7}USB Cell phone detection class}{19}{subsection.4.7}} +\@writefile{lof}{\contentsline {figure}{\numberline {14}{\ignorespaces }}{19}{figure.14}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.8}Truth table class}{19}{subsection.4.8}} +\@writefile{lof}{\contentsline {figure}{\numberline {15}{\ignorespaces }}{19}{figure.15}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.9}Init Test class}{19}{subsection.4.9}} +\@writefile{lof}{\contentsline {figure}{\numberline {16}{\ignorespaces }}{20}{figure.16}} +\@writefile{toc}{\contentsline {subsection}{\numberline {4.10}Controller class}{20}{subsection.4.10}} +\@writefile{lof}{\contentsline {figure}{\numberline {17}{\ignorespaces }}{20}{figure.17}} +\citation{beagleDataSheet} +\@writefile{toc}{\contentsline {section}{\numberline {5}Hardware design}{21}{section.5}} +\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}BeagleBoard}{21}{subsection.5.1}} +\@writefile{lof}{\contentsline {figure}{\numberline {18}{\ignorespaces }}{21}{figure.18}} +\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Cell phones}{21}{subsection.5.2}} +\@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Cables for the cell phones}{22}{subsection.5.3}} +\@writefile{toc}{\contentsline {subsection}{\numberline {5.4}Server}{22}{subsection.5.4}} +\@writefile{toc}{\contentsline {section}{\numberline {6}Communication protocol}{23}{section.6}} +\@writefile{toc}{\contentsline {subsection}{\numberline {6.1}Communication between the handler and controller}{23}{subsection.6.1}} +\@writefile{lof}{\contentsline {figure}{\numberline {19}{\ignorespaces }}{25}{figure.19}} +\citation{spin} +\citation{spin} +\citation{wiki} +\@writefile{lof}{\contentsline {figure}{\numberline {20}{\ignorespaces }}{26}{figure.20}} +\@writefile{lof}{\contentsline {figure}{\numberline {21}{\ignorespaces }}{26}{figure.21}} +\@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Verification of the protocol}{26}{subsection.6.2}} +\citation{sshTunnel} +\@writefile{toc}{\contentsline {section}{\numberline {7}Security and safety of the system}{28}{section.7}} +\@writefile{toc}{\contentsline {subsection}{\numberline {7.1}Encryption of the communication channels}{28}{subsection.7.1}} +\@writefile{lof}{\contentsline {figure}{\numberline {22}{\ignorespaces }}{28}{figure.22}} +\citation{https} +\@writefile{toc}{\contentsline {subsection}{\numberline {7.2}Security on the web site}{29}{subsection.7.2}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.1}Configuring the http secure protocol https}{29}{subsubsection.7.2.1}} +\citation{https} +\citation{https} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.2}Password protecting the web site using .htaccess}{32}{subsubsection.7.2.2}} +\citation{htaccess} +\@writefile{toc}{\contentsline {section}{\numberline {8}Web page}{34}{section.8}} +\@writefile{toc}{\contentsline {subsection}{\numberline {8.1}Communication between the web page and the test software}{34}{subsection.8.1}} +\@writefile{toc}{\contentsline {subsection}{\numberline {8.2}Results on the web page}{34}{subsection.8.2}} +\citation{pChart} +\@writefile{lof}{\contentsline {figure}{\numberline {23}{\ignorespaces }}{35}{figure.23}} +\@writefile{toc}{\contentsline {section}{\numberline {9}Employing the test software system}{36}{section.9}} +\@writefile{toc}{\contentsline {subsection}{\numberline {9.1}Required software and libraries}{36}{subsection.9.1}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.1.1}Python installation}{36}{subsubsection.9.1.1}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.1.2}Apache Web server installation}{36}{subsubsection.9.1.2}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.1.3}SSH}{36}{subsubsection.9.1.3}} +\citation{pjsip} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.1.4}MySQL database and MySQLdb library}{37}{subsubsection.9.1.4}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.1.5}Serial port library}{37}{subsubsection.9.1.5}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.1.6}PJSUA library}{37}{subsubsection.9.1.6}} +\citation{wiki} +\citation{pChart} +\citation{proctitle} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.1.7}pChart library}{38}{subsubsection.9.1.7}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.1.8}proctitle library}{38}{subsubsection.9.1.8}} +\@writefile{toc}{\contentsline {subsection}{\numberline {9.2}Configuring hardware}{38}{subsection.9.2}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.2.1}Configuring the cell phones}{40}{subsubsection.9.2.1}} +\@writefile{lof}{\contentsline {figure}{\numberline {24}{\ignorespaces }}{40}{figure.24}} +\@writefile{lof}{\contentsline {figure}{\numberline {25}{\ignorespaces }}{40}{figure.25}} +\@writefile{lof}{\contentsline {figure}{\numberline {26}{\ignorespaces }}{40}{figure.26}} +\@writefile{toc}{\contentsline {subsection}{\numberline {9.3}Location of the files}{41}{subsection.9.3}} +\@writefile{toc}{\contentsline {subsection}{\numberline {9.4}Setting up the parameters}{42}{subsection.9.4}} +\@writefile{toc}{\contentsline {subsection}{\numberline {9.5}Test descriptions}{42}{subsection.9.5}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.5.1}Smart test}{42}{subsubsection.9.5.1}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.5.2}SIP test}{43}{subsubsection.9.5.2}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.5.3}GSM test}{43}{subsubsection.9.5.3}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.5.4}All test}{43}{subsubsection.9.5.4}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.5.5}Manual test}{43}{subsubsection.9.5.5}} +\@writefile{toc}{\contentsline {subsection}{\numberline {9.6}Result descriptions}{44}{subsection.9.6}} +\@writefile{toc}{\contentsline {subsection}{\numberline {9.7}Using the software}{45}{subsection.9.7}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.7.1}Web site guide}{45}{subsubsection.9.7.1}} +\@writefile{lof}{\contentsline {figure}{\numberline {27}{\ignorespaces }}{45}{figure.27}} +\@writefile{lof}{\contentsline {figure}{\numberline {28}{\ignorespaces }}{46}{figure.28}} +\@writefile{lof}{\contentsline {figure}{\numberline {29}{\ignorespaces }}{46}{figure.29}} +\@writefile{lof}{\contentsline {figure}{\numberline {30}{\ignorespaces }}{47}{figure.30}} +\@writefile{lof}{\contentsline {figure}{\numberline {31}{\ignorespaces }}{47}{figure.31}} +\@writefile{toc}{\contentsline {subsubsection}{\numberline {9.7.2}Terminal guide}{47}{subsubsection.9.7.2}} +\@writefile{lof}{\contentsline {figure}{\numberline {32}{\ignorespaces }}{48}{figure.32}} +\@writefile{lof}{\contentsline {figure}{\numberline {33}{\ignorespaces }}{48}{figure.33}} +\@writefile{lof}{\contentsline {figure}{\numberline {34}{\ignorespaces }}{48}{figure.34}} +\@writefile{toc}{\contentsline {section}{\numberline {10}Conclusion}{49}{section.10}} +\bibcite{network}{1} +\bibcite{python}{2} +\bibcite{mysqlManual}{3} +\bibcite{wiki}{4} +\bibcite{socket}{5} +\bibcite{spin}{6} +\bibcite{sshTunnel}{7} +\bibcite{https}{8} +\bibcite{htaccess}{9} +\bibcite{pChart}{10} +\bibcite{beagleDataSheet}{11} +\bibcite{proctitle}{12} +\bibcite{pjsip}{13} +\newlabel{LastPage}{{}{50}{}{page.50}{}} diff --git a/documenting/Report/test.log b/documenting/Report/test.log new file mode 100644 index 0000000..e88ead4 --- /dev/null +++ b/documenting/Report/test.log @@ -0,0 +1,641 @@ +This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.9.27) 8 NOV 2011 12:30 +entering extended mode + %&-line parsing enabled. +**test.tex +(./test.tex +LaTeX2e <2009/09/24> +Babel and hyphenation patterns for english, usenglishmax, dumylang, noh +yphenation, loaded. +(/usr/share/texmf-texlive/tex/latex/koma-script/scrartcl.cls +Document Class: scrartcl 2009/07/24 v3.04a KOMA-Script document class (article) + +(/usr/share/texmf-texlive/tex/latex/koma-script/scrkbase.sty +Package: scrkbase 2009/07/24 v3.04a KOMA-Script package (KOMA-Script-dependent +basics and keyval usage) + +(/usr/share/texmf-texlive/tex/latex/koma-script/scrbase.sty +Package: scrbase 2009/07/24 v3.04a KOMA-Script package (KOMA-Script-independent + basics and keyval usage) + +(/usr/share/texmf-texlive/tex/latex/graphics/keyval.sty +Package: keyval 1999/03/16 v1.13 key=value parser (DPC) +\KV@toks@=\toks14 +) +(/usr/share/texmf-texlive/tex/latex/koma-script/scrlfile.sty +Package: scrlfile 2009/03/25 v3.03 KOMA-Script package (loading files) + +Package scrlfile, 2009/03/25 v3.03 KOMA-Script package (loading files) + Copyright (C) Markus Kohm + +))) (/usr/share/texmf-texlive/tex/latex/koma-script/tocbasic.sty +Package: tocbasic 2009/06/08 v3.03b KOMA-Script package (handling toc-files) +) +Package tocbasic Info: omitting babel extension for `toc' +(tocbasic) because of feature `nobabel' available +(tocbasic) for `toc' on input line 115. +Package tocbasic Info: omitting babel extension for `lof' +(tocbasic) because of feature `nobabel' available +(tocbasic) for `lof' on input line 116. +Package tocbasic Info: omitting babel extension for `lot' +(tocbasic) because of feature `nobabel' available +(tocbasic) for `lot' on input line 117. +Class scrartcl Info: You've used standard option `oneside'. +(scrartcl) This is correct! +(scrartcl) Internaly I'm using `twoside=false'. +(scrartcl) If you'd like to set the option with \KOMAoptions, +(scrartcl) you'd have to use `twoside=false' there +(scrartcl) instead of `oneside', too. +Class scrartcl Info: File `scrsize11pt.clo' used instead of +(scrartcl) file `scrsize11.clo' to setup font sizes on input line 117 +1. + +(/usr/share/texmf-texlive/tex/latex/koma-script/scrsize11pt.clo +File: scrsize11pt.clo 2009/07/24 v3.04a KOMA-Script font size class option (11p +t) +) +(/usr/share/texmf-texlive/tex/latex/koma-script/typearea.sty +Package: typearea 2009/07/24 v3.04a KOMA-Script package (type area) + +Package typearea, 2009/07/24 v3.04a KOMA-Script package (type area) + Copyright (C) Frank Neukam, 1992-1994 + Copyright (C) Markus Kohm, 1994- + +\ta@bcor=\skip41 +\ta@div=\count79 +Package typearea Info: You've used standard option `a4paper'. +(typearea) This is correct! +(typearea) Internaly I'm using `paper=a4'. +(typearea) If you'd like to set the option with \KOMAoptions, +(typearea) you'd have to use `paper=a4' there +(typearea) instead of `a4paper', too. +Package typearea Info: You've used standard option `oneside'. +(typearea) This is correct! +(typearea) Internaly I'm using `twoside=false'. +(typearea) If you'd like to set the option with \KOMAoptions, +(typearea) you'd have to use `twoside=false' there +(typearea) instead of `oneside', too. +\ta@hblk=\skip42 +\ta@vblk=\skip43 +\ta@temp=\skip44 +Package typearea Info: These are the values describing the layout: +(typearea) DIV = 10 +(typearea) BCOR = 0.0pt +(typearea) \paperwidth = 597.50793pt +(typearea) \textwidth = 418.25555pt +(typearea) DIV departure = -6% +(typearea) \evensidemargin = 17.3562pt +(typearea) \oddsidemargin = 17.3562pt +(typearea) \paperheight = 845.04694pt +(typearea) \textheight = 514.20023pt +(typearea) \topmargin = 12.2347pt +(typearea) \headheight = 17.0pt +(typearea) \headsep = 20.40001pt +(typearea) \topskip = 11.0pt +(typearea) \footskip = 47.60002pt +(typearea) \baselineskip = 13.6pt +(typearea) on input line 1115. +) +\c@part=\count80 +\c@section=\count81 +\c@subsection=\count82 +\c@subsubsection=\count83 +\c@paragraph=\count84 +\c@subparagraph=\count85 +\abovecaptionskip=\skip45 +\belowcaptionskip=\skip46 +\c@pti@nb@sid@b@x=\box26 +\c@figure=\count86 +\c@table=\count87 +\bibindent=\dimen102 +) (/usr/share/texmf-texlive/tex/latex/graphics/lscape.sty +Package: lscape 2000/10/22 v3.01 Landscape Pages (DPC) + +(/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty +Package: graphics 2009/02/05 v1.0o Standard LaTeX Graphics (DPC,SPQR) + +(/usr/share/texmf-texlive/tex/latex/graphics/trig.sty +Package: trig 1999/03/16 v1.09 sin cos tan (DPC) +) +(/etc/texmf/tex/latex/config/graphics.cfg +File: graphics.cfg 2009/08/28 v1.8 graphics configuration of TeX Live +) +Package graphics Info: Driver file: pdftex.def on input line 91. + +(/usr/share/texmf-texlive/tex/latex/pdftex-def/pdftex.def +File: pdftex.def 2010/03/12 v0.04p Graphics/color for pdfTeX +\Gread@gobject=\count88 +))) +(/usr/share/texmf-texlive/tex/generic/babel/babel.sty +Package: babel 2008/07/06 v3.8l The Babel package + +(/usr/share/texmf-texlive/tex/generic/babel/english.ldf +Language: english 2005/03/30 v3.3o English support from the babel system + +(/usr/share/texmf-texlive/tex/generic/babel/babel.def +File: babel.def 2008/07/06 v3.8l Babel common definitions +\babel@savecnt=\count89 +\U@D=\dimen103 +) +\l@british = a dialect from \language\l@english +\l@UKenglish = a dialect from \language\l@english +\l@canadian = a dialect from \language\l@american +\l@australian = a dialect from \language\l@british +\l@newzealand = a dialect from \language\l@british +)) +(/usr/share/texmf-texlive/tex/latex/base/inputenc.sty +Package: inputenc 2008/03/30 v1.1d Input encoding file +\inpenc@prehook=\toks15 +\inpenc@posthook=\toks16 + +(/usr/share/texmf-texlive/tex/latex/base/latin2.def +File: latin2.def 2008/03/30 v1.1d Input encoding file +)) (./titlepic.sty +Package: titlepic 2009/08/03 1.1 Package to display a picture on the title page + +) +(/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty +Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR) +\Gin@req@height=\dimen104 +\Gin@req@width=\dimen105 +) +(/usr/share/texmf-texlive/tex/latex/ltxmisc/url.sty +\Urlmuskip=\muskip10 +Package: url 2006/04/12 ver 3.3 Verb mode for urls, etc. +) +(/usr/share/texmf-texlive/tex/latex/lastpage/lastpage.sty +Package: lastpage 1994/06/25 v0.1b LaTeX2e package for refs to last page number + (JPG) +) +(/usr/share/texmf-texlive/tex/latex/base/fontenc.sty +Package: fontenc 2005/09/27 v1.99g Standard LaTeX package + +(/usr/share/texmf-texlive/tex/latex/base/t1enc.def +File: t1enc.def 2005/09/27 v1.99g Standard LaTeX file +LaTeX Font Info: Redeclaring font encoding T1 on input line 43. +)) +(/usr/share/texmf-texlive/tex/latex/koma-script/scrpage2.sty +Package: scrpage2 2008/12/08 v2.3 LaTeX2e KOMA-Script package +LaTeX Info: Redefining \pagemark on input line 176. +) +(/usr/share/texmf-texlive/tex/latex/hyperref/hyperref.sty +Package: hyperref 2009/10/09 v6.79a Hypertext links for LaTeX + +(/usr/share/texmf-texlive/tex/generic/oberdiek/ifpdf.sty +Package: ifpdf 2009/04/10 v2.0 Provides the ifpdf switch (HO) +Package ifpdf Info: pdfTeX in pdf mode detected. +) +(/usr/share/texmf-texlive/tex/generic/oberdiek/ifvtex.sty +Package: ifvtex 2008/11/04 v1.4 Switches for detecting VTeX and its modes (HO) +Package ifvtex Info: VTeX not detected. +) +(/usr/share/texmf-texlive/tex/generic/ifxetex/ifxetex.sty +Package: ifxetex 2009/01/23 v0.5 Provides ifxetex conditional +) +(/usr/share/texmf-texlive/tex/latex/oberdiek/hycolor.sty +Package: hycolor 2009/10/02 v1.5 Code for color options of hyperref/bookmark (H +O) + +(/usr/share/texmf-texlive/tex/latex/oberdiek/xcolor-patch.sty +Package: xcolor-patch 2009/10/02 xcolor patch +)) +\@linkdim=\dimen106 +\Hy@linkcounter=\count90 +\Hy@pagecounter=\count91 + +(/usr/share/texmf-texlive/tex/latex/hyperref/pd1enc.def +File: pd1enc.def 2009/10/09 v6.79a Hyperref: PDFDocEncoding definition (HO) +) +(/usr/share/texmf-texlive/tex/generic/oberdiek/etexcmds.sty +Package: etexcmds 2007/12/12 v1.2 Prefix for e-TeX command names (HO) + +(/usr/share/texmf-texlive/tex/generic/oberdiek/infwarerr.sty +Package: infwarerr 2007/09/09 v1.2 Providing info/warning/message (HO) +) +Package etexcmds Info: Could not find \expanded. +(etexcmds) That can mean that you are not using pdfTeX 1.50 or +(etexcmds) that some package has redefined \expanded. +(etexcmds) In the latter case, load this package earlier. +) +(/usr/share/texmf-texlive/tex/latex/latexconfig/hyperref.cfg +File: hyperref.cfg 2002/06/06 v1.2 hyperref configuration of TeXLive +) +(/usr/share/texmf-texlive/tex/latex/oberdiek/kvoptions.sty +Package: kvoptions 2009/08/13 v3.4 Keyval support for LaTeX options (HO) + +(/usr/share/texmf-texlive/tex/generic/oberdiek/kvsetkeys.sty +Package: kvsetkeys 2009/07/30 v1.5 Key value parser with default handler suppor +t (HO) +)) +Package hyperref Info: Hyper figures OFF on input line 2975. +Package hyperref Info: Link nesting OFF on input line 2980. +Package hyperref Info: Hyper index ON on input line 2983. +Package hyperref Info: Plain pages OFF on input line 2990. +Package hyperref Info: Backreferencing OFF on input line 2995. + +Implicit mode ON; LaTeX internals redefined +Package hyperref Info: Bookmarks ON on input line 3191. +LaTeX Info: Redefining \url on input line 3428. +(/usr/share/texmf-texlive/tex/generic/oberdiek/bitset.sty +Package: bitset 2007/09/28 v1.0 Data type bit set (HO) + +(/usr/share/texmf-texlive/tex/generic/oberdiek/intcalc.sty +Package: intcalc 2007/09/27 v1.1 Expandable integer calculations (HO) +) +(/usr/share/texmf-texlive/tex/generic/oberdiek/bigintcalc.sty +Package: bigintcalc 2007/11/11 v1.1 Expandable big integer calculations (HO) + +(/usr/share/texmf-texlive/tex/generic/oberdiek/pdftexcmds.sty +Package: pdftexcmds 2009/09/23 v0.6 LuaTeX support for pdfTeX utility functions + (HO) + +(/usr/share/texmf-texlive/tex/generic/oberdiek/ifluatex.sty +Package: ifluatex 2009/04/17 v1.2 Provides the ifluatex switch (HO) +Package ifluatex Info: LuaTeX not detected. +) +(/usr/share/texmf-texlive/tex/generic/oberdiek/ltxcmds.sty +Package: ltxcmds 2009/08/05 v1.0 Some LaTeX kernel commands for general use (HO +) +) +Package pdftexcmds Info: LuaTeX not detected. +Package pdftexcmds Info: \pdf@primitive is available. +Package pdftexcmds Info: \pdf@ifprimitive is available. +))) +\Fld@menulength=\count92 +\Field@Width=\dimen107 +\Fld@charsize=\dimen108 +\Field@toks=\toks17 +Package hyperref Info: Hyper figures OFF on input line 4377. +Package hyperref Info: Link nesting OFF on input line 4382. +Package hyperref Info: Hyper index ON on input line 4385. +Package hyperref Info: backreferencing OFF on input line 4392. +Package hyperref Info: Link coloring OFF on input line 4397. +Package hyperref Info: Link coloring with OCG OFF on input line 4402. +Package hyperref Info: PDF/A mode OFF on input line 4407. + +(/usr/share/texmf-texlive/tex/generic/oberdiek/atbegshi.sty +Package: atbegshi 2008/07/31 v1.9 At begin shipout hook (HO) +) +\Hy@abspage=\count93 +\c@Item=\count94 +\c@Hfootnote=\count95 +) +*hyperref using driver hpdftex* +(/usr/share/texmf-texlive/tex/latex/hyperref/hpdftex.def +File: hpdftex.def 2009/10/09 v6.79a Hyperref driver for pdfTeX +\Fld@listcount=\count96 +) +Package hyperref Info: Option `colorlinks' set `true' on input line 36. + +(/usr/share/texmf-texlive/tex/latex/graphics/color.sty +Package: color 2005/11/14 v1.0j Standard LaTeX Color (DPC) + +(/etc/texmf/tex/latex/config/color.cfg +File: color.cfg 2007/01/18 v1.5 color configuration of teTeX/TeXLive +) +Package color Info: Driver file: pdftex.def on input line 130. +) +(/usr/share/texmf-texlive/tex/latex/listings/listings.sty +\lst@mode=\count97 +\lst@gtempboxa=\box27 +\lst@token=\toks18 +\lst@length=\count98 +\lst@currlwidth=\dimen109 +\lst@column=\count99 +\lst@pos=\count100 +\lst@lostspace=\dimen110 +\lst@width=\dimen111 +\lst@newlines=\count101 +\lst@lineno=\count102 +\lst@maxwidth=\dimen112 + +(/usr/share/texmf-texlive/tex/latex/listings/lstmisc.sty +File: lstmisc.sty 2007/02/22 1.4 (Carsten Heinz) +\c@lstnumber=\count103 +\lst@skipnumbers=\count104 +\lst@framebox=\box28 +) +(/usr/share/texmf-texlive/tex/latex/listings/listings.cfg +File: listings.cfg 2007/02/22 1.4 listings configuration +)) +Package: listings 2007/02/22 1.4 (Carsten Heinz) + +(/usr/share/texmf-texlive/tex/latex/fancyvrb/fancyvrb.sty +Package: fancyvrb 2008/02/07 + +Style option: `fancyvrb' v2.7a, with DG/SPQR fixes, and firstline=lastline fix +<2008/02/07> (tvz) +\FV@CodeLineNo=\count105 +\FV@InFile=\read1 +\FV@TabBox=\box29 +\c@FancyVerbLine=\count106 +\FV@StepNumber=\count107 +\FV@OutFile=\write3 +) (./test.aux) +\openout1 = `test.aux'. + +LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 96. +LaTeX Font Info: ... okay on input line 96. +LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 96. +LaTeX Font Info: ... okay on input line 96. +LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 96. +LaTeX Font Info: ... okay on input line 96. +LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 96. +LaTeX Font Info: ... okay on input line 96. +LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 96. +LaTeX Font Info: ... okay on input line 96. +LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 96. +LaTeX Font Info: ... okay on input line 96. +LaTeX Font Info: Checking defaults for PD1/pdf/m/n on input line 96. +LaTeX Font Info: ... okay on input line 96. + +(/usr/share/texmf/tex/context/base/supp-pdf.mkii +[Loading MPS to PDF converter (version 2006.09.02).] +\scratchcounter=\count108 +\scratchdimen=\dimen113 +\scratchbox=\box30 +\nofMPsegments=\count109 +\nofMParguments=\count110 +\everyMPshowfont=\toks19 +\MPscratchCnt=\count111 +\MPscratchDim=\dimen114 +\MPnumerator=\count112 +\everyMPtoPDFconversion=\toks20 +) +Package hyperref Info: Link coloring ON on input line 96. + (/usr/share/texmf-texlive/tex/latex/hyperref/nameref.sty +Package: nameref 2007/05/29 v2.31 Cross-referencing by name of section + +(/usr/share/texmf-texlive/tex/latex/oberdiek/refcount.sty +Package: refcount 2008/08/11 v3.1 Data extraction from references (HO) +) +\c@section@level=\count113 +) +LaTeX Info: Redefining \ref on input line 96. +LaTeX Info: Redefining \pageref on input line 96. + (./test.out) +(./test.out) +\@outlinefile=\write4 +\openout4 = `test.out'. + +\AtBeginShipoutBox=\box31 +\c@lstlisting=\count114 +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <12> on input line 113. +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <8> on input line 113. +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <6> on input line 113. + +File: uniLogo2.png Graphic file (type png) + +[1 + +{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map} <./uniLogo2.png (PNG copy)> +] +LaTeX Font Info: Try loading font information for T1+cmss on input line 115. + + (/usr/share/texmf-texlive/tex/latex/base/t1cmss.fd +File: t1cmss.fd 1999/05/25 v2.5h Standard LaTeX font definitions +) (./test.toc +Class scrartcl Info: You've told me to use the font selection of the element +(scrartcl) `sectioning' that is an alias of element `disposition' +(scrartcl) on input line 2. +Class scrartcl Info: You've told me to use the font selection of the element +(scrartcl) `sectioning' that is an alias of element `disposition' +(scrartcl) on input line 3. +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <10.95> on input line 4. +Class scrartcl Info: You've told me to use the font selection of the element +(scrartcl) `sectioning' that is an alias of element `disposition' +(scrartcl) on input line 7. +Class scrartcl Info: You've told me to use the font selection of the element +(scrartcl) `sectioning' that is an alias of element `disposition' +(scrartcl) on input line 8. +Class scrartcl Info: You've told me to use the font selection of the element +(scrartcl) `sectioning' that is an alias of element `disposition' +(scrartcl) on input line 19. +Class scrartcl Info: You've told me to use the font selection of the element +(scrartcl) `sectioning' that is an alias of element `disposition' +(scrartcl) on input line 24. +Class scrartcl Info: You've told me to use the font selection of the element +(scrartcl) `sectioning' that is an alias of element `disposition' +(scrartcl) on input line 27. +Class scrartcl Info: You've told me to use the font selection of the element +(scrartcl) `sectioning' that is an alias of element `disposition' +(scrartcl) on input line 32. +Class scrartcl Info: You've told me to use the font selection of the element +(scrartcl) `sectioning' that is an alias of element `disposition' +(scrartcl) on input line 35. + [2] +Class scrartcl Info: You've told me to use the font selection of the element +(scrartcl) `sectioning' that is an alias of element `disposition' +(scrartcl) on input line 59. +) +\tf@toc=\write5 +\openout5 = `test.toc'. + + +[3] [4 + +] +File: BigPicture_new1.png Graphic file (type png) + + + +File: activity_diagram.png Graphic file (type png) + + [5 + + <./BigPicture_new1.png>] [6 <./activity_diagram.png>] +File: test_Use_case.png Graphic file (type png) + + [7 <./test_Use_case.png>] [8] +LaTeX Font Info: Try loading font information for T1+cmtt on input line 188. + + +(/usr/share/texmf-texlive/tex/latex/base/t1cmtt.fd +File: t1cmtt.fd 1999/05/25 v2.5h Standard LaTeX font definitions +) [9] [10] + +File: DBRelationship.png Graphic file (type png) + +[11 + + <./DBRelationship.png>] +LaTeX Font Info: Try loading font information for OMS+cmr on input line 234. + + (/usr/share/texmf-texlive/tex/latex/base/omscmr.fd +File: omscmr.fd 1999/05/25 v2.5h Standard LaTeX font definitions +) +LaTeX Font Info: Font shape `OMS/cmr/m/n' in size <10.95> not available +(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 234. + +File: activityControllerEdited.png Graphic file (type png) + + +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <9> on input line 258. +LaTeX Font Info: External font `cmex10' loaded for size +(Font) <5> on input line 258. + [12 + + <./activityControllerEdited.png (PNG copy)>] [13] +File: classDiagram.png Graphic file (type png) + + [14 + + <./classDiagram.png>] + +File: dbClass.png Graphic file (type png) + + +File: serialPort.png Graphic file (type png) + +[15 + + <./dbClass.png>] +File: serverClass.png Graphic file (type png) + + +File: ClientClass.png Graphic file (type png) + + [16 <./serialPort.png (PNG copy)>] + +File: ping.png Graphic file (type png) + [17 <./serverClass.png (PNG copy)> <./ClientClass.png (PNG copy +)>] + +File: logging.png Graphic file (type png) + + +File: sshTunnelClass.png Graphic file (type png) + + +File: usbDetectClass.png Graphic file (type png) + + [18 <./ping.png (PNG copy)> <./logging.png (PNG copy)> + <./sshTunnelClass.png (PNG copy)>] + +File: trueTable.png Graphic file (type png) + + +File: initTestClass.png Graphic file (type png) + + +File: controllerclass.png Graphic file (type png) + + [19 <./usbDetectClass.png (PNG copy)> <./trueTable.pn +g (PNG copy)>] [20 <./initTestClass.png> <./controllerclass.png (PNG copy)>] + +File: bb.jpg Graphic file (type jpg) + [21 + + <./bb.jpg>] [22] +[23 + +] [24] + +File: protocolCommunicationHandler.png Graphic file (type png) + + [25 + + <./protocolCommunicationHandler.png (PNG copy)>] + +File: protocolCommunicationcControllerReceiver.png Graphic file (type png) + + +File: protocolCommunicationcControllerCaller.png Graphic file (type png) + [26 + + <./protocolCommunicationcControllerReceiver.png (PNG copy)> <./protocolCommuni +cationcControllerCaller.png (PNG copy)>] [27] +File: sshTunnel.png Graphic file (type png) + + [28 + + <./sshTunnel.png (PNG copy)>] [29] [30] +LaTeX Font Info: Font shape `OMS/cmr/m/n' in size <9> not available +(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 710. + [31] [32] +[33] [34] +File: resultsImage.png Graphic file (type png) + + [35 <./resultsImage.png (PNG copy)>] [36] [37] [38] +[39] +File: First.png Graphic file (type png) + + +File: Second.png Graphic file (type png) + + +File: Third.png Graphic file (type png) + [40 <./First.png> <./Second.png> <./Third.png>] [41 + +] [42] [43] [44] + +File: website1.png Graphic file (type png) + + +File: website2.png Graphic file (type png) + [45 + + <./website1.png (PNG copy)>] +File: webpageReport.png Graphic file (type png) + + +File: website3.png Graphic file (type png) + + +File: website4.png Graphic file (type png) + + [46 <./website2.png (PNG copy)> <./webpageReport.png (PNG co +py)>] +File: terminalCommand.png Graphic file (type png) + + + +File: resultterminal.png Graphic file (type png) + + [47 <./website3.png (PNG copy)> <./website4.png (PNG c +opy)>] +File: devconf.png Graphic file (type png) + +[48 <./terminalCommand.png (PNG copy)> <./resultterminal.png (PNG copy)> <./dev +conf.png (PNG copy)>] [49 + +] AED: lastpage setting LastPage [50] (./test.aux) ) +Here is how much of TeX's memory you used: + 8696 strings out of 495061 + 126228 string characters out of 1182621 + 768145 words of memory out of 3000000 + 11294 multiletter control sequences out of 15000+50000 + 18496 words of font info for 43 fonts, out of 3000000 for 9000 + 28 hyphenation exceptions out of 8191 + 43i,11n,45p,760b,1784s stack positions out of 5000i,500n,10000p,200000b,50000s + + +Output written on test.pdf (50 pages, 5058627 bytes). +PDF statistics: + 1657 PDF objects out of 1728 (max. 8388607) + 418 named destinations out of 1000 (max. 500000) + 640 words of extra memory for PDF output out of 10000 (max. 10000000) + diff --git a/documenting/Report/test.out b/documenting/Report/test.out new file mode 100644 index 0000000..b4daec0 --- /dev/null +++ b/documenting/Report/test.out @@ -0,0 +1,58 @@ +\BOOKMARK [1][-]{section.1}{Introduction and Motivation}{} +\BOOKMARK [1][-]{section.2}{Requirements}{} +\BOOKMARK [2][-]{subsection.2.1}{Logical and algorithmic requirements}{section.2} +\BOOKMARK [2][-]{subsection.2.2}{Software requirements}{section.2} +\BOOKMARK [2][-]{subsection.2.3}{Hardware requirements}{section.2} +\BOOKMARK [1][-]{section.3}{Database design}{} +\BOOKMARK [1][-]{section.4}{Software design}{} +\BOOKMARK [2][-]{subsection.4.1}{Database access}{section.4} +\BOOKMARK [2][-]{subsection.4.2}{Controlling the cell phones}{section.4} +\BOOKMARK [2][-]{subsection.4.3}{Client and Server class}{section.4} +\BOOKMARK [2][-]{subsection.4.4}{Ping class}{section.4} +\BOOKMARK [2][-]{subsection.4.5}{Data logging}{section.4} +\BOOKMARK [2][-]{subsection.4.6}{SSH Tunnel Class}{section.4} +\BOOKMARK [2][-]{subsection.4.7}{USB Cell phone detection class}{section.4} +\BOOKMARK [2][-]{subsection.4.8}{Truth table class}{section.4} +\BOOKMARK [2][-]{subsection.4.9}{Init Test class}{section.4} +\BOOKMARK [2][-]{subsection.4.10}{Controller class}{section.4} +\BOOKMARK [1][-]{section.5}{Hardware design}{} +\BOOKMARK [2][-]{subsection.5.1}{BeagleBoard}{section.5} +\BOOKMARK [2][-]{subsection.5.2}{Cell phones}{section.5} +\BOOKMARK [2][-]{subsection.5.3}{Cables for the cell phones}{section.5} +\BOOKMARK [2][-]{subsection.5.4}{Server}{section.5} +\BOOKMARK [1][-]{section.6}{Communication protocol}{} +\BOOKMARK [2][-]{subsection.6.1}{Communication between the handler and controller}{section.6} +\BOOKMARK [2][-]{subsection.6.2}{Verification of the protocol}{section.6} +\BOOKMARK [1][-]{section.7}{Security and safety of the system}{} +\BOOKMARK [2][-]{subsection.7.1}{Encryption of the communication channels}{section.7} +\BOOKMARK [2][-]{subsection.7.2}{Security on the web site}{section.7} +\BOOKMARK [3][-]{subsubsection.7.2.1}{Configuring the http secure protocol https}{subsection.7.2} +\BOOKMARK [3][-]{subsubsection.7.2.2}{Password protecting the web site using .htaccess}{subsection.7.2} +\BOOKMARK [1][-]{section.8}{Web page}{} +\BOOKMARK [2][-]{subsection.8.1}{Communication between the web page and the test software}{section.8} +\BOOKMARK [2][-]{subsection.8.2}{Results on the web page}{section.8} +\BOOKMARK [1][-]{section.9}{Employing the test software system}{} +\BOOKMARK [2][-]{subsection.9.1}{Required software and libraries}{section.9} +\BOOKMARK [3][-]{subsubsection.9.1.1}{Python installation}{subsection.9.1} +\BOOKMARK [3][-]{subsubsection.9.1.2}{Apache Web server installation}{subsection.9.1} +\BOOKMARK [3][-]{subsubsection.9.1.3}{SSH}{subsection.9.1} +\BOOKMARK [3][-]{subsubsection.9.1.4}{MySQL database and MySQLdb library}{subsection.9.1} +\BOOKMARK [3][-]{subsubsection.9.1.5}{Serial port library}{subsection.9.1} +\BOOKMARK [3][-]{subsubsection.9.1.6}{PJSUA library}{subsection.9.1} +\BOOKMARK [3][-]{subsubsection.9.1.7}{pChart library}{subsection.9.1} +\BOOKMARK [3][-]{subsubsection.9.1.8}{proctitle library}{subsection.9.1} +\BOOKMARK [2][-]{subsection.9.2}{Configuring hardware}{section.9} +\BOOKMARK [3][-]{subsubsection.9.2.1}{Configuring the cell phones}{subsection.9.2} +\BOOKMARK [2][-]{subsection.9.3}{Location of the files}{section.9} +\BOOKMARK [2][-]{subsection.9.4}{Setting up the parameters}{section.9} +\BOOKMARK [2][-]{subsection.9.5}{Test descriptions}{section.9} +\BOOKMARK [3][-]{subsubsection.9.5.1}{Smart test}{subsection.9.5} +\BOOKMARK [3][-]{subsubsection.9.5.2}{SIP test}{subsection.9.5} +\BOOKMARK [3][-]{subsubsection.9.5.3}{GSM test}{subsection.9.5} +\BOOKMARK [3][-]{subsubsection.9.5.4}{All test}{subsection.9.5} +\BOOKMARK [3][-]{subsubsection.9.5.5}{Manual test}{subsection.9.5} +\BOOKMARK [2][-]{subsection.9.6}{Result descriptions}{section.9} +\BOOKMARK [2][-]{subsection.9.7}{Using the software}{section.9} +\BOOKMARK [3][-]{subsubsection.9.7.1}{Web site guide}{subsection.9.7} +\BOOKMARK [3][-]{subsubsection.9.7.2}{Terminal guide}{subsection.9.7} +\BOOKMARK [1][-]{section.10}{Conclusion}{} diff --git a/documenting/Report/test.pdf b/documenting/Report/test.pdf new file mode 100644 index 0000000..71c64e0 Binary files /dev/null and b/documenting/Report/test.pdf differ diff --git a/documenting/Report/test.tex b/documenting/Report/test.tex new file mode 100644 index 0000000..6e15c02 --- /dev/null +++ b/documenting/Report/test.tex @@ -0,0 +1,1376 @@ +\documentclass[a4paper, titlepage, oneside, headsepline, footsepline]{scrartcl} +%PACKAGES +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\usepackage{lscape} %for the landscape pages it is used +\usepackage[english]{babel} %what language are we using +\usepackage[latin2]{inputenc} %what alphabet + +\usepackage[tt]{titlepic} %used for adding the title image +\usepackage{graphicx} %used for adding images +\usepackage{url} %used for the url in bibliography +\usepackage{lastpage} %give me the total number of pages, used in footer: \pageref{LastPage} + +\usepackage[T1]{fontenc} %used for fonts +\usepackage{scrpage2} %used for making headers, footers and correct margins +%\usepackage{hyperref} %used for the linking of table of content + +%information for the PDF +\usepackage[pdftex, %used for adding pdf information + pdfauthor={Refik Hadzialic, Triatmoko}, + pdftitle={Software for self-testing of the Telecommunication network of University of Freiburg}, + pdfsubject={Telecommunication network testing software}, + pdfkeywords={telecommunication;network;networking;linux;ubuntu;university;Freiburg;python;tcp/ip;security;gsm;sip;voip}, + pdfproducer={Latex with hyperref, or other system}, + pdfcreator={pdflatex, or other tool}]{hyperref} %used for the linking of table of content + + + + + +\hypersetup{ %setting up the look of the links + colorlinks, + citecolor=black, + filecolor=black, + linkcolor=black, + urlcolor=black +} + +\usepackage{color} %used for highlighting source code +\usepackage{listings} %used to make a box with source code +\usepackage{fancyvrb} +\DefineVerbatimEnvironment{code}{Verbatim}{fontsize=\small} +\DefineVerbatimEnvironment{example}{Verbatim}{fontsize=\small} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%DEFINE LOOK OF THE PAGES +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\pagestyle{scrheadings} + +\renewenvironment{abstract} + {\begin{center}\large\textbf{}\noindent\end{center}}{\vspace{2\baselineskip}} + +% Disable single lines at the start of a paragraph (Schusterjungen) +\clubpenalty = 10000 +% Disable single lines at the end of a paragraph (Hurenkinder) +\widowpenalty = 10000 \displaywidowpenalty = 10000 + +\setlength{\parskip}{0.01\baselineskip} +\textheight = 620pt + +\ohead{Software for self-testing of the Telecommunication network of University of Freiburg} %make the header +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%DEFINE THE STUFF FOR CODE +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\lstset{ % +%language=Python, % choose the language of the code +columns=fullflexible, +keywordstyle=\color[rgb]{0.608,0.561,0.008}, +commentstyle=\color[rgb]{0.25,0.5,0.35}, +stringstyle=\color[rgb]{0.25,0.35,0.85}, +basicstyle=\footnotesize,%\scriptsize % the size of the fonts that are used for the code +%numbers=left, % where to put the line-numbers +numberstyle=\footnotesize, % the size of the fonts that are used for the line-numbers +stepnumber=1, % the step between two line-numbers. If it is 1 each line will be numbered +numbersep=8pt, % how far the line-numbers are from the code +backgroundcolor=\color{white}, % choose the background color. You must add \usepackage{color} +showspaces=false, % show spaces adding particular underscores +showstringspaces=false, % underline spaces within strings +showtabs=false, % show tabs within strings adding particular underscores +frame=single, % adds a frame around the code +tabsize=2, % sets default tabsize to 2 spaces +captionpos=b, % sets the caption-position to bottom +breaklines=true, % sets automatic line breaking +breakatwhitespace=false, % sets if automatic breaks should only happen at whitespace +escapeinside={\%}{)} % if you want to add a comment within your code +} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + + +\newcommand{\titleOfProject}{Software For Self-Testing Of The Telecommunication Network Of University Of Freiburg} + + + +%begin of the document +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\begin{document} + + + + +%make the title page +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\titlepic{\includegraphics[width=90mm]{uniLogo2.png}} +\title{Team Project \\ ``\titleOfProject''} % type title between braces +\date{\today} % type date between braces +\author{Refik Had\v{z}iali\'{c}\\ Triatmoko } % type author(s) between braces +\department{\vspace{1\baselineskip} \large Albert-Ludwigs-Universit\"{a}t Freiburg \\ +Lehrstuhl f\"{u}r Komunikationsysteme\\ +Prof. Dr. Gerhard Schneider\\ \vspace{1\baselineskip} Supervisors: \\ Konrad Meier \\ Dennis Wehrle \\ \vspace{1\baselineskip} Sommersemester 2011} + +\maketitle +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%add the table of contents +\tableofcontents + +%new page to start with +\clearpage + + + + +% first chapter +\section{Introduction and Motivation} % chapter 1 +In the following report, the authors will try to give you a brief insight into our team project. The goal of our project was to develop a mechanism for automatic testing of our University Telecommunication network. The Telecommunication network of University of Freiburg consists of: our own internal GSM and telephone network systems; GSM redirecting device (if one initiates a call to one of the four external GSM networks, it redirects the calls to: T-mobile, 02, Vodaphone or E-Plus); a SIP gateway for land-line calls inside of Germany (sipgate.de) and international calls. Since we did not have access to internal servers, our strategy was to exploit the existing systems from an external perspective and infer the results out of our findings. +Before we had started working on our project, we had to analyze the overall network to come up with the 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. In the following chapters we will describe in more detail our approach to the problem and how each subsystem works. +This particular report and our wiki page should be a sufficient guide and manual for understanding, running and continuing the development of our test software. +Certainly, we had a lot of fun while working on the project due the fact that we lost one team member. +We would like to thank the whole department for the free coffee and their support, especially +Konrad Meier, Dennis Wehrle, Richard M. Zahoransky and Larissa Linz, without their support this project would not +end up this way. +\clearpage +\section{Requirements} % chapter 2 +At the start of the project the requirements were not completely known but as the time had passed we redefined our requirements and goals. +The first and the most important part at the start was to identify the key goals of our team project. The basic goal of our team project was to build a +test software system which could tell an operator user what part of the system is not properly working in our University telecommunication network. +Konrad and Dennis suggested us to analyze figure 1 and depending on it to build our test software. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{BigPicture_new1.png} + \caption[]{Overview of the Freiburg University telecommunication network \cite{network}} +\end{figure} +Our first attempt was to see what could we test without having access to the system. We installed numerous communication programs to see what others have done. +After gaining access to the communication software, we had decided to build most of the test software ourselves. Libraries, which were used, +were only the ones we could not develop ourselves because of the time-span of our team project. +\subsection{Logical and algorithmic requirements} +Despite the software and hardware requirements, the logic in our team project may be considered as the most important part. +Controlling the software and hardware in a specific manner was one of the requirements in our team project. +Moreover, we were required to draw a use case diagram and a simple test case diagram so that we could better understand all the problems we had to deal with +but also to easier follow the development of our test software. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{activity_diagram.png} + \caption[]{Simple algorithmic overview of a test case} +\end{figure} +\subsection{Software requirements} +Afterwards, as we had defined our logical approach to the problems, we had to choose the programming language to realize our ideas. Since we had the freedom of choice, between the three suggested programming languages +Java, C++ and Python, we made a joint decision to use Python as the main programming language in our team project. One of the requirements was to finish the team project in time, +therefore our decision to use Python is justified. Using Python we could work faster and integrate our subsystems more effectively \cite{python}. +Our programming language of choice is multi-platform, therefore our test software would be easy portable to other operating systems. +\par Likewise we had to decide how our test software will work. One of the requirements by Dennis and Konrad was to make the software capable of being run from the terminal. +The next requirement was to make an appealing GUI so that even an user without advanced Linux experience could handle the software and read out the results. +\par In addition it was required to log all the past tests. Later on a machine learning algorithm or some other intelligence could be applied to deduce some error behavior of the system +(e.g. an intelligent algorithm could find that part of the system fail in a combined manner). To accomplish the logging of all the tests we had to use a database system. +We decided to use MySQL since it is open source and well supported. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{test_Use_case.png} + \caption[]{Test case diagram} +\end{figure} +\subsection{Hardware requirements} +Likewise the software requirements, we had hardware requirements as well. We were required to identify the hardware we will need to perform the tests. +It was important to find old and cheap cell phones that could support \emph{AT Modem} commands because our budget was limited. +\par A problem we had to deal with at the start was that the base stations are located at different geographical points which were not near to each other. +No one should go everyday to the rooms where our cell phones are located only to change or charge the batteries. +In the cable subsection we describe our approach to the charging battery problem. As we defined our requirements we continued with the process of developing the test software. +During the development time we refined our requirements. In the next chapters we will explain our database, software and hardware design ideas. +\newpage +\section{Database design} +As we mentioned in the software requirements section, we decided to use MySQL as our database system for storing the test information and results. +It was not difficult to decide what database to use, since MySQL is one of the most supported database and one can find a library to use it with major programming languages. +The key point in the design of our database was the simplicity and speed of accessing the data. We had decided to use seven tables. In the following paragraphs we will explain each table separately and its usage. +The database design can be seen in figure 4. + +\par The \emph{PingResultTable} table has six attributes (\emph{taskNo, sipServer, sipGate, unisip, gsmBox1, gsmBox2}), all of integer type. +The \emph{taskNo} attribute identifies the test number but not a single test (e.g. an operator user has selected three different tests to be executed, all of the three tests will have the same \emph{taskNo} to identify them together as belonging to one test group and \emph{taskId} identifies each single test and will be explained later). +\emph{sipServer} represents the Asterisk server ping result. \emph{sipGate} is used to represent the SIP Gate server for the landline calls (\url{http://www.sipgate.de}). \emph{uniSip} represents the ping results for our local University telephone network SIP server. +\emph{gsmBox1} and \emph{gsmBox2} are the two single-chip Linux computers (BeagleBoard), that control two cell phones each one (i.e. they are also known under the name of \emph{nanoBTSx controller}). +\emph{taskNo} is the primary and unique key in the table \emph{PingResultTable}. Rest of the attributes (i.e. \emph{sipServer, sipGate, uniSip, gsmBox1, gsmBox2}) are used to insert the ping results, if the assigned servers are reachable or not. +Before any test attempt is made, our test software first tries to ping the servers. These results are then stored in the \emph{PingResultTable}. + +\par The \emph{ErrorCodeTable} table defines all the possible test results in the system, in other words it represents a list with error codes with their appropriate descriptions and meanings. It consists of two attributes (\emph{errorcode} and \emph{description}), the first is of integer type and the second of varchar type (the description message is allowed to be only 100 characters long). +The \emph{ErrorCodeTable} table is used by the main test software (i.e. controller) to report the operator user what kind of error had appeared in the system. + +\par The \emph{DeviceAddressTable} is the table containing the location and identification data for each server and device. The table consists of seven attributes, \emph{deviceName, portName, number, lastChange, username, password, server}. +\emph{deviceName} is the attribute with the name of the device or server (e.g. GSMRZ1 or landline), it is of varchar type. \emph{portName} is the attribute field with the location address for a cell phone (e.g. \emph{/dev/ttyUSB1}) or 'localhost' instead of NULL value for a server, it is of the varchar type. +\emph{number} represents the number of the used service (i.e. number of the cell phone, SIP, etc.) and is of varchar type. +\emph{lastChange} is a time value and represents the date and time the given entry was modified (we had plans in future versions of our test software that if an device gets a new IP address assigned it automatically changes it in the database). +\emph{username} is the field with the username stored in for a server/service, like SIP and landline. \emph{password} attribute stores the password information for the given service. The \emph{server} attribute stores information about the location of the server, IP or DNS address of the server. All three fields, \emph{username}, \emph{password} and \emph{server} are of varchar type. +The information stored in the given table is used by the test software to obtain usernames, passwords and addresses of the used services for the tests. + +\par The \emph{ResultTable} table is used by the test system to store final results for the performed tests. Our given table consists of two fields, \emph{taskID} and \emph{result} and both are of integer type. For each test entry with unique \emph{taskID} an error code is assigned in the \emph{result} field, +depending on the test results. Error codes found in the \emph{ErrorCodeTable} table can be only assigned to this field. + +\par The \emph{TempTaskTable} table represents the table with the tasks the system has to execute next time the test software is started. The given table gets new data every time an operator user submits one or more test cases from the website to be executed. \emph{TempTaskTable} includes four attributes, \emph{taskID, taskNo, from, to}. Former two are of integer type and later two of varchar type. +\emph{taskID} and \emph{taskNo} identify the test task to be executed, \emph{taskID} is the unique primary key. \emph{from} and \emph{to} fields have to match the names given in \emph{DeviceAddressTable.deviceName}, these two attributes specify the caller and callee devices/services. Consequently, after the tasks get executed, the test tasks are removed and the given table is empty again until next tests are added to it. +However, all the test tasks even after deleting them from \emph{TempTaskTable} are kept in the \emph{TaskTable}. The reason why the authors of this project divided it into two tables was because of the database row selection speed. We had made the assumption that with time the database size will grow and therefore the database speed will not be the same as during the development period. + +\par The \emph{TaskTable} table, as mentioned before contains all the tests ever performed from the web site. It is made out of five attributes, \emph{taskID, taskNo, from, to, timestamp}. The first four fields are the same as in \emph{TempTaskTable}, however the last one, \emph{timestamp}, is used to record the exact time when the test was performed. +\par The \emph{GSMListPrefix} table contains the data about the GSM networks and their prefixes. It consists of two +attributes, both of varchar type, \emph{providerName} and \emph{prefix}. +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{DBRelationship.png} + \caption[]{Database relationship diagram} +\end{figure} +\end{center} +\end{landscape} + + + + + +\section{Software design} % section 2.1 +Software design was the next step after we analyzed the problem and developed a plan how to proceed further. Good analysis and planning with poor algorithmic implementation is valueless. +During the work on the project, we had spent most of our time for software design. +We kept in mind that our software should satisfy major paradigms of software engineering, +like compatibility, extensibility, modularity, reliability, security, fault-tolerance and usability. +The software engineering design concepts were achieved following way: +\begin{itemize} +\item Compatibility - we used Python and MySQL which are multi-platform and work on major OS +\item Extensibility - new parts of code can be easily added by just modifying the classes +\item Mudalarity - the components are independent black boxes, they are tested and validated independently +\item Reliability - we use mutex locks to perform tests and database transaction operations to insert data into the database +\item Security - all communication channels, as well as the access to the web site, are encrypted with asymmetric key cryptography +\item Fault-tolerance - the classes were designed to continue operating even if error events appear and handlers are logging all events +\item Usability - we tried to create a simple user interface and easily to use for everyone +\end{itemize} + +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{activityControllerEdited.png} + \caption[]{Working principle of the test software} +\end{figure} + +\par The basic principle how the test software works can be seen in figure 5. The test software is +started either manually from the terminal or using the web site. When the test software +is started manually it is database dependent as well and therefore could not be used if the +database is being maintained or not working. If it is started from the web site it +connects to the database to get its tasks which have to be performed. After receiving +the tasks it makes a simple network test by pinging all the servers. The ping results +are stored in the database (in case the test was started from the web site). Then it +proceeds with the tests by connecting itself to the handlers and sending them commands +to perform the tests\footnote{Before it connects to the handlers, it uses the ping +results to see is the service/device physically connected to the network.}. +At the higher level, these commands can be seen as requests for being the +callee and caller. Meanwhile the handlers send their test results to the main +test software which in return decides if the test result was successful or not. +The result is written to the database (in case the software was started from the website), +otherwise the results are displayed in the terminal window and the user who started +it manually can see the test results. We will proceed with introducing the classes. +The software class diagram can be seen in the following figure. More details for the +classes, like the input/output can be found on our project's wiki page \cite{wiki}. + +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{classDiagram.png} + \caption[]{Class diagram (some classes were excluded)} +\end{figure} +\end{center} +\end{landscape} + + +\newpage +\subsection{Database access} % subsection 2.1.1 +Accessing the database is of critical value to our project, therefore we had developed our own class that limits the access to the database. In the process of developing our own class we used the MySQLdb library in Python \cite{mysqlManual}. +The database class has two working modes, a normal working mode and a debugging mode. The difference between these two modes is in the output information. In case the error handling function raises an error and it is unknown, if the debug mode is set a complete back-trace of the error will be printed out. A developer can change the mode by setting the variable \emph{debugMode=1}. The class diagram can be seen in the following figure. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{dbClass.png} + \caption[]{Class diagram for the dbClass} +\end{figure} +The method names are self-explanatory and do not require extra explanations. All the outputs produced by the class can be found on the project wiki page \cite{wiki}. +\subsection{Controlling the cell phones} +Our first version of the developed program code for controlling the cell phones used predefined timed values +to send commands instead of using a state controlled approach to confirm that every command was successfully received and executed by the cell phone. +It meant we had to make an enormous number of assumptions. In comparison to our second approach, to build a state controlled cell phone control class, +our first approach was inferior and slower. The state controlled method connected two cell phones, on the same base station, up to 15 times faster than the timed approach. +\begin{figure}[ht!] + \centering + \includegraphics[width=80mm]{serialPort.png} + \caption[]{GSM class diagram for controlling the cell phones} +\end{figure} +One can easily apply the class just by correctly defining the parameters: port address, baud rate and timeout. The former two are self-explanatory and the timeout parameter is used to define when the alarm function should raise a timeout exception. +A timeout exception gets raised when the cell phone does not respond (i.e. when the cell phone enters a deadlock or delayed state). We had used the serial port library inside of Python although we use USB cables to connect to our cell phones. One should +be aware that our USB cables create a virtual serial port. More details on class design and an example can be found on our project wiki \cite{wiki}. +\subsection{Client and Server class} +Our socket communication code is based on the example given in the Python socket manual \cite{socket}. +We extended it into two classes, a client and a server class. We had used the TCP protocol to base our two classes on\footnote{TCP is reliable compared to UDP (i.e. transmitted packets get also delivered), +packets are ordered when received and data are received in a stream (i.e. multiple packets can be read at once).}. +The Server class can be seen in the following figure. The server class is implemented to accept only local connections\footnote{More details are given in the section 7.1}. +First we determine our IP address and then create the socket to listen only for the same IP address (with a different IP address than the selected one a connection cannot be even established). +One has to define the port on which the server object should listen. +When receiving data one can easily define the timeout to be raised if data are not received in the timeout range or set it to \emph{0} to infinitely wait for the buffer to be filled with received data. While testing the server class we had the problem to listen on the same port if the application was forcibly\footnote{Manually closed using CTRL+C and run again.} restarted in less than 60 seconds. We got the error message: \emph{"Address already in use"}. +This is not known as error behavior but rather an option to help the server to catch lost live packets (i.e. packets that are still in the network looking for it is goal destination). +We solved the problem by changing the socket options with the \emph{SO\_REUSEADDR} parameter. This enabled us to get around the error when we tried to restart our server application. +Before solving the problem without using the socket parameter, we had another solution to get around this problem by killing the application running the port, this old method is obsolete now. +\begin{figure}[ht!] + \centering + \includegraphics[scale=0.8]{serverClass.png} + \caption[]{Server class, used by the server application} +\end{figure} +In the process of testing the client class we did not have any major problems. The only major flow we had to debug was when one of the sides disconnects that we get out of the waiting loop if the timeout variable was set to \emph{0} (i.e. infinite waiting loop). +The client class can be seen in the following figure. To initialize the client object one needs to define the IP address and the port of the server application listening on it. +\begin{figure}[hb!] + \centering + \includegraphics[scale=0.5]{ClientClass.png} + \caption[]{Client class, used by the client application} +\end{figure} +Once an instance of it is created and loaded with the IP address and the port, one needs to call the \emph{connect()} method. +The method will produce an integer based on its connection state. Output information and the programming code can be found on our project wiki page \cite{wiki}. +\subsection{Ping class} +Before making any test and establishing a connection we were required to ensure that the server is online. The best way to assess the liveness property was to ping the server computer running the required service. Once the class is properly defined, we could easily set the number of ping tries. +A ping timeout response was set up to 2 seconds. For more details and insights, one can read more about it on our wiki page \cite{wiki}. +\begin{figure}[ht!] + \centering + \includegraphics[width=70mm]{ping.png} + \caption[]{Ping class, used by test software} +\end{figure} +\subsection{Data logging} +If errors appear it is important to reconstruct the events that led to the misbehavior of the software. One of the best ways to reconstruct the events was to log +events for different blocks of programming code. +We had used the logging class to follow our handler code run on the BeagleBoard. In case there is an error we could look inside of the log files and track the error. +How the class works and what kind of outputs it produces can be found on our project wiki page \cite{wiki}. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{logging.png} + \caption[]{Logging class} +\end{figure} +\subsection{SSH Tunnel Class} +Since security played an important role in our team project. We decided to encrypt all of our data that was not processed on our server computer. +The simplest solution to this problem was to build an SSH Class that could open and close a local forwarding port. +All data sent through the created port is encrypted until it gets to its destination location. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{sshTunnelClass.png} + \caption[]{SSH Tunnel class} +\end{figure} +\subsection{USB Cell phone detection class} +Since we had used cables to connect the cell phones with the computer, usually the devices +got their own port addresses. They were automatically assigned by the operating system, +either after the cables were plugged into the USB port or after a system reboot. +One of the problems we had to deal with was assigning the right cell phone +(i.e. with the appropriate GSM network) to the corresponding port address. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{usbDetectClass.png} + \caption[]{USB cable detection class} +\end{figure} +The operating system randomly assigned the port names after every reboot. +We were looking for a solution to prevent this misaddressing of the devices. +Our solution was to recognize every device and update the port address in the database. +The principle how we identify the cell phones is by their calling numbers in the database. +More details can be found on our project wiki page \cite{wiki}. +\subsection{Truth table class} +The truth table class was built to identify the broken and working parts of the system. +It requires the list with test results to be present to be operable. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{trueTable.png} + \caption[]{Truth table class} +\end{figure} +Then the class tries to identify the broken parts of our telecommunication network. +The class can easily identify how many nanoBTSs are installed in the network and +derive a decision which part of the network is broken. +All the test results are stored in a list and can be easily read by calling the +\emph{initTrueTable(x)} function. More details can be found on our project wiki page \cite{wiki}. +\subsection{Init Test class} +The main purpose of the class is to get device data from the database and to process it. +The processed data get forwarded to the controller class and in the end the class +fetches the results from the test. This class contains the \emph{smart test} functionality. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{initTestClass.png} + \caption[]{Init test class} +\end{figure} +It selects automatically the important tests to perform. In the next step it +tries to identify the problem in the network. +More details can be found in the \emph{smart test} description. +\subsection{Controller class} +The controller class is used to assign jobs to handlers (in other words, which one is +going to be the caller and callee). Simultaneously, it defines the port addresses for +the communication between the handlers and the main test software (controller). +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{controllerclass.png} + \caption[]{Controller class} +\end{figure} +If the callee or the caller are nanoBTS controller boxes (i.e. BeagleBoards outside +the Rechenzentrum), it will first create an SSH connection to make a tunnel before +the local socket connection is created. Then the controller class sends all the +required data regarding the test tasks to the handlers. + +\clearpage +\section{Hardware design} +In our team project we had the option to choose all the required hardware ourself beside the two BeagleBoards, which we were supplied by Konrad and Dennis. +Since one of the project goals was to reduce the costs as much as it was possible, we had tried to use some of the leftovers found in our lab. + +\subsection{BeagleBoard} +``The BeagleBoard is an OMAP3530 platform designed specifically to address the Open +Source Community. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{bb.jpg} + \caption[]{BeagleBoard, a Linux-on-chip board where our controller software runs the GSM device } +\end{figure} +It has been equipped with a minimum set of features to allow the +user to experience the power of the OMAP3530 and is not intended as a full development +platform as many of the features and interfaces supplied by the OMAP3530 are not +accessible from the BeagleBoard'' \cite{beagleDataSheet}. +We run on it a special precompiled version of Ubuntu for the ARM processor type. The Linux system boots up from an SD Card. +The board has an USB hub and network port attached to it. In our project it is connected to our +internal university LAN network and to a cell phone. We positioned the two BeagleBoards in rooms where +we had LAN access and GSM signal coverage of our two local base stations. + +\subsection{Cell phones} +Our first attempt was to control a Nokia cell phone 3310 with the supplied USB connection cable. +The protocols used by old versions of Nokia cell phones, as the 3310, use the F-Bus protocol. It was not easy to work with. +After performing various experiments we succeeded to send and to read SMS messages. Later on we found out that it was not possible to +send commands for receiving and making the calls. In the meantime we found two Siemens phones, one M45 and S55. +The first one, Siemens M45, had a cable supplied with it and it was not difficult to control it with the standard set of AT modem commands. +At the start we did not have a cable supplied for the Siemens S55 phone. We controlled it over the Bluetooth port. + +\subsection{Cables for the cell phones} +Due to the fact that we had used 5 cell phones on a single computer, the best solution was to order 5 USB cables. +Konrad bought 5 cables for 5 Siemens S55 cell phones. All of the cables have an USB2Serial chip converter inside of them. +Once they were plugged into the USB port, Ubuntu automatically recognized the cables and installed the drivers. +The virtual serial ports were created and could be found on \emph{/dev/ttyUSBx}, where $x$ is the automatically assigned number for the port. +Some of the cables had the capability to charge the Siemens S55 phones. +Konrad had opened several cables to solder the power supplies to some contacts and the problem was solved for all of the cables. +\subsection{Server} +We were given an old Pentium 3 computer where we installed Ubuntu Linux. Configured the Apache web server and MySQL. +Afterwards we installed the Python on it and all the required libraries\footnote{Required libraries are mentioned in section 9.1.}. +\clearpage + +\section{Communication protocol} +A communication protocol represents a set of well defined rules by whose help two or more computing systems exchange information in-between. +When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate +response from the other side. Our approach to this problem was to build a simple synchronous protocol, where every expected message is +confirmed or otherwise the connection between two sides is immediately terminated. Since designing protocols is a demanding and challenging +topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum +protocol\footnote{Design concepts and paradigms for the protocol design have been used from the +``Network Protocol Design and Evaluation'' course, lectured by Dr. Stefan R\"{u}hrup}. +In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works, +it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device +that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software +controlling the handler side and assigning the task to it. + +\subsection{Communication between the handler and controller} +The handler side is always in the waiting mode, by waiting we denote the mode where the socket is already created and it is waiting +for a connection to be accepted at the defined port. The controller initiates a socket connection to the two handlers. +Subsequently, after the connection has been established, it is waiting for a message to be received. The first message +has to be 13 characters long and include the following content \emph{HELLO HANDLER}. Thereupon, after the message has +been validated, the handler side sends the controller side a response, \emph{HELLO CONTROLLER}. +We call this first message exchange the initialization. Now the controller side has to decide which of the two handler's +will be the caller/callee whereas the other handler will be the opposite. Let's assume the controller sends to the first +handler the message \emph{RECEIVER} and to the second one the message \emph{CALLER|\#}, replace the callee number with the \# sign. +In the meantime, both handlers initialize the software required to make the call and to receive the call. Asynchronously they +respond back to the controller their successful initialization. The successful initialization is reported by sending \emph{RECEIVER READY} +and \emph{CALLER READY}. After receiving the mentioned messages, the controller first sends the callee handler the +message \emph{RECEIVE START} and then to the caller handler, the message \emph{CALLER START}. As a result of these messages, +the handlers enter the receiving, respectively calling state. In the given states two timeout timers gets activated. +These timers are responsible for the case if the physical connection between the callee and the caller are not successfully +established or terminated\footnote{The client and server classes responsible for the communication have timeout timers as well +for the case if the connection between the controller and handlers are broken.}. Afterwards, depending if the physical connection +between the handlers (i.e. the callee and the caller) was successfully established or not, the handlers report their +corresponding state with a message to the controller. The message is of the form \emph{CALL OK}, meaning the handler successfully +established a physical connection with the other handler, or of the form \emph{CALL NOT OK}, meaning a physical connection was +not successfully established on the given handler. The controller considers only a test successful if both handlers report +with \emph{CALL OK}. The test software ends the established connection with the handlers by sending them the \emph{TERMINATE CONNECTION} +command. After the handlers have terminated the connection, they enter the waiting for a new connection state and the process starts +from beginning again. If the states are not entered in the specified order the connection is immediately terminated and +the state machine is in the waiting for a new connection state\footnote{It cannot be seen in the protocol flowchart but one should +keep in mind it works like a well defined state machine.}. + +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{protocolCommunicationHandler.png} + \caption[]{Flowchart of the protocol on the handler side without the state representation} +\end{figure} +\end{center} +\end{landscape} + + + +\begin{figure}[ht!] + \centering + \includegraphics[width=147mm]{protocolCommunicationcControllerReceiver.png} + \caption[]{Flowchart of the protocol on the controller side for the caller without the state representation} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=147mm]{protocolCommunicationcControllerCaller.png} + \caption[]{Flowchart of the protocol on the controller side for the receiver without the state representation} +\end{figure} + +\subsection{Verification of the protocol} +``SPIN is a model checker - a software tool for verifying models of physical +systems, in particular, computerized systems. First, a model is written that +describes the behavior of the system; then, correctness properties that express +requirements on the system's behavior are specified; finally, the model +checker is run to check if the correctness properties hold for the model, and, +if not, to provide a counterexample: a computation that does not satisfy a +correctness property.'' \cite{spin}. We modeled our simple protocol in SPIN using +the programming language PROMELA \cite{spin}. Since PROMELA is similar to C it was +not possible to ensure 100\% matching with Python but we had made the assumptions of it. +We modeled both sides, server and client side. As well as the server side being a caller +and a callee. It was important to find out if our protocol is deadlock or delayed state free. +For more details our model can be found on our wiki project page with the PROMELA source code \cite{wiki}. +We had built in a 50\% random probability that the call test will not be successful, to make the model even more +realistic. Our protocol idea was deadlock free and the verification results prove it. +After we had modeled the basic idea we had written the code that implements our idea. The Python code +resembles some kind of a state machine which remembers the last state and what the next state should be in case +of receiving corresponding message. Otherwise it enters the exit state and then the start state. + +\begin{lstlisting} +(Spin Version 6.1.0 -- 2 May 2011) + + Partial Order Reduction +Full statespace search for: + never claim - (none specified) + assertion violations + + cycle checks - (disabled by -DSAFETY) + invalid end states + +State-vector 44 byte, depth reached 65, errors: 0 + 40 states, stored + 3 states, matched + 43 transitions (= stored+matched) + 90 atomic steps +hash conflicts: 0 (resolved) + 2.195 memory usage (Mbyte) +unreached in proctype Server1 + (0 of 36 states) +unreached in proctype Server2 + (0 of 36 states) +unreached in proctype Client + (0 of 67 states) +pan: elapsed time 0 seconds +\end{lstlisting} + +\clearpage +\newpage + + +\section{Security and safety of the system} +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 +(e.g. assume the University alarm system uses the SIP gateway to connect to the outside world and to alarm the police, if one knows that the SIP gateway is not working properly, a burglar could plan to rob the University building just at that moment). Therefore the choice to go Open Source is justified due to the fact that one should know how every single detail of the system works. +All the time, while we were working on the project, we were made aware of this issue by Dennis and Konrad. +We decided to use asymmetric key cryptography, where each side has two keys (private and public). In the next sections we will explain in more details how we applied the methods. +\subsection{Encryption of the communication channels} +At first we thought to encrypt the data before sending them but since none of us was an expert on encryption standards the idea was rejected. Alongside the fact that none of us had been an expert in the field of cryptography, we were neither experts in the field of Internet programming. One could find maybe a way to disable our server software with various hacking methods (e.g. +trying to open the port until the system runs out of memory and in our case the system which we used on the handler side was a BeagleBoard with ARM architecture running on a single chip TI OMAP processor, refer to the picture in figure). +We had to eliminate even the slightest possible threat in return for spending more time for debugging the test software system. Despite we were aware of all these facts, we had to choose one of the plenty implemented encryption standards on Linux. +Dennis and Konrad suggested using the SSH Tunneling method. + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{sshTunnel.png} + \caption[]{SSH Tunnel, all the communication inside the tunnel is encrypted } +\end{figure} + +Using the SSH Tunnel port forwarding method we could hide the real port we had used for our socket connection. On the other hand we could force the socket to accept only local connections (i.e. from the machine where the handler software was running). +The SSH Tunnel port forwarding method creates an encrypted tunnel between the two computers and then it creates two ports, one on the local and remote computer. All the data sent through the port on the local machine appear on the port at the remote machine. \newline The first problem we faced was that SSH required the username and password every time we tried to make an SSH connection. We could avoid this problem by copying the public key from our server (where our test software runs) to the BeagleBoard \cite{sshTunnel}. +This can be performed by executing the following commands in the terminal shell. +One has to create first the private and public keys on the local machine(i.e. server computer, where the test software runs): + +\begin{lstlisting} +refik@ubuntu:$ [Note: You are on local-host here] + +refik@ubuntu:$ ssh-keygen +Generating public/private rsa key pair. +Enter file in which to save the key (/home/refik/.ssh/id_rsa):[Enter key] +Enter passphrase (empty for no passphrase): [Press enter key] +Enter same passphrase again: [Press enter key] +Your identification has been saved in /home/refik/.ssh/id_rsa. +Your public key has been saved in /home/refik/.ssh/id_rsa.pub. +The key fingerprint is: +33:b3:fe:af:95:95:18:11:31:d5:de:96:2f:f2:35:f9 refik@ubuntu +\end{lstlisting} + +Then one needs to copy the public key to the remote machine (BeagleBoard) using ssh-copy-id: + +\begin{lstlisting} +refik@ubuntu:$ ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host +refik@remote-host's password: +Now try logging into the machine, with "ssh 'remote-host'", and check in: + +.ssh/authorized_keys + +to make sure we haven't added extra keys that you weren't expecting. +\end{lstlisting} + +After we have created the public and private keys, and coppied the public key on the machine to which we want to connect, we can test if we can make an SSH connection to the remote machine: + +\begin{lstlisting} +refik@ubuntu:$ ssh remote-host +[Note: SSH did not ask for password.] + +refik@remote-host:$ [Note: You are on remote-host here] +\end{lstlisting} +The test was successful. We tested it with our SSH Tunnel port forwarding class and it worked perfectly. +\subsection{Security on the web site} +Aside from having secured the data communication channels between various parts of our software +(the handlers and the controller), it was crucial to ensure all the communication between +test user's browser and our server. Therefore we had used the \emph{https} protocol and +the \emph{.htaccess} file to password protect the web site so only the privileged users +have access to our test system. +\subsubsection{Configuring the http secure protocol https} +Securing the communication channels without making certain the web site is safe would be worthless. +We decided to use the \emph{https} protocol instead of the \emph{http} since a person in the middle +could sniff our data (e.g. a person is connected with his/her smart-phone over an unprotected wireless network) \cite{https}. +At the same time the web site should be accessible only by the authorized personel. Our first approach to this +problem was to build an PHP page with \emph{MD5} hashed passwords, however we got a suggestion by Konrad and Dennis to +use a safer encryption method implemented in the Apache web server software, \emph{.htaccess}. By using +these two techniques we protected the web site of some vulnerabilities known to us. If the web site +will be only accessed from our local university network, we can additionally add an IP filter mask as well. +In the following paragraph we will explain our procedure how to generate the keys and to enable the https protocol. +\par First we want to generate a server key by typing the following command: +\begin{lstlisting} +openssl genrsa -des3 -out server.key 4096 +\end{lstlisting} +\par This will generate a 4096 bit long private server key, one is asked to enter two times a password for the \emph{server.key}. +Using the generated private server key, we will create a certificate signing request, \emph{server.csr}. We were prompted with a series of questions +like country, state, organization name and etc which we had to enter to resume. +\begin{lstlisting} +openssl req -new -key server.key -out server.csr +\end{lstlisting} +\par In the next step we had to sign the certificate signing request and enter the amount of days for how long it should be valid. +In our case we entered the duration of one year, one can make it for longer periods as well (i.e. the amount of 365 has to be changed). +\begin{lstlisting} +openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt +\end{lstlisting} +\par We were asked to enter the password again for \emph{server.key}. After we have completed this step we had to make +a version of the \emph{server.key} which did not require a password, \emph{server.key.insecure} and we will rename the files appropriately. +\begin{lstlisting} +openssl rsa -in server.key -out server.key.insecure +mv server.key server.key.secure +mv server.key.insecure server.key +\end{lstlisting} +\par The generated files are very sensitive, since they are our keys. After these steps were completed, we had generated 4 files: \emph{server.crt}, \emph{server.csr}, \emph{server.key} and \\ \emph{server.key.secure}. Now we need to enable the SSL engine on the Apache web server. +We coppied \emph{server.key} and \emph{server.crt} into \emph{/etc/appache2/ssl}. +\begin{lstlisting} +refik@ubuntu:/etc/apache2$ sudo mkdir ssl +cp server.key /etc/apache2/ssl +cp server.crt /etc/apache2/ssl +\end{lstlisting} +\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 symlink-ed for loading)'' \cite{https}. +\begin{lstlisting} +refik@ubuntu:/etc/apache2/ssl$ sudo a2enmod ssl +Enabling module ssl. +See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates. +Run '/etc/init.d/apache2 restart' to activate new configuration! +\end{lstlisting} +\par In the next procedure we had to establish a symlink from the 'available' default-ssl file to the 'enabled' file \cite{https}. Then we created a folder where our secured PHP files will be located (e.g. https://some-domain-name.com/test-software). +\begin{lstlisting} +refik@ubuntu:/etc/apache2/ssl$ sudo ln -s /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/000-default-ssl +refik@ubuntu:/etc/apache2/ssl$ cd /var/ +refik@ubuntu:/var$ sudo mkdir www-ssl +\end{lstlisting} +\par We had backed up our old configuration files for the virtual hosts, for the case if we damage the Apache configuration files. Then we edited the \emph{default-ssl} file. +\begin{lstlisting} +refik@ubuntu:/var$ cd /etc/apache2/sites-available +refik@ubuntu:/etc/apache2/sites-available$ sudo cp default default_original +refik@ubuntu:/etc/apache2/sites-available$ sudo cp default-ssl default-ssl_original +refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl +\end{lstlisting} +\par Only the beginning of the file is listed here and we have modified the line starting with \emph{DocumentRoot} +and \emph{} from \emph{DocumentRoot /var/www} to \emph{DocumentRoot /var/www-ssl} +and from \emph{} to \emph{} +(i.e. we had to redefine the location of our SSL directory). +\begin{lstlisting} + + + ServerAdmin webmaster@localhost + + DocumentRoot /var/www-ssl + + Options FollowSymLinks + AllowOverride None + + + Options Indexes FollowSymLinks MultiViews + AllowOverride None + Order allow,deny + allow from all + +\end{lstlisting} +\par One should keep in mind that the port 443 should be free for Apache to use it. In the proceeding step we had to ensure that Apache listens on the given port for a \emph{https} connection. +One could test that by going into the \emph{/etc/apache2/ports.conf}. +\begin{lstlisting} + + # If you add NameVirtualHost *:443 here, you will also have to change + # the VirtualHost statement in /etc/apache2/sites-available/default-ssl + # to + # Server Name Indication for SSL named virtual hosts is currently not + # supported by MSIE on Windows XP. + Listen 443 + +\end{lstlisting} +\par In our case it was set up correctly, since the command: \emph{Listen 443} was present. +In our last configuration step we had to edit \emph{default-ssl} file to define the correct locations of our keys and to ensure the SSL engine was turned on. +\begin{lstlisting} +refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl +\end{lstlisting} +\par The following part of the file had to be found and modified according to our locations: +\begin{lstlisting} +SSLEngine on + + # A self-signed (snakeoil) certificate can be created by installing + # the ssl-cert package. See + # /usr/share/doc/apache2.2-common/README.Debian.gz for more info. + # If both key and certificate are stored in the same file, only the + # SSLCertificateFile directive is needed. + SSLCertificateFile /etc/apache2/ssl/server.crt + SSLCertificateKeyFile /etc/apache2/ssl/server.key + + # Server Certificate Chain: + # Point SSLCertificateChainFile at a file containing the +\end{lstlisting} +\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 + ... waiting [Sat Oct 08 21:52:52 2011] [warn] _default_ VirtualHost overlap on port 443, the first has precedence [ OK ] +refik@ubuntu:/etc/apache2/sites-available$ +\end{lstlisting} +\subsubsection{Password protecting the web site using .htaccess} +Aside from using a secure communication protocol on the web, \emph{https}, it is important +to ensure that only permissioned users gain access to the web site. We had achieved it using +the \emph{.htaccess} file. However, to enable the use of Apache \emph{.htaccess} files, +we will have to reconfigure the Apache configuration files again. \emph{root} access will +be required. First we have to edit the \emph{/etc/apache2/sites-available/default-ssl} file. +Find the following lines and modify the \emph{AllowOverride None} to \emph{AllowOverride All} +like in the given configuration segment: +\begin{lstlisting} + + Options Indexes FollowSymLinks MultiViews + AllowOverride All + Order allow,deny + allow from all + +\end{lstlisting} +This will tell Apache web server that it is okay to allow \emph{.htaccess} files +to over-ride previous directives. We must reload the Apache web server before the +changes can take effect. We can do it by typing: +\begin{lstlisting} +sudo /etc/init.d/apache2 reload +\end{lstlisting} +The next step is to go to the directory where our test software web page is located +(e.g. \emph{/var/www-ssl/testsoftware}) and to create a file called \emph{.htaccess}. +Please insert the following code segment inside the created \emph{.htaccess} file where +\emph{/var/www-ssl/testsoftware/.htpasswd} is your full path address to \emph{.htpasswd}: +\begin{lstlisting} +AuthUserFile /var/www-ssl/testsoftware/.htpasswd +AuthName "Authorization Required" +AuthType Basic +require valid-user +\end{lstlisting} +Then in the next step, create another file called \emph{.htpasswd}. After you have created it, +we will add the usernames that should have access to the web site. We do that by typing the +following command, where you can replace \emph{konrad} with any other combination of letters +which will represent your username: +\begin{lstlisting} +refik@ubuntu:/var/www-ssl/testsoftware$ sudo htpasswd -c .htpasswd konrad +\end{lstlisting} +Afterwards, you will be required to type twice the same password for the username +you want to create, in this case \emph{konrad}. ``The -c flag is used only when you +are creating a new file. After the first time, you will omit the -c flag, +when you are adding new users to an already-existing password file. Otherwise you +will overwrite the file!'' \cite{htaccess}. You can add as many users as you wish, +do not forget to remove the -c flag when you do it. +In the last step, we have to modify the \emph{/etc/apache2/apache2.conf} file and +to add at the end of it the following code segment where \emph{/vaw/www-ssl/testsoftware} +is the full path to your web page directory where you put the \emph{.htpasswd} file: +\begin{lstlisting} + +AllowOverride All + +\end{lstlisting} +We are done with editing. All we have to do now is to restart the Apache web server. We +can do that by typing: +\begin{lstlisting} +sudo /etc/init.d/apache2 restart +\end{lstlisting} +You can test it now by opening a new browser tab and navigating to \emph{https://localhost/\\testsoftware} +(keep in mind to replace \emph{testsoftware} with your name of the folder where the web page +is located). If you configured everything properly, you should get a dialog where you can +enter your created username and password and try to login. + +\newpage +\section{Web page} +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 access 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 as 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 Cell phones 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 in-between 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=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 immediately identify the network operability in percentage\footnote{The test user has to take into account that this percentage 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{Employing the test software system} +In this section the reader can find out how to install and how to use the test system. +Our goal was to make a multi-platform test software, however we tested it only under Ubuntu +11.04 32 bit Linux OS and the given instruction manual is only tested under that OS. The +test software performed well, both on PC and MAC computers. +One should keep in mind that some of the libraries we had used do not work +under the 64 bit version of Linux OS. + +\subsection{Required software and libraries} +In the next subsections, we will guide you how to install all the required software and +libraries to flawlessly run our test software on your employed server. +You will be required to have \emph{root} access privileges and to open a new +terminal window where the commands will be typed in. + +\subsubsection{Python installation} +Python was our programming language of choice\footnote{We had explained earlier why we +have decided to use Python.}. The required version of Python is 2.7. One can easily +install python by typing the following commands: +\begin{lstlisting} +sudo apt-get update +sudo apt-get install python2.7 +\end{lstlisting} +It will take a short amount of time to be installed. You will be required to enter +the \emph{root} password. + +\subsubsection{Apache Web server installation} +We had decided to use the Apache web server because of its wide support on the Internet +and safety reasons. If there are any bugs or security flaws, the patches are +easily installed with the Ubuntu update manager. The Apache web server can be easily +installed by typing the following command: +\begin{lstlisting} +sudo apt-get install apache2 +\end{lstlisting} +You might be required to follow other installation instructions printed on the +terminal screen. +After the installation has completed successfully, one can test if it works by going +to the following web address: \emph{http://localhost}. For configuring the \emph{https} +please go to the section 7.2. + +\subsubsection{SSH} +Secure Shell (SSH) is a network protocol for secure data communication between two +computers inside of a network. All computers are required to have SSH installed on it. +You can easily install it by typing the following command: +\begin{lstlisting} +sudo apt-get install ssh +\end{lstlisting} + +\subsubsection{MySQL database and MySQLdb library} +The MySQLdb library is required to perform various operations on the MySQL database within +Python. We used the MySQLdb library instead of the native MySQL C API \emph{\_mysql} library +to make the code cleaner and more portable. +We suggest you to install first the MySQL database on the server computer. If you +have installed MySQL you can skip the next part. To star the installation process one can +type the following commands: +\begin{lstlisting} +sudo apt-get install mysql-server +\end{lstlisting} +You will be required to enter the Linux \emph{root} password. At some point during +the installation process, you will be required to enter the password for the MySQL +database. After you have performed the above step, we can proceed with the +MySQLdb library installation. By typing: +\begin{lstlisting} +sudo apt-get install python-mysqldb +\end{lstlisting} +If the \emph{python-mysqldb} name has changed, one can easily find the correct name of the +file by issuing the following command: +\begin{lstlisting} +apt-cache search MySQLdb +\end{lstlisting} +By typing in the commands given above, you should have successfully installed the MySQLdb +library. + +\subsubsection{Serial port library} +The serial port library is required for the cell phones to communicate with the +server computer and the BeagleBoards. The required library for Python can be installed +by typing the following command: +\begin{lstlisting} +sudo apt-get install python-serial +\end{lstlisting} +The installation should not produce any errors or warnings. + +\subsubsection{PJSUA library} +\emph{PJSUA} is an open source command line SIP user agent (soft-phone). We use the library +for the SIP handler. First, one needs to download the library +from \url{http://www.pjsip.org/download.htm} \cite{pjsip}. Then extract it to some folder. +Then we will build the library using make. This can be accomplished by typing the following +commands: +\begin{lstlisting} +cd your-pjsip-root-dir +./configure && make dep && make +cd pjsip-apps/src/python +sudo make +\end{lstlisting} + +If you get an error similar to this one: +\begin{lstlisting} +_pjsua.h:25:20: fatal error: Python.h: No such file or directory +compilation terminated. +error: command 'gcc' failed with exit status 1 +\end{lstlisting} +Then you will be required to install python-dev as well, that matches your version of +python (e.g. python2.7-dev). You can do it by typing: +\begin{lstlisting} +sudo apt-get install python2.7-dev +\end{lstlisting} +After you have successfully installed python2.7-dev, repeat the the commands given above. +Now you should have a properly installed PJSUA library. One can easily test if the installation +was successful by compiling a simple python code, \emph{python test.py}, with the following +source code: +\begin{lstlisting} +import pjsua +\end{lstlisting} +If you do not get any errors, you have successfully installed the library. More detail can +be found on our project wiki page \cite{wiki}. + +\subsubsection{pChart library} +The pChart library is within our installation files and does not require to be installed +individually. The library is only required if one uses the web interface and +requires the generated resulting image. The library is open source and does not require +any licensing. However, if one needs to learn how the library works, +information can be found on the pChart web page \cite{pChart}. + +\subsubsection{proctitle library} +We had used this library to rename the currently executed process name. +``The library allows a process to change its title (as displayed by system +tools such as ps and top). Changing the title is mostly useful in +multi-process systems, for example when a master process is forked: +changing the children's title allows to identify the task each process is +busy with.'' \cite{proctitle}. The library can be easily installed by typing: +\begin{lstlisting} +sudo easy_install setproctitle +\end{lstlisting} + + +\subsection{Configuring hardware} +Before proceeding with the next steps, please connect all the cell phones +to the USB hub using the suitable cables. Then make sure the cables are +recognized by the operating system. This can be performed by typing the following command: +\begin{lstlisting} +dmesg | grep ttyU +\end{lstlisting} +The given command should produce a result similar to: +\begin{lstlisting} +[ 5178.753600] usb 1-1.2: pl2303 converter now attached to ttyUSB0 +\end{lstlisting} + +We have two different ways to configure the cell phones, manually and automatic. +Both options can be accessed either using the website or the terminal window. +Using the manual configuration from the terminal, the user configures everything him/herself. +The user will be presented with a few questions like the port address, cell phone number and IMEI. +After the user enters all the required parameters, the software will check +if the given port address is accessible and it will look for a response from the devices. +Then you will be asked to enter the IMEI and the cell phone number of the device. +If the entered IMEI matches the device IMEI then the software will update the database +with the entered information. You can run, both the manual and automatic configuration +by typing: +\begin{lstlisting} +python gsmselftest.py --devconf +\end{lstlisting} +In the automatic configuration, the software will automatically try to detect every +cell phone that is connected to the USB hub. This configuration option can detect +up to nine cell phones, that are connected to the server computer. We had set a limit to +nine cell phones because we required only five (four for the external GSM networks +and one for our internal GSM BST). The only limitation of the automatic cell phone configuration +is that it only supports cell phones where we could read out the number using the \emph{AT Modem} +commands since some cell phone manufacturers do not use the standardized \emph{AT Modem} commands. +\newpage +\subsubsection{Configuring the cell phones} +It is important to write in the Siemens S55 cell phones their numbers if you want to use +automatic device configuration. You can do that by following the next few steps: + +\par Open the phone book on the S55 and choose \emph{} and press the select button. +\par In the second step, press select on \emph{}. +\par In the third and last step, enter your cell phone number and save it! +\begin{figure}[ht!] + \centering + \includegraphics[width=20mm]{First.png} + \caption[]{First step in configuring the phone} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=20mm]{Second.png} + \caption[]{Second step in configuring the phone} +\end{figure} +\begin{figure}[ht!] + \centering + \includegraphics[width=20mm]{Third.png} + \caption[]{Second step in configuring the phone} +\end{figure} +\clearpage +\subsection{Location of the files} +For proper operation of the software, it is important that each file is at its correct path +located. In the given section you can find out the correct path locations. +If you are not an expert, please do not change these locations. +The following files have to be located in the \emph{/var/www-ssl/testsoftware/} folder: +\begin{lstlisting} +drwxr-xr-x 7 root root 4096 2011-10-28 12:45 . +drwxr-xr-x 3 root root 4096 2011-10-20 17:06 .. +-rw-r--r-- 1 root root 109 2011-10-26 16:55 .htaccess +-rw-r--r-- 1 root root 20 2011-10-26 17:11 .htpasswd +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 class +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 css +-rw-r--r-- 1 root root 7547 2011-10-20 17:06 delayedLoading.js +-rw-r--r-- 1 root root 3431 2011-10-25 14:38 devconf.html +-rw-r--r-- 1 root root 2024 2011-10-25 23:47 devconfigAuto.php +-rw-r--r-- 1 root root 1811 2011-10-26 13:44 devconfigManual.php +-rw-r--r-- 1 root root 2195 2011-10-25 23:45 devconfig.php +-rw-r--r-- 1 root root 3526 2011-10-27 14:51 devconf.php +-rwxr-xr-x 1 root root 725 2011-10-20 17:06 execute.php +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 fonts +-rw-r--r-- 1 root root 2259 2011-10-28 12:43 index.html +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 icons +drwxr-xr-x 2 root root 4096 2011-10-25 14:10 Images +-rw-r--r-- 1 root root 2038 2011-10-20 17:06 insertData.php +-rw-r--r-- 1 root root 636 2011-10-26 13:43 insertdevice.php +-rw-r--r-- 1 root root 10819 2011-10-20 17:06 loader.gif +-rw-r--r-- 1 root root 2268 2011-10-26 16:07 main.php +-rw-r--r-- 1 root root 5416 2011-10-20 17:06 moocheck.js +-rw-r--r-- 1 root root 75836 2011-10-20 17:06 mootools.js +-rw-r--r-- 1 root root 677 2011-10-20 17:06 mutexFunctions.php +-rw-r--r-- 1 root root 9063 2011-10-25 17:20 mutexSmartTest.php +-rwxr-xr-x 1 root root 9143 2011-10-28 12:45 mutexTry.php +-rw-r--r-- 1 root root 13304 2011-10-20 17:06 networkResult.php +-rw-r--r-- 1 root root 8294 2011-10-21 19:02 post.php +-rw-r--r-- 1 root root 19218 2011-10-21 17:36 startTest2.php +-rw-r--r-- 1 root root 18852 2011-10-20 17:06 startTest.php +-rw-r--r-- 1 root root 18787 2011-10-25 16:43 TaskTest.html +-rw-r--r-- 1 root root 3685 2011-10-20 17:06 testCase.php +-rw-r--r-- 1 root root 2545 2011-10-20 17:06 wait.gif +\end{lstlisting} +The \emph{startSoftware.py} file is required to be in the \emph{/etc/init.d/} folder, +since it is required to be start with the computer boot however if that does not work, +one should start it manually. This part of the software is +responsible for starting the testing software from the web page\footnote{The web page +communicates with this script via a socket connection and sends a signal to start +the main test software.}. +The main test software python files should be located in \emph{/home/gsmselftest/SoftwareTesting/}. +\begin{lstlisting} +drwxr-xr-x 2 gsmselftest gsmselftest 4096 2011-11-03 14:29 . +drwxr-xr-x 30 gsmselftest gsmselftest 4096 2011-11-02 18:28 .. +-rwxr--r-- 1 gsmselftest gsmselftest 2909 2011-10-20 17:54 ClientClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 3628 2011-10-20 17:54 ClientClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 9814 2011-11-02 16:19 ControllerClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 9247 2011-11-02 16:20 ControllerClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 15129 2011-11-02 15:32 DbClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 11712 2011-11-02 15:32 DbClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 8512 2011-11-02 13:30 GSMClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 7337 2011-11-02 13:42 GSMClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 8063 2011-11-02 13:24 GSMHandler.py +-rwxr-xr-x 1 gsmselftest gsmselftest 20346 2011-11-02 18:32 gsmselftest.py +-rwxr--r-- 1 gsmselftest gsmselftest 698 2011-11-02 18:36 help.txt +-rwxr-xr-x 1 gsmselftest gsmselftest 8661 2011-11-02 16:35 initTestClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 7497 2011-11-02 16:37 initTestClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 645 2011-10-20 17:54 LogFileClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1509 2011-10-20 17:54 LogFileClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 817 2011-10-20 17:54 PingClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1263 2011-10-20 17:54 PingClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 3982 2011-10-20 17:54 ServerClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 4596 2011-10-20 17:57 ServerClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 4129 2011-10-20 23:17 ServerClassSoftware.py +-rw-r--r-- 1 gsmselftest gsmselftest 4802 2011-10-20 23:17 ServerClassSoftware.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 5252 2011-10-22 03:58 SIPHandler.py +-rwxr--r-- 1 gsmselftest gsmselftest 1267 2011-11-02 14:07 SSHTunnelBoxClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1852 2011-11-02 14:19 SSHTunnelBoxClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 323 2011-11-02 18:44 startSoftware.py +-rwxr-xr-x 1 gsmselftest gsmselftest 6378 2011-11-02 16:13 trueTableClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 4583 2011-11-02 16:16 trueTableClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 2248 2011-10-28 14:04 usbDetectClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 3590 2011-10-28 14:05 usbDetectClass.pyc +\end{lstlisting} + +\subsection{Setting up the parameters} +After configuring the hardware, \emph{https} and \emph{.htaccess} on the web server, +it is important to modify the files for proper operations. In the given section you +can find out how to configure the rest of the files (e.g. database passwords, etc.). +The following files you have to modify to have a working database access: +\emph{initTestClass.py, GsmSelfTest.py, UsbDetectClass.py} and \emph{truthtableClass.py}. +\subsection{Test descriptions} +In the following section we will describe the tests that can be performed and what kind +of problems they can identify. There are five types of tests: +\begin{itemize} +\item Smart test +\item SIP test +\item GSM test +\item Everything test +\item Manual test +\end{itemize} +Each test will be described in the next subsections. +\subsubsection{Smart test} +\par The \emph{smart} test is not called smart without a reason. It tries automatically to identify +problems inside of the telecommunication network. The user is not required to define what kind +of tests have to be performed. In the first part the test software communicates with the +database to see what systems are available. In the next step it performs a call from the +University telephone system to a random local cell phone\footnote{Local cell phone or +local GSM network means our University GSM Network or RZ GSM.} +inside of our University GSM network. +While executing this task, automatically the Asterisk server, OpenBSC and a random nanoBTS +(or the one cell phone in RZ) are tested. The next task to be performed in the smart test, +a randomly selected cell phone inside of our local GSM network will try to call: a random +cell phone within the external (O2, Vodaphone,E-Plus or T-Mobile) or local GSM network. +This might test the external network and will test it with high probability, however the +probability exists to make a local to local GSM test call. In the third task, we perform +a test where we call from the landline a random cell phone inside of our local GSM network. +In the fourth or last task, we call from SIP to the service we did not test yet (e.g. +if we did not test the external GSM network using the second test task, then in this last +task we will exploit it). After the smart test had been completed you will be presented +with the results. +\subsubsection{SIP test} +The \emph{SIP} test option will perform test in such a way that all the SIP subsystems are +tested (SIP and University telephone network). It will try to identify if there are any +problems on the Asterisk server and our University telephone network, including incoming and +outgoing calls from the SIP side. +\subsubsection{GSM test} +In the \emph{GSM} test both GSM networks get tested, the local and the external GSM network. +We test the nanoBTS controller boxes (i.e. BeagleBoards) as well. Using this test, both incoming +and outgoing calls are performed, we can detect possible errors on the OpenBSC and the nanoBTS. +\subsubsection{All test} +The \emph{All} test selects all the given tests and executes them step-by-step. It is the test +that takes the greatest amount of time. While the test are performed, results are +immediately printed in the terminal window or on the web site. +\subsubsection{Manual test} +The \emph{Manual} test as the name itself says, is the test where you can manually select +what kind of tests you want to be performed. +\newpage +\subsection{Result descriptions} +In the following table one can see the messages returned by the test software! +These messages should guide the test user operator to debug the system. + +\begin{table}[h]\footnotesize + \begin{center} + %\caption[]{Table of error descriptions} + \begin{tabular}{| l | c | l | } + \hline + \textbf{Number} & \textbf{Code} & \textbf{Code number description} \\ \hline + 1 & 200 & Call was OK \\ \hline + 2 & 604 & General Handler Error: Destination handler did not respond. Timeout \\ \hline + 3 & 998 & General Handler Error: Could not connect to the destination handler! \\ \hline + 4 & 605 & General Handler Error: Caller handler did not respond. Timeout \\ \hline + 5 & 999 & General Handler Error: Could not connect to the caller handler! \\ \hline + 6 & 486 & Call Failed \\ \hline + 7 & 333 & Could not establish a connection to the database! \\ \hline + 8 & 100 & Missing account detail \\ \hline + 9 & 402 & Payment Required (E-Plus Card) \\ \hline + 10 & 801 & Connection to caller established, but the device does not respond \\ \hline + 11 & 802 & Connection to destination established, but the device does not respond \\ \hline + 12 & 501 & Destination server Internal Error \\ \hline + 13 & 502 & Caller server Internal Error \\ \hline + %\hline + + \end{tabular} + \end{center} +\end{table} + +The errors can be described the following way: + +\begin{itemize} +\item \emph{200}, Connection between the caller and callee was properly established +\item \emph{604}, Callee handler has a problem during executing the test, a connection error between caller and callee +\item \emph{998}, Controller cannot establish a connection and send messages to the callee handler but the callee handler is alive +\item \emph{605}, Caller handler has a problem during executing the test, a connection error between caller and callee +\item \emph{999}, Controller cannot establish a connection and send messages to the caller handler but the caller handler is alive +\item \emph{486}, Call test failled, the connection between the caller and callee could not be established +\item \emph{500}, Caller handler cannot be reached from the server +\item \emph{501}, Callee handler cannot be reached from the server +\item \emph{333}, Cannot login to the MySQL database +\item \emph{100}, Software cannot sign in to the SIP account(SIP at Asterisk, Landline at sipgate.de, SIP at University telephone network), due to missing or incorrect information in the device address table +\item \emph{402}, Payment required for the E-Plus SIM card +\item \emph{801}, Caller device on the handler times out or is not properly connected +\item \emph{802}, Callee device on the handler times out or is not properly connected +\end{itemize} + +\clearpage +\newpage +\subsection{Using the software} +In this section, you will be taught step by step how to use our test software. There are two options to run our test software, from the web site or the terminal. +The first is easier, but the second is easy as well however requires terminal skills. + +\subsubsection{Web site guide} +Once you enter the address in the address bar of your browser (e.g. \emph{https://localhost/\\testsoftware}). +You will be required to enter your username and password for the web page\footnote{The username and password creation process is explained in section 7.2.2.}. +If you entered the correct username and password you should see the same image as in the following figure. +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website1.png} + \caption[]{Web page of test software} +\end{figure} +Here you can choose what kind of test you want to perform or maybe if you want to configure the devices (manually or automatically). +If you press the ``Smart test'' button, you have to wait a few moments and the results should appear in a short amount of time. +However, if you pressed the ``Choose the test'' button, you will be presented with a new page, given in figure 28. +You will have to select the tests you want to perform manually or to press on the left side one of the given buttons for different +tests. You can choose between ``SIP Test'', ``GSM Test'', ``Check all'' and ``Uncheck all''. ``Check all'' will select all the possible +tests, whereas ``Uncheck all'' will deselect all of them. After you finished the procedure of selecting the tests, you should press the +``Submit'' on the left side. Wait a few moments and the results will start to appear in real time. After the table on the left is filled +(i.e. after all the tests have been completed) a result image will be generated on the right side, can be seen in figure 20. However, if +your pressed the ``Device configuration'' button, then you will end up on a page as given in figure 30. + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website2.png} + \caption[]{Manually selecting the tests} +\end{figure} + +If you press the ``Automatic configuration'' button, the test software will try automatically to match your cell phones with +their port addresses and numbers. However, if the automatic matching does not work, you will have to manually configure it. +You can do it by entering all the required information on the web site, as in figure 31. Once you correctly filled in the required +information, you should press the ``Submit'' button. + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{webpageReport.png} + \caption[]{Result web page} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website3.png} + \caption[]{Device configuration web page} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website4.png} + \caption[]{Manual device configuration page} +\end{figure} +%\clearpage +\newpage +\subsubsection{Terminal guide} +In the following text, we will guide you and show you step-by-step how to use the test software from the terminal. All you have to +do is just type the command for starting the test software in the folder where it is located, \emph{./gsmselftest.py ---option} (keep +in mind there are two dashes before \emph{option}). +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{terminalCommand.png} + \caption[]{Test software terminal options} +\end{figure} +You can perform the tests manually by typing what you want to test or by choosing one of the predefined tests. For example, you +want to test manually does the SIP work with the University telephone network, you would type the following: \emph{./gsmselftest.py --db sip unisip}. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{resultterminal.png} + \caption[]{Example results from the terminal screen} +\end{figure} +After the tests have been performed the results will be displayed. Green result text means the test was performed successfully and red result +text means that something is not working properly. + +If you need to configure the cell phones manually or automatically, you can do it by typing: \emph{./gsmselftest.py --devconf} (keep +in mind there are two dashes before \emph{devconf}). Then you can press ``a'' on the keyboard for automatic configuration or ``m'' for +manual configuration. One should keep in mind that the terminal test software can be started even through \emph{ssh}, however with an +additional command \emph{-X}\footnote{For example: ssh -X username@address}. +\begin{figure}[htb] + \centering + \includegraphics[width=100mm]{devconf.png} + \caption[]{Test software device configuration from terminal screen} +\end{figure} + +\clearpage +\newpage +\section{Conclusion} +As a result of our successfully finished team project, we had felt how it is to work +in a team. We had learnt how to confront various software and hardware issues. The problems +were broken into smaller fragments and the solutions were derived in a step-by-step approach. +\par While designing the software, we kept in mind that every single step should be well thought-out, +documented, tested and validated. At the end we joined all the ``black-boxes'' together +into one big piece of software. We fulfilled our stated requirements and goals. +\par Despite the fact that our test software will be used by well educated engineers, we may +conclude that all the way along we thought about the usage-simplicity, safety and security +of our product. Our team members were enthusiastic about the idea that our team project will +contribute to a better performance and quality of the overall telecommunication network, +for all of the University staff and our colleagues, the students. +\newpage + + + +%bibliography start +\begin{thebibliography}{9} + +\bibitem{network} \emph{Projects based on RZ-GSM}, accessed on 10.06.2011, available at +\url{http://lab.ks.uni-freiburg.de/projects/gsm/wiki}. + +\bibitem{python} \emph{Python Programming Language - Official Website}, accessed on 10.06.2011, available at +\url{http://www.python.org/}. + +\bibitem{mysqlManual} \emph{MySQLdb User's Guide}, accessed on 05.06.2011, available at \\ +\url{http://mysql-python.sourceforge.net/MySQLdb.html}. + +\bibitem{wiki} \emph{[2011] GSM Selftest - Wiki - Lehrstuhl f\"{u}r Kommunikationssysteme}, accessed on 20.09.2011, available at \\ +\url{http://lab.ks.uni-freiburg.de/projects/gsm-selftest/wiki}. + +\bibitem{socket} \emph{17.2. socket - Low-level networking interface}, accessed on 20.06.2011, available at +\url{http://docs.python.org/library/socket.html}. + +\bibitem{spin} M. Ben-Ari \emph{Principles of the Spin Model Checker}, +Springer Verlag, Weizmann Institute of Science, Israel, ISBN: 978-1-84628-769-5, 2008. + +\bibitem{sshTunnel} R. Natarajan, \emph{3 Steps to perform SSH login without password using ssh-keygen \& ssh-copy-id}, accessed on 18.08.2011, available at +\url{http://goo.gl/fX68N}. + +\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{htaccess} \emph{EnablingUseOfApacheHtaccessFiles}, accessed on 18.08.2011, available at +\url{https://help.ubuntu.com/community/EnablingUseOfApacheHtaccessFiles}. + +\bibitem{pChart} \emph{pChart}, accessed on 15.08.2011, available at +\url{http://www.pchart.net/}. + +\bibitem{beagleDataSheet} \emph{BeagleBoard System Reference Manual}, accessed on 20.06.2011, available at +\url{http://beagleboard.org/static/BBSRM_latest.pdf}. + +\bibitem{proctitle} \emph{setproctitle 1.1.2}, accessed on 20.10.2011, available at +\url{http://pypi.python.org/pypi/setproctitle}. + +\bibitem{pjsip} \emph{Open source SIP stack and media stack for presence, im/instant messaging, and multimedia communication}, accessed on 20.10.2011, available at +\url{http://www.pjsip.org/}. + +%bibliography end +\end{thebibliography} + +%end of the document +\end{document} \ No newline at end of file diff --git a/documenting/Report/test.tex.backup b/documenting/Report/test.tex.backup new file mode 100644 index 0000000..ee7caec --- /dev/null +++ b/documenting/Report/test.tex.backup @@ -0,0 +1,1360 @@ +\documentclass[a4paper, titlepage, oneside, headsepline, footsepline]{scrartcl} +%PACKAGES +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\usepackage{lscape} %for the landscape pages it is used +\usepackage[english]{babel} %what language are we using +\usepackage[latin2]{inputenc} %what alphabet + +\usepackage[tt]{titlepic} %used for adding the title image +\usepackage{graphicx} %used for adding images +\usepackage{url} %used for the url in bibliography +\usepackage{lastpage} %give me the total number of pages, used in footer: \pageref{LastPage} + +\usepackage[T1]{fontenc} %used for fonts +\usepackage{scrpage2} %used for making headers, footers and correct margins +%\usepackage{hyperref} %used for the linking of table of content + +%information for the PDF +\usepackage[pdftex, %used for adding pdf information + pdfauthor={Refik Hadzialic, Triatmoko}, + pdftitle={Software for self-testing of the Telecommunication network of University of Freiburg}, + pdfsubject={Telecommunication network testing software}, + pdfkeywords={telecommunication;network;networking;linux;ubuntu;university;Freiburg;python;tcp/ip;security;gsm;sip;voip}, + pdfproducer={Latex with hyperref, or other system}, + pdfcreator={pdflatex, or other tool}]{hyperref} %used for the linking of table of content + + + + + +\hypersetup{ %setting up the look of the links + colorlinks, + citecolor=black, + filecolor=black, + linkcolor=black, + urlcolor=black +} + +\usepackage{color} %used for highlighting source code +\usepackage{listings} %used to make a box with source code +\usepackage{fancyvrb} +\DefineVerbatimEnvironment{code}{Verbatim}{fontsize=\small} +\DefineVerbatimEnvironment{example}{Verbatim}{fontsize=\small} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%DEFINE LOOK OF THE PAGES +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\pagestyle{scrheadings} + +\renewenvironment{abstract} + {\begin{center}\large\textbf{}\noindent\end{center}}{\vspace{2\baselineskip}} + +% Disable single lines at the start of a paragraph (Schusterjungen) +\clubpenalty = 10000 +% Disable single lines at the end of a paragraph (Hurenkinder) +\widowpenalty = 10000 \displaywidowpenalty = 10000 + +\setlength{\parskip}{0.01\baselineskip} +\textheight = 620pt + +\ohead{Software for self-testing of the Telecommunication network of University of Freiburg} %make the header +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%DEFINE THE STUFF FOR CODE +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\lstset{ % +%language=Python, % choose the language of the code +columns=fullflexible, +keywordstyle=\color[rgb]{0.608,0.561,0.008}, +commentstyle=\color[rgb]{0.25,0.5,0.35}, +stringstyle=\color[rgb]{0.25,0.35,0.85}, +basicstyle=\footnotesize,%\scriptsize % the size of the fonts that are used for the code +%numbers=left, % where to put the line-numbers +numberstyle=\footnotesize, % the size of the fonts that are used for the line-numbers +stepnumber=1, % the step between two line-numbers. If it is 1 each line will be numbered +numbersep=8pt, % how far the line-numbers are from the code +backgroundcolor=\color{white}, % choose the background color. You must add \usepackage{color} +showspaces=false, % show spaces adding particular underscores +showstringspaces=false, % underline spaces within strings +showtabs=false, % show tabs within strings adding particular underscores +frame=single, % adds a frame around the code +tabsize=2, % sets default tabsize to 2 spaces +captionpos=b, % sets the caption-position to bottom +breaklines=true, % sets automatic line breaking +breakatwhitespace=false, % sets if automatic breaks should only happen at whitespace +escapeinside={\%}{)} % if you want to add a comment within your code +} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + + +\newcommand{\titleOfProject}{Software For Self-Testing Of The Telecommunication Network Of University Of Freiburg} + + + +%begin of the document +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\begin{document} + + + + +%make the title page +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\titlepic{\includegraphics[width=90mm]{uniLogo2.png}} +\title{Team Project \\ ``\titleOfProject''} % type title between braces +\date{\today} % type date between braces +\author{Refik Had\v{z}iali\'{c}\\ Triatmoko } % type author(s) between braces +\department{\vspace{1\baselineskip} \large Albert-Ludwigs-Universit\"{a}t Freiburg \\ +Lehrstuhl f\"{u}r Komunikationsysteme\\ +Prof. Dr. Gerhard Schneider\\ \vspace{1\baselineskip} Supervisors: \\ Konrad Meier \\ Dennis Wehrle \\ \vspace{1\baselineskip} Sommersemester 2011} + +\maketitle +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%add the table of contents +\tableofcontents + +%new page to start with +\clearpage + + + + +% first chapter +\section{Introduction and Motivation} % chapter 1 +In the following report, the authors will try to give you a brief insight into our team project. The goal of our project was to develop a mechanism for automatic testing of our University Telecommunication network. The Telecommunication network of University of Freiburg consists of: our own internal GSM and telephone network systems; GSM redirecting device (if one initiates a call to one of the four external GSM networks, it redirects the calls to: T-mobile, 02, Vodaphone or E-Plus); a SIP gateway for land-line calls inside of Germany (sipgate.de) and international calls. Since we did not have access to internal servers, our strategy was to exploit the existing systems from an external perspective and infer the results out of our findings. +Before we had started working on our project, we had to analyze the overall network to come up with the 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. In the following chapters we will describe in more detail our approach to the problem and how each subsystem works. +This particular report and our wiki page should be a sufficient guide and manual for understanding, running and continuing the development of our test software. +Certainly, we had a lot of fun while working on the project due the fact that we lost one team member. +We would like to thank the whole department for the free coffee and their support, especially +Konrad Meier, Dennis Wehrle, Richard M. Zahoransky and Larissa Linz, without their support this project would not +end up this way. +\clearpage +\section{Requirements} % chapter 2 +At the start of the project the requirements were not completely known but as the time had passed we redefined our requirements and goals. +The first and the most important part at the start was to identify the key goals of our team project. The basic goal of our team project was to build a +test software system which could tell an operator user what part of the system is not properly working in our University telecommunication network. +Konrad and Dennis suggested us to analyze figure 1 and depending on it to build our test software. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{BigPicture_new1.png} + \caption[]{Overview of the Freiburg University telecommunication network \cite{network}} +\end{figure} +Our first attempt was to see what could we test without having access to the system. We installed numerous communication programs to see what others have done. +After gaining access to the communication software, we had decided to build most of the test software ourselves. Libraries, which were used, +were only the ones we could not develop ourselves because of the time-span of our team project. +\subsection{Logical and algorithmic requirements} +Despite the software and hardware requirements, the logic in our team project may be considered as the most important part. +Controlling the software and hardware in a specific manner was one of the requirements in our team project. +Moreover, we were required to draw a use case diagram and a simple test case diagram so that we could better understand all the problems we had to deal with +but also to easier follow the development of our test software. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{activity_diagram.png} + \caption[]{Simple algorithmic overview of a test case} +\end{figure} +\subsection{Software requirements} +Afterwards, as we had defined our logical approach to the problems, we had to choose the programming language to realize our ideas. Since we had the freedom of choice, between the three suggested programming languages +Java, C++ and Python, we made a joint decision to use Python as the main programming language in our team project. One of the requirements was to finish the team project in time, +therefore our decision to use Python is justified. Using Python we could work faster and integrate our subsystems more effectively \cite{python}. +Our programming language of choice is multi-platform, therefore our test software would be easy portable to other operating systems. +\par Likewise we had to decide how our test software will work. One of the requirements by Dennis and Konrad was to make the software capable of being run from the terminal. +The next requirement was to make an appealing GUI so that even an user without advanced Linux experience could handle the software and read out the results. +\par In addition it was required to log all the past tests. Later on a machine learning algorithm or some other intelligence could be applied to deduce some error behavior of the system +(e.g. an intelligent algorithm could find that part of the system fail in a combined manner). To accomplish the logging of all the tests we had to use a database system. +We decided to use MySQL since it is open source and well supported. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{test_Use_case.png} + \caption[]{Test case diagram} +\end{figure} +\subsection{Hardware requirements} +Likewise the software requirements, we had hardware requirements as well. We were required to identify the hardware we will need to perform the tests. +It was important to find old and cheap cell phones that could support \emph{AT Modem} commands because our budget was limited. +\par A problem we had to deal with at the start was that the base stations are located at different geographical points which were not near to each other. +No one should go everyday to the rooms where our cell phones are located only to change or charge the batteries. +In the cable subsection we describe our approach to the charging battery problem. As we defined our requirements we continued with the process of developing the test software. +During the development time we refined our requirements. In the next chapters we will explain our database, software and hardware design ideas. +\newpage +\section{Database design} +As we mentioned in the software requirements section, we decided to use MySQL as our database system for storing the test information and results. +It was not difficult to decide what database to use, since MySQL is one of the most supported database and one can find a library to use it with major programming languages. +The key point in the design of our database was the simplicity and speed of accessing the data. We had decided to use seven tables. In the following paragraphs we will explain each table separately and its usage. +The database design can be seen in figure 4. + +\par The \emph{PingResultTable} table has six attributes (\emph{taskNo, sipServer, sipGate, unisip, gsmBox1, gsmBox2}), all of integer type. +The \emph{taskNo} attribute identifies the test number but not a single test (e.g. an operator user has selected three different tests to be executed, all of the three tests will have the same \emph{taskNo} to identify them together as belonging to one test group and \emph{taskId} identifies each single test and will be explained later). +\emph{sipServer} represents the Asterisk server ping result. \emph{sipGate} is used to represent the SIP Gate server for the landline calls (\url{http://www.sipgate.de}). \emph{uniSip} represents the ping results for our local University telephone network SIP server. +\emph{gsmBox1} and \emph{gsmBox2} are the two single-chip Linux computers (BeagleBoard), that control two cell phones each one (i.e. they are also known under the name of \emph{nanoBTSx controller}). +\emph{taskNo} is the primary and unique key in the table \emph{PingResultTable}. Rest of the attributes (i.e. \emph{sipServer, sipGate, uniSip, gsmBox1, gsmBox2}) are used to insert the ping results, if the assigned servers are reachable or not. +Before any test attempt is made, our test software first tries to ping the servers. These results are then stored in the \emph{PingResultTable}. + +\par The \emph{ErrorCodeTable} table defines all the possible test results in the system, in other words it represents a list with error codes with their appropriate descriptions and meanings. It consists of two attributes (\emph{errorcode} and \emph{description}), the first is of integer type and the second of varchar type (the description message is allowed to be only 100 characters long). +The \emph{ErrorCodeTable} table is used by the main test software (i.e. controller) to report the operator user what kind of error had appeared in the system. + +\par The \emph{DeviceAddressTable} is the table containing the location and identification data for each server and device. The table consists of seven attributes, \emph{deviceName, portName, number, lastChange, username, password, server}. +\emph{deviceName} is the attribute with the name of the device or server (e.g. GSMRZ1 or landline), it is of varchar type. \emph{portName} is the attribute field with the location address for a cell phone (e.g. \emph{/dev/ttyUSB1}) or 'localhost' instead of NULL value for a server, it is of the varchar type. +\emph{number} represents the number of the used service (i.e. number of the cell phone, SIP, etc.) and is of varchar type. +\emph{lastChange} is a time value and represents the date and time the given entry was modified (we had plans in future versions of our test software that if an device gets a new IP address assigned it automatically changes it in the database). +\emph{username} is the field with the username stored in for a server/service, like SIP and landline. \emph{password} attribute stores the password information for the given service. The \emph{server} attribute stores information about the location of the server, IP or DNS address of the server. All three fields, \emph{username}, \emph{password} and \emph{server} are of varchar type. +The information stored in the given table is used by the test software to obtain usernames, passwords and addresses of the used services for the tests. + +\par The \emph{ResultTable} table is used by the test system to store final results for the performed tests. Our given table consists of two fields, \emph{taskID} and \emph{result} and both are of integer type. For each test entry with unique \emph{taskID} an error code is assigned in the \emph{result} field, +depending on the test results. Error codes found in the \emph{ErrorCodeTable} table can be only assigned to this field. + +\par The \emph{TempTaskTable} table represents the table with the tasks the system has to execute next time the test software is started. The given table gets new data every time an operator user submits one or more test cases from the website to be executed. \emph{TempTaskTable} includes four attributes, \emph{taskID, taskNo, from, to}. Former two are of integer type and later two of varchar type. +\emph{taskID} and \emph{taskNo} identify the test task to be executed, \emph{taskID} is the unique primary key. \emph{from} and \emph{to} fields have to match the names given in \emph{DeviceAddressTable.deviceName}, these two attributes specify the caller and callee devices/services. Consequently, after the tasks get executed, the test tasks are removed and the given table is empty again until next tests are added to it. +However, all the test tasks even after deleting them from \emph{TempTaskTable} are kept in the \emph{TaskTable}. The reason why the authors of this project divided it into two tables was because of the database row selection speed. We had made the assumption that with time the database size will grow and therefore the database speed will not be the same as during the development period. + +\par The \emph{TaskTable} table, as mentioned before contains all the tests ever performed from the web site. It is made out of five attributes, \emph{taskID, taskNo, from, to, timestamp}. The first four fields are the same as in \emph{TempTaskTable}, however the last one, \emph{timestamp}, is used to record the exact time when the test was performed. +\par The \emph{GSMListPrefix} table contains the data about the GSM networks and their prefixes. It consists of two +attributes, both of varchar type, \emph{providerName} and \emph{prefix}. +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{DBRelationship.png} + \caption[]{Database relationship diagram} +\end{figure} +\end{center} +\end{landscape} + + + + + +\section{Software design} % section 2.1 +Software design was the next step after we analyzed the problem and developed a plan how to proceed further. Good analysis and planning with poor algorithmic implementation is valueless. +During the work on the project, we had spent most of our time for software design. +We kept in mind that our software should satisfy major paradigms of software engineering, +like compatibility, extensibility, modularity, reliability, security, fault-tolerance and usability. +The software engineering design concepts were achieved following way: +\begin{itemize} +\item Compatibility - we used Python and MySQL which are multi-platform and work on major OS +\item Extensibility - new parts of code can be easily added by just modifying the classes +\item Mudalarity - the components are independent black boxes, they are tested and validated independently +\item Reliability - we use mutex locks to perform tests and database transaction operations to insert data into the database +\item Security - all communication channels, as well as the access to the web site, are encrypted with asymmetric key cryptography +\item Fault-tolerance - the classes were designed to continue operating even if error events appear and handlers are logging all events +\item Usability - we tried to create a simple user interface and easily to use for everyone +\end{itemize} + +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{activityControllerEdited.png} + \caption[]{Working principle of the test software} +\end{figure} + +\par The basic principle how the test software works can be seen in figure 5. The test software is +started either manually from the terminal or using the web site. When the test software +is started manually it is database dependent as well and therefore could not be used if the +database is being maintained or not working. If it is started from the web site it +connects to the database to get its tasks which have to be performed. After receiving +the tasks it makes a simple network test by pinging all the servers. The ping results +are stored in the database (in case the test was started from the web site). Then it +proceeds with the tests by connecting itself to the handlers and sending them commands +to perform the tests\footnote{Before it connects to the handlers, it uses the ping +results to see is the service/device physically connected to the network.}. +At the higher level, these commands can be seen as requests for being the +callee and caller. Meanwhile the handlers send their test results to the main +test software which in return decides if the test result was successful or not. +The result is written to the database (in case the software was started from the website), +otherwise the results are displayed in the terminal window and the user who started +it manually can see the test results. We will proceed with introducing the classes. +The software class diagram can be seen in the following figure. More details for the +classes, like the input/output can be found on our project's wiki page \cite{wiki}. + +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{classDiagram.png} + \caption[]{Class diagram (some classes were excluded)} +\end{figure} +\end{center} +\end{landscape} + + +\newpage +\subsection{Database access} % subsection 2.1.1 +Accessing the database is of critical value to our project, therefore we had developed our own class that limits the access to the database. In the process of developing our own class we used the MySQLdb library in Python \cite{mysqlManual}. +The database class has two working modes, a normal working mode and a debugging mode. The difference between these two modes is in the output information. In case the error handling function raises an error and it is unknown, if the debug mode is set a complete back-trace of the error will be printed out. A developer can change the mode by setting the variable \emph{debugMode=1}. The class diagram can be seen in the following figure. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{dbClass.png} + \caption[]{Class diagram for the dbClass} +\end{figure} +The method names are self-explanatory and do not require extra explanations. All the outputs produced by the class can be found on the project wiki page \cite{wiki}. +\subsection{Controlling the cell phones} +Our first version of the developed program code for controlling the cell phones used predefined timed values +to send commands instead of using a state controlled approach to confirm that every command was successfully received and executed by the cell phone. +It meant we had to make an enormous number of assumptions. In comparison to our second approach, to build a state controlled cell phone control class, +our first approach was inferior and slower. The state controlled method connected two cell phones, on the same base station, up to 15 times faster than the timed approach. +\begin{figure}[ht!] + \centering + \includegraphics[width=80mm]{serialPort.png} + \caption[]{GSM class diagram for controlling the cell phones} +\end{figure} +One can easily apply the class just by correctly defining the parameters: port address, baud rate and timeout. The former two are self-explanatory and the timeout parameter is used to define when the alarm function should raise a timeout exception. +A timeout exception gets raised when the cell phone does not respond (i.e. when the cell phone enters a deadlock or delayed state). We had used the serial port library inside of Python although we use USB cables to connect to our cell phones. One should +be aware that our USB cables create a virtual serial port. More details on class design and an example can be found on our project wiki \cite{wiki}. +\subsection{Client and Server class} +Our socket communication code is based on the example given in the Python socket manual \cite{socket}. +We extended it into two classes, a client and a server class. We had used the TCP protocol to base our two classes on\footnote{TCP is reliable compared to UDP (i.e. transmitted packets get also delivered), +packets are ordered when received and data are received in a stream (i.e. multiple packets can be read at once).}. +The Server class can be seen in the following figure. The server class is implemented to accept only local connections\footnote{More details are given in the section 7.1}. +First we determine our IP address and then create the socket to listen only for the same IP address (with a different IP address than the selected one a connection cannot be even established). +One has to define the port on which the server object should listen. +When receiving data one can easily define the timeout to be raised if data are not received in the timeout range or set it to \emph{0} to infinitely wait for the buffer to be filled with received data. While testing the server class we had the problem to listen on the same port if the application was forcibly\footnote{Manually closed using CTRL+C and run again.} restarted in less than 60 seconds. We got the error message: \emph{"Address already in use"}. +This is not known as error behavior but rather an option to help the server to catch lost live packets (i.e. packets that are still in the network looking for it is goal destination). +We solved the problem by changing the socket options with the \emph{SO\_REUSEADDR} parameter. This enabled us to get around the error when we tried to restart our server application. +Before solving the problem without using the socket parameter, we had another solution to get around this problem by killing the application running the port, this old method is obsolete now. +\begin{figure}[ht!] + \centering + \includegraphics[scale=0.8]{serverClass.png} + \caption[]{Server class, used by the server application} +\end{figure} +In the process of testing the client class we did not have any major problems. The only major flow we had to debug was when one of the sides disconnects that we get out of the waiting loop if the timeout variable was set to \emph{0} (i.e. infinite waiting loop). +The client class can be seen in the following figure. To initialize the client object one needs to define the IP address and the port of the server application listening on it. +\begin{figure}[hb!] + \centering + \includegraphics[scale=0.5]{ClientClass.png} + \caption[]{Client class, used by the client application} +\end{figure} +Once an instance of it is created and loaded with the IP address and the port, one needs to call the \emph{connect()} method. +The method will produce an integer based on its connection state. Output information and the programming code can be found on our project wiki page \cite{wiki}. +\subsection{Ping class} +Before making any test and establishing a connection we were required to ensure that the server is online. The best way to assess the liveness property was to ping the server computer running the required service. Once the class is properly defined, we could easily set the number of ping tries. +A ping timeout response was set up to 2 seconds. For more details and insights, one can read more about it on our wiki page \cite{wiki}. +\begin{figure}[ht!] + \centering + \includegraphics[width=70mm]{ping.png} + \caption[]{Ping class, used by test software} +\end{figure} +\subsection{Data logging} +If errors appear it is important to reconstruct the events that led to the misbehavior of the software. One of the best ways to reconstruct the events was to log +events for different blocks of programming code. +We had used the logging class to follow our handler code run on the BeagleBoard. In case there is an error we could look inside of the log files and track the error. +How the class works and what kind of outputs it produces can be found on our project wiki page \cite{wiki}. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{logging.png} + \caption[]{Logging class} +\end{figure} +\subsection{SSH Tunnel Class} +Since security played an important role in our team project. We decided to encrypt all of our data that was not processed on our server computer. +The simplest solution to this problem was to build an SSH Class that could open and close a local forwarding port. +All data sent through the created port is encrypted until it gets to its destination location. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{sshTunnelClass.png} + \caption[]{SSH Tunnel class} +\end{figure} +\subsection{USB Cell phone detection class} +Since we had used cables to connect the cell phones with the computer, usually the devices +got their own port addresses. They were automatically assigned by the operating system, +either after the cables were plugged into the USB port or after a system reboot. +One of the problems we had to deal with was assigning the right cell phone +(i.e. with the appropriate GSM network) to the corresponding port address. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{usbDetectClass.png} + \caption[]{USB cable detection class} +\end{figure} +The operating system randomly assigned the port names after every reboot. +We were looking for a solution to prevent this misaddressing of the devices. +Our solution was to recognize every device and update the port address in the database. +The principle how we identify the cell phones is by their calling numbers in the database. +More details can be found on our project wiki page \cite{wiki}. +\subsection{Truth table class} +The truth table class was built to identify the broken and working parts of the system. +It requires the list with test results to be present to be operable. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{trueTable.png} + \caption[]{Truth table class} +\end{figure} +Then the class tries to identify the broken parts of our telecommunication network. +The class can easily identify how many nanoBTSs are installed in the network and +derive a decision which part of the network is broken. +All the test results are stored in a list and can be easily read by calling the +\emph{initTrueTable(x)} function. More details can be found on our project wiki page \cite{wiki}. +\subsection{Init Test class} +The main purpose of the class is to get device data from the database and to process it. +The processed data get forwarded to the controller class and in the end the class +fetches the results from the test. This class contains the \emph{smart test} functionality. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{initTestClass.png} + \caption[]{Init test class} +\end{figure} +It selects automatically the important tests to perform. In the next step it +tries to identify the problem in the network. +More details can be found in the \emph{smart test} description. +\subsection{Controller class} +The controller class is used to assign jobs to handlers (in other words, which one is +going to be the caller and callee). Simultaneously, it defines the port addresses for +the communication between the handlers and the main test software (controller). +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{controllerclass.png} + \caption[]{Controller class} +\end{figure} +If the callee or the caller are nanoBTS controller boxes (i.e. BeagleBoards outside +the Rechenzentrum), it will first create an SSH connection to make a tunnel before +the local socket connection is created. Then the controller class sends all the +required data regarding the test tasks to the handlers. + +\clearpage +\section{Hardware design} +In our team project we had the option to choose all the required hardware ourself beside the two BeagleBoards, which we were supplied by Konrad and Dennis. +Since one of the project goals was to reduce the costs as much as it was possible, we had tried to use some of the leftovers found in our lab. + +\subsection{BeagleBoard} +``The BeagleBoard is an OMAP3530 platform designed specifically to address the Open +Source Community. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{bb.jpg} + \caption[]{BeagleBoard, a Linux-on-chip board where our controller software runs the GSM device } +\end{figure} +It has been equipped with a minimum set of features to allow the +user to experience the power of the OMAP3530 and is not intended as a full development +platform as many of the features and interfaces supplied by the OMAP3530 are not +accessible from the BeagleBoard'' \cite{beagleDataSheet}. +We run on it a special precompiled version of Ubuntu for the ARM processor type. The Linux system boots up from an SD Card. +The board has an USB hub and network port attached to it. In our project it is connected to our +internal university LAN network and to a cell phone. We positioned the two BeagleBoards in rooms where +we had LAN access and GSM signal coverage of our two local base stations. + +\subsection{Cell phones} +Our first attempt was to control a Nokia cell phone 3310 with the supplied USB connection cable. +The protocols used by old versions of Nokia cell phones, as the 3310, use the F-Bus protocol. It was not easy to work with. +After performing various experiments we succeeded to send and to read SMS messages. Later on we found out that it was not possible to +send commands for receiving and making the calls. In the meantime we found two Siemens phones, one M45 and S55. +The first one, Siemens M45, had a cable supplied with it and it was not difficult to control it with the standard set of AT modem commands. +At the start we did not have a cable supplied for the Siemens S55 phone. We controlled it over the Bluetooth port. + +\subsection{Cables for the cell phones} +Due to the fact that we had used 5 cell phones on a single computer, the best solution was to order 5 USB cables. +Konrad bought 5 cables for 5 Siemens S55 cell phones. All of the cables have an USB2Serial chip converter inside of them. +Once they were plugged into the USB port, Ubuntu automatically recognized the cables and installed the drivers. +The virtual serial ports were created and could be found on \emph{/dev/ttyUSBx}, where $x$ is the automatically assigned number for the port. +Some of the cables had the capability to charge the Siemens S55 phones. +Konrad had opened several cables to solder the power supplies to some contacts and the problem was solved for all of the cables. +\subsection{Server} +We were given an old Pentium 3 computer where we installed Ubuntu Linux. Configured the Apache web server and MySQL. +Afterwards we installed the Python on it and all the required libraries\footnote{Required libraries are mentioned in section 9.1.}. +\clearpage + +\section{Communication protocol} +A communication protocol represents a set of well defined rules by whose help two or more computing systems exchange information in-between. +When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate +response from the other side. Our approach to this problem was to build a simple synchronous protocol, where every expected message is +confirmed or otherwise the connection between two sides is immediately terminated. Since designing protocols is a demanding and challenging +topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum +protocol\footnote{Design concepts and paradigms for the protocol design have been used from the +``Network Protocol Design and Evaluation'' course, lectured by Dr. Stefan R\"{u}hrup}. +In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works, +it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device +that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software +controlling the handler side and assigning the task to it. + +\subsection{Communication between the handler and controller} +The handler side is always in the waiting mode, by waiting we denote the mode where the socket is already created and it is waiting +for a connection to be accepted at the defined port. The controller initiates a socket connection to the two handlers. +Subsequently, after the connection has been established, it is waiting for a message to be received. The first message +has to be 13 characters long and include the following content \emph{HELLO HANDLER}. Thereupon, after the message has +been validated, the handler side sends the controller side a response, \emph{HELLO CONTROLLER}. +We call this first message exchange the initialization. Now the controller side has to decide which of the two handler's +will be the caller/callee whereas the other handler will be the opposite. Let's assume the controller sends to the first +handler the message \emph{RECEIVER} and to the second one the message \emph{CALLER|\#}, replace the callee number with the \# sign. +In the meantime, both handlers initialize the software required to make the call and to receive the call. Asynchronously they +respond back to the controller their successful initialization. The successful initialization is reported by sending \emph{RECEIVER READY} +and \emph{CALLER READY}. After receiving the mentioned messages, the controller first sends the callee handler the +message \emph{RECEIVE START} and then to the caller handler, the message \emph{CALLER START}. As a result of these messages, +the handlers enter the receiving, respectively calling state. In the given states two timeout timers gets activated. +These timers are responsible for the case if the physical connection between the callee and the caller are not successfully +established or terminated\footnote{The client and server classes responsible for the communication have timeout timers as well +for the case if the connection between the controller and handlers are broken.}. Afterwards, depending if the physical connection +between the handlers (i.e. the callee and the caller) was successfully established or not, the handlers report their +corresponding state with a message to the controller. The message is of the form \emph{CALL OK}, meaning the handler successfully +established a physical connection with the other handler, or of the form \emph{CALL NOT OK}, meaning a physical connection was +not successfully established on the given handler. The controller considers only a test successful if both handlers report +with \emph{CALL OK}. The test software ends the established connection with the handlers by sending them the \emph{TERMINATE CONNECTION} +command. After the handlers have terminated the connection, they enter the waiting for a new connection state and the process starts +from beginning again. If the states are not entered in the specified order the connection is immediately terminated and +the state machine is in the waiting for a new connection state\footnote{It cannot be seen in the protocol flowchart but one should +keep in mind it works like a well defined state machine.}. + +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{protocolCommunicationHandler.png} + \caption[]{Flowchart of the protocol on the handler side without the state representation} +\end{figure} +\end{center} +\end{landscape} + + + +\begin{figure}[ht!] + \centering + \includegraphics[width=147mm]{protocolCommunicationcControllerReceiver.png} + \caption[]{Flowchart of the protocol on the controller side for the caller without the state representation} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=147mm]{protocolCommunicationcControllerCaller.png} + \caption[]{Flowchart of the protocol on the controller side for the receiver without the state representation} +\end{figure} + +\subsection{Verification of the protocol} +``SPIN is a model checker - a software tool for verifying models of physical +systems, in particular, computerized systems. First, a model is written that +describes the behavior of the system; then, correctness properties that express +requirements on the system's behavior are specified; finally, the model +checker is run to check if the correctness properties hold for the model, and, +if not, to provide a counterexample: a computation that does not satisfy a +correctness property.'' \cite{spin}. We modeled our simple protocol in SPIN using +the programming language PROMELA \cite{spin}. Since PROMELA is similar to C it was +not possible to ensure 100\% matching with Python but we had made the assumptions of it. +We modeled both sides, server and client side. As well as the server side being a caller +and a callee. It was important to find out if our protocol is deadlock or delayed state free. +For more details our model can be found on our wiki project page with the PROMELA source code \cite{wiki}. +We had built in a 50\% random probability that the call test will not be successful, to make the model even more +realistic. Our protocol idea was deadlock free and the verification results prove it. +After we had modeled the basic idea we had written the code that implements our idea. The Python code +resembles some kind of a state machine which remembers the last state and what the next state should be in case +of receiving corresponding message. Otherwise it enters the exit state and then the start state. + +\begin{lstlisting} +(Spin Version 6.1.0 -- 2 May 2011) + + Partial Order Reduction +Full statespace search for: + never claim - (none specified) + assertion violations + + cycle checks - (disabled by -DSAFETY) + invalid end states + +State-vector 44 byte, depth reached 65, errors: 0 + 40 states, stored + 3 states, matched + 43 transitions (= stored+matched) + 90 atomic steps +hash conflicts: 0 (resolved) + 2.195 memory usage (Mbyte) +unreached in proctype Server1 + (0 of 36 states) +unreached in proctype Server2 + (0 of 36 states) +unreached in proctype Client + (0 of 67 states) +pan: elapsed time 0 seconds +\end{lstlisting} + +\clearpage +\newpage + + +\section{Security and safety of the system} +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 +(e.g. assume the University alarm system uses the SIP gateway to connect to the outside world and to alarm the police, if one knows that the SIP gateway is not working properly, a burglar could plan to rob the University building just at that moment). Therefore the choice to go Open Source is justified due to the fact that one should know how every single detail of the system works. +All the time, while we were working on the project, we were made aware of this issue by Dennis and Konrad. +We decided to use asymmetric key cryptography, where each side has two keys (private and public). In the next sections we will explain in more details how we applied the methods. +\subsection{Encryption of the communication channels} +At first we thought to encrypt the data before sending them but since none of us was an expert on encryption standards the idea was rejected. Alongside the fact that none of us had been an expert in the field of cryptography, we were neither experts in the field of Internet programming. One could find maybe a way to disable our server software with various hacking methods (e.g. +trying to open the port until the system runs out of memory and in our case the system which we used on the handler side was a BeagleBoard with ARM architecture running on a single chip TI OMAP processor, refer to the picture in figure). +We had to eliminate even the slightest possible threat in return for spending more time for debugging the test software system. Despite we were aware of all these facts, we had to choose one of the plenty implemented encryption standards on Linux. +Dennis and Konrad suggested using the SSH Tunneling method. + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{sshTunnel.png} + \caption[]{SSH Tunnel, all the communication inside the tunnel is encrypted } +\end{figure} + +Using the SSH Tunnel port forwarding method we could hide the real port we had used for our socket connection. On the other hand we could force the socket to accept only local connections (i.e. from the machine where the handler software was running). +The SSH Tunnel port forwarding method creates an encrypted tunnel between the two computers and then it creates two ports, one on the local and remote computer. All the data sent through the port on the local machine appear on the port at the remote machine. \newline The first problem we faced was that SSH required the username and password every time we tried to make an SSH connection. We could avoid this problem by copying the public key from our server (where our test software runs) to the BeagleBoard \cite{sshTunnel}. +This can be performed by executing the following commands in the terminal shell. +One has to create first the private and public keys on the local machine(i.e. server computer, where the test software runs): + +\begin{lstlisting} +refik@ubuntu:$ [Note: You are on local-host here] + +refik@ubuntu:$ ssh-keygen +Generating public/private rsa key pair. +Enter file in which to save the key (/home/refik/.ssh/id_rsa):[Enter key] +Enter passphrase (empty for no passphrase): [Press enter key] +Enter same passphrase again: [Press enter key] +Your identification has been saved in /home/refik/.ssh/id_rsa. +Your public key has been saved in /home/refik/.ssh/id_rsa.pub. +The key fingerprint is: +33:b3:fe:af:95:95:18:11:31:d5:de:96:2f:f2:35:f9 refik@ubuntu +\end{lstlisting} + +Then one needs to copy the public key to the remote machine (BeagleBoard) using ssh-copy-id: + +\begin{lstlisting} +refik@ubuntu:$ ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host +refik@remote-host's password: +Now try logging into the machine, with "ssh 'remote-host'", and check in: + +.ssh/authorized_keys + +to make sure we haven't added extra keys that you weren't expecting. +\end{lstlisting} + +After we have created the public and private keys, and coppied the public key on the machine to which we want to connect, we can test if we can make an SSH connection to the remote machine: + +\begin{lstlisting} +refik@ubuntu:$ ssh remote-host +[Note: SSH did not ask for password.] + +refik@remote-host:$ [Note: You are on remote-host here] +\end{lstlisting} +The test was successful. We tested it with our SSH Tunnel port forwarding class and it worked perfectly. +\subsection{Security on the web site} +Aside from having secured the data communication channels between various parts of our software +(the handlers and the controller), it was crucial to ensure all the communication between +test user's browser and our server. Therefore we had used the \emph{https} protocol and +the \emph{.htaccess} file to password protect the web site so only the privileged users +have access to our test system. +\subsubsection{Configuring the http secure protocol https} +Securing the communication channels without making certain the web site is safe would be worthless. +We decided to use the \emph{https} protocol instead of the \emph{http} since a person in the middle +could sniff our data (e.g. a person is connected with his/her smart-phone over an unprotected wireless network) \cite{https}. +At the same time the web site should be accessible only by the authorized personel. Our first approach to this +problem was to build an PHP page with \emph{MD5} hashed passwords, however we got a suggestion by Konrad and Dennis to +use a safer encryption method implemented in the Apache web server software, \emph{.htaccess}. By using +these two techniques we protected the web site of some vulnerabilities known to us. If the web site +will be only accessed from our local university network, we can additionally add an IP filter mask as well. +In the following paragraph we will explain our procedure how to generate the keys and to enable the https protocol. +\par First we want to generate a server key by typing the following command: +\begin{lstlisting} +openssl genrsa -des3 -out server.key 4096 +\end{lstlisting} +\par This will generate a 4096 bit long private server key, one is asked to enter two times a password for the \emph{server.key}. +Using the generated private server key, we will create a certificate signing request, \emph{server.csr}. We were prompted with a series of questions +like country, state, organization name and etc which we had to enter to resume. +\begin{lstlisting} +openssl req -new -key server.key -out server.csr +\end{lstlisting} +\par In the next step we had to sign the certificate signing request and enter the amount of days for how long it should be valid. +In our case we entered the duration of one year, one can make it for longer periods as well (i.e. the amount of 365 has to be changed). +\begin{lstlisting} +openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt +\end{lstlisting} +\par We were asked to enter the password again for \emph{server.key}. After we have completed this step we had to make +a version of the \emph{server.key} which did not require a password, \emph{server.key.insecure} and we will rename the files appropriately. +\begin{lstlisting} +openssl rsa -in server.key -out server.key.insecure +mv server.key server.key.secure +mv server.key.insecure server.key +\end{lstlisting} +\par The generated files are very sensitive, since they are our keys. After these steps were completed, we had generated 4 files: \emph{server.crt}, \emph{server.csr}, \emph{server.key} and \\ \emph{server.key.secure}. Now we need to enable the SSL engine on the Apache web server. +We coppied \emph{server.key} and \emph{server.crt} into \emph{/etc/appache2/ssl}. +\begin{lstlisting} +refik@ubuntu:/etc/apache2$ sudo mkdir ssl +cp server.key /etc/apache2/ssl +cp server.crt /etc/apache2/ssl +\end{lstlisting} +\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 symlink-ed for loading)'' \cite{https}. +\begin{lstlisting} +refik@ubuntu:/etc/apache2/ssl$ sudo a2enmod ssl +Enabling module ssl. +See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates. +Run '/etc/init.d/apache2 restart' to activate new configuration! +\end{lstlisting} +\par In the next procedure we had to establish a symlink from the 'available' default-ssl file to the 'enabled' file \cite{https}. Then we created a folder where our secured PHP files will be located (e.g. https://some-domain-name.com/test-software). +\begin{lstlisting} +refik@ubuntu:/etc/apache2/ssl$ sudo ln -s /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/000-default-ssl +refik@ubuntu:/etc/apache2/ssl$ cd /var/ +refik@ubuntu:/var$ sudo mkdir www-ssl +\end{lstlisting} +\par We had backed up our old configuration files for the virtual hosts, for the case if we damage the Apache configuration files. Then we edited the \emph{default-ssl} file. +\begin{lstlisting} +refik@ubuntu:/var$ cd /etc/apache2/sites-available +refik@ubuntu:/etc/apache2/sites-available$ sudo cp default default_original +refik@ubuntu:/etc/apache2/sites-available$ sudo cp default-ssl default-ssl_original +refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl +\end{lstlisting} +\par Only the beginning of the file is listed here and we have modified the line starting with \emph{DocumentRoot} +and \emph{} from \emph{DocumentRoot /var/www} to \emph{DocumentRoot /var/www-ssl} +and from \emph{} to \emph{} +(i.e. we had to redefine the location of our SSL directory). +\begin{lstlisting} + + + ServerAdmin webmaster@localhost + + DocumentRoot /var/www-ssl + + Options FollowSymLinks + AllowOverride None + + + Options Indexes FollowSymLinks MultiViews + AllowOverride None + Order allow,deny + allow from all + +\end{lstlisting} +\par One should keep in mind that the port 443 should be free for Apache to use it. In the proceeding step we had to ensure that Apache listens on the given port for a \emph{https} connection. +One could test that by going into the \emph{/etc/apache2/ports.conf}. +\begin{lstlisting} + + # If you add NameVirtualHost *:443 here, you will also have to change + # the VirtualHost statement in /etc/apache2/sites-available/default-ssl + # to + # Server Name Indication for SSL named virtual hosts is currently not + # supported by MSIE on Windows XP. + Listen 443 + +\end{lstlisting} +\par In our case it was set up correctly, since the command: \emph{Listen 443} was present. +In our last configuration step we had to edit \emph{default-ssl} file to define the correct locations of our keys and to ensure the SSL engine was turned on. +\begin{lstlisting} +refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl +\end{lstlisting} +\par The following part of the file had to be found and modified according to our locations: +\begin{lstlisting} +SSLEngine on + + # A self-signed (snakeoil) certificate can be created by installing + # the ssl-cert package. See + # /usr/share/doc/apache2.2-common/README.Debian.gz for more info. + # If both key and certificate are stored in the same file, only the + # SSLCertificateFile directive is needed. + SSLCertificateFile /etc/apache2/ssl/server.crt + SSLCertificateKeyFile /etc/apache2/ssl/server.key + + # Server Certificate Chain: + # Point SSLCertificateChainFile at a file containing the +\end{lstlisting} +\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 + ... waiting [Sat Oct 08 21:52:52 2011] [warn] _default_ VirtualHost overlap on port 443, the first has precedence [ OK ] +refik@ubuntu:/etc/apache2/sites-available$ +\end{lstlisting} +\subsubsection{Password protecting the web site using .htaccess} +Aside from using a secure communication protocol on the web, \emph{https}, it is important +to ensure that only permissioned users gain access to the web site. We had achieved it using +the \emph{.htaccess} file. However, to enable the use of Apache \emph{.htaccess} files, +we will have to reconfigure the Apache configuration files again. \emph{root} access will +be required. First we have to edit the \emph{/etc/apache2/sites-available/default-ssl} file. +Find the following lines and modify the \emph{AllowOverride None} to \emph{AllowOverride All} +like in the given configuration segment: +\begin{lstlisting} + + Options Indexes FollowSymLinks MultiViews + AllowOverride All + Order allow,deny + allow from all + +\end{lstlisting} +This will tell Apache web server that it is okay to allow \emph{.htaccess} files +to over-ride previous directives. We must reload the Apache web server before the +changes can take effect. We can do it by typing: +\begin{lstlisting} +sudo /etc/init.d/apache2 reload +\end{lstlisting} +The next step is to go to the directory where our test software web page is located +(e.g. \emph{/var/www-ssl/testsoftware}) and to create a file called \emph{.htaccess}. +Please insert the following code segment inside the created \emph{.htaccess} file where +\emph{/var/www-ssl/testsoftware/.htpasswd} is your full path address to \emph{.htpasswd}: +\begin{lstlisting} +AuthUserFile /var/www-ssl/testsoftware/.htpasswd +AuthName "Authorization Required" +AuthType Basic +require valid-user +\end{lstlisting} +Then in the next step, create another file called \emph{.htpasswd}. After you have created it, +we will add the usernames that should have access to the web site. We do that by typing the +following command, where you can replace \emph{konrad} with any other combination of letters +which will represent your username: +\begin{lstlisting} +refik@ubuntu:/var/www-ssl/testsoftware$ sudo htpasswd -c .htpasswd konrad +\end{lstlisting} +Afterwards, you will be required to type twice the same password for the username +you want to create, in this case \emph{konrad}. ``The -c flag is used only when you +are creating a new file. After the first time, you will omit the -c flag, +when you are adding new users to an already-existing password file. Otherwise you +will overwrite the file!'' \cite{htaccess}. You can add as many users as you wish, +do not forget to remove the -c flag when you do it. +In the last step, we have to modify the \emph{/etc/apache2/apache2.conf} file and +to add at the end of it the following code segment where \emph{/vaw/www-ssl/testsoftware} +is the full path to your web page directory where you put the \emph{.htpasswd} file: +\begin{lstlisting} + +AllowOverride All + +\end{lstlisting} +We are done with editing. All we have to do now is to restart the Apache web server. We +can do that by typing: +\begin{lstlisting} +sudo /etc/init.d/apache2 restart +\end{lstlisting} +You can test it now by opening a new browser tab and navigating to \emph{https://localhost/\\testsoftware} +(keep in mind to replace \emph{testsoftware} with your name of the folder where the web page +is located). If you configured everything properly, you should get a dialog where you can +enter your created username and password and try to login. + +\newpage +\section{Web page} +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 access 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 as 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 Cell phones 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 in-between 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=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 immediately identify the network operability in percentage\footnote{The test user has to take into account that this percentage 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{Employing the test software system} +In this section the reader can find out how to install and how to use the test system. +Our goal was to make a multi-platform test software, however we tested it only under Ubuntu +11.04 32 bit Linux OS and the given instruction manual is only tested under that OS. The +test software performed well, both on PC and MAC computers. +One should keep in mind that some of the libraries we had used do not work +under the 64 bit version of Linux OS. + +\subsection{Required software and libraries} +In the next subsections, we will guide you how to install all the required software and +libraries to flawlessly run our test software on your employed server. +You will be required to have \emph{root} access privileges and to open a new +terminal window where the commands will be typed in. + +\subsubsection{Python installation} +Python was our programming language of choice\footnote{We had explained earlier why we +have decided to use Python.}. The required version of Python is 2.7. One can easily +install python by typing the following commands: +\begin{lstlisting} +sudo apt-get update +sudo apt-get install python2.7 +\end{lstlisting} +It will take a short amount of time to be installed. You will be required to enter +the \emph{root} password. + +\subsubsection{Apache Web server installation} +We had decided to use the Apache web server because of its wide support on the Internet +and safety reasons. If there are any bugs or security flaws, the patches are +easily installed with the Ubuntu update manager. The Apache web server can be easily +installed by typing the following command: +\begin{lstlisting} +sudo apt-get install apache2 +\end{lstlisting} +You might be required to follow other installation instructions printed on the +terminal screen. +After the installation has completed successfully, one can test if it works by going +to the following web address: \emph{http://localhost}. For configuring the \emph{https} +please go to the section 7.2. + +\subsubsection{SSH} +Secure Shell (SSH) is a network protocol for secure data communication between two +computers inside of a network. All computers are required to have SSH installed on it. +You can easily install it by typing the following command: +\begin{lstlisting} +sudo apt-get install ssh +\end{lstlisting} + +\subsubsection{MySQL database and MySQLdb library} +The MySQLdb library is required to perform various operations on the MySQL database within +Python. We used the MySQLdb library instead of the native MySQL C API \emph{\_mysql} library +to make the code cleaner and more portable. +We suggest you to install first the MySQL database on the server computer. If you +have installed MySQL you can skip the next part. To star the installation process one can +type the following commands: +\begin{lstlisting} +sudo apt-get install mysql-server +\end{lstlisting} +You will be required to enter the Linux \emph{root} password. At some point during +the installation process, you will be required to enter the password for the MySQL +database. After you have performed the above step, we can proceed with the +MySQLdb library installation. By typing: +\begin{lstlisting} +sudo apt-get install python-mysqldb +\end{lstlisting} +If the \emph{python-mysqldb} name has changed, one can easily find the correct name of the +file by issuing the following command: +\begin{lstlisting} +apt-cache search MySQLdb +\end{lstlisting} +By typing in the commands given above, you should have successfully installed the MySQLdb +library. + +\subsubsection{Serial port library} +The serial port library is required for the cell phones to communicate with the +server computer and the BeagleBoards. The required library for Python can be installed +by typing the following command: +\begin{lstlisting} +sudo apt-get install python-serial +\end{lstlisting} +The installation should not produce any errors or warnings. + +\subsubsection{PJSUA library} +\emph{PJSUA} is an open source command line SIP user agent (soft-phone). We use the library +for the SIP handler. First, one needs to download the library +from \url{http://www.pjsip.org/download.htm} \cite{pjsip}. Then extract it to some folder. +Then we will build the library using make. This can be accomplished by typing the following +commands: +\begin{lstlisting} +cd your-pjsip-root-dir +./configure && make dep && make +cd pjsip-apps/src/python +sudo make +\end{lstlisting} + +If you get an error similar to this one: +\begin{lstlisting} +_pjsua.h:25:20: fatal error: Python.h: No such file or directory +compilation terminated. +error: command 'gcc' failed with exit status 1 +\end{lstlisting} +Then you will be required to install python-dev as well, that matches your version of +python (e.g. python2.7-dev). You can do it by typing: +\begin{lstlisting} +sudo apt-get install python2.7-dev +\end{lstlisting} +After you have successfully installed python2.7-dev, repeat the the commands given above. +Now you should have a properly installed PJSUA library. One can easily test if the installation +was successful by compiling a simple python code, \emph{python test.py}, with the following +source code: +\begin{lstlisting} +import pjsua +\end{lstlisting} +If you do not get any errors, you have successfully installed the library. More detail can +be found on our project wiki page \cite{wiki}. + +\subsubsection{pChart library} +The pChart library is within our installation files and does not require to be installed +individually. The library is only required if one uses the web interface and +requires the generated resulting image. The library is open source and does not require +any licensing. However, if one needs to learn how the library works, +information can be found on the pChart web page \cite{pChart}. + +\subsubsection{proctitle library} +We had used this library to rename the currently executed process name. +``The library allows a process to change its title (as displayed by system +tools such as ps and top). Changing the title is mostly useful in +multi-process systems, for example when a master process is forked: +changing the children's title allows to identify the task each process is +busy with.'' \cite{proctitle}. The library can be easily installed by typing: +\begin{lstlisting} +sudo easy_install setproctitle +\end{lstlisting} + + +\subsection{Configuring hardware} +Before proceeding with the next steps, please connect all the cell phones +to the USB hub using the suitable cables. Then make sure the cables are +recognized by the operating system. This can be performed by typing the following command: +\begin{lstlisting} +dmesg | grep ttyU +\end{lstlisting} +The given command should produce a result similar to: +\begin{lstlisting} +[ 5178.753600] usb 1-1.2: pl2303 converter now attached to ttyUSB0 +\end{lstlisting} + +We have two different ways to configure the cell phones, manually and automatic. +Both options can be accessed either using the website or the terminal window. +Using the manual configuration from the terminal, the user configures everything him/herself. +The user will be presented with a few questions like the port address, cell phone number and IMEI. +After the user enters all the required parameters, the software will check +if the given port address is accessible and it will look for a response from the devices. +Then you will be asked to enter the IMEI and the cell phone number of the device. +If the entered IMEI matches the device IMEI then the software will update the database +with the entered information. You can run, both the manual and automatic configuration +by typing: +\begin{lstlisting} +python gsmselftest.py --devconf +\end{lstlisting} +In the automatic configuration, the software will automatically try to detect every +cell phone that is connected to the USB hub. This configuration option can detect +up to nine cell phones, that are connected to the server computer. We had set a limit to +nine cell phones because we required only five (four for the external GSM networks +and one for our internal GSM BST). The only limitation of the automatic cell phone configuration +is that it only supports cell phones where we could read out the number using the \emph{AT Modem} +commands since some cell phone manufacturers do not use the standardized \emph{AT Modem} commands. +\newpage +\subsubsection{Configuring the cell phones} +It is important to write in the Siemens S55 cell phones their numbers if you want to use +automatic device configuration. You can do that by following the next few steps: + +\par Open the phone book on the S55 and choose \emph{} and press the select button. +\par In the second step, press select on \emph{}. +\par In the third and last step, enter your cell phone number and save it! +\begin{figure}[ht!] + \centering + \includegraphics[width=20mm]{First.png} + \caption[]{First step in configuring the phone} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=20mm]{Second.png} + \caption[]{Second step in configuring the phone} +\end{figure} +\begin{figure}[ht!] + \centering + \includegraphics[width=20mm]{Third.png} + \caption[]{Second step in configuring the phone} +\end{figure} +\clearpage +\subsection{Location of the files} +For proper operation of the software, it is important that each file is at its correct path +located. In the given section you can find out the correct path locations. +If you are not an expert, please do not change these locations. +The following files have to be located in the \emph{/var/www-ssl/testsoftware/} folder: +\begin{lstlisting} +drwxr-xr-x 7 root root 4096 2011-10-28 12:45 . +drwxr-xr-x 3 root root 4096 2011-10-20 17:06 .. +-rw-r--r-- 1 root root 109 2011-10-26 16:55 .htaccess +-rw-r--r-- 1 root root 20 2011-10-26 17:11 .htpasswd +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 class +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 css +-rw-r--r-- 1 root root 7547 2011-10-20 17:06 delayedLoading.js +-rw-r--r-- 1 root root 3431 2011-10-25 14:38 devconf.html +-rw-r--r-- 1 root root 2024 2011-10-25 23:47 devconfigAuto.php +-rw-r--r-- 1 root root 1811 2011-10-26 13:44 devconfigManual.php +-rw-r--r-- 1 root root 2195 2011-10-25 23:45 devconfig.php +-rw-r--r-- 1 root root 3526 2011-10-27 14:51 devconf.php +-rwxr-xr-x 1 root root 725 2011-10-20 17:06 execute.php +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 fonts +-rw-r--r-- 1 root root 2259 2011-10-28 12:43 index.html +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 icons +drwxr-xr-x 2 root root 4096 2011-10-25 14:10 Images +-rw-r--r-- 1 root root 2038 2011-10-20 17:06 insertData.php +-rw-r--r-- 1 root root 636 2011-10-26 13:43 insertdevice.php +-rw-r--r-- 1 root root 10819 2011-10-20 17:06 loader.gif +-rw-r--r-- 1 root root 2268 2011-10-26 16:07 main.php +-rw-r--r-- 1 root root 5416 2011-10-20 17:06 moocheck.js +-rw-r--r-- 1 root root 75836 2011-10-20 17:06 mootools.js +-rw-r--r-- 1 root root 677 2011-10-20 17:06 mutexFunctions.php +-rw-r--r-- 1 root root 9063 2011-10-25 17:20 mutexSmartTest.php +-rwxr-xr-x 1 root root 9143 2011-10-28 12:45 mutexTry.php +-rw-r--r-- 1 root root 13304 2011-10-20 17:06 networkResult.php +-rw-r--r-- 1 root root 8294 2011-10-21 19:02 post.php +-rw-r--r-- 1 root root 19218 2011-10-21 17:36 startTest2.php +-rw-r--r-- 1 root root 18852 2011-10-20 17:06 startTest.php +-rw-r--r-- 1 root root 18787 2011-10-25 16:43 TaskTest.html +-rw-r--r-- 1 root root 3685 2011-10-20 17:06 testCase.php +-rw-r--r-- 1 root root 2545 2011-10-20 17:06 wait.gif +\end{lstlisting} +The \emph{startSoftware.py} file is required to be in the \emph{/etc/init.d/} folder, +since it is required to be start with the computer boot however if that does not work, +one should start it manually. This part of the software is +responsible for starting the testing software from the web page\footnote{The web page +communicates with this script via a socket connection and sends a signal to start +the main test software.}. +The main test software python files should be located in \emph{/home/gsmselftest/SoftwareTesting/}. +\begin{lstlisting} +drwxr-xr-x 2 gsmselftest gsmselftest 4096 2011-11-03 14:29 . +drwxr-xr-x 30 gsmselftest gsmselftest 4096 2011-11-02 18:28 .. +-rwxr--r-- 1 gsmselftest gsmselftest 2909 2011-10-20 17:54 ClientClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 3628 2011-10-20 17:54 ClientClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 9814 2011-11-02 16:19 ControllerClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 9247 2011-11-02 16:20 ControllerClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 15129 2011-11-02 15:32 DbClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 11712 2011-11-02 15:32 DbClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 8512 2011-11-02 13:30 GSMClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 7337 2011-11-02 13:42 GSMClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 8063 2011-11-02 13:24 GSMHandler.py +-rwxr-xr-x 1 gsmselftest gsmselftest 20346 2011-11-02 18:32 gsmselftest.py +-rwxr--r-- 1 gsmselftest gsmselftest 698 2011-11-02 18:36 help.txt +-rwxr-xr-x 1 gsmselftest gsmselftest 8661 2011-11-02 16:35 initTestClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 7497 2011-11-02 16:37 initTestClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 645 2011-10-20 17:54 LogFileClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1509 2011-10-20 17:54 LogFileClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 817 2011-10-20 17:54 PingClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1263 2011-10-20 17:54 PingClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 3982 2011-10-20 17:54 ServerClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 4596 2011-10-20 17:57 ServerClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 4129 2011-10-20 23:17 ServerClassSoftware.py +-rw-r--r-- 1 gsmselftest gsmselftest 4802 2011-10-20 23:17 ServerClassSoftware.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 5252 2011-10-22 03:58 SIPHandler.py +-rwxr--r-- 1 gsmselftest gsmselftest 1267 2011-11-02 14:07 SSHTunnelBoxClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1852 2011-11-02 14:19 SSHTunnelBoxClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 323 2011-11-02 18:44 startSoftware.py +-rwxr-xr-x 1 gsmselftest gsmselftest 6378 2011-11-02 16:13 trueTableClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 4583 2011-11-02 16:16 trueTableClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 2248 2011-10-28 14:04 usbDetectClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 3590 2011-10-28 14:05 usbDetectClass.pyc +\end{lstlisting} + +\subsection{Setting up the parameters} +After configuring the hardware, \emph{https} and \emph{.htaccess} on the web server, +it is important to modify the files for proper operations. In the given section you +can find out how to configure the rest of the files (e.g. database passwords, etc.). +The following files you have to modify to have a working database access: +\emph{initTestClass.py, GsmSelfTest.py, UsbDetectClass.py} and \emph{truthtableClass.py}. +\subsection{Test descriptions} +In the following section we will describe the tests that can be performed and what kind +of problems they can identify. There are five types of tests: +\begin{itemize} +\item Smart test +\item SIP test +\item GSM test +\item Everything test +\item Manual test +\end{itemize} +Each test will be described in the next subsections. +\subsubsection{Smart test} +\par The \emph{smart} test is not called smart without a reason. It tries automatically to identify +problems inside of the telecommunication network. The user is not required to define what kind +of tests have to be performed. In the first part the test software communicates with the +database to see what systems are available. In the next step it performs a call from the +University telephone system to a random local cell phone\footnote{Local cell phone or +local GSM network means our University GSM Network or RZ GSM.} +inside of our University GSM network. +While executing this task, automatically the Asterisk server, OpenBSC and a random nanoBTS +(or the one cell phone in RZ) are tested. The next task to be performed in the smart test, +a randomly selected cell phone inside of our local GSM network will try to call: a random +cell phone within the external (O2, Vodaphone,E-Plus or T-Mobile) or local GSM network. +This might test the external network and will test it with high probability, however the +probability exists to make a local to local GSM test call. In the third task, we perform +a test where we call from the landline a random cell phone inside of our local GSM network. +In the fourth or last task, we call from SIP to the service we did not test yet (e.g. +if we did not test the external GSM network using the second test task, then in this last +task we will exploit it). After the smart test had been completed you will be presented +with the results. +\subsubsection{SIP test} +The \emph{SIP} test option will perform test in such a way that all the SIP subsystems are +tested (SIP and University telephone network). It will try to identify if there are any +problems on the Asterisk server and our University telephone network, including incoming and +outgoing calls from the SIP side. +\subsubsection{GSM test} +In the \emph{GSM} test both GSM networks get tested, the local and the external GSM network. +We test the nanoBTS controller boxes (i.e. BeagleBoards) as well. Using this test, both incoming +and outgoing calls are performed, we can detect possible errors on the OpenBSC and the nanoBTS. +\subsubsection{All test} +The \emph{All} test selects all the given tests and executes them step-by-step. It is the test +that takes the greatest amount of time. While the test are performed, results are +immediately printed in the terminal window or on the web site. +\subsubsection{Manual test} +The \emph{Manual} test as the name itself says, is the test where you can manually select +what kind of tests you want to be performed. +\newpage +\subsection{Result descriptions} +In the following table one can see the messages returned by the test software! +These messages should guide the test user operator to debug the system. + +\begin{table}[h]\footnotesize + \begin{center} + %\caption[]{Table of error descriptions} + \begin{tabular}{| l | c | l | } + \hline + \textbf{Number} & \textbf{Code} & \textbf{Code number description} \\ \hline + 1 & 200 & Call was OK \\ \hline + 2 & 604 & General Handler Error: Destination handler did not respond. Timeout \\ \hline + 3 & 998 & General Handler Error: Could not connect to the destination handler! \\ \hline + 4 & 605 & General Handler Error: Caller handler did not respond. Timeout \\ \hline + 5 & 999 & General Handler Error: Could not connect to the caller handler! \\ \hline + 6 & 486 & Call Failed \\ \hline + 7 & 333 & Could not establish a connection to the database! \\ \hline + 8 & 100 & Missing account detail \\ \hline + 9 & 402 & Payment Required (E-Plus Card) \\ \hline + 10 & 801 & Connection to caller established, but the device does not respond \\ \hline + 11 & 802 & Connection to destination established, but the device does not respond \\ \hline + 12 & 501 & Destination server Internal Error \\ \hline + 13 & 502 & Caller server Internal Error \\ \hline + %\hline + + \end{tabular} + \end{center} +\end{table} + + + +\clearpage +\newpage +\subsection{Using the software} +In this section, you will be taught step by step how to use our test software. There are two options to run our test software, from the web site or the terminal. +The first is easier, but the second is easy as well however requires terminal skills. + +\subsubsection{Web site guide} +Once you enter the address in the address bar of your browser (e.g. \emph{https://localhost/\\testsoftware}). +You will be required to enter your username and password for the web page\footnote{The username and password creation process is explained in section 7.2.2.}. +If you entered the correct username and password you should see the same image as in the following figure. +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website1.png} + \caption[]{Web page of test software} +\end{figure} +Here you can choose what kind of test you want to perform or maybe if you want to configure the devices (manually or automatically). +If you press the ``Smart test'' button, you have to wait a few moments and the results should appear in a short amount of time. +However, if you pressed the ``Choose the test'' button, you will be presented with a new page, given in figure 28. +You will have to select the tests you want to perform manually or to press on the left side one of the given buttons for different +tests. You can choose between ``SIP Test'', ``GSM Test'', ``Check all'' and ``Uncheck all''. ``Check all'' will select all the possible +tests, whereas ``Uncheck all'' will deselect all of them. After you finished the procedure of selecting the tests, you should press the +``Submit'' on the left side. Wait a few moments and the results will start to appear in real time. After the table on the left is filled +(i.e. after all the tests have been completed) a result image will be generated on the right side, can be seen in figure 20. However, if +your pressed the ``Device configuration'' button, then you will end up on a page as given in figure 30. + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website2.png} + \caption[]{Manually selecting the tests} +\end{figure} + +If you press the ``Automatic configuration'' button, the test software will try automatically to match your cell phones with +their port addresses and numbers. However, if the automatic matching does not work, you will have to manually configure it. +You can do it by entering all the required information on the web site, as in figure 31. Once you correctly filled in the required +information, you should press the ``Submit'' button. + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{webpageReport.png} + \caption[]{Result web page} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website3.png} + \caption[]{Device configuration web page} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website4.png} + \caption[]{Manual device configuration page} +\end{figure} +%\clearpage +\newpage +\subsubsection{Terminal guide} +In the following text, we will guide you and show you step-by-step how to use the test software from the terminal. All you have to +do is just type the command for starting the test software in the folder where it is located, \emph{./gsmselftest.py ---option} (keep +in mind there are two dashes before \emph{option}). +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{terminalCommand.png} + \caption[]{Test software terminal options} +\end{figure} +You can perform the tests manually by typing what you want to test or by choosing one of the predefined tests. For example, you +want to test manually does the SIP work with the University telephone network, you would type the following: \emph{./gsmselftest.py --db sip unisip}. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{resultterminal.png} + \caption[]{Example results from the terminal screen} +\end{figure} +After the tests have been performed the results will be displayed. Green result text means the test was performed successfully and red result +text means that something is not working properly. + +If you need to configure the cell phones manually or automatically, you can do it by typing: \emph{./gsmselftest.py --devconf} (keep +in mind there are two dashes before \emph{devconf}). Then you can press ``a'' on the keyboard for automatic configuration or ``m'' for +manual configuration. One should keep in mind that the terminal test software can be started even through \emph{ssh}, however with an +additional command \emph{-X}\footnote{For example: ssh -X username@address}. +\begin{figure}[htb] + \centering + \includegraphics[width=100mm]{devconf.png} + \caption[]{Test software device configuration from terminal screen} +\end{figure} + +\clearpage +\newpage +\section{Conclusion} +As a result of our successfully finished team project, we had felt how it is to work +in a team. We had learnt how to confront various software and hardware issues. The problems +were broken into smaller fragments and the solutions were derived in a step-by-step approach. +\par While designing the software, we kept in mind that every single step should be well thought-out, +documented, tested and validated. At the end we joined all the ``black-boxes'' together +into one big piece of software. We fulfilled our stated requirements and goals. +\par Despite the fact that our test software will be used by well educated engineers, we may +conclude that all the way along we thought about the usage-simplicity, safety and security +of our product. Our team members were enthusiastic about the idea that our team project will +contribute to a better performance and quality of the overall telecommunication network, +for all of the University staff and our colleagues, the students. +\newpage + + + +%bibliography start +\begin{thebibliography}{9} + +\bibitem{network} \emph{Projects based on RZ-GSM}, accessed on 10.06.2011, available at +\url{http://lab.ks.uni-freiburg.de/projects/gsm/wiki}. + +\bibitem{python} \emph{Python Programming Language - Official Website}, accessed on 10.06.2011, available at +\url{http://www.python.org/}. + +\bibitem{mysqlManual} \emph{MySQLdb User's Guide}, accessed on 05.06.2011, available at \\ +\url{http://mysql-python.sourceforge.net/MySQLdb.html}. + +\bibitem{wiki} \emph{[2011] GSM Selftest - Wiki - Lehrstuhl f\"{u}r Kommunikationssysteme}, accessed on 20.09.2011, available at \\ +\url{http://lab.ks.uni-freiburg.de/projects/gsm-selftest/wiki}. + +\bibitem{socket} \emph{17.2. socket - Low-level networking interface}, accessed on 20.06.2011, available at +\url{http://docs.python.org/library/socket.html}. + +\bibitem{spin} M. Ben-Ari \emph{Principles of the Spin Model Checker}, +Springer Verlag, Weizmann Institute of Science, Israel, ISBN: 978-1-84628-769-5, 2008. + +\bibitem{sshTunnel} R. Natarajan, \emph{3 Steps to perform SSH login without password using ssh-keygen \& ssh-copy-id}, accessed on 18.08.2011, available at +\url{http://goo.gl/fX68N}. + +\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{htaccess} \emph{EnablingUseOfApacheHtaccessFiles}, accessed on 18.08.2011, available at +\url{https://help.ubuntu.com/community/EnablingUseOfApacheHtaccessFiles}. + +\bibitem{pChart} \emph{pChart}, accessed on 15.08.2011, available at +\url{http://www.pchart.net/}. + +\bibitem{beagleDataSheet} \emph{BeagleBoard System Reference Manual}, accessed on 20.06.2011, available at +\url{http://beagleboard.org/static/BBSRM_latest.pdf}. + +\bibitem{proctitle} \emph{setproctitle 1.1.2}, accessed on 20.10.2011, available at +\url{http://pypi.python.org/pypi/setproctitle}. + +\bibitem{pjsip} \emph{Open source SIP stack and media stack for presence, im/instant messaging, and multimedia communication}, accessed on 20.10.2011, available at +\url{http://www.pjsip.org/}. + +%bibliography end +\end{thebibliography} + +%end of the document +\end{document} \ No newline at end of file diff --git a/documenting/Report/test.tex.bak b/documenting/Report/test.tex.bak new file mode 100644 index 0000000..c6faea2 --- /dev/null +++ b/documenting/Report/test.tex.bak @@ -0,0 +1,1326 @@ +\documentclass[a4paper, titlepage, oneside, headsepline, footsepline]{scrartcl} +%PACKAGES +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\usepackage{lscape} %for the landscape pages it is used +\usepackage[english]{babel} %what language are we using +\usepackage[latin2]{inputenc} %what alphabet + +\usepackage[tt]{titlepic} %used for adding the title image +\usepackage{graphicx} %used for adding images +\usepackage{url} %used for the url in bibliography +\usepackage{lastpage} %give me the total number of pages, used in footer: \pageref{LastPage} + +\usepackage[T1]{fontenc} %used for fonts +\usepackage{scrpage2} %used for making headers, footers and correct margins +%\usepackage{hyperref} %used for the linking of table of content + +%information for the PDF +\usepackage[pdftex, %used for adding pdf information + pdfauthor={Refik Hadzialic, Tri Atmoko}, + pdftitle={Software for self-testing of the Telecommunication network of University of Freiburg}, + pdfsubject={Telecommunication network testing software}, + pdfkeywords={telecommunication;network;networking;linux;ubuntu;university;freiburg;python;tcp/ip;security;gsm;sip;voip}, + pdfproducer={Latex with hyperref, or other system}, + pdfcreator={pdflatex, or other tool}]{hyperref} %used for the linking of table of content + + + + + +\hypersetup{ %setting up the look of the links + colorlinks, + citecolor=black, + filecolor=black, + linkcolor=black, + urlcolor=black +} + +\usepackage{color} %used for highlighting source code +\usepackage{listings} %used to make a box with source code +\usepackage{fancyvrb} +\DefineVerbatimEnvironment{code}{Verbatim}{fontsize=\small} +\DefineVerbatimEnvironment{example}{Verbatim}{fontsize=\small} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%DEFINE LOOK OF THE PAGES +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\pagestyle{scrheadings} + +\renewenvironment{abstract} + {\begin{center}\large\textbf{}\noindent\end{center}}{\vspace{2\baselineskip}} + +% Disable single lines at the start of a paragraph (Schusterjungen) +\clubpenalty = 10000 +% Disable single lines at the end of a paragraph (Hurenkinder) +\widowpenalty = 10000 \displaywidowpenalty = 10000 + +\setlength{\parskip}{0.01\baselineskip} +\textheight = 620pt + +\ohead{Software for self-testing of the Telecommunication network of University of Freiburg} %make the header +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%DEFINE THE STUFF FOR CODE +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\lstset{ % +%language=Python, % choose the language of the code +columns=fullflexible, +keywordstyle=\color[rgb]{0.608,0.561,0.008}, +commentstyle=\color[rgb]{0.25,0.5,0.35}, +stringstyle=\color[rgb]{0.25,0.35,0.85}, +basicstyle=\footnotesize,%\scriptsize % the size of the fonts that are used for the code +%numbers=left, % where to put the line-numbers +numberstyle=\footnotesize, % the size of the fonts that are used for the line-numbers +stepnumber=1, % the step between two line-numbers. If it is 1 each line will be numbered +numbersep=8pt, % how far the line-numbers are from the code +backgroundcolor=\color{white}, % choose the background color. You must add \usepackage{color} +showspaces=false, % show spaces adding particular underscores +showstringspaces=false, % underline spaces within strings +showtabs=false, % show tabs within strings adding particular underscores +frame=single, % adds a frame around the code +tabsize=2, % sets default tabsize to 2 spaces +captionpos=b, % sets the caption-position to bottom +breaklines=true, % sets automatic line breaking +breakatwhitespace=false, % sets if automatic breaks should only happen at whitespace +escapeinside={\%}{)} % if you want to add a comment within your code +} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + + +\newcommand{\titleOfProject}{Software For Self-Testing Of The Telecommunication Network Of University Of Freiburg} + + + +%begin of the document +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\begin{document} + + + + +%make the title page +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\titlepic{\includegraphics[width=90mm]{uniLogo2.png}} +\title{Team Project \\ ``\titleOfProject''} % type title between braces +\date{\today} % type date between braces +\author{Refik Had\v{z}iali\'{c}\\ Tri Atmoko } % type author(s) between braces +\department{\vspace{1\baselineskip} \large Albert-Ludwigs-Universit\"{a}t Freiburg \\ +Lehrstuhl f\"{u}r Komunikationsysteme\\ +Prof. Dr. Gerhard Schneider\\ \vspace{1\baselineskip} Supervisors: \\ Konrad Meier \\ Dennis Wehrle \\ \vspace{1\baselineskip} Sommersemester 2011} + +\maketitle +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%add the table of contents +\tableofcontents + +%new page to start with +\clearpage + + + + +% first chapter +\section{Introduction and Motivation} % chapter 1 +In the following report, the authors will try to give you a brief insight into our team project. The goal of our project was to develop a mechanism for automatic testing of our University Telecommunication network. The Telecommunication network of University of Freiburg consists of: our own internal GSM and telephone network systems; GSM redirecting device (if one initiates a call to one of the four external GSM networks, it redirects the calls to: T-mobile, 02, Vodaphone or E-Plus); a SIP gateway for land-line calls inside of Germany (sipgate.de) and international calls. Since we did not have access to internal servers, our strategy was to exploit the existing systems from an external perspective and infer the results out of our findings. +Before we had started working on our project, we had to analyze the overall network to come up with the 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. In the following chapters we will describe in more detail our approach to the problem and how each subsystem works. +This particular report and our wiki page should be a sufficient guide and manual for understanding, running and continuing the development of our test software. +Certainly, we had a lot of fun while working on the project due the fact that we lost one team member. +We would like to thank the whole department for the free coffee and their support, especially +Konrad Maier, Dennis Wehrle and Richard M. Zahoransky, without their support this project would not +end up this way. +\clearpage +\section{Requirements} % chapter 2 +At the start of the project the requirements were not completely known but as the time had passed we redefined our requirements and goals. +The first and the most important part at the start was to identify the key goals of our team project. The basic goal of our team project was to build a +test software system which could tell an operator user what part of the system is not properly working in our University telecommunication network. +Konrad and Dennis suggested us to analyze figure 1 and depending on it to build our test software. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{BigPicture_new1.png} + \caption[]{Overview of the Freiburg University telecommunication network \cite{network}} +\end{figure} +Our first attempt was to see what could we test without having access to the system. We installed numerous communication programs to see what others have done. +After gaining access to the communication software, we had decided to build most of the test software ourselves. Libraries, which were used, +were only the ones we could not develop ourselves because of the time-span of our team project. +\subsection{Logical and algorithmic requirements} +Despite the software and hardware requirements, the logic in our team project may be considered as the most important part. +Controlling the software and hardware in a specific manner was one of the requirements in our team project. +Moreover, we were required to draw a use case diagram and a simple test case diagram so that we could better understand all the problems we had to deal with +but also to easier follow the development of our test software. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{activity_diagram.png} + \caption[]{Simple algorithmic overview of a test case} +\end{figure} +\subsection{Software requirements} +Afterwards, as we had defined our logical approach to the problems, we had to choose the programming language to realize our ideas. Since we had the freedom of choice, between the three suggested programming languages +Java, C++ and Python, we made a joint decision to use Python as the main programming language in our team project. One of the requirements was to finish the team project in time, +therefore our decision to use Python is justified. Using Python we could work faster and integrate our subsystems more effectively \cite{python}. +Our programming language of choice is multi-platform, therefore our test software would be easy portable to other operating systems. +\par Likewise we had to decide how our test software will work. One of the requirements by Dennis and Konrad was to make the software capable of being run from the terminal. +The next requirement was to make an appealing GUI so that even an user without advanced Linux experience could handle the software and read out the results. +\par In addition it was required to log all the past tests. Later on a machine learning algorithm or some other intelligence could be applied to deduce some error behavior of the system +(e.g. an intelligent algorithm could find that part of the system fail in a combined manner). To accomplish the logging of all the tests we had to use a database system. +We decided to use MySQL since it is open source and well supported. However, one should keep in mind the test results are only stored in the database in case the test was started from the web site. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{test_Use_case.png} + \caption[]{Test case diagram} +\end{figure} +\subsection{Hardware requirements} +Likewise the software requirements, we had hardware requirements as well. We were required to identify the hardware we will need to perform the tests. +It was important to find old and cheap cell phones that could support \emph{AT Modem} commands because our budget was limited. +\par A problem we had to deal with at the start was that the base stations are located at different geographical points which were not near to each other. +No one should go everyday to the rooms where our cell phones are located only to change or charge the batteries. +In the cable subsection we describe our approach to the charging battery problem. As we defined our requirements we continued with the process of developing the test software. +During the development time we refined our requirements. In the next chapters we will explain our database, software and hardware design ideas. +\newpage +\section{Database design} +As we mentioned in the software requirements section, we decided to use MySQL as our database system for storing the test information and results. +It was not difficult to decide what database to use, since MySQL is one of the most supported database and one can find a library to use it with major programming languages. +The key point in the design of our database was the simplicity and speed of accessing the data. We had decided to use seven tables. In the following paragraphs we will explain each table separately and its usage. +The database design can be seen in figure 4. + +\par The \emph{PingResultTable} table has six attributes (\emph{taskNo, sipServer, sipGate, unisip, gsmBox1, gsmBox2}), all of integer type. +The \emph{taskNo} attribute identifies the test number but not a single test (e.g. an operator user has selected three different tests to be executed, all of the three tests will have the same \emph{taskNo} to identify them together as belonging to one test group and \emph{taskId} identifies each single test and will be explained later). +\emph{sipServer} represents the Asterisk server ping result. \emph{sipGate} is used to represent the SIP Gate server for the landline calls (\url{http://www.sipgate.de}). \emph{uniSip} represents the ping results for our local University telephone network SIP server. +\emph{gsmBox1} and \emph{gsmBox2} are the two single-chip Linux computers (BeagleBoard), that control two cell phones each one (i.e. they are also known under the name of \emph{nanoBTSx controller}). +\emph{taskNo} is the primary and unique key in the table \emph{PingResultTable}. Rest of the attributes (i.e. \emph{sipServer, sipGate, uniSip, gsmBox1, gsmBox2}) are used to insert the ping results, if the assigned servers are reachable or not. +Before any test attempt is made, our test software first tries to ping the servers. These results are then stored in the \emph{PingResultTable}. + +\par The \emph{ErrorCodeTable} table defines all the possible test results in the system, in other words it represents a list with error codes with their appropriate descriptions and meanings. It consists of two attributes (\emph{errorcode} and \emph{description}), the first is of integer type and the second of varchar type (the description message is allowed to be only 100 characters long). +The \emph{ErrorCodeTable} table is used by the main test software (i.e. controller) to report the operator user what kind of error had appeared in the system. + +\par The \emph{DeviceAddressTable} is the table containing the location and identification data for each server and device. The table consists of seven attributes, \emph{deviceName, portName, number, lastChange, username, password, server}. +\emph{deviceName} is the attribute with the name of the device or server (e.g. GSMRZ1 or landline), it is of varchar type. \emph{portName} is the attribute field with the location address for a cell phone (e.g. \emph{/dev/ttyUSB1}) or 'localhost' instead of NULL value for a server, it is of the varchar type. +\emph{number} represents the number of the used service (i.e. number of the cell phone, SIP, etc.) and is of varchar type. +\emph{lastChange} is a time value and represents the date and time the given entry was modified (we had plans in future versions of our test software that if an device gets a new IP address assigned it automatically changes it in the database). +\emph{username} is the field with the username stored in for a server/service, like SIP and landline. \emph{password} attribute stores the password information for the given service. The \emph{server} attribute stores information about the location of the server, IP or DNS address of the server. All three fields, \emph{username}, \emph{password} and \emph{server} are of varchar type. +The information stored in the given table is used by the test software to obtain usernames, passwords and addresses of the used services for the tests. + +\par The \emph{ResultTable} table is used by the test system to store final results for the performed tests. Our given table consists of two fields, \emph{taskID} and \emph{result} and both are of integer type. For each test entry with unique \emph{taskID} an error code is assigned in the \emph{result} field, +depending on the test results. Error codes found in the \emph{ErrorCodeTable} table can be only assigned to this field. + +\par The \emph{TempTaskTable} table represents the table with the tasks the system has to execute next time the test software is started. The given table gets new data every time an operator user submits one or more test cases from the website to be executed. \emph{TempTaskTable} includes four attributes, \emph{taskID, taskNo, from, to}. Former two are of integer type and later two of varchar type. +\emph{taskID} and \emph{taskNo} identify the test task to be executed, \emph{taskID} is the unique primary key. \emph{from} and \emph{to} fields have to match the names given in \emph{DeviceAddressTable.deviceName}, these two attributes specify the caller and callee devices/services. Consequently, after the tasks get executed, the test tasks are removed and the given table is empty again until next tests are added to it. +However, all the test tasks even after deleting them from \emph{TempTaskTable} are kept in the \emph{TaskTable}. The reason why the authors of this project divided it into two tables was because of the database row selection speed. We had made the assumption that with time the database size will grow and therefore the database speed will not be the same as during the development period. + +\par The \emph{TaskTable} table, as mentioned before contains all the tests ever performed from the web site. It is made out of five attributes, \emph{taskID, taskNo, from, to, timestamp}. The first four fields are the same as in \emph{TempTaskTable}, however the last one, \emph{timestamp}, is used to record the exact time when the test was performed. +\par The \emph{GSMListPrefix} table contains the data about the GSM networks and their prefixes. It consists of two +attributes, both of varchar type, \emph{providerName} and \emph{prefix}. +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{DBRelationship.png} + \caption[]{Database relationship diagram} +\end{figure} +\end{center} +\end{landscape} + + + + + +\section{Software design} % section 2.1 +Software design was the next step after we analyzed the problem and developed a plan how to proceed further. Good analysis and planning with poor algorithmic implementation is valueless. +During the work on the project, we had spent most of our time for software design. +We kept in mind that our software should satisfy major paradigms of software engineering, +like compatibility, extensibility, modularity, relliability, security, fault-tolerance and usability. +The software engineering design concepts were achieved following way: +\begin{itemize} +\item Compatibility - we used Python and MySQL which are multiplatform and work on major OS +\item Extensibility - new parts of code can be easily added by just modifying the classes +\item Mudalarity - the components are independent black boxes, they are tested and validated independently +\item Reliability - we use mutex locks to perform tests and database transaction operations to insert data into the database +\item Security - all communication channels, as well as the access to the web site, are encrypted with asymmetric key cryptography +\item Fault-tolerance - the classes were designed to continue operating even if error events appear and handlers are logging all events +\item Usability - we tried to create a simple user interface and easily to use for everyone +\end{itemize} + +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{activityControllerEdited.png} + \caption[]{Working principle of the test software} +\end{figure} + +\par The basic principle how the test software works can be seen in figure 5. The test software is +started either manually from the terminal or using the web site. When the test software +is started manually it is database dependent as well and thefore could not be used if the +database is being maintained or not working. If it is started from the web site it +connects to the database to get its tasks which have to be performed. After receiving +the tasks it makes a simple network test by pinging all the servers. The ping results +are stored in the database (in case the test was started from the web site). Then it +proceeds with the tests by connecting itself to the handlers and sending them commands +to perform the tests\footnote{Before it connects to the handlers, it uses the ping +results to see is the service/device physically connected to the network.}. +At the higher level, these commands can be seen as requests for being the +callee and caller. Meanwhile the handlers send their test results to the main +test software which in return decides if the test result was successful or not. +The result is written to the database (in case the software was started from the website), +otherwise the results are displayed in the terminal window and the user who started +it manually can see the test results. We will proceed with introducing the classes. +The software class diagram can be seen in the following figure. More details for the +classes, like the input/output can be found on our project's wiki page \cite{wiki}. + +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{classDiagram.png} + \caption[]{Class diagram (some classes were excluded)} +\end{figure} +\end{center} +\end{landscape} + + +\newpage +\subsection{Database access} % subsection 2.1.1 +Accessing the database is of critical value to our project, therefore we had developed our own class that limits the access to the database. In the process of developing our own class we used the MySQLdb library in Python \cite{mysqlManual}. +The database class has two working modes, a normal working mode and a debugging mode. The difference between these two modes is in the output information. In case the error handling function raises an error and it is unknown, if the debug mode is set a complete back-trace of the error will be printed out. A developer can change the mode by setting the variable \emph{debugMode=1}. The class diagram can be seen in the following figure. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{dbClass.png} + \caption[]{Class diagram for the dbClass} +\end{figure} +The method names are self-explanatory and do not require extra explanations. All the outputs produced by the class can be found on the project wiki page \cite{wiki}. +\subsection{Controlling the cell phones} +Our first version of the developed program code for controlling the cell phones used predefined timed values +to send commands instead of using a state controlled approach to confirm that every command was successfully received and executed by the cell phone. +It meant we had to make an enormous number of assumptions. In comparison to our second approach, to build a state controlled cell phone control class, +our first approach was inferior and slower. The state controlled method connected two cell phones, on the same base station, up to 15 times faster than the timed approach. +\begin{figure}[ht!] + \centering + \includegraphics[width=80mm]{serialPort.png} + \caption[]{GSM class diagram for controlling the cell phones} +\end{figure} +One can easily apply the class just by correctly defining the parameters: port address, baud rate and timeout. The former two are self-explanatory and the timeout parameter is used to define when the alarm function should raise a timeout exception. +A timeout exception gets raised when the cell phone does not respond (i.e. when the cell phone enters a deadlock or delayed state). We had used the serial port library inside of Python although we use USB cables to connect to our cell phones. One should +be aware that our USB cables create a virtual serial port. More details on class design and an example can be found on our project wiki \cite{wiki}. +\subsection{Client and Server class} +Our socket communication code is based on the example given in the Python socket manual \cite{socket}. +We extended it into two classes, a client and a server class. We had used the TCP protocol to base our two classes on\footnote{TCP is reliable compared to UDP (i.e. transmitted packets get also delivered), +packets are ordered when received and data are received in a stream (i.e. multiple packets can be read at once).}. +The Server class can be seen in the following figure. The server class is implemented to accept only local connections\footnote{More details are given in the section 7.1}. +First we determine our IP address and then create the socket to listen only for the same IP address (with a different IP address than the selected one a connection cannot be even established). +One has to define the port on which the server object should listen. +When receiving data one can easily define the timeout to be raised if data are not received in the timeout range or set it to \emph{0} to infinitely wait for the buffer to be filled with received data. While testing the server class we had the problem to listen on the same port if the application was forcibly\footnote{Manually closed using CTRL+C and run again.} restarted in less than 60 seconds. We got the error message: \emph{"Address already in use"}. +This is not known as error behavior but rather an option to help the server to catch lost live packets (i.e. packets that are still in the network looking for it is goal destination). +We solved the problem by changing the socket options with the \emph{SO\_REUSEADDR} parameter. This enabled us to get around the error when we tried to restart our server application. +Before solving the problem without using the socket parameter, we had another solution to get around this problem by killing the application running the port, this old method is obsolete now. +\begin{figure}[ht!] + \centering + \includegraphics[scale=0.8]{serverClass.png} + \caption[]{Server class, used by the server application} +\end{figure} +In the process of testing the client class we did not have any major problems. The only major flow we had to debug was when one of the sides disconnects that we get out of the waiting loop if the timeout variable was set to \emph{0} (i.e. infinite waiting loop). +The client class can be seen in the following figure. To initialize the client object one needs to define the IP address and the port of the server application listening on it. +\begin{figure}[hb!] + \centering + \includegraphics[scale=0.5]{ClientClass.png} + \caption[]{Client class, used by the client application} +\end{figure} +Once an instance of it is created and loaded with the IP address and the port, one needs to call the \emph{connect()} method. +The method will produce an integer based on its connection state. Output information and the programming code can be found on our project wiki page \cite{wiki}. +\subsection{Ping class} +Before making any test and establishing a connection we were required to ensure that the server is online. The best way to assess the liveness property was to ping the server computer running the required service. Once the class is properly defined, we could easily set the number of ping tries. +A ping timeout response was set up to 2 seconds. For more details and insights, one can read more about it on our wiki page \cite{wiki}. +\begin{figure}[ht!] + \centering + \includegraphics[width=70mm]{ping.png} + \caption[]{Ping class, used by test software} +\end{figure} +\subsection{Data logging} +If errors appear it is important to reconstruct the events that led to the misbehaviour of the software. One of the best ways to reconstruct the events was to log +events for different blocks of programming code. +We had used the logging class to follow our handler code run on the BeagleBoard. In case there is an error we could look inside of the log files and track the error. +How the class works and what kind of outputs it produces can be found on our project wiki page \cite{wiki}. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{logging.png} + \caption[]{Logging class} +\end{figure} +\subsection{SSH Tunnel Class} +Since security played an important role in our team project. We decided to encrypt all of our data that was not processed on our server computer. +The simplest solution to this problem was to build an SSH Class that could open and close a local forwarding port. +All data sent through the created port is encrypted until it gets to its destination location. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{sshTunnelClass.png} + \caption[]{SSH Tunnel class} +\end{figure} +\subsection{USB Cell phone detection class} +Since we had used cables to connect the cell phones with the computer, usually the devices +got their own port addresses. They were automatically assigned by the operating system, +either after the cables were plugged into the USB port or after a system reboot. +One of the problems we had to deal with was assigning the right cell phone +(i.e. with the appropriate GSM network) to the corresponding port address. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{usbDetectClass.png} + \caption[]{USB cable detection class} +\end{figure} +The operating system randomly assigned the port names after every reboot. +We were looking for a solution to prevent this misaddressing of the devices. +Our solution was to recognize every device and update the port address in the database. +The principle how we identify the cell phones is by their calling numbers in the database. +More details can be found on our project wiki page \cite{wiki}. +\subsection{Truth table class} +The truth table class was built to identify the broken and working parts of the system. +It requires the list with test results to be present to be operable. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{trueTable.png} + \caption[]{Truth table class} +\end{figure} +Then the class tries to identify the broken parts of our telecommunication network. +The class can easily identify how many nanoBTSs are installed in the network and +derive a decision which part of the network is broken. +All the test results are stored in a list and can be easily read by calling the +\emph{initTrueTable(x)} function. More details can be found on our project wiki page \cite{wiki}. +\subsection{Init Test class} +The main purpose of the class is to get device data from the database and to process it. +The processed data get forwarded to the controller class and in the end the class +fetches the results from the test. This class contains the \emph{smart test} functionality. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{initTestClass.png} + \caption[]{Init test class} +\end{figure} +It selects automatically the important tests to perform. In the next step it +tries to identify the problem in the network. +More details can be found in the \emph{smart test} description. +\subsection{Controller class} +The controller class is used to assign jobs to handlers (in other words, which one is +going to be the caller and callee). Simultaneously, it defines the port addresses for +the communication between the handlers and the main test software (controller). +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{controllerclass.png} + \caption[]{Controller class} +\end{figure} +If the callee or the caller are nanoBTS controller boxes (i.e. BeagleBoards outside +the Rechenzentrum), it will first create an SSH connection to make a tunnel before +the local socket connection is created. Then the controller class sends all the +required data regarding the test tasks to the handlers. + +\clearpage +\section{Hardware design} +In our team project we had the option to choose all the required hardware ourself beside the two BeagleBoards, which we were supplied by Konrad and Dennis. +Since one of the project goals was to reduce the costs as much as it was possible, we had tried to use some of the leftovers found in our lab. + +\subsection{BeagleBoard} +``The BeagleBoard is an OMAP3530 platform designed specifically to address the Open +Source Community. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{bb.jpg} + \caption[]{BeagleBoard, a Linux-on-chip board where our controller software runs the GSM device } +\end{figure} +It has been equipped with a minimum set of features to allow the +user to experience the power of the OMAP3530 and is not intended as a full development +platform as many of the features and interfaces supplied by the OMAP3530 are not +accessible from the BeagleBoard'' \cite{beagleDataSheet}. +We run on it a special precompiled version of Ubuntu for the ARM processor type. The Linux system boots up from an SD Card. +The board has an USB hub and network port attached to it. In our project it is connected to our +internal university LAN network and to a cell phone. We positioned the two BeagleBoards in rooms where +we had LAN access and GSM signal coverage of our two local base stations. + +\subsection{Cell phones} +Our first attempt was to control a Nokia cell phone 3310 with the supplied USB connection cable. +The protocols used by old versions of Nokia cell phones, as the 3310, use the F-Bus protocol. It was not easy to work with. +After performing various experiments we succeeded to send and to read SMS messages. Later on we found out that it was not possible to +send commands for receiving and making the calls. In the meantime we found two Siemens phones, one M45 and S55. +The first one, Siemens M45, had a cable supplied with it and it was not difficult to control it with the standard set of AT modem commands. +At the start we did not have a cable supplied for the Siemens S55 phone. We controlled it over the Bluetooth port. + +\subsection{Cables for the cell phones} +Due to the fact that we had used 5 cell phones on a single computer, the best solution was to order 5 USB cables. +Konrad bought 5 cables for 5 Siemens S55 cell phones. All of the cables have an USB2Serial chip converter inside of them. +Once they were plugged into the USB port, Ubuntu automatically recognized the cables and installed the drivers. +The virtual serial ports were created and could be found on \emph{/dev/ttyUSBx}, where $x$ is the automatically assigned number for the port. +Some of the cables had the capability to charge the Siemens S55 phones. +Konrad had opened several cables to solder the power supplies to some contacts and the problem was solved for all of the cables. +\subsection{Server} +We were given an old Pentium 3 computer where we installed Ubuntu Linux. Configured the Apache web server and MySQL. +Afterwards we installed the Python on it and all the required libraries\footnote{Required libraries are mentioned in section 9.1.}. +\clearpage + +\section{Communication protocol} +A communication protocol represents a set of well defined rules by whose help two or more computing systems exchange information inbetween. +When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate +response from the other side. Our approch to this problem was to build a simple synchronous protocol, where every expected message is +confirmed or otherwise the connection between two sides is immediatelly terminated. Since designing protocols is a demanding and challenging +topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum +protocol\footnote{Design concepts and paradigms for the protocol design have been used from the +``Network Protocol Design and Evaluation'' course, lectured by Dr. Stefan R\"{u}hrup}. +In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works, +it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device +that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software +controlling the handler side and assigning the task to it. + +\subsection{Communication between the handler and controller} +The handler side is always in the waiting mode, by waiting we denote the mode where the socket is already created and it is waiting +for a connection to be accepted at the defined port. The controller initiates a socket connection to the two handlers. +Subsequently, after the connection has been established, it is waiting for a message to be received. The first message +has to be 13 characters long and include the following content \emph{HELLO HANDLER}. Thereupon, after the message has +been validated, the handler side sends the controller side a response, \emph{HELLO CONTROLLER}. +We call this first message exchange the initialization. Now the controller side has to decide which of the two handler's +will be the caller/callee whereas the other handler will be the opposite. Let's assume the controller sends to the first +handler the message \emph{RECEIVER} and to the second one the message \emph{CALLER|\#}, replace the callee number with the \# sign. +In the meantime, both handlers initialize the software required to make the call and to receive the call. Asynchronously they +respond back to the controller their successful initialization. The successful initialization is reported by sending \emph{RECEIVER READY} +and \emph{CALLER READY}. After receiving the mentioned messages, the controller first sends the callee handler the +message \emph{RECEIVE START} and then to the caller handler, the message \emph{CALLER START}. As a result of these messages, +the handlers enter the receiving, respectively calling state. In the given states two timeout timers gets activated. +These timers are responsible for the case if the physical connection between the callee and the caller are not successfully +established or terminated\footnote{The client and server classes responsible for the communication have timeout timers as well +for the case if the connection between the controller and handlers are broken.}. Afterwards, depending if the physical connection +between the handlers (i.e. the callee and the caller) was successfully established or not, the handlers report their +coresponding state with a message to the controller. The message is of the form \emph{CALL OK}, meaning the handler successfully +established a physical connection with the other handler, or of the form \emph{CALL NOT OK}, meaning a physical connection was +not successfully established on the given handler. The controller considers only a test successful if both handlers report +with \emph{CALL OK}. The test software ends the established connection with the handlers by sending them the \emph{TERMINATE CONNECTION} +command. After the handlers have terminated the connection, they enter the waiting for a new connection state and the process starts +from begining again. If the states are not entered in the specified order the connection is immediatelly terminated and +the state machine is in the waiting for a new connection state\footnote{It cannot be seen in the protocol flowchart but one should +keep in mind it works like a well defined state machine.}. + +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{protocolCommunicationHandler.png} + \caption[]{Flowchart of the protocol on the handler side without the state representation} +\end{figure} +\end{center} +\end{landscape} + + + +\begin{figure}[ht!] + \centering + \includegraphics[width=147mm]{protocolCommunicationcControllerReceiver.png} + \caption[]{Flowchart of the protocol on the controller side for the caller without the state representation} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=147mm]{protocolCommunicationcControllerCaller.png} + \caption[]{Flowchart of the protocol on the controller side for the receiver without the state representation} +\end{figure} + +\subsection{Verification of the protocol} +``SPIN is a model checker - a software tool for verifying models of physical +systems, in particular, computerized systems. First, a model is written that +describes the behavior of the system; then, correctness properties that express +requirements on the system's behavior are specified; finally, the model +checker is run to check if the correctness properties hold for the model, and, +if not, to provide a counterexample: a computation that does not satisfy a +correctness property.'' \cite{spin}. We modeled our simple protocol in SPIN using +the programming language PROMELA \cite{spin}. Since PROMELA is similar to C it was +not possible to ensure 100\% matching with Python but we had made the assumptions of it. +We modeled both sides, server and client side. As well as the server side being a caller +and a callee. It was important to find out if our protocol is deadlock or delayed state free. +For more details our model can be found on our wiki project page with the PROMELA source code \cite{wiki}. +We had built in a 50\% random probability that the call test will not be successful, to make the model even more +realistic. Our protocol idea was deadlock free and the verification results prove it. +After we had modeled the basic idea we had written the code that implements our idea. The Python code +resembles some kind of a state machine which remembers the last state and what the next state should be in case +of receiving corresponding message. Otherwise it enters the exit state and then the start state. + +\begin{lstlisting} +(Spin Version 6.1.0 -- 2 May 2011) + + Partial Order Reduction +Full statespace search for: + never claim - (none specified) + assertion violations + + cycle checks - (disabled by -DSAFETY) + invalid end states + +State-vector 44 byte, depth reached 65, errors: 0 + 40 states, stored + 3 states, matched + 43 transitions (= stored+matched) + 90 atomic steps +hash conflicts: 0 (resolved) + 2.195 memory usage (Mbyte) +unreached in proctype Server1 + (0 of 36 states) +unreached in proctype Server2 + (0 of 36 states) +unreached in proctype Client + (0 of 67 states) +pan: elapsed time 0 seconds +\end{lstlisting} + +\clearpage +\newpage + + +\section{Security and safety of the system} +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 +(e.g. assume the University alarm system uses the SIP gateway to connect to the outside world and to alarm the police, if one knows that the SIP gateway is not working properly, a burglar could plan to rob the University building just at that moment). Therefore the choice to go Open Source is justified due to the fact that one should know how every single detail of the system works. +All the time, while we were working on the project, we were made aware of this issue by Denis and Konrad. +We decided to use asymmetric key cryptography, where each side has two keys (private and public). In the next sections we will explain in more details how we applied the methods. +\subsection{Encryption of the communication channels} +At first we thought to encrypt the data before sending them but since none of us was an expert on encryption standards the idea was rejected. Alongside the fact that none of us had been an expert in the field of cryptography, we were neither experts in the field of Internet programming. One could find maybe a way to disable our server software with various hacking methods (e.g. +trying to open the port until the system runs out of memory and in our case the system which we used on the handler side was a BeagleBoard with ARM architecture running on a single chip TI OMAP processor, refer to the picture in figure). +We had to eliminate even the slightest possible threat in return for spending more time for debugging the test software system. Despite we were aware of all these facts, we had to choose one of the plenty implemented encryption standards on Linux. +Denis and Konrad suggested using the SSH Tunneling method. + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{sshTunnel.png} + \caption[]{SSH Tunnel, all the communication inside the tunnel is encrypted } +\end{figure} + +Using the SSH Tunnel port forwarding method we could hide the real port we had used for our socket connection. On the other hand we could force the socket to accept only local connections (i.e. from the machine where the handler software was running). +The SSH Tunnel port forwarding method creates an encrypted tunnel between the two computers and then it creates two ports, one on the local and remote computer. All the data sent through the port on the local machine appear on the port at the remote machine. \newline The first problem we faced was that SSH required the username and password every time we tried to make an SSH connection. We could avoid this problem by copying the public key from our server (where our test software runs) to the BeagleBoard \cite{sshTunnel}. +This can be performed by executing the following commands in the terminal shell. +One has to create first the private and public keys on the local machine(i.e. server computer, where the test software runs): + +\begin{lstlisting} +refik@ubuntu:$ [Note: You are on local-host here] + +refik@ubuntu:$ ssh-keygen +Generating public/private rsa key pair. +Enter file in which to save the key (/home/refik/.ssh/id_rsa):[Enter key] +Enter passphrase (empty for no passphrase): [Press enter key] +Enter same passphrase again: [Press enter key] +Your identification has been saved in /home/refik/.ssh/id_rsa. +Your public key has been saved in /home/refik/.ssh/id_rsa.pub. +The key fingerprint is: +33:b3:fe:af:95:95:18:11:31:d5:de:96:2f:f2:35:f9 refik@ubuntu +\end{lstlisting} + +Then one needs to copy the public key to the remote machine (BeagleBoard) using ssh-copy-id: + +\begin{lstlisting} +refik@ubuntu:$ ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host +refik@remote-host's password: +Now try logging into the machine, with "ssh 'remote-host'", and check in: + +.ssh/authorized_keys + +to make sure we haven't added extra keys that you weren't expecting. +\end{lstlisting} + +After we have created the public and private keys, and coppied the public key on the machine to which we want to connect, we can test if we can make an SSH connection to the remote machine: + +\begin{lstlisting} +refik@ubuntu:$ ssh remote-host +[Note: SSH did not ask for password.] + +refik@remote-host:$ [Note: You are on remote-host here] +\end{lstlisting} +The test was successful. We tested it with our SSH Tunnel port forwarding class and it worked perfectly. +\subsection{Security on the web site} +Aside from having secured the data communication channels between various parts of our software +(the handlers and the controller), it was crucial to ensure all the communication between +test user's browser and our server. Therefore we had used the \emph{https} protocol and +the \emph{.htaccess} file to password protect the web site so only the privileged users +have access to our test system. +\subsubsection{Configuring the http secure protocol https} +Securing the communication channels without making certain the web site is safe would be worthless. +We decided to use the \emph{https} protocol instead of the \emph{http} since a person in the middle +could sniff our data (e.g. a person is connected with his/her smart-phone over an unprotected wireless network) \cite{https}. +At the same time the web site should be accessible only by the authorized personel. Our first approach to this +problem was to build an PHP page with \emph{MD5} hashed passwords, however we got a suggestion by Konrad and Denis to +use a safer encryption method implemented in the Apache web server software, \emph{.htaccess}. By using +these two techniques we protected the web site of some vulnerabilities known to us. If the web site +will be only accessed from our local university network, we can additionally add an IP filter mask as well. +In the following paragraph we will explain our procedure how to generate the keys and to enable the https protocol. +\par First we want to generate a server key by typing the following command: +\begin{lstlisting} +openssl genrsa -des3 -out server.key 4096 +\end{lstlisting} +\par This will generate a 4096 bit long private server key, one is asked to enter two times a password for the \emph{server.key}. +Using the generated private server key, we will create a certificate signing request, \emph{server.csr}. We were prompted with a series of questions +like country, state, organization name and etc which we had to enter to resume. +\begin{lstlisting} +openssl req -new -key server.key -out server.csr +\end{lstlisting} +\par In the next step we had to sign the certificate signing request and enter the amount of days for how long it should be valid. +In our case we entered the duration of one year, one can make it for longer periods as well (i.e. the amount of 365 has to be changed). +\begin{lstlisting} +openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt +\end{lstlisting} +\par We were asked to enter the password again for \emph{server.key}. After we have completed this step we had to make +a version of the \emph{server.key} which did not require a password, \emph{server.key.insecure} and we will rename the files appropriately. +\begin{lstlisting} +openssl rsa -in server.key -out server.key.insecure +mv server.key server.key.secure +mv server.key.insecure server.key +\end{lstlisting} +\par The generated files are very sensitive, since they are our keys. After these steps were completed, we had generated 4 files: \emph{server.crt}, \emph{server.csr}, \emph{server.key} and \\ \emph{server.key.secure}. Now we need to enable the SSL engine on the Apache web server. +We coppied \emph{server.key} and \emph{server.crt} into \emph{/etc/appache2/ssl}. +\begin{lstlisting} +refik@ubuntu:/etc/apache2$ sudo mkdir ssl +cp server.key /etc/apache2/ssl +cp server.crt /etc/apache2/ssl +\end{lstlisting} +\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. +See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates. +Run '/etc/init.d/apache2 restart' to activate new configuration! +\end{lstlisting} +\par In the next procedure we had to establish a symlink from the 'available' default-ssl file to the 'enabled' file \cite{https}. Then we created a folder where our secured PHP files will be located (e.g. https://some-domain-name.com/test-software). +\begin{lstlisting} +refik@ubuntu:/etc/apache2/ssl$ sudo ln -s /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/000-default-ssl +refik@ubuntu:/etc/apache2/ssl$ cd /var/ +refik@ubuntu:/var$ sudo mkdir www-ssl +\end{lstlisting} +\par We had backed up our old configuration files for the virtual hosts, for the case if we damage the Apache configuration files. Then we edited the \emph{default-ssl} file. +\begin{lstlisting} +refik@ubuntu:/var$ cd /etc/apache2/sites-available +refik@ubuntu:/etc/apache2/sites-available$ sudo cp default default_original +refik@ubuntu:/etc/apache2/sites-available$ sudo cp default-ssl default-ssl_original +refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl +\end{lstlisting} +\par Only the beginning of the file is listed here and we have modified the line starting with \emph{DocumentRoot} +and \emph{} from \emph{DocumentRoot /var/www} to \emph{DocumentRoot /var/www-ssl} +and from \emph{} to \emph{} +(i.e. we had to redefine the location of our SSL directory). +\begin{lstlisting} + + + ServerAdmin webmaster@localhost + + DocumentRoot /var/www-ssl + + Options FollowSymLinks + AllowOverride None + + + Options Indexes FollowSymLinks MultiViews + AllowOverride None + Order allow,deny + allow from all + +\end{lstlisting} +\par One should keep in mind that the port 443 should be free for Apache to use it. In the proceeding step we had to ensure that Apache listens on the given port for a \emph{https} connection. +One could test that by going into the \emph{/etc/apache2/ports.conf}. +\begin{lstlisting} + + # If you add NameVirtualHost *:443 here, you will also have to change + # the VirtualHost statement in /etc/apache2/sites-available/default-ssl + # to + # Server Name Indication for SSL named virtual hosts is currently not + # supported by MSIE on Windows XP. + Listen 443 + +\end{lstlisting} +\par In our case it was set up correctly, since the command: \emph{Listen 443} was present. +In our last configuration step we had to edit \emph{default-ssl} file to define the correct locations of our keys and to ensure the SSL engine was turned on. +\begin{lstlisting} +refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl +\end{lstlisting} +\par The following part of the file had to be found and modified according to our locations: +\begin{lstlisting} +SSLEngine on + + # A self-signed (snakeoil) certificate can be created by installing + # the ssl-cert package. See + # /usr/share/doc/apache2.2-common/README.Debian.gz for more info. + # If both key and certificate are stored in the same file, only the + # SSLCertificateFile directive is needed. + SSLCertificateFile /etc/apache2/ssl/server.crt + SSLCertificateKeyFile /etc/apache2/ssl/server.key + + # Server Certificate Chain: + # Point SSLCertificateChainFile at a file containing the +\end{lstlisting} +\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 + ... waiting [Sat Oct 08 21:52:52 2011] [warn] _default_ VirtualHost overlap on port 443, the first has precedence [ OK ] +refik@ubuntu:/etc/apache2/sites-available$ +\end{lstlisting} +\subsubsection{Password protecting the web site using .htaccess} +Aside from using a secure communication protocol on the web, \emph{https}, it is important +to ensure that only permissioned users gain access to the web site. We had achieved it using +the \emph{.htaccess} file. However, to enable the use of Apache \emph{.htaccess} files, +we will have to reconfigure the Apache configuration files again. \emph{root} access will +be required. First we have to edit the \emph{/etc/apache2/sites-available/default-ssl} file. +Find the following lines and modify the \emph{AllowOverride None} to \emph{AllowOverride All} +like in the given configuration segment: +\begin{lstlisting} + + Options Indexes FollowSymLinks MultiViews + AllowOverride All + Order allow,deny + allow from all + +\end{lstlisting} +This will tell Apache web server that it is okay to allow \emph{.htaccess} files +to over-ride previous directives. We must reload the Apache web server before the +changes can take effect. We can do it by typing: +\begin{lstlisting} +sudo /etc/init.d/apache2 reload +\end{lstlisting} +The next step is to go to the directory where our test software web page is located +(e.g. \emph{/var/www-ssl/testsoftware}) and to create a file called \emph{.htaccess}. +Please insert the following code segment inside the created \emph{.htaccess} file where +\emph{/var/www-ssl/testsoftware/.htpasswd} is your full path address to \emph{.htpasswd}: +\begin{lstlisting} +AuthUserFile /var/www-ssl/testsoftware/.htpasswd +AuthName "Authorization Required" +AuthType Basic +require valid-user +\end{lstlisting} +Then in the next step, create another file called \emph{.htpasswd}. After you have created it, +we will add the usernames that should have access to the web site. We do that by typing the +following command, where you can replace \emph{konrad} with any other combination of letters +which will represent your username: +\begin{lstlisting} +refik@ubuntu:/var/www-ssl/testsoftware$ sudo htpasswd -c .htpasswd konrad +\end{lstlisting} +Afterwards, you will be required to type twice the same password for the username +you want to create, in this case \emph{konrad}. ``The -c flag is used only when you +are creating a new file. After the first time, you will omit the -c flag, +when you are adding new users to an already-existing password file. Otherwise you +will overwrite the file!'' \cite{htaccess}. You can add as many users as you wish, +do not forget to remove the -c flag when you do it. +In the last step, we have to modify the \emph{/etc/apache2/apache2.conf} file and +to add at the end of it the following code segment where \emph{/vaw/www-ssl/testsoftware} +is the full path to your web page directory where you put the \emph{.htpasswd} file: +\begin{lstlisting} + +AllowOverride All + +\end{lstlisting} +We are done with editing. All we have to do now is to restart the Apache web server. We +can do that by typing: +\begin{lstlisting} +sudo /etc/init.d/apache2 restart +\end{lstlisting} +You can test it now by opening a new browser tab and navigating to \emph{https://localhost/\\testsoftware} +(keep in mind to replace \emph{testsoftware} with your name of the folder where the web page +is located). If you configured everything properly, you should get a dialog where you can +enter your created username and password and try to login. + +\newpage +\section{Web page} +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 as 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=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{Employing the test software system} +In this section the reader can find out how to install and how to use the test system. +Our goal was to make a multiplatform test software, however we tested it only under Ubuntu +11.04 32 bit Linux OS and the given instruction manual is only tested under that OS. The +test software performed well, both on PC and MAC computers. +One should keep in mind that some of the libraries we had used do not work +under the 64 bit version of Linux OS. + +\subsection{Required software and libraries} +In the next subsections, we will guide you how to install all the required software and +libraries to flawlessly run our test software on your employed server. +You will be required to have \emph{root} access privileges and to open a new +terminal window where the commands will be typed in. + +\subsubsection{Python installation} +Python was our programming language of choice\footnote{We had explained earlier why we +have decided to use Python.}. The required version of Python is 2.7. One can easily +install python by typing the following commands: +\begin{lstlisting} +sudo apt-get update +sudo apt-get install python2.7 +\end{lstlisting} +It will take a short amount of time to be installed. You will be required to enter +the \emph{root} password. + +\subsubsection{Apache Web server installation} +We had decided to use the Apache web server because of its wide support on the internet +and safety reasons. If there are any bugs or security flaws, the patches are +easily installed with the Ubuntu update manager. The Apache web server can be easily +installed by typing the following command: +\begin{lstlisting} +sudo apt-get install apache2 +\end{lstlisting} +You might be required to follow other installation instructions printed on the +terminal screen. +After the installation has completed successfully, one can test if it works by going +to the following web address: \emph{http://localhost}. For configuring the \emph{https} +please go to the section 7.2. + +\subsubsection{SSH} +Secure Shell (SSH) is a network protocol for secure data communication between two +computers inside of a network. All computers are required to have SSH installed on it. +You can easily install it by typing the following command: +\begin{lstlisting} +sudo apt-get install ssh +\end{lstlisting} + +\subsubsection{MySQL database and MySQLdb library} +The MySQLdb library is required to perform various operations on the MySQL database within +Python. We used the MySQLdb library instead of the native MySQL C API \emph{\_mysql} library +to make the code cleaner and more portable. +We suggest you to install first the MySQL database on the server computer. If you +have installed MySQL you can skip the next part. To star the installation process one can +type the following commands: +\begin{lstlisting} +sudo apt-get install mysql-server +\end{lstlisting} +You will be required to enter the Linux \emph{root} password. At some point during +the installation process, you will be required to enter the password for the MySQL +database. After you have performed the above step, we can proceed with the +MySQLdb library installation. By typing: +\begin{lstlisting} +sudo apt-get install python-mysqldb +\end{lstlisting} +If the \emph{python-mysqldb} name has changed, one can easily find the correct name of the +file by issuing the following command: +\begin{lstlisting} +apt-cache search MySQLdb +\end{lstlisting} +By typing in the commands given above, you should have successfully installed the MySQLdb +library. + +\subsubsection{Serial port library} +The serial port library is required for the cell phones to communicate with the +server computer and the BeagleBoards. The required library for Python can be installed +by typing the following command: +\begin{lstlisting} +sudo apt-get install python-serial +\end{lstlisting} +The installation should not produce any errors or warnings. + +\subsubsection{PJSUA library} +\emph{PJSUA} is an open source command line SIP user agent (softphone). We use the library +for the SIP handler. First, one needs to download the library +from \url{http://www.pjsip.org/download.htm} \cite{pjsip}. Then extract it to some folder. +Then we will build the library using make. This can be accomplished by typing the following +commands: +\begin{lstlisting} +cd your-pjsip-root-dir +./configure && make dep && make +cd pjsip-apps/src/python +sudo make +\end{lstlisting} + +If you get an error similar to this one: +\begin{lstlisting} +_pjsua.h:25:20: fatal error: Python.h: No such file or directory +compilation terminated. +error: command 'gcc' failed with exit status 1 +\end{lstlisting} +Then you will be required to install python-dev as well, that matches your version of +python (e.g. python2.7-dev). You can do it by typing: +\begin{lstlisting} +sudo apt-get install python2.7-dev +\end{lstlisting} +After you have successfully installed python2.7-dev, repeat the the commands given above. +Now you should have a properly installed PJSUA library. One can easily test if the installation +was successful by copiling a simple python code, \emph{python test.py}, with the following +source code: +\begin{lstlisting} +import pjsua +\end{lstlisting} +If you do not get any errors, you have successfully installed the library. More detail can +be found on our project wiki page \cite{wiki}. + +\subsubsection{pChart library} +The pChart library is within our installation files and does not require to be installed +individually. The library is only required if one uses the web interface and +requires the generated resulting image. The library is open source and does not require +any licensing. However, if one needs to learn how the library works, +information can be found on the pChart web page \cite{pChart}. + +\subsubsection{proctitle library} +We had used this library to rename the currently executed process name. +``The library allows a process to change its title (as displayed by system +tools such as ps and top). Changing the title is mostly useful in +multi-process systems, for example when a master process is forked: +changing the children's title allows to identify the task each process is +busy with.'' \cite{proctitle}. The library can be easily installed by typing: +\begin{lstlisting} +sudo easy_install setproctitle +\end{lstlisting} + + +\subsection{Configuring hardware} +Before proceeding with the next steps, please connect all the cell phones +to the USB hub using the suitable cables. Then make sure the cables are +recognized by the operating system. This can be performed by typing the following command: +\begin{lstlisting} +dmesg | grep ttyU +\end{lstlisting} +The given command should produce a result similar to: +\begin{lstlisting} +[ 5178.753600] usb 1-1.2: pl2303 converter now attached to ttyUSB0 +\end{lstlisting} + +We have two different ways to configure the cell phones, manually and automatic. +Both options can be accessed either using the website or the terminal window. +Using the manual configuration from the terminal, the user configures everything him/herself. +The user will be presented with a few questions like the port address, cell phone number and IMEI. +After the user enters all the required parameters, the software will check +if the given port address is accessible and it will look for a response from the devices. +Then you will be asked to enter the IMEI and the cell phone number of the device. +If the entered IMEI matches the device IMEI then the software will update the database +with the entered information. You can run, both the manual and automatic configuration +by typing: +\begin{lstlisting} +python gsmselftest.py --devconf +\end{lstlisting} +In the automatic configuration, the software will automatically try to detect every +cell phone that is connected to the USB hub. This configuration option can detect +up to nine cell phones, that are connected to the server computer. We had set a limit to +nine cell phones because we required only five (four for the external GSM networks +and one for our internal GSM BST). The only limitation of the automatic cell phone congiguration +is that it only supports cell phones where we could read out the number using the \emph{AT Modem} +commands since some cell phone manufacturers do not use the standardized \emph{AT Modem} commands. +\subsection{Location of the files} +For proper operation of the software, it is important that each file is at its correct path +located. In the given section you can find out the correct path locations. +If you are not an expert, please do not change these locations. +The following files have to be located in the \emph{/var/www-ssl/testsoftware/} folder: +\begin{lstlisting} +drwxr-xr-x 7 root root 4096 2011-10-28 12:45 . +drwxr-xr-x 3 root root 4096 2011-10-20 17:06 .. +-rw-r--r-- 1 root root 109 2011-10-26 16:55 .htaccess +-rw-r--r-- 1 root root 20 2011-10-26 17:11 .htpasswd +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 class +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 css +-rw-r--r-- 1 root root 7547 2011-10-20 17:06 delayedLoading.js +-rw-r--r-- 1 root root 3431 2011-10-25 14:38 devconf.html +-rw-r--r-- 1 root root 2024 2011-10-25 23:47 devconfigAuto.php +-rw-r--r-- 1 root root 1811 2011-10-26 13:44 devconfigManual.php +-rw-r--r-- 1 root root 2195 2011-10-25 23:45 devconfig.php +-rw-r--r-- 1 root root 3526 2011-10-27 14:51 devconf.php +-rwxr-xr-x 1 root root 725 2011-10-20 17:06 execute.php +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 fonts +-rw-r--r-- 1 root root 2259 2011-10-28 12:43 index.html +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 icons +drwxr-xr-x 2 root root 4096 2011-10-25 14:10 Images +-rw-r--r-- 1 root root 2038 2011-10-20 17:06 insertData.php +-rw-r--r-- 1 root root 636 2011-10-26 13:43 insertdevice.php +-rw-r--r-- 1 root root 10819 2011-10-20 17:06 loader.gif +-rw-r--r-- 1 root root 2268 2011-10-26 16:07 main.php +-rw-r--r-- 1 root root 5416 2011-10-20 17:06 moocheck.js +-rw-r--r-- 1 root root 75836 2011-10-20 17:06 mootools.js +-rw-r--r-- 1 root root 677 2011-10-20 17:06 mutexFunctions.php +-rw-r--r-- 1 root root 9063 2011-10-25 17:20 mutexSmartTest.php +-rwxr-xr-x 1 root root 9143 2011-10-28 12:45 mutexTry.php +-rw-r--r-- 1 root root 13304 2011-10-20 17:06 networkResult.php +-rw-r--r-- 1 root root 8294 2011-10-21 19:02 post.php +-rw-r--r-- 1 root root 19218 2011-10-21 17:36 startTest2.php +-rw-r--r-- 1 root root 18852 2011-10-20 17:06 startTest.php +-rw-r--r-- 1 root root 18787 2011-10-25 16:43 TaskTest.html +-rw-r--r-- 1 root root 3685 2011-10-20 17:06 testCase.php +-rw-r--r-- 1 root root 2545 2011-10-20 17:06 wait.gif +\end{lstlisting} +The \emph{startSoftware.py} file is required to be in the \emph{/etc/init.d/} folder, +since it is required to be start with the computer boot however if that does not work, +one should start it manually. This part of the software is +responsible for starting the testing software from the web page\footnote{The web page +communicates with this script via a socket connection and sends a signal to start +the main test software.}. +The main test software python files should be located in \emph{/home/gsmselftest/SoftwareTesting/}. +\begin{lstlisting} +drwxr-xr-x 2 gsmselftest gsmselftest 4096 2011-11-03 14:29 . +drwxr-xr-x 30 gsmselftest gsmselftest 4096 2011-11-02 18:28 .. +-rwxr--r-- 1 gsmselftest gsmselftest 2909 2011-10-20 17:54 ClientClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 3628 2011-10-20 17:54 ClientClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 9814 2011-11-02 16:19 ControllerClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 9247 2011-11-02 16:20 ControllerClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 15129 2011-11-02 15:32 DbClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 11712 2011-11-02 15:32 DbClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 8512 2011-11-02 13:30 GSMClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 7337 2011-11-02 13:42 GSMClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 8063 2011-11-02 13:24 GSMHandler.py +-rwxr-xr-x 1 gsmselftest gsmselftest 20346 2011-11-02 18:32 gsmselftest.py +-rwxr--r-- 1 gsmselftest gsmselftest 698 2011-11-02 18:36 help.txt +-rwxr-xr-x 1 gsmselftest gsmselftest 8661 2011-11-02 16:35 initTestClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 7497 2011-11-02 16:37 initTestClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 645 2011-10-20 17:54 LogFileClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1509 2011-10-20 17:54 LogFileClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 817 2011-10-20 17:54 PingClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1263 2011-10-20 17:54 PingClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 3982 2011-10-20 17:54 ServerClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 4596 2011-10-20 17:57 ServerClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 4129 2011-10-20 23:17 ServerClassSoftware.py +-rw-r--r-- 1 gsmselftest gsmselftest 4802 2011-10-20 23:17 ServerClassSoftware.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 5252 2011-10-22 03:58 SIPHandler.py +-rwxr--r-- 1 gsmselftest gsmselftest 1267 2011-11-02 14:07 SSHTunnelBoxClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1852 2011-11-02 14:19 SSHTunnelBoxClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 323 2011-11-02 18:44 startSoftware.py +-rwxr-xr-x 1 gsmselftest gsmselftest 6378 2011-11-02 16:13 trueTableClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 4583 2011-11-02 16:16 trueTableClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 2248 2011-10-28 14:04 usbDetectClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 3590 2011-10-28 14:05 usbDetectClass.pyc +\end{lstlisting} + +\subsection{Setting up the parameters} +After configuring the hardware, \emph{https} and \emph{.htaccess} on the web server, +it is important to modify the files for proper operations. In the given section you +can find out how to configure the rest of the files (e.g. database passwords, etc.). +The following files you have to modify to have a working database access: +\emph{initTestClass.py, GsmSelfTest.py, UsbDetectClass.py} and \emph{truthtableClass.py}. +\subsection{Test descriptions} +In the following section we will describe the tests that can be performed and what kind +of problems they can identify. There are five types of tests: +\begin{itemize} +\item Smart test +\item SIP test +\item GSM test +\item Everything test +\item Manual test +\end{itemize} +Each test will be described in the next subsections. +\subsubsection{Smart test} +\par The \emph{smart} test is not called smart without a reason. It tries automatically to identify +problems inside of the telecommunication network. The user is not required to define what kind +of tests have to be performed. In the first part the test software communicates with the +database to see what systems are available. In the next step it performs a call from the +University telephone system to a random local cell phone\footnote{Local cell phone or +local GSM network means our University GSM Network or RZ GSM.} +inside of our University GSM network. +While executing this task, automatically the Asterisk server, OpenBSC and a random nanoBTS +(or the one cell phone in RZ) are tested. The next task to be performed in the smart test, +a randomly selected cell phone inside of our local GSM network will try to call: a random +cell phone within the external (O2, Vodaphone,E-Plus or T-Mobile) or local GSM network. +This might test the external network and will test it with high probability, however the +probability exists to make a local to local GSM test call. In the third task, we perform +a test where we call from the landline a random cell phone inside of our local GSM network. +In the fourth or last task, we call from SIP to the service we did not test yet (e.g. +if we did not test the external GSM network using the second test task, then in this last +task we will exploit it). After the smart test had been completed you will be presented +with the results. +\subsubsection{SIP test} +The \emph{SIP} test option will perform test in such a way that all the SIP subsystems are +tested (SIP and University telephone network). It will try to identify if there are any +problems on the Asterisk server and our University telephone network, including incoming and +outgoing calls from the SIP side. +\subsubsection{GSM test} +In the \emph{GSM} test both GSM networks get tested, the local and the external GSM netwrok. +We test the nanoBTS controller boxes (i.e. BeagleBoards) as well. Using this test, both incoming +and outgoing calls are performed, we can detect possible errors on the OpenBSC and the nanoBTS. +\subsubsection{All test} +The \emph{All} test selects all the given tests and executes them step-by-step. It is the test +that takes the greatest amount of time. While the test are performed, results are +immediatelly printed in the terminal window or on the web site. +\subsubsection{Manual test} +The \emph{Manual} test as the name itself says, is the test where you can manually select +what kind of tests you want to be performed. +\subsection{Result descriptions} +In the following table one can see the messages returned by the test software! +These messages should guide the test user operator to debug the system. + +\begin{table}[h]\footnotesize + \begin{center} + %\caption[]{Table of error descriptions} + \begin{tabular}{| l | c | l | } + \hline + \textbf{Number} & \textbf{Code} & \textbf{Code number description} \\ \hline + 1 & 200 & Call was OK \\ \hline + 2 & 604 & General Handler Error: Destination handler did not respond. Timeout \\ \hline + 3 & 998 & General Handler Error: Could not connect to the destination handler! \\ \hline + 4 & 605 & General Handler Error: Caller handler did not respond. Timeout \\ \hline + 5 & 999 & General Handler Error: Could not connect to the caller handler! \\ \hline + 6 & 486 & Call Failed \\ \hline + 7 & 333 & Could not establish a connection to the database! \\ \hline + 8 & 100 & Missing account detail \\ \hline + 9 & 402 & Payment Required (E-Plus Card) \\ \hline + %\hline + + \end{tabular} + \end{center} +\end{table} + +\subsection{Using the software} +In this section, you will be taught step by step how to use our test software. There are two options to run our test software, from the web site or the terminal. +The first is easier, but the second is easy as well however requires terminal skills. + +\subsubsection{Web site guide} +Once you enter the address in the address bar of your browser (e.g. \emph{https://localhost/\\testsoftware}). +You will be required to enter your username and password for the web page\footnote{The username and password creation process is explained in section 7.2.2.}. +If you entered the correct username and password you should see the same image as in the following figure. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{website1.png} + \caption[]{Web page of test software} +\end{figure} +Here you can choose what kind of test you want to perform or maybe if you want to configure the devices (manually or automatically). +If you press the ``Smart test'' button, you have to wait a few moments and the results should appear in a short amount of time. +However, if you pressed the ``Choose the test'' button, you will be presented with a new page, given in figure 25. +You will have to select the tests you want to perform manually or to press on the left side one of the given buttons for different +tests. You can choose between ``SIP Test'', ``GSM Test'', ``Check all'' and ``Uncheck all''. ``Check all'' will select all the possible +tests, whereas ``Uncheck all'' will deselect all of them. After you finished the procedure of selecting the tests, you should press the +``Submit'' on the left side. Wait a few moments and the results will start to appear in real time. After the table on the left is filled +(i.e. after all the tests have been completed) a result image will be generated on the right side, can be seen in figure 26. However, if +your pressed the ``Device configuration'' button, then you will end up on a page as given in figure 27. + +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{website2.png} + \caption[]{Manually selecting the tests} +\end{figure} + +If you press the ``Automatic configuration'' button, the test software will try automatically to match your cell phones with +their port addresses and numbers. However, if the automatical matching does not work, you will have to manually configure it. +You can do it by entering all the required information on the web site, as in figure 28. Once you correctly filled in the required +information, you should press the ``Submit'' button. + +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{webpageReport.png} + \caption[]{Result web page} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{website3.png} + \caption[]{Device configuration web page} +\end{figure} + +\begin{figure}[!t] + \centering + \includegraphics[width=140mm]{website4.png} + \caption[]{Manual device configuration page} +\end{figure} + + +\subsubsection{Terminal guide} +In the following text, we will guide you and show you step-by-step how to use the test software from the terminal. All you have to +do is just type the command for starting the test software in the folder where it is located, \emph{./gsmselftest.py ---option} (keep +in mind there are two dashes before \emph{option}). +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{terminalCommand.png} + \caption[]{Test software terminal options} +\end{figure} +You can perform the tests manually by typing what you want to test or by choosing one of the predefined tests. For example, you +want to test manually does the SIP work with the University telephone network, you would type the following: \emph{./gsmselftest.py --db sip unisip}. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{resultterminal.png} + \caption[]{Example results from the terminal screen} +\end{figure} +After the tests have been performed the results will be displayed. Green result text means the test was performed successfully and red result +text means that something is not working properly. + +If you need to configure the cell phones manually or automatically, you can do it by typing: \emph{./gsmselftest.py --devconf} (keep +in mind there are two dashes before \emph{devconf}). Then you can press ``a'' on the keyboard for automatic configuration or ``m'' for +manual configuration. One should keep in mind that the terminal test software can be started even through \emph{ssh}, however with an +additional command \emph{-X}\footnote{For example: ssh -X username@address}. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{devconf.png} + \caption[]{Test software device configuration from terminal screen} +\end{figure} + +\clearpage +\newpage +\section{Conclusion} +As a result of our successfully finished team project, we had felt how it is to work +in a team. We had learnt how to confront various sofware and hardware issues. The problems +were broken into smaller fragments and the solutions were derived in a step-by-step approach. +\par While designing the software, we kept in mind that every single step should be well thought-out, +documented, tested and validated. At the end we joined all the ``black-boxes'' together +into one big piece of software. We fulfilled our stated requirements and goals. +\par Despite the fact that our test software will be used by well educated engineers, we may +conclude that all the way along we thought about the usage-simplicity, safety and security +of our product. Our team members were enthusiastic about the idea that our team project will +contribute to a better perferomance and quality of the overall telecommunication network, +for all of the University staff and our colleagues, the students. +\newpage + + + +%bibliography start +\begin{thebibliography}{9} + +\bibitem{network} \emph{Projects based on RZ-GSM}, accessed on 10.06.2011, available at +\url{http://lab.ks.uni-freiburg.de/projects/gsm/wiki}. + +\bibitem{python} \emph{Python Programming Language - Official Website}, accessed on 10.06.2011, available at +\url{http://www.python.org/}. + +\bibitem{mysqlManual} \emph{MySQLdb User's Guide}, accessed on 05.06.2011, available at \\ +\url{http://mysql-python.sourceforge.net/MySQLdb.html}. + +\bibitem{wiki} \emph{[2011] GSM Selftest - Wiki - Lehrstuhl f\"{u}r Kommunikationssysteme}, accessed on 20.09.2011, available at \\ +\url{http://lab.ks.uni-freiburg.de/projects/gsm-selftest/wiki}. + +\bibitem{socket} \emph{17.2. socket - Low-level networking interface}, accessed on 20.06.2011, available at +\url{http://docs.python.org/library/socket.html}. + +\bibitem{spin} M. Ben-Ari \emph{Principles of the Spin Model Checker}, +Springer Verlag, Weizmann Institute of Science, Israel, ISBN: 978-1-84628-769-5, 2008. + +\bibitem{sshTunnel} R. Natarajan, \emph{3 Steps to perform SSH login without password using ssh-keygen \& ssh-copy-id}, accessed on 18.08.2011, available at +\url{http://goo.gl/fX68N}. + +\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{htaccess} \emph{EnablingUseOfApacheHtaccessFiles}, accessed on 18.08.2011, available at +\url{https://help.ubuntu.com/community/EnablingUseOfApacheHtaccessFiles}. + +\bibitem{pChart} \emph{pChart}, accessed on 15.08.2011, available at +\url{http://www.pchart.net/}. + +\bibitem{beagleDataSheet} \emph{BeagleBoard System Reference Manual}, accessed on 20.06.2011, available at +\url{http://beagleboard.org/static/BBSRM_latest.pdf}. + +\bibitem{proctitle} \emph{setproctitle 1.1.2}, accessed on 20.10.2011, available at +\url{http://pypi.python.org/pypi/setproctitle}. + +\bibitem{pjsip} \emph{Open source SIP stack and media stack for presence, im/instant messaging, and multimedia communication}, accessed on 20.10.2011, available at +\url{http://www.pjsip.org/}. + +%bibliography end +\end{thebibliography} + +%end of the document +\end{document} \ No newline at end of file diff --git a/documenting/Report/test.tex~ b/documenting/Report/test.tex~ new file mode 100644 index 0000000..866b72b --- /dev/null +++ b/documenting/Report/test.tex~ @@ -0,0 +1,1397 @@ +\documentclass[a4paper, titlepage, oneside, headsepline, footsepline]{scrartcl} +%PACKAGES +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\usepackage{lscape} %for the landscape pages it is used +\usepackage[english]{babel} %what language are we using +\usepackage[latin2]{inputenc} %what alphabet + +\usepackage[tt]{titlepic} %used for adding the title image +\usepackage{graphicx} %used for adding images +\usepackage{url} %used for the url in bibliography +\usepackage{lastpage} %give me the total number of pages, used in footer: \pageref{LastPage} + +\usepackage[T1]{fontenc} %used for fonts +\usepackage{scrpage2} %used for making headers, footers and correct margins +%\usepackage{hyperref} %used for the linking of table of content + +%information for the PDF +\usepackage[pdftex, %used for adding pdf information + pdfauthor={Refik Hadzialic, Triatmoko}, + pdftitle={Software for self-testing of the Telecommunication network of University of Freiburg}, + pdfsubject={Telecommunication network testing software}, + pdfkeywords={telecommunication;network;networking;linux;ubuntu;university;Freiburg;python;tcp/ip;security;gsm;sip;voip}, + pdfproducer={Latex with hyperref, or other system}, + pdfcreator={pdflatex, or other tool}]{hyperref} %used for the linking of table of content + + + + + +\hypersetup{ %setting up the look of the links + colorlinks, + citecolor=black, + filecolor=black, + linkcolor=black, + urlcolor=black +} + +\usepackage{color} %used for highlighting source code +\usepackage{listings} %used to make a box with source code +\usepackage{fancyvrb} +\DefineVerbatimEnvironment{code}{Verbatim}{fontsize=\small} +\DefineVerbatimEnvironment{example}{Verbatim}{fontsize=\small} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%DEFINE LOOK OF THE PAGES +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\pagestyle{scrheadings} + +\renewenvironment{abstract} + {\begin{center}\large\textbf{}\noindent\end{center}}{\vspace{2\baselineskip}} + +% Disable single lines at the start of a paragraph (Schusterjungen) +\clubpenalty = 10000 +% Disable single lines at the end of a paragraph (Hurenkinder) +\widowpenalty = 10000 \displaywidowpenalty = 10000 + +\setlength{\parskip}{0.01\baselineskip} +\textheight = 620pt + +\ohead{Software for self-testing of the Telecommunication network of University of Freiburg} %make the header +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%DEFINE THE STUFF FOR CODE +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\lstset{ % +%language=Python, % choose the language of the code +columns=fullflexible, +keywordstyle=\color[rgb]{0.608,0.561,0.008}, +commentstyle=\color[rgb]{0.25,0.5,0.35}, +stringstyle=\color[rgb]{0.25,0.35,0.85}, +basicstyle=\footnotesize,%\scriptsize % the size of the fonts that are used for the code +%numbers=left, % where to put the line-numbers +numberstyle=\footnotesize, % the size of the fonts that are used for the line-numbers +stepnumber=1, % the step between two line-numbers. If it is 1 each line will be numbered +numbersep=8pt, % how far the line-numbers are from the code +backgroundcolor=\color{white}, % choose the background color. You must add \usepackage{color} +showspaces=false, % show spaces adding particular underscores +showstringspaces=false, % underline spaces within strings +showtabs=false, % show tabs within strings adding particular underscores +frame=single, % adds a frame around the code +tabsize=2, % sets default tabsize to 2 spaces +captionpos=b, % sets the caption-position to bottom +breaklines=true, % sets automatic line breaking +breakatwhitespace=false, % sets if automatic breaks should only happen at whitespace +escapeinside={\%}{)} % if you want to add a comment within your code +} +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + + +\newcommand{\titleOfProject}{Software For Self-Testing Of The Telecommunication Network Of University Of Freiburg} + + + +%begin of the document +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\begin{document} + + + + +%make the title page +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\titlepic{\includegraphics[width=90mm]{uniLogo2.png}} +\title{Team Project \\ ``\titleOfProject''} % type title between braces +\date{\today} % type date between braces +\author{Refik Had\v{z}iali\'{c}\\ Triatmoko } % type author(s) between braces +\department{\vspace{1\baselineskip} \large Albert-Ludwigs-Universit\"{a}t Freiburg \\ +Lehrstuhl f\"{u}r Komunikationsysteme\\ +Prof. Dr. Gerhard Schneider\\ \vspace{1\baselineskip} Supervisors: \\ Konrad Meier \\ Dennis Wehrle \\ \vspace{1\baselineskip} Sommersemester 2011} + +\maketitle +%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%add the table of contents +\tableofcontents + +%new page to start with +\clearpage + + + + +% first chapter +\section{Introduction and Motivation} % chapter 1 +In the following report, the authors will try to give you a brief insight into our team project. The goal of our project was to develop a mechanism for automatic testing of our University Telecommunication network. The Telecommunication network of University of Freiburg consists of: our own internal GSM and telephone network systems; GSM redirecting device (if one initiates a call to one of the four external GSM networks, it redirects the calls to: T-mobile, 02, Vodaphone or E-Plus); a SIP gateway for land-line calls inside of Germany (sipgate.de) and international calls. Since we did not have access to internal servers, our strategy was to exploit the existing systems from an external perspective and infer the results out of our findings. +Before we had started working on our project, we had to analyze the overall network to come up with the 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. In the following chapters we will describe in more detail our approach to the problem and how each subsystem works. +This particular report and our wiki page should be a sufficient guide and manual for understanding, running and continuing the development of our test software. +Certainly, we had a lot of fun while working on the project due the fact that we lost one team member. +We would like to thank the whole department for the free coffee and their support, especially +Konrad Meier, Dennis Wehrle, Richard M. Zahoransky and Larissa Linz, without their support this project would not +end up this way. +\clearpage +\section{Requirements} % chapter 2 +At the start of the project the requirements were not completely known but as the time had passed we redefined our requirements and goals. +The first and the most important part at the start was to identify the key goals of our team project. The basic goal of our team project was to build a +test software system which could tell an operator user what part of the system is not properly working in our University telecommunication network. +Konrad and Dennis suggested us to analyze figure 1 and depending on it to build our test software. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{BigPicture_new1.png} + \caption[]{Overview of the Freiburg University telecommunication network \cite{network}} +\end{figure} +Our first attempt was to see what could we test without having access to the system. We installed numerous communication programs to see what others have done. +After gaining access to the communication software, we had decided to build most of the test software ourselves. Libraries, which were used, +were only the ones we could not develop ourselves because of the time-span of our team project. +\subsection{Logical and algorithmic requirements} +Despite the software and hardware requirements, the logic in our team project may be considered as the most important part. +Controlling the software and hardware in a specific manner was one of the requirements in our team project. +Moreover, we were required to draw a use case diagram and a simple test case diagram so that we could better understand all the problems we had to deal with +but also to easier follow the development of our test software. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{activity_diagram.png} + \caption[]{Simple algorithmic overview of a test case} +\end{figure} +\subsection{Software requirements} +Afterwards, as we had defined our logical approach to the problems, we had to choose the programming language to realize our ideas. Since we had the freedom of choice, between the three suggested programming languages +Java, C++ and Python, we made a joint decision to use Python as the main programming language in our team project. One of the requirements was to finish the team project in time, +therefore our decision to use Python is justified. Using Python we could work faster and integrate our subsystems more effectively \cite{python}. +Our programming language of choice is multi-platform, therefore our test software would be easy portable to other operating systems. +\par Likewise we had to decide how our test software will work. One of the requirements by Dennis and Konrad was to make the software capable of being run from the terminal. +The next requirement was to make an appealing GUI so that even an user without advanced Linux experience could handle the software and read out the results. +\par In addition it was required to log all the past tests. Later on a machine learning algorithm or some other intelligence could be applied to deduce some error behavior of the system +(e.g. an intelligent algorithm could find that part of the system fail in a combined manner). To accomplish the logging of all the tests we had to use a database system. +We decided to use MySQL since it is open source and well supported. +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{test_Use_case.png} + \caption[]{Test case diagram} +\end{figure} +\subsection{Hardware requirements} +Likewise the software requirements, we had hardware requirements as well. We were required to identify the hardware we will need to perform the tests. +It was important to find old and cheap cell phones that could support \emph{AT Modem} commands because our budget was limited. +\par A problem we had to deal with at the start was that the base stations are located at different geographical points which were not near to each other. +No one should go everyday to the rooms where our cell phones are located only to change or charge the batteries. +In the cable subsection we describe our approach to the charging battery problem. As we defined our requirements we continued with the process of developing the test software. +During the development time we refined our requirements. In the next chapters we will explain our database, software and hardware design ideas. +\newpage +\section{Database design} +As we mentioned in the software requirements section, we decided to use MySQL as our database system for storing the test information and results. +It was not difficult to decide what database to use, since MySQL is one of the most supported database and one can find a library to use it with major programming languages. +The key point in the design of our database was the simplicity and speed of accessing the data. We had decided to use seven tables. In the following paragraphs we will explain each table separately and its usage. +The database design can be seen in figure 4. + +\par The \emph{PingResultTable} table has six attributes (\emph{taskNo, sipServer, sipGate, unisip, gsmBox1, gsmBox2}), all of integer type. +The \emph{taskNo} attribute identifies the test number but not a single test (e.g. an operator user has selected three different tests to be executed, all of the three tests will have the same \emph{taskNo} to identify them together as belonging to one test group and \emph{taskId} identifies each single test and will be explained later). +\emph{sipServer} represents the Asterisk server ping result. \emph{sipGate} is used to represent the SIP Gate server for the landline calls (\url{http://www.sipgate.de}). \emph{uniSip} represents the ping results for our local University telephone network SIP server. +\emph{gsmBox1} and \emph{gsmBox2} are the two single-chip Linux computers (BeagleBoard), that control two cell phones each one (i.e. they are also known under the name of \emph{nanoBTSx controller}). +\emph{taskNo} is the primary and unique key in the table \emph{PingResultTable}. Rest of the attributes (i.e. \emph{sipServer, sipGate, uniSip, gsmBox1, gsmBox2}) are used to insert the ping results, if the assigned servers are reachable or not. +Before any test attempt is made, our test software first tries to ping the servers. These results are then stored in the \emph{PingResultTable}. + +\par The \emph{ErrorCodeTable} table defines all the possible test results in the system, in other words it represents a list with error codes with their appropriate descriptions and meanings. It consists of two attributes (\emph{errorcode} and \emph{description}), the first is of integer type and the second of varchar type (the description message is allowed to be only 100 characters long). +The \emph{ErrorCodeTable} table is used by the main test software (i.e. controller) to report the operator user what kind of error had appeared in the system. + +\par The \emph{DeviceAddressTable} is the table containing the location and identification data for each server and device. The table consists of seven attributes, \emph{deviceName, portName, number, lastChange, username, password, server}. +\emph{deviceName} is the attribute with the name of the device or server (e.g. GSMRZ1 or landline), it is of varchar type. \emph{portName} is the attribute field with the location address for a cell phone (e.g. \emph{/dev/ttyUSB1}) or 'localhost' instead of NULL value for a server, it is of the varchar type. +\emph{number} represents the number of the used service (i.e. number of the cell phone, SIP, etc.) and is of varchar type. +\emph{lastChange} is a time value and represents the date and time the given entry was modified (we had plans in future versions of our test software that if an device gets a new IP address assigned it automatically changes it in the database). +\emph{username} is the field with the username stored in for a server/service, like SIP and landline. \emph{password} attribute stores the password information for the given service. The \emph{server} attribute stores information about the location of the server, IP or DNS address of the server. All three fields, \emph{username}, \emph{password} and \emph{server} are of varchar type. +The information stored in the given table is used by the test software to obtain usernames, passwords and addresses of the used services for the tests. + +\par The \emph{ResultTable} table is used by the test system to store final results for the performed tests. Our given table consists of two fields, \emph{taskID} and \emph{result} and both are of integer type. For each test entry with unique \emph{taskID} an error code is assigned in the \emph{result} field, +depending on the test results. Error codes found in the \emph{ErrorCodeTable} table can be only assigned to this field. + +\par The \emph{TempTaskTable} table represents the table with the tasks the system has to execute next time the test software is started. The given table gets new data every time an operator user submits one or more test cases from the website to be executed. \emph{TempTaskTable} includes four attributes, \emph{taskID, taskNo, from, to}. Former two are of integer type and later two of varchar type. +\emph{taskID} and \emph{taskNo} identify the test task to be executed, \emph{taskID} is the unique primary key. \emph{from} and \emph{to} fields have to match the names given in \emph{DeviceAddressTable.deviceName}, these two attributes specify the caller and callee devices/services. Consequently, after the tasks get executed, the test tasks are removed and the given table is empty again until next tests are added to it. +However, all the test tasks even after deleting them from \emph{TempTaskTable} are kept in the \emph{TaskTable}. The reason why the authors of this project divided it into two tables was because of the database row selection speed. We had made the assumption that with time the database size will grow and therefore the database speed will not be the same as during the development period. + +\par The \emph{TaskTable} table, as mentioned before contains all the tests ever performed from the web site. It is made out of five attributes, \emph{taskID, taskNo, from, to, timestamp}. The first four fields are the same as in \emph{TempTaskTable}, however the last one, \emph{timestamp}, is used to record the exact time when the test was performed. +\par The \emph{GSMListPrefix} table contains the data about the GSM networks and their prefixes. It consists of two +attributes, both of varchar type, \emph{providerName} and \emph{prefix}. +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{DBRelationship.png} + \caption[]{Database relationship diagram} +\end{figure} +\end{center} +\end{landscape} + + + + + +\section{Software design} % section 2.1 +Software design was the next step after we analyzed the problem and developed a plan how to proceed further. Good analysis and planning with poor algorithmic implementation is valueless. +During the work on the project, we had spent most of our time for software design. +We kept in mind that our software should satisfy major paradigms of software engineering, +like compatibility, extensibility, modularity, reliability, security, fault-tolerance and usability. +The software engineering design concepts were achieved following way: +\begin{itemize} +\item Compatibility - we used Python and MySQL which are multi-platform and work on major OS +\item Extensibility - new parts of code can be easily added by just modifying the classes +\item Mudalarity - the components are independent black boxes, they are tested and validated independently +\item Reliability - we use mutex locks to perform tests and database transaction operations to insert data into the database +\item Security - all communication channels, as well as the access to the web site, are encrypted with asymmetric key cryptography +\item Fault-tolerance - the classes were designed to continue operating even if error events appear and handlers are logging all events +\item Usability - we tried to create a simple user interface and easily to use for everyone +\end{itemize} + +\begin{figure}[ht!] + \centering + \includegraphics[width=140mm]{activityControllerEdited.png} + \caption[]{Working principle of the test software} +\end{figure} + +\par The basic principle how the test software works can be seen in figure 5. The test software is +started either manually from the terminal or using the web site. When the test software +is started manually it is database dependent as well and therefore could not be used if the +database is being maintained or not working. If it is started from the web site it +connects to the database to get its tasks which have to be performed. After receiving +the tasks it makes a simple network test by pinging all the servers. The ping results +are stored in the database (in case the test was started from the web site). Then it +proceeds with the tests by connecting itself to the handlers and sending them commands +to perform the tests\footnote{Before it connects to the handlers, it uses the ping +results to see is the service/device physically connected to the network.}. +At the higher level, these commands can be seen as requests for being the +callee and caller. Meanwhile the handlers send their test results to the main +test software which in return decides if the test result was successful or not. +The result is written to the database (in case the software was started from the website), +otherwise the results are displayed in the terminal window and the user who started +it manually can see the test results. We will proceed with introducing the classes. +The software class diagram can be seen in the following figure. More details for the +classes, like the input/output can be found on our project's wiki page \cite{wiki}. + +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{classDiagram.png} + \caption[]{Class diagram (some classes were excluded)} +\end{figure} +\end{center} +\end{landscape} + + +\newpage +\subsection{Database access} % subsection 2.1.1 +Accessing the database is of critical value to our project, therefore we had developed our own class that limits the access to the database. In the process of developing our own class we used the MySQLdb library in Python \cite{mysqlManual}. +The database class has two working modes, a normal working mode and a debugging mode. The difference between these two modes is in the output information. In case the error handling function raises an error and it is unknown, if the debug mode is set a complete back-trace of the error will be printed out. A developer can change the mode by setting the variable \emph{debugMode=1}. The class diagram can be seen in the following figure. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{dbClass.png} + \caption[]{Class diagram for the dbClass} +\end{figure} +The method names are self-explanatory and do not require extra explanations. All the outputs produced by the class can be found on the project wiki page \cite{wiki}. +\subsection{Controlling the cell phones} +Our first version of the developed program code for controlling the cell phones used predefined timed values +to send commands instead of using a state controlled approach to confirm that every command was successfully received and executed by the cell phone. +It meant we had to make an enormous number of assumptions. In comparison to our second approach, to build a state controlled cell phone control class, +our first approach was inferior and slower. The state controlled method connected two cell phones, on the same base station, up to 15 times faster than the timed approach. +\begin{figure}[ht!] + \centering + \includegraphics[width=80mm]{serialPort.png} + \caption[]{GSM class diagram for controlling the cell phones} +\end{figure} +One can easily apply the class just by correctly defining the parameters: port address, baud rate and timeout. The former two are self-explanatory and the timeout parameter is used to define when the alarm function should raise a timeout exception. +A timeout exception gets raised when the cell phone does not respond (i.e. when the cell phone enters a deadlock or delayed state). We had used the serial port library inside of Python although we use USB cables to connect to our cell phones. One should +be aware that our USB cables create a virtual serial port. More details on class design and an example can be found on our project wiki \cite{wiki}. +\subsection{Client and Server class} +Our socket communication code is based on the example given in the Python socket manual \cite{socket}. +We extended it into two classes, a client and a server class. We had used the TCP protocol to base our two classes on\footnote{TCP is reliable compared to UDP (i.e. transmitted packets get also delivered), +packets are ordered when received and data are received in a stream (i.e. multiple packets can be read at once).}. +The Server class can be seen in the following figure. The server class is implemented to accept only local connections\footnote{More details are given in the section 7.1}. +First we determine our IP address and then create the socket to listen only for the same IP address (with a different IP address than the selected one a connection cannot be even established). +One has to define the port on which the server object should listen. +When receiving data one can easily define the timeout to be raised if data are not received in the timeout range or set it to \emph{0} to infinitely wait for the buffer to be filled with received data. While testing the server class we had the problem to listen on the same port if the application was forcibly\footnote{Manually closed using CTRL+C and run again.} restarted in less than 60 seconds. We got the error message: \emph{"Address already in use"}. +This is not known as error behavior but rather an option to help the server to catch lost live packets (i.e. packets that are still in the network looking for it is goal destination). +We solved the problem by changing the socket options with the \emph{SO\_REUSEADDR} parameter. This enabled us to get around the error when we tried to restart our server application. +Before solving the problem without using the socket parameter, we had another solution to get around this problem by killing the application running the port, this old method is obsolete now. +\begin{figure}[ht!] + \centering + \includegraphics[scale=0.8]{serverClass.png} + \caption[]{Server class, used by the server application} +\end{figure} +In the process of testing the client class we did not have any major problems. The only major flow we had to debug was when one of the sides disconnects that we get out of the waiting loop if the timeout variable was set to \emph{0} (i.e. infinite waiting loop). +The client class can be seen in the following figure. To initialize the client object one needs to define the IP address and the port of the server application listening on it. +\begin{figure}[hb!] + \centering + \includegraphics[scale=0.5]{ClientClass.png} + \caption[]{Client class, used by the client application} +\end{figure} +Once an instance of it is created and loaded with the IP address and the port, one needs to call the \emph{connect()} method. +The method will produce an integer based on its connection state. Output information and the programming code can be found on our project wiki page \cite{wiki}. +\subsection{Ping class} +Before making any test and establishing a connection we were required to ensure that the server is online. The best way to assess the liveness property was to ping the server computer running the required service. Once the class is properly defined, we could easily set the number of ping tries. +A ping timeout response was set up to 2 seconds. For more details and insights, one can read more about it on our wiki page \cite{wiki}. +\begin{figure}[ht!] + \centering + \includegraphics[width=70mm]{ping.png} + \caption[]{Ping class, used by test software} +\end{figure} +\subsection{Data logging} +If errors appear it is important to reconstruct the events that led to the misbehavior of the software. One of the best ways to reconstruct the events was to log +events for different blocks of programming code. +We had used the logging class to follow our handler code run on the BeagleBoard. In case there is an error we could look inside of the log files and track the error. +How the class works and what kind of outputs it produces can be found on our project wiki page \cite{wiki}. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{logging.png} + \caption[]{Logging class} +\end{figure} +\subsection{SSH Tunnel Class} +Since security played an important role in our team project. We decided to encrypt all of our data that was not processed on our server computer. +The simplest solution to this problem was to build an SSH Class that could open and close a local forwarding port. +All data sent through the created port is encrypted until it gets to its destination location. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{sshTunnelClass.png} + \caption[]{SSH Tunnel class} +\end{figure} +\subsection{USB Cell phone detection class} +Since we had used cables to connect the cell phones with the computer, usually the devices +got their own port addresses. They were automatically assigned by the operating system, +either after the cables were plugged into the USB port or after a system reboot. +One of the problems we had to deal with was assigning the right cell phone +(i.e. with the appropriate GSM network) to the corresponding port address. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{usbDetectClass.png} + \caption[]{USB cable detection class} +\end{figure} +The operating system randomly assigned the port names after every reboot. +We were looking for a solution to prevent this misaddressing of the devices. +Our solution was to recognize every device and update the port address in the database. +The principle how we identify the cell phones is by their calling numbers in the database. +More details can be found on our project wiki page \cite{wiki}. +\subsection{Truth table class} +The truth table class was built to identify the broken and working parts of the system. +It requires the list with test results to be present to be operable. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{trueTable.png} + \caption[]{Truth table class} +\end{figure} +Then the class tries to identify the broken parts of our telecommunication network. +The class can easily identify how many nanoBTSs are installed in the network and +derive a decision which part of the network is broken. +All the test results are stored in a list and can be easily read by calling the +\emph{initTrueTable(x)} function. More details can be found on our project wiki page \cite{wiki}. +\subsection{Init Test class} +The main purpose of the class is to get device data from the database and to process it. +The processed data get forwarded to the controller class and in the end the class +fetches the results from the test. This class contains the \emph{smart test} functionality. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{initTestClass.png} + \caption[]{Init test class} +\end{figure} +It selects automatically the important tests to perform. In the next step it +tries to identify the problem in the network. +More details can be found in the \emph{smart test} description. +\subsection{Controller class} +The controller class is used to assign jobs to handlers (in other words, which one is +going to be the caller and callee). Simultaneously, it defines the port addresses for +the communication between the handlers and the main test software (controller). +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{controllerclass.png} + \caption[]{Controller class} +\end{figure} +If the callee or the caller are nanoBTS controller boxes (i.e. BeagleBoards outside +the Rechenzentrum), it will first create an SSH connection to make a tunnel before +the local socket connection is created. Then the controller class sends all the +required data regarding the test tasks to the handlers. + +\clearpage +\section{Hardware design} +In our team project we had the option to choose all the required hardware ourself beside the two BeagleBoards, which we were supplied by Konrad and Dennis. +Since one of the project goals was to reduce the costs as much as it was possible, we had tried to use some of the leftovers found in our lab. + +\subsection{BeagleBoard} +``The BeagleBoard is an OMAP3530 platform designed specifically to address the Open +Source Community. +\begin{figure}[ht!] + \centering + \includegraphics[width=60mm]{bb.jpg} + \caption[]{BeagleBoard, a Linux-on-chip board where our controller software runs the GSM device } +\end{figure} +It has been equipped with a minimum set of features to allow the +user to experience the power of the OMAP3530 and is not intended as a full development +platform as many of the features and interfaces supplied by the OMAP3530 are not +accessible from the BeagleBoard'' \cite{beagleDataSheet}. +We run on it a special precompiled version of Ubuntu for the ARM processor type. The Linux system boots up from an SD Card. +The board has an USB hub and network port attached to it. In our project it is connected to our +internal university LAN network and to a cell phone. We positioned the two BeagleBoards in rooms where +we had LAN access and GSM signal coverage of our two local base stations. + +\subsection{Cell phones} +Our first attempt was to control a Nokia cell phone 3310 with the supplied USB connection cable. +The protocols used by old versions of Nokia cell phones, as the 3310, use the F-Bus protocol. It was not easy to work with. +After performing various experiments we succeeded to send and to read SMS messages. Later on we found out that it was not possible to +send commands for receiving and making the calls. In the meantime we found two Siemens phones, one M45 and S55. +The first one, Siemens M45, had a cable supplied with it and it was not difficult to control it with the standard set of AT modem commands. +At the start we did not have a cable supplied for the Siemens S55 phone. We controlled it over the Bluetooth port. + +\subsection{Cables for the cell phones} +Due to the fact that we had used 5 cell phones on a single computer, the best solution was to order 5 USB cables. +Konrad bought 5 cables for 5 Siemens S55 cell phones. All of the cables have an USB2Serial chip converter inside of them. +Once they were plugged into the USB port, Ubuntu automatically recognized the cables and installed the drivers. +The virtual serial ports were created and could be found on \emph{/dev/ttyUSBx}, where $x$ is the automatically assigned number for the port. +Some of the cables had the capability to charge the Siemens S55 phones. +Konrad had opened several cables to solder the power supplies to some contacts and the problem was solved for all of the cables. +\subsection{Server} +We were given an old Pentium 3 computer where we installed Ubuntu Linux. Configured the Apache web server and MySQL. +Afterwards we installed the Python on it and all the required libraries\footnote{Required libraries are mentioned in section 9.1.}. +\clearpage + +\section{Communication protocol} +A communication protocol represents a set of well defined rules by whose help two or more computing systems exchange information in-between. +When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate +response from the other side. Our approach to this problem was to build a simple synchronous protocol, where every expected message is +confirmed or otherwise the connection between two sides is immediately terminated. Since designing protocols is a demanding and challenging +topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum +protocol\footnote{Design concepts and paradigms for the protocol design have been used from the +``Network Protocol Design and Evaluation'' course, lectured by Dr. Stefan R\"{u}hrup}. +In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works, +it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device +that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software +controlling the handler side and assigning the task to it. + +\subsection{Communication between the handler and controller} +The handler side is always in the waiting mode, by waiting we denote the mode where the socket is already created and it is waiting +for a connection to be accepted at the defined port. The controller initiates a socket connection to the two handlers. +Subsequently, after the connection has been established, it is waiting for a message to be received. The first message +has to be 13 characters long and include the following content \emph{HELLO HANDLER}. Thereupon, after the message has +been validated, the handler side sends the controller side a response, \emph{HELLO CONTROLLER}. +We call this first message exchange the initialization. Now the controller side has to decide which of the two handler's +will be the caller/callee whereas the other handler will be the opposite. Let's assume the controller sends to the first +handler the message \emph{RECEIVER} and to the second one the message \emph{CALLER|\#}, replace the callee number with the \# sign. +In the meantime, both handlers initialize the software required to make the call and to receive the call. Asynchronously they +respond back to the controller their successful initialization. The successful initialization is reported by sending \emph{RECEIVER READY} +and \emph{CALLER READY}. After receiving the mentioned messages, the controller first sends the callee handler the +message \emph{RECEIVE START} and then to the caller handler, the message \emph{CALLER START}. As a result of these messages, +the handlers enter the receiving, respectively calling state. In the given states two timeout timers gets activated. +These timers are responsible for the case if the physical connection between the callee and the caller are not successfully +established or terminated\footnote{The client and server classes responsible for the communication have timeout timers as well +for the case if the connection between the controller and handlers are broken.}. Afterwards, depending if the physical connection +between the handlers (i.e. the callee and the caller) was successfully established or not, the handlers report their +corresponding state with a message to the controller. The message is of the form \emph{CALL OK}, meaning the handler successfully +established a physical connection with the other handler, or of the form \emph{CALL NOT OK}, meaning a physical connection was +not successfully established on the given handler. The controller considers only a test successful if both handlers report +with \emph{CALL OK}. The test software ends the established connection with the handlers by sending them the \emph{TERMINATE CONNECTION} +command. After the handlers have terminated the connection, they enter the waiting for a new connection state and the process starts +from beginning again. If the states are not entered in the specified order the connection is immediately terminated and +the state machine is in the waiting for a new connection state\footnote{It cannot be seen in the protocol flowchart but one should +keep in mind it works like a well defined state machine.}. + +\begin{landscape} +\begin{center} +\begin{figure}[ht!] + \centering + \includegraphics[width=218mm]{protocolCommunicationHandler.png} + \caption[]{Flowchart of the protocol on the handler side without the state representation} +\end{figure} +\end{center} +\end{landscape} + + + +\begin{figure}[ht!] + \centering + \includegraphics[width=147mm]{protocolCommunicationcControllerReceiver.png} + \caption[]{Flowchart of the protocol on the controller side for the caller without the state representation} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=147mm]{protocolCommunicationcControllerCaller.png} + \caption[]{Flowchart of the protocol on the controller side for the receiver without the state representation} +\end{figure} + +\subsection{Verification of the protocol} +``SPIN is a model checker - a software tool for verifying models of physical +systems, in particular, computerized systems. First, a model is written that +describes the behavior of the system; then, correctness properties that express +requirements on the system's behavior are specified; finally, the model +checker is run to check if the correctness properties hold for the model, and, +if not, to provide a counterexample: a computation that does not satisfy a +correctness property.'' \cite{spin}. We modeled our simple protocol in SPIN using +the programming language PROMELA \cite{spin}. Since PROMELA is similar to C it was +not possible to ensure 100\% matching with Python but we had made the assumptions of it. +We modeled both sides, server and client side. As well as the server side being a caller +and a callee. It was important to find out if our protocol is deadlock or delayed state free. +For more details our model can be found on our wiki project page with the PROMELA source code \cite{wiki}. +We had built in a 50\% random probability that the call test will not be successful, to make the model even more +realistic. Our protocol idea was deadlock free and the verification results prove it. +After we had modeled the basic idea we had written the code that implements our idea. The Python code +resembles some kind of a state machine which remembers the last state and what the next state should be in case +of receiving corresponding message. Otherwise it enters the exit state and then the start state. + +\begin{lstlisting} +(Spin Version 6.1.0 -- 2 May 2011) + + Partial Order Reduction +Full statespace search for: + never claim - (none specified) + assertion violations + + cycle checks - (disabled by -DSAFETY) + invalid end states + +State-vector 44 byte, depth reached 65, errors: 0 + 40 states, stored + 3 states, matched + 43 transitions (= stored+matched) + 90 atomic steps +hash conflicts: 0 (resolved) + 2.195 memory usage (Mbyte) +unreached in proctype Server1 + (0 of 36 states) +unreached in proctype Server2 + (0 of 36 states) +unreached in proctype Client + (0 of 67 states) +pan: elapsed time 0 seconds +\end{lstlisting} + +\clearpage +\newpage + + +\section{Security and safety of the system} +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 +(e.g. assume the University alarm system uses the SIP gateway to connect to the outside world and to alarm the police, if one knows that the SIP gateway is not working properly, a burglar could plan to rob the University building just at that moment). Therefore the choice to go Open Source is justified due to the fact that one should know how every single detail of the system works. +All the time, while we were working on the project, we were made aware of this issue by Dennis and Konrad. +We decided to use asymmetric key cryptography, where each side has two keys (private and public). In the next sections we will explain in more details how we applied the methods. +\subsection{Encryption of the communication channels} +At first we thought to encrypt the data before sending them but since none of us was an expert on encryption standards the idea was rejected. Alongside the fact that none of us had been an expert in the field of cryptography, we were neither experts in the field of Internet programming. One could find maybe a way to disable our server software with various hacking methods (e.g. +trying to open the port until the system runs out of memory and in our case the system which we used on the handler side was a BeagleBoard with ARM architecture running on a single chip TI OMAP processor, refer to the picture in figure). +We had to eliminate even the slightest possible threat in return for spending more time for debugging the test software system. Despite we were aware of all these facts, we had to choose one of the plenty implemented encryption standards on Linux. +Dennis and Konrad suggested using the SSH Tunneling method. + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{sshTunnel.png} + \caption[]{SSH Tunnel, all the communication inside the tunnel is encrypted } +\end{figure} + +Using the SSH Tunnel port forwarding method we could hide the real port we had used for our socket connection. On the other hand we could force the socket to accept only local connections (i.e. from the machine where the handler software was running). +The SSH Tunnel port forwarding method creates an encrypted tunnel between the two computers and then it creates two ports, one on the local and remote computer. All the data sent through the port on the local machine appear on the port at the remote machine. \newline The first problem we faced was that SSH required the username and password every time we tried to make an SSH connection. We could avoid this problem by copying the public key from our server (where our test software runs) to the BeagleBoard \cite{sshTunnel}. +This can be performed by executing the following commands in the terminal shell. +One has to create first the private and public keys on the local machine(i.e. server computer, where the test software runs): + +\begin{lstlisting} +refik@ubuntu:$ [Note: You are on local-host here] + +refik@ubuntu:$ ssh-keygen +Generating public/private rsa key pair. +Enter file in which to save the key (/home/refik/.ssh/id_rsa):[Enter key] +Enter passphrase (empty for no passphrase): [Press enter key] +Enter same passphrase again: [Press enter key] +Your identification has been saved in /home/refik/.ssh/id_rsa. +Your public key has been saved in /home/refik/.ssh/id_rsa.pub. +The key fingerprint is: +33:b3:fe:af:95:95:18:11:31:d5:de:96:2f:f2:35:f9 refik@ubuntu +\end{lstlisting} + +Then one needs to copy the public key to the remote machine (BeagleBoard) using ssh-copy-id: + +\begin{lstlisting} +refik@ubuntu:$ ssh-copy-id -i ~/.ssh/id_rsa.pub remote-host +refik@remote-host's password: +Now try logging into the machine, with "ssh 'remote-host'", and check in: + +.ssh/authorized_keys + +to make sure we haven't added extra keys that you weren't expecting. +\end{lstlisting} + +After we have created the public and private keys, and coppied the public key on the machine to which we want to connect, we can test if we can make an SSH connection to the remote machine: + +\begin{lstlisting} +refik@ubuntu:$ ssh remote-host +[Note: SSH did not ask for password.] + +refik@remote-host:$ [Note: You are on remote-host here] +\end{lstlisting} +The test was successful. We tested it with our SSH Tunnel port forwarding class and it worked perfectly. +\subsection{Security on the web site} +Aside from having secured the data communication channels between various parts of our software +(the handlers and the controller), it was crucial to ensure all the communication between +test user's browser and our server. Therefore we had used the \emph{https} protocol and +the \emph{.htaccess} file to password protect the web site so only the privileged users +have access to our test system. +\subsubsection{Configuring the http secure protocol https} +Securing the communication channels without making certain the web site is safe would be worthless. +We decided to use the \emph{https} protocol instead of the \emph{http} since a person in the middle +could sniff our data (e.g. a person is connected with his/her smart-phone over an unprotected wireless network) \cite{https}. +At the same time the web site should be accessible only by the authorized personel. Our first approach to this +problem was to build an PHP page with \emph{MD5} hashed passwords, however we got a suggestion by Konrad and Dennis to +use a safer encryption method implemented in the Apache web server software, \emph{.htaccess}. By using +these two techniques we protected the web site of some vulnerabilities known to us. If the web site +will be only accessed from our local university network, we can additionally add an IP filter mask as well. +In the following paragraph we will explain our procedure how to generate the keys and to enable the https protocol. +\par First we want to generate a server key by typing the following command: +\begin{lstlisting} +openssl genrsa -des3 -out server.key 4096 +\end{lstlisting} +\par This will generate a 4096 bit long private server key, one is asked to enter two times a password for the \emph{server.key}. +Using the generated private server key, we will create a certificate signing request, \emph{server.csr}. We were prompted with a series of questions +like country, state, organization name and etc which we had to enter to resume. +\begin{lstlisting} +openssl req -new -key server.key -out server.csr +\end{lstlisting} +\par In the next step we had to sign the certificate signing request and enter the amount of days for how long it should be valid. +In our case we entered the duration of one year, one can make it for longer periods as well (i.e. the amount of 365 has to be changed). +\begin{lstlisting} +openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt +\end{lstlisting} +\par We were asked to enter the password again for \emph{server.key}. After we have completed this step we had to make +a version of the \emph{server.key} which did not require a password, \emph{server.key.insecure} and we will rename the files appropriately. +\begin{lstlisting} +openssl rsa -in server.key -out server.key.insecure +mv server.key server.key.secure +mv server.key.insecure server.key +\end{lstlisting} +\par The generated files are very sensitive, since they are our keys. After these steps were completed, we had generated 4 files: \emph{server.crt}, \emph{server.csr}, \emph{server.key} and \\ \emph{server.key.secure}. Now we need to enable the SSL engine on the Apache web server. +We coppied \emph{server.key} and \emph{server.crt} into \emph{/etc/appache2/ssl}. +\begin{lstlisting} +refik@ubuntu:/etc/apache2$ sudo mkdir ssl +cp server.key /etc/apache2/ssl +cp server.crt /etc/apache2/ssl +\end{lstlisting} +\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 symlink-ed for loading)'' \cite{https}. +\begin{lstlisting} +refik@ubuntu:/etc/apache2/ssl$ sudo a2enmod ssl +Enabling module ssl. +See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates. +Run '/etc/init.d/apache2 restart' to activate new configuration! +\end{lstlisting} +\par In the next procedure we had to establish a symlink from the 'available' default-ssl file to the 'enabled' file \cite{https}. Then we created a folder where our secured PHP files will be located (e.g. https://some-domain-name.com/test-software). +\begin{lstlisting} +refik@ubuntu:/etc/apache2/ssl$ sudo ln -s /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/000-default-ssl +refik@ubuntu:/etc/apache2/ssl$ cd /var/ +refik@ubuntu:/var$ sudo mkdir www-ssl +\end{lstlisting} +\par We had backed up our old configuration files for the virtual hosts, for the case if we damage the Apache configuration files. Then we edited the \emph{default-ssl} file. +\begin{lstlisting} +refik@ubuntu:/var$ cd /etc/apache2/sites-available +refik@ubuntu:/etc/apache2/sites-available$ sudo cp default default_original +refik@ubuntu:/etc/apache2/sites-available$ sudo cp default-ssl default-ssl_original +refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl +\end{lstlisting} +\par Only the beginning of the file is listed here and we have modified the line starting with \emph{DocumentRoot} +and \emph{} from \emph{DocumentRoot /var/www} to \emph{DocumentRoot /var/www-ssl} +and from \emph{} to \emph{} +(i.e. we had to redefine the location of our SSL directory). +\begin{lstlisting} + + + ServerAdmin webmaster@localhost + + DocumentRoot /var/www-ssl + + Options FollowSymLinks + AllowOverride None + + + Options Indexes FollowSymLinks MultiViews + AllowOverride None + Order allow,deny + allow from all + +\end{lstlisting} +\par One should keep in mind that the port 443 should be free for Apache to use it. In the proceeding step we had to ensure that Apache listens on the given port for a \emph{https} connection. +One could test that by going into the \emph{/etc/apache2/ports.conf}. +\begin{lstlisting} + + # If you add NameVirtualHost *:443 here, you will also have to change + # the VirtualHost statement in /etc/apache2/sites-available/default-ssl + # to + # Server Name Indication for SSL named virtual hosts is currently not + # supported by MSIE on Windows XP. + Listen 443 + +\end{lstlisting} +\par In our case it was set up correctly, since the command: \emph{Listen 443} was present. +In our last configuration step we had to edit \emph{default-ssl} file to define the correct locations of our keys and to ensure the SSL engine was turned on. +\begin{lstlisting} +refik@ubuntu:/etc/apache2/sites-available$ sudo vim default-ssl +\end{lstlisting} +\par The following part of the file had to be found and modified according to our locations: +\begin{lstlisting} +SSLEngine on + + # A self-signed (snakeoil) certificate can be created by installing + # the ssl-cert package. See + # /usr/share/doc/apache2.2-common/README.Debian.gz for more info. + # If both key and certificate are stored in the same file, only the + # SSLCertificateFile directive is needed. + SSLCertificateFile /etc/apache2/ssl/server.crt + SSLCertificateKeyFile /etc/apache2/ssl/server.key + + # Server Certificate Chain: + # Point SSLCertificateChainFile at a file containing the +\end{lstlisting} +\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 + ... waiting [Sat Oct 08 21:52:52 2011] [warn] _default_ VirtualHost overlap on port 443, the first has precedence [ OK ] +refik@ubuntu:/etc/apache2/sites-available$ +\end{lstlisting} +\subsubsection{Password protecting the web site using .htaccess} +Aside from using a secure communication protocol on the web, \emph{https}, it is important +to ensure that only permissioned users gain access to the web site. We had achieved it using +the \emph{.htaccess} file. However, to enable the use of Apache \emph{.htaccess} files, +we will have to reconfigure the Apache configuration files again. \emph{root} access will +be required. First we have to edit the \emph{/etc/apache2/sites-available/default-ssl} file. +Find the following lines and modify the \emph{AllowOverride None} to \emph{AllowOverride All} +like in the given configuration segment: +\begin{lstlisting} + + Options Indexes FollowSymLinks MultiViews + AllowOverride All + Order allow,deny + allow from all + +\end{lstlisting} +This will tell Apache web server that it is okay to allow \emph{.htaccess} files +to over-ride previous directives. We must reload the Apache web server before the +changes can take effect. We can do it by typing: +\begin{lstlisting} +sudo /etc/init.d/apache2 reload +\end{lstlisting} +The next step is to go to the directory where our test software web page is located +(e.g. \emph{/var/www-ssl/testsoftware}) and to create a file called \emph{.htaccess}. +Please insert the following code segment inside the created \emph{.htaccess} file where +\emph{/var/www-ssl/testsoftware/.htpasswd} is your full path address to \emph{.htpasswd}: +\begin{lstlisting} +AuthUserFile /var/www-ssl/testsoftware/.htpasswd +AuthName "Authorization Required" +AuthType Basic +require valid-user +\end{lstlisting} +Then in the next step, create another file called \emph{.htpasswd}. After you have created it, +we will add the usernames that should have access to the web site. We do that by typing the +following command, where you can replace \emph{konrad} with any other combination of letters +which will represent your username: +\begin{lstlisting} +refik@ubuntu:/var/www-ssl/testsoftware$ sudo htpasswd -c .htpasswd konrad +\end{lstlisting} +Afterwards, you will be required to type twice the same password for the username +you want to create, in this case \emph{konrad}. ``The -c flag is used only when you +are creating a new file. After the first time, you will omit the -c flag, +when you are adding new users to an already-existing password file. Otherwise you +will overwrite the file!'' \cite{htaccess}. You can add as many users as you wish, +do not forget to remove the -c flag when you do it. +In the last step, we have to modify the \emph{/etc/apache2/apache2.conf} file and +to add at the end of it the following code segment where \emph{/vaw/www-ssl/testsoftware} +is the full path to your web page directory where you put the \emph{.htpasswd} file: +\begin{lstlisting} + +AllowOverride All + +\end{lstlisting} +We are done with editing. All we have to do now is to restart the Apache web server. We +can do that by typing: +\begin{lstlisting} +sudo /etc/init.d/apache2 restart +\end{lstlisting} +You can test it now by opening a new browser tab and navigating to \emph{https://localhost/\\testsoftware} +(keep in mind to replace \emph{testsoftware} with your name of the folder where the web page +is located). If you configured everything properly, you should get a dialog where you can +enter your created username and password and try to login. + +\newpage +\section{Web page} +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 access 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 as 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 Cell phones 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 in-between 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=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 immediately identify the network operability in percentage\footnote{The test user has to take into account that this percentage 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{Employing the test software system} +In this section the reader can find out how to install and how to use the test system. +Our goal was to make a multi-platform test software, however we tested it only under Ubuntu +11.04 32 bit Linux OS and the given instruction manual is only tested under that OS. The +test software performed well, both on PC and MAC computers. +One should keep in mind that some of the libraries we had used do not work +under the 64 bit version of Linux OS. + +\subsection{Required software and libraries} +In the next subsections, we will guide you how to install all the required software and +libraries to flawlessly run our test software on your employed server. +You will be required to have \emph{root} access privileges and to open a new +terminal window where the commands will be typed in. + +\subsubsection{Python installation} +Python was our programming language of choice\footnote{We had explained earlier why we +have decided to use Python.}. The required version of Python is 2.7. One can easily +install python by typing the following commands: +\begin{lstlisting} +sudo apt-get update +sudo apt-get install python2.7 +\end{lstlisting} +It will take a short amount of time to be installed. You will be required to enter +the \emph{root} password. + +\subsubsection{Apache Web server installation} +We had decided to use the Apache web server because of its wide support on the Internet +and safety reasons. If there are any bugs or security flaws, the patches are +easily installed with the Ubuntu update manager. The Apache web server can be easily +installed by typing the following command: +\begin{lstlisting} +sudo apt-get install apache2 +\end{lstlisting} +You might be required to follow other installation instructions printed on the +terminal screen. +After the installation has completed successfully, one can test if it works by going +to the following web address: \emph{http://localhost}. For configuring the \emph{https} +please go to the section 7.2. + +\subsubsection{SSH} +Secure Shell (SSH) is a network protocol for secure data communication between two +computers inside of a network. All computers are required to have SSH installed on it. +You can easily install it by typing the following command: +\begin{lstlisting} +sudo apt-get install ssh +\end{lstlisting} + +\subsubsection{MySQL database and MySQLdb library} +The MySQLdb library is required to perform various operations on the MySQL database within +Python. We used the MySQLdb library instead of the native MySQL C API \emph{\_mysql} library +to make the code cleaner and more portable. +We suggest you to install first the MySQL database on the server computer. If you +have installed MySQL you can skip the next part. To star the installation process one can +type the following commands: +\begin{lstlisting} +sudo apt-get install mysql-server +\end{lstlisting} +You will be required to enter the Linux \emph{root} password. At some point during +the installation process, you will be required to enter the password for the MySQL +database. After you have performed the above step, we can proceed with the +MySQLdb library installation. By typing: +\begin{lstlisting} +sudo apt-get install python-mysqldb +\end{lstlisting} +If the \emph{python-mysqldb} name has changed, one can easily find the correct name of the +file by issuing the following command: +\begin{lstlisting} +apt-cache search MySQLdb +\end{lstlisting} +By typing in the commands given above, you should have successfully installed the MySQLdb +library. + +\subsubsection{Serial port library} +The serial port library is required for the cell phones to communicate with the +server computer and the BeagleBoards. The required library for Python can be installed +by typing the following command: +\begin{lstlisting} +sudo apt-get install python-serial +\end{lstlisting} +The installation should not produce any errors or warnings. + +\subsubsection{PJSUA library} +\emph{PJSUA} is an open source command line SIP user agent (soft-phone). We use the library +for the SIP handler. First, one needs to download the library +from \url{http://www.pjsip.org/download.htm} \cite{pjsip}. Then extract it to some folder. +Then we will build the library using make. This can be accomplished by typing the following +commands: +\begin{lstlisting} +cd your-pjsip-root-dir +./configure && make dep && make +cd pjsip-apps/src/python +sudo make +\end{lstlisting} + +If you get an error similar to this one: +\begin{lstlisting} +_pjsua.h:25:20: fatal error: Python.h: No such file or directory +compilation terminated. +error: command 'gcc' failed with exit status 1 +\end{lstlisting} +Then you will be required to install python-dev as well, that matches your version of +python (e.g. python2.7-dev). You can do it by typing: +\begin{lstlisting} +sudo apt-get install python2.7-dev +\end{lstlisting} +After you have successfully installed python2.7-dev, repeat the the commands given above. +Now you should have a properly installed PJSUA library. One can easily test if the installation +was successful by compiling a simple python code, \emph{python test.py}, with the following +source code: +\begin{lstlisting} +import pjsua +\end{lstlisting} +If you do not get any errors, you have successfully installed the library. More detail can +be found on our project wiki page \cite{wiki}. + +\subsubsection{pChart library} +The pChart library is within our installation files and does not require to be installed +individually. The library is only required if one uses the web interface and +requires the generated resulting image. The library is open source and does not require +any licensing. However, if one needs to learn how the library works, +information can be found on the pChart web page \cite{pChart}. + +\subsubsection{proctitle library} +We had used this library to rename the currently executed process name. +``The library allows a process to change its title (as displayed by system +tools such as ps and top). Changing the title is mostly useful in +multi-process systems, for example when a master process is forked: +changing the children's title allows to identify the task each process is +busy with.'' \cite{proctitle}. The library can be easily installed by typing: +\begin{lstlisting} +sudo easy_install setproctitle +\end{lstlisting} + + +\subsection{Configuring hardware} +Before proceeding with the next steps, please connect all the cell phones +to the USB hub using the suitable cables. Then make sure the cables are +recognized by the operating system. This can be performed by typing the following command: +\begin{lstlisting} +dmesg | grep ttyU +\end{lstlisting} +The given command should produce a result similar to: +\begin{lstlisting} +[ 5178.753600] usb 1-1.2: pl2303 converter now attached to ttyUSB0 +\end{lstlisting} + +We have two different ways to configure the cell phones, manually and automatic. +Both options can be accessed either using the website or the terminal window. +Using the manual configuration from the terminal, the user configures everything him/herself. +The user will be presented with a few questions like the port address, cell phone number and IMEI. +After the user enters all the required parameters, the software will check +if the given port address is accessible and it will look for a response from the devices. +Then you will be asked to enter the IMEI and the cell phone number of the device. +If the entered IMEI matches the device IMEI then the software will update the database +with the entered information. You can run, both the manual and automatic configuration +by typing: +\begin{lstlisting} +python gsmselftest.py --devconf +\end{lstlisting} +In the automatic configuration, the software will automatically try to detect every +cell phone that is connected to the USB hub. This configuration option can detect +up to nine cell phones, that are connected to the server computer. We had set a limit to +nine cell phones because we required only five (four for the external GSM networks +and one for our internal GSM BST). The only limitation of the automatic cell phone configuration +is that it only supports cell phones where we could read out the number using the \emph{AT Modem} +commands since some cell phone manufacturers do not use the standardized \emph{AT Modem} commands. +\newpage +\subsubsection{Configuring the cell phones} +It is important to write in the Siemens S55 cell phones their numbers if you want to use +automatic device configuration. You can do that by following the next few steps: + +\par Open the phone book on the S55 and choose \emph{} and press the select button. +\par In the second step, press select on \emph{}. +\par In the third and last step, enter your cell phone number and save it! +\begin{figure}[ht!] + \centering + \includegraphics[width=20mm]{First.png} + \caption[]{First step in configuring the phone} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=20mm]{Second.png} + \caption[]{Second step in configuring the phone} +\end{figure} +\begin{figure}[ht!] + \centering + \includegraphics[width=20mm]{Third.png} + \caption[]{Second step in configuring the phone} +\end{figure} +\clearpage +\subsection{Location of the files} +For proper operation of the software, it is important that each file is at its correct path +located. In the given section you can find out the correct path locations. +If you are not an expert, please do not change these locations. +The following files have to be located in the \emph{/var/www-ssl/testsoftware/} folder: +\begin{lstlisting} +drwxr-xr-x 7 root root 4096 2011-10-28 12:45 . +drwxr-xr-x 3 root root 4096 2011-10-20 17:06 .. +-rw-r--r-- 1 root root 109 2011-10-26 16:55 .htaccess +-rw-r--r-- 1 root root 20 2011-10-26 17:11 .htpasswd +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 class +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 css +-rw-r--r-- 1 root root 7547 2011-10-20 17:06 delayedLoading.js +-rw-r--r-- 1 root root 3431 2011-10-25 14:38 devconf.html +-rw-r--r-- 1 root root 2024 2011-10-25 23:47 devconfigAuto.php +-rw-r--r-- 1 root root 1811 2011-10-26 13:44 devconfigManual.php +-rw-r--r-- 1 root root 2195 2011-10-25 23:45 devconfig.php +-rw-r--r-- 1 root root 3526 2011-10-27 14:51 devconf.php +-rwxr-xr-x 1 root root 725 2011-10-20 17:06 execute.php +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 fonts +-rw-r--r-- 1 root root 2259 2011-10-28 12:43 index.html +drwxr-xr-x 2 root root 4096 2011-10-20 17:06 icons +drwxr-xr-x 2 root root 4096 2011-10-25 14:10 Images +-rw-r--r-- 1 root root 2038 2011-10-20 17:06 insertData.php +-rw-r--r-- 1 root root 636 2011-10-26 13:43 insertdevice.php +-rw-r--r-- 1 root root 10819 2011-10-20 17:06 loader.gif +-rw-r--r-- 1 root root 2268 2011-10-26 16:07 main.php +-rw-r--r-- 1 root root 5416 2011-10-20 17:06 moocheck.js +-rw-r--r-- 1 root root 75836 2011-10-20 17:06 mootools.js +-rw-r--r-- 1 root root 677 2011-10-20 17:06 mutexFunctions.php +-rw-r--r-- 1 root root 9063 2011-10-25 17:20 mutexSmartTest.php +-rwxr-xr-x 1 root root 9143 2011-10-28 12:45 mutexTry.php +-rw-r--r-- 1 root root 13304 2011-10-20 17:06 networkResult.php +-rw-r--r-- 1 root root 8294 2011-10-21 19:02 post.php +-rw-r--r-- 1 root root 19218 2011-10-21 17:36 startTest2.php +-rw-r--r-- 1 root root 18852 2011-10-20 17:06 startTest.php +-rw-r--r-- 1 root root 18787 2011-10-25 16:43 TaskTest.html +-rw-r--r-- 1 root root 3685 2011-10-20 17:06 testCase.php +-rw-r--r-- 1 root root 2545 2011-10-20 17:06 wait.gif +\end{lstlisting} +The \emph{startSoftware.py} file is required to be in the \emph{/etc/init.d/} folder, +since it is required to be start with the computer boot however if that does not work, +one should start it manually. This part of the software is +responsible for starting the testing software from the web page\footnote{The web page +communicates with this script via a socket connection and sends a signal to start +the main test software.}. +The main test software python files should be located in \emph{/home/gsmselftest/SoftwareTesting/}. +\begin{lstlisting} +drwxr-xr-x 2 gsmselftest gsmselftest 4096 2011-11-03 14:29 . +drwxr-xr-x 30 gsmselftest gsmselftest 4096 2011-11-02 18:28 .. +-rwxr--r-- 1 gsmselftest gsmselftest 2909 2011-10-20 17:54 ClientClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 3628 2011-10-20 17:54 ClientClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 9814 2011-11-02 16:19 ControllerClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 9247 2011-11-02 16:20 ControllerClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 15129 2011-11-02 15:32 DbClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 11712 2011-11-02 15:32 DbClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 8512 2011-11-02 13:30 GSMClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 7337 2011-11-02 13:42 GSMClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 8063 2011-11-02 13:24 GSMHandler.py +-rwxr-xr-x 1 gsmselftest gsmselftest 20346 2011-11-02 18:32 gsmselftest.py +-rwxr--r-- 1 gsmselftest gsmselftest 698 2011-11-02 18:36 help.txt +-rwxr-xr-x 1 gsmselftest gsmselftest 8661 2011-11-02 16:35 initTestClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 7497 2011-11-02 16:37 initTestClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 645 2011-10-20 17:54 LogFileClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1509 2011-10-20 17:54 LogFileClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 817 2011-10-20 17:54 PingClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1263 2011-10-20 17:54 PingClass.pyc +-rwxr--r-- 1 gsmselftest gsmselftest 3982 2011-10-20 17:54 ServerClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 4596 2011-10-20 17:57 ServerClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 4129 2011-10-20 23:17 ServerClassSoftware.py +-rw-r--r-- 1 gsmselftest gsmselftest 4802 2011-10-20 23:17 ServerClassSoftware.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 5252 2011-10-22 03:58 SIPHandler.py +-rwxr--r-- 1 gsmselftest gsmselftest 1267 2011-11-02 14:07 SSHTunnelBoxClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 1852 2011-11-02 14:19 SSHTunnelBoxClass.pyc +-rw-r--r-- 1 gsmselftest gsmselftest 323 2011-11-02 18:44 startSoftware.py +-rwxr-xr-x 1 gsmselftest gsmselftest 6378 2011-11-02 16:13 trueTableClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 4583 2011-11-02 16:16 trueTableClass.pyc +-rwxr-xr-x 1 gsmselftest gsmselftest 2248 2011-10-28 14:04 usbDetectClass.py +-rw-r--r-- 1 gsmselftest gsmselftest 3590 2011-10-28 14:05 usbDetectClass.pyc +\end{lstlisting} + +\subsection{Setting up the parameters} +After configuring the hardware, \emph{https} and \emph{.htaccess} on the web server, +it is important to modify the files for proper operations. In the given section you +can find out how to configure the rest of the files (e.g. database passwords, etc.). +The following files you have to modify to have a working database access: +\emph{initTestClass.py, GsmSelfTest.py, UsbDetectClass.py} and \emph{truthtableClass.py}. +\subsection{Test descriptions} +In the following section we will describe the tests that can be performed and what kind +of problems they can identify. There are five types of tests: +\begin{itemize} +\item Smart test +\item SIP test +\item GSM test +\item Everything test +\item Manual test +\end{itemize} +Each test will be described in the next subsections. +\subsubsection{Smart test} +\par The \emph{smart} test is not called smart without a reason. It tries automatically to identify +problems inside of the telecommunication network. The user is not required to define what kind +of tests have to be performed. In the first part the test software communicates with the +database to see what systems are available. In the next step it performs a call from the +University telephone system to a random local cell phone\footnote{Local cell phone or +local GSM network means our University GSM Network or RZ GSM.} +inside of our University GSM network. +While executing this task, automatically the Asterisk server, OpenBSC and a random nanoBTS +(or the one cell phone in RZ) are tested. The next task to be performed in the smart test, +a randomly selected cell phone inside of our local GSM network will try to call: a random +cell phone within the external (O2, Vodaphone,E-Plus or T-Mobile) or local GSM network. +This might test the external network and will test it with high probability, however the +probability exists to make a local to local GSM test call. In the third task, we perform +a test where we call from the landline a random cell phone inside of our local GSM network. +In the fourth or last task, we call from SIP to the service we did not test yet (e.g. +if we did not test the external GSM network using the second test task, then in this last +task we will exploit it). After the smart test had been completed you will be presented +with the results. +\subsubsection{SIP test} +The \emph{SIP} test option will perform test in such a way that all the SIP subsystems are +tested (SIP and University telephone network). It will try to identify if there are any +problems on the Asterisk server and our University telephone network, including incoming and +outgoing calls from the SIP side. +\subsubsection{GSM test} +In the \emph{GSM} test both GSM networks get tested, the local and the external GSM network. +We test the nanoBTS controller boxes (i.e. BeagleBoards) as well. Using this test, both incoming +and outgoing calls are performed, we can detect possible errors on the OpenBSC and the nanoBTS. +\subsubsection{All test} +The \emph{All} test selects all the given tests and executes them step-by-step. It is the test +that takes the greatest amount of time. While the test are performed, results are +immediately printed in the terminal window or on the web site. +\subsubsection{Manual test} +The \emph{Manual} test as the name itself says, is the test where you can manually select +what kind of tests you want to be performed. +\newpage +\subsection{Result descriptions} +In the following table one can see the messages returned by the test software! +These messages should guide the test user operator to debug the system. + +\begin{table}[h]\footnotesize + \begin{center} + %\caption[]{Table of error descriptions} + \begin{tabular}{| l | c | l | } + \hline + \textbf{Number} & \textbf{Code} & \textbf{Code number description} \\ \hline + 1 & 200 & Call was OK \\ \hline + 2 & 604 & General Handler Error: Destination handler did not respond. Timeout \\ \hline + 3 & 998 & General Handler Error: Could not connect to the destination handler! \\ \hline + 4 & 605 & General Handler Error: Caller handler did not respond. Timeout \\ \hline + 5 & 999 & General Handler Error: Could not connect to the caller handler! \\ \hline + 6 & 486 & Call Failed \\ \hline + 7 & 333 & Could not establish a connection to the database! \\ \hline + 8 & 100 & Missing account detail \\ \hline + 9 & 402 & Payment Required (E-Plus Card) \\ \hline + 10 & 801 & Connection to caller established, but the device does not respond \\ \hline + 11 & 802 & Connection to destination established, but the device does not respond \\ \hline + 12 & 501 & Destination server Internal Error \\ \hline + 13 & 502 & Caller server Internal Error \\ \hline + %\hline + + \end{tabular} + \end{center} +\end{table} + +The errors can be described the following way: + +\begin{itemize} +\item \emph{200}, Connection between the caller and callee was properly established +\item \emph{604}, Callee handler has a problem , a connection error between caller and callee +\item \emph{998}, Controller software cannot establish a connection and send messages to the callee handler but the destination handler is alive +\item \emph{605}, Caller handler has a problem during executing the test, a connection error between caller and callee +\end{itemize} +605, 'General Handler Error: Caller handler did not respond. Timeout' +Means that The caller handler having problem during the test task. Probably the connection between controller and caller handler having problem. + + +999, 'General Handler Error: Could not connect to the caller handler!' +Means that controller can’t make connection and send message to caller handler but the caller handler reachable from the server. + +486, 'Call Failed’ +The test task is failed. The connection between caller and destination are broken. + +500, 'Caller server Internal Error' +Means that the caller handler unreachable from the server. + +501, 'Destination server Internal Error' +Means that the destination handler unreachable from the server. + +333, 'Could not establish a connection to the database!’ +Could not login to the database MySql. + +100, 'Missing account detail' +Means can’t sign to the existing account at SIP server (SIP at asterisk, Landline at sipgate.de, SIP at University telephone network) due missing or incorrect information in the device address table. + +402, 'Payment Required (Eplus Card)'), +Error respond code for E-Plus card. + +801, 'Connection to caller establishment, but device error' +The device on the caller handler doesn’t connect properly or die. + +802, 'Connection to destination establishment, but device error'); +The device on the Destination handler doesn’t connect properly or die. + +\clearpage +\newpage +\subsection{Using the software} +In this section, you will be taught step by step how to use our test software. There are two options to run our test software, from the web site or the terminal. +The first is easier, but the second is easy as well however requires terminal skills. + +\subsubsection{Web site guide} +Once you enter the address in the address bar of your browser (e.g. \emph{https://localhost/\\testsoftware}). +You will be required to enter your username and password for the web page\footnote{The username and password creation process is explained in section 7.2.2.}. +If you entered the correct username and password you should see the same image as in the following figure. +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website1.png} + \caption[]{Web page of test software} +\end{figure} +Here you can choose what kind of test you want to perform or maybe if you want to configure the devices (manually or automatically). +If you press the ``Smart test'' button, you have to wait a few moments and the results should appear in a short amount of time. +However, if you pressed the ``Choose the test'' button, you will be presented with a new page, given in figure 28. +You will have to select the tests you want to perform manually or to press on the left side one of the given buttons for different +tests. You can choose between ``SIP Test'', ``GSM Test'', ``Check all'' and ``Uncheck all''. ``Check all'' will select all the possible +tests, whereas ``Uncheck all'' will deselect all of them. After you finished the procedure of selecting the tests, you should press the +``Submit'' on the left side. Wait a few moments and the results will start to appear in real time. After the table on the left is filled +(i.e. after all the tests have been completed) a result image will be generated on the right side, can be seen in figure 20. However, if +your pressed the ``Device configuration'' button, then you will end up on a page as given in figure 30. + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website2.png} + \caption[]{Manually selecting the tests} +\end{figure} + +If you press the ``Automatic configuration'' button, the test software will try automatically to match your cell phones with +their port addresses and numbers. However, if the automatic matching does not work, you will have to manually configure it. +You can do it by entering all the required information on the web site, as in figure 31. Once you correctly filled in the required +information, you should press the ``Submit'' button. + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{webpageReport.png} + \caption[]{Result web page} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website3.png} + \caption[]{Device configuration web page} +\end{figure} + +\begin{figure}[ht!] + \centering + \includegraphics[width=120mm]{website4.png} + \caption[]{Manual device configuration page} +\end{figure} +%\clearpage +\newpage +\subsubsection{Terminal guide} +In the following text, we will guide you and show you step-by-step how to use the test software from the terminal. All you have to +do is just type the command for starting the test software in the folder where it is located, \emph{./gsmselftest.py ---option} (keep +in mind there are two dashes before \emph{option}). +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{terminalCommand.png} + \caption[]{Test software terminal options} +\end{figure} +You can perform the tests manually by typing what you want to test or by choosing one of the predefined tests. For example, you +want to test manually does the SIP work with the University telephone network, you would type the following: \emph{./gsmselftest.py --db sip unisip}. +\begin{figure}[ht!] + \centering + \includegraphics[width=100mm]{resultterminal.png} + \caption[]{Example results from the terminal screen} +\end{figure} +After the tests have been performed the results will be displayed. Green result text means the test was performed successfully and red result +text means that something is not working properly. + +If you need to configure the cell phones manually or automatically, you can do it by typing: \emph{./gsmselftest.py --devconf} (keep +in mind there are two dashes before \emph{devconf}). Then you can press ``a'' on the keyboard for automatic configuration or ``m'' for +manual configuration. One should keep in mind that the terminal test software can be started even through \emph{ssh}, however with an +additional command \emph{-X}\footnote{For example: ssh -X username@address}. +\begin{figure}[htb] + \centering + \includegraphics[width=100mm]{devconf.png} + \caption[]{Test software device configuration from terminal screen} +\end{figure} + +\clearpage +\newpage +\section{Conclusion} +As a result of our successfully finished team project, we had felt how it is to work +in a team. We had learnt how to confront various software and hardware issues. The problems +were broken into smaller fragments and the solutions were derived in a step-by-step approach. +\par While designing the software, we kept in mind that every single step should be well thought-out, +documented, tested and validated. At the end we joined all the ``black-boxes'' together +into one big piece of software. We fulfilled our stated requirements and goals. +\par Despite the fact that our test software will be used by well educated engineers, we may +conclude that all the way along we thought about the usage-simplicity, safety and security +of our product. Our team members were enthusiastic about the idea that our team project will +contribute to a better performance and quality of the overall telecommunication network, +for all of the University staff and our colleagues, the students. +\newpage + + + +%bibliography start +\begin{thebibliography}{9} + +\bibitem{network} \emph{Projects based on RZ-GSM}, accessed on 10.06.2011, available at +\url{http://lab.ks.uni-freiburg.de/projects/gsm/wiki}. + +\bibitem{python} \emph{Python Programming Language - Official Website}, accessed on 10.06.2011, available at +\url{http://www.python.org/}. + +\bibitem{mysqlManual} \emph{MySQLdb User's Guide}, accessed on 05.06.2011, available at \\ +\url{http://mysql-python.sourceforge.net/MySQLdb.html}. + +\bibitem{wiki} \emph{[2011] GSM Selftest - Wiki - Lehrstuhl f\"{u}r Kommunikationssysteme}, accessed on 20.09.2011, available at \\ +\url{http://lab.ks.uni-freiburg.de/projects/gsm-selftest/wiki}. + +\bibitem{socket} \emph{17.2. socket - Low-level networking interface}, accessed on 20.06.2011, available at +\url{http://docs.python.org/library/socket.html}. + +\bibitem{spin} M. Ben-Ari \emph{Principles of the Spin Model Checker}, +Springer Verlag, Weizmann Institute of Science, Israel, ISBN: 978-1-84628-769-5, 2008. + +\bibitem{sshTunnel} R. Natarajan, \emph{3 Steps to perform SSH login without password using ssh-keygen \& ssh-copy-id}, accessed on 18.08.2011, available at +\url{http://goo.gl/fX68N}. + +\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{htaccess} \emph{EnablingUseOfApacheHtaccessFiles}, accessed on 18.08.2011, available at +\url{https://help.ubuntu.com/community/EnablingUseOfApacheHtaccessFiles}. + +\bibitem{pChart} \emph{pChart}, accessed on 15.08.2011, available at +\url{http://www.pchart.net/}. + +\bibitem{beagleDataSheet} \emph{BeagleBoard System Reference Manual}, accessed on 20.06.2011, available at +\url{http://beagleboard.org/static/BBSRM_latest.pdf}. + +\bibitem{proctitle} \emph{setproctitle 1.1.2}, accessed on 20.10.2011, available at +\url{http://pypi.python.org/pypi/setproctitle}. + +\bibitem{pjsip} \emph{Open source SIP stack and media stack for presence, im/instant messaging, and multimedia communication}, accessed on 20.10.2011, available at +\url{http://www.pjsip.org/}. + +%bibliography end +\end{thebibliography} + +%end of the document +\end{document} \ No newline at end of file diff --git a/documenting/Report/test.toc b/documenting/Report/test.toc new file mode 100644 index 0000000..b7618eb --- /dev/null +++ b/documenting/Report/test.toc @@ -0,0 +1,59 @@ +\select@language {english} +\contentsline {section}{\numberline {1}Introduction and Motivation}{4}{section.1} +\contentsline {section}{\numberline {2}Requirements}{5}{section.2} +\contentsline {subsection}{\numberline {2.1}Logical and algorithmic requirements}{5}{subsection.2.1} +\contentsline {subsection}{\numberline {2.2}Software requirements}{6}{subsection.2.2} +\contentsline {subsection}{\numberline {2.3}Hardware requirements}{8}{subsection.2.3} +\contentsline {section}{\numberline {3}Database design}{9}{section.3} +\contentsline {section}{\numberline {4}Software design}{12}{section.4} +\contentsline {subsection}{\numberline {4.1}Database access}{15}{subsection.4.1} +\contentsline {subsection}{\numberline {4.2}Controlling the cell phones}{15}{subsection.4.2} +\contentsline {subsection}{\numberline {4.3}Client and Server class}{16}{subsection.4.3} +\contentsline {subsection}{\numberline {4.4}Ping class}{17}{subsection.4.4} +\contentsline {subsection}{\numberline {4.5}Data logging}{18}{subsection.4.5} +\contentsline {subsection}{\numberline {4.6}SSH Tunnel Class}{18}{subsection.4.6} +\contentsline {subsection}{\numberline {4.7}USB Cell phone detection class}{19}{subsection.4.7} +\contentsline {subsection}{\numberline {4.8}Truth table class}{19}{subsection.4.8} +\contentsline {subsection}{\numberline {4.9}Init Test class}{19}{subsection.4.9} +\contentsline {subsection}{\numberline {4.10}Controller class}{20}{subsection.4.10} +\contentsline {section}{\numberline {5}Hardware design}{21}{section.5} +\contentsline {subsection}{\numberline {5.1}BeagleBoard}{21}{subsection.5.1} +\contentsline {subsection}{\numberline {5.2}Cell phones}{21}{subsection.5.2} +\contentsline {subsection}{\numberline {5.3}Cables for the cell phones}{22}{subsection.5.3} +\contentsline {subsection}{\numberline {5.4}Server}{22}{subsection.5.4} +\contentsline {section}{\numberline {6}Communication protocol}{23}{section.6} +\contentsline {subsection}{\numberline {6.1}Communication between the handler and controller}{23}{subsection.6.1} +\contentsline {subsection}{\numberline {6.2}Verification of the protocol}{26}{subsection.6.2} +\contentsline {section}{\numberline {7}Security and safety of the system}{28}{section.7} +\contentsline {subsection}{\numberline {7.1}Encryption of the communication channels}{28}{subsection.7.1} +\contentsline {subsection}{\numberline {7.2}Security on the web site}{29}{subsection.7.2} +\contentsline {subsubsection}{\numberline {7.2.1}Configuring the http secure protocol https}{29}{subsubsection.7.2.1} +\contentsline {subsubsection}{\numberline {7.2.2}Password protecting the web site using .htaccess}{32}{subsubsection.7.2.2} +\contentsline {section}{\numberline {8}Web page}{34}{section.8} +\contentsline {subsection}{\numberline {8.1}Communication between the web page and the test software}{34}{subsection.8.1} +\contentsline {subsection}{\numberline {8.2}Results on the web page}{34}{subsection.8.2} +\contentsline {section}{\numberline {9}Employing the test software system}{36}{section.9} +\contentsline {subsection}{\numberline {9.1}Required software and libraries}{36}{subsection.9.1} +\contentsline {subsubsection}{\numberline {9.1.1}Python installation}{36}{subsubsection.9.1.1} +\contentsline {subsubsection}{\numberline {9.1.2}Apache Web server installation}{36}{subsubsection.9.1.2} +\contentsline {subsubsection}{\numberline {9.1.3}SSH}{36}{subsubsection.9.1.3} +\contentsline {subsubsection}{\numberline {9.1.4}MySQL database and MySQLdb library}{37}{subsubsection.9.1.4} +\contentsline {subsubsection}{\numberline {9.1.5}Serial port library}{37}{subsubsection.9.1.5} +\contentsline {subsubsection}{\numberline {9.1.6}PJSUA library}{37}{subsubsection.9.1.6} +\contentsline {subsubsection}{\numberline {9.1.7}pChart library}{38}{subsubsection.9.1.7} +\contentsline {subsubsection}{\numberline {9.1.8}proctitle library}{38}{subsubsection.9.1.8} +\contentsline {subsection}{\numberline {9.2}Configuring hardware}{38}{subsection.9.2} +\contentsline {subsubsection}{\numberline {9.2.1}Configuring the cell phones}{40}{subsubsection.9.2.1} +\contentsline {subsection}{\numberline {9.3}Location of the files}{41}{subsection.9.3} +\contentsline {subsection}{\numberline {9.4}Setting up the parameters}{42}{subsection.9.4} +\contentsline {subsection}{\numberline {9.5}Test descriptions}{42}{subsection.9.5} +\contentsline {subsubsection}{\numberline {9.5.1}Smart test}{42}{subsubsection.9.5.1} +\contentsline {subsubsection}{\numberline {9.5.2}SIP test}{43}{subsubsection.9.5.2} +\contentsline {subsubsection}{\numberline {9.5.3}GSM test}{43}{subsubsection.9.5.3} +\contentsline {subsubsection}{\numberline {9.5.4}All test}{43}{subsubsection.9.5.4} +\contentsline {subsubsection}{\numberline {9.5.5}Manual test}{43}{subsubsection.9.5.5} +\contentsline {subsection}{\numberline {9.6}Result descriptions}{44}{subsection.9.6} +\contentsline {subsection}{\numberline {9.7}Using the software}{45}{subsection.9.7} +\contentsline {subsubsection}{\numberline {9.7.1}Web site guide}{45}{subsubsection.9.7.1} +\contentsline {subsubsection}{\numberline {9.7.2}Terminal guide}{47}{subsubsection.9.7.2} +\contentsline {section}{\numberline {10}Conclusion}{49}{section.10} diff --git a/documenting/Report/test_Use_case.png b/documenting/Report/test_Use_case.png new file mode 100644 index 0000000..637cd44 Binary files /dev/null and b/documenting/Report/test_Use_case.png differ diff --git a/documenting/Report/titlepic.sty b/documenting/Report/titlepic.sty new file mode 100644 index 0000000..befca4e --- /dev/null +++ b/documenting/Report/titlepic.sty @@ -0,0 +1,76 @@ +% titlepic.sty is a LaTeX package to show a picture on the cover produced by \maketitle. +% By Thomas ten Cate . Free software, no warranty of any kind. +% +% Version history: +% 1.1: now more self-contained, comes with a PDF manual +% 1.0: first release +% +% ----------------------------------------------------------------------------- + +% No idea whether it works on older LaTeXes. +\NeedsTeXFormat{LaTeX2e} + +% Package identification and version number. +\ProvidesPackage{titlepic}[2009/08/03 1.1 Package to display a picture on the title page] + +% Declare the options. +\DeclareOption{tt}{\gdef\@tptopspace{}\gdef\@tpsepspace{\vskip 3em}} +\DeclareOption{tc}{\gdef\@tptopspace{}\gdef\@tpsepspace{\vfil}} +\DeclareOption{cc}{\gdef\@tptopspace{\null\vfil}\gdef\@tpsepspace{\vskip 3em}} +\ExecuteOptions{cc} +\ProcessOptions + +% Define the sole command introduced by this package. +% Very similar to the definition of \title, etc. +\def\titlepic#1{\gdef\@titlepic{#1}} +\def\@titlepic{\@empty} % default: no picture + +\def\department#1{\gdef\@department{#1}} +\def\@department{\@empty} % default: no picture + +% If a title page was requested from the document class (article/report/book), +% override \maketitle to show our picture. +\if@titlepage +\renewcommand\maketitle{ + \begin{titlepage}% + \let\footnotesize\small + \let\footnoterule\relax + \let \footnote \thanks + \@tptopspace% + \begin{center}% + {\LARGE \@title \par}% + \vskip 3em% + {\large + \lineskip .75em% + \begin{tabular}[t]{c}% + \@author + \end{tabular}\par% + }% + \vskip 1.5em% + {\large \@date \par}% % Set date in \large size. + \end{center}\par + + \@tpsepspace% + {\centering\@titlepic\par} + \begin{center} + \@department + \end{center} + + \vfil + \@thanks + \end{titlepage}% + \setcounter{footnote}{0}% + \global\let\thanks\relax + \global\let\maketitle\relax + \global\let\@thanks\@empty + \global\let\@author\@empty + \global\let\@date\@empty + \global\let\@title\@empty + \global\let\@titlepic\@empty + \global\let\title\relax + \global\let\author\relax + \global\let\date\relax + \global\let\and\relax + \global\let\titlepic\relax +} +\fi diff --git a/documenting/Report/trueTable.png b/documenting/Report/trueTable.png new file mode 100644 index 0000000..4753844 Binary files /dev/null and b/documenting/Report/trueTable.png differ diff --git a/documenting/Report/uniLogo1.jpg b/documenting/Report/uniLogo1.jpg new file mode 100644 index 0000000..ba54fa9 Binary files /dev/null and b/documenting/Report/uniLogo1.jpg differ diff --git a/documenting/Report/uniLogo2.png b/documenting/Report/uniLogo2.png new file mode 100644 index 0000000..5dc939e Binary files /dev/null and b/documenting/Report/uniLogo2.png differ diff --git a/documenting/Report/usbDetectClass.png b/documenting/Report/usbDetectClass.png new file mode 100644 index 0000000..7233a53 Binary files /dev/null and b/documenting/Report/usbDetectClass.png differ diff --git a/documenting/Report/webpageReport.png b/documenting/Report/webpageReport.png new file mode 100644 index 0000000..75b9cf9 Binary files /dev/null and b/documenting/Report/webpageReport.png differ diff --git a/documenting/Report/website1.png b/documenting/Report/website1.png new file mode 100644 index 0000000..d5aab85 Binary files /dev/null and b/documenting/Report/website1.png differ diff --git a/documenting/Report/website2.png b/documenting/Report/website2.png new file mode 100644 index 0000000..2424706 Binary files /dev/null and b/documenting/Report/website2.png differ diff --git a/documenting/Report/website3.png b/documenting/Report/website3.png new file mode 100644 index 0000000..8be2732 Binary files /dev/null and b/documenting/Report/website3.png differ diff --git a/documenting/Report/website4.png b/documenting/Report/website4.png new file mode 100644 index 0000000..8e8ad6b Binary files /dev/null and b/documenting/Report/website4.png differ diff --git a/documenting/Report/website6.png b/documenting/Report/website6.png new file mode 100644 index 0000000..09d9884 Binary files /dev/null and b/documenting/Report/website6.png differ -- cgit v1.2.3-55-g7522