visualisation of tcpdump output - bathmdv/courses/cm30082/projects.bho/2009-10/pag… ·...

Visualisation of tcpdump Output

Alexander Page

Bachelor of Science in Computer Science with HonoursThe University of Bath

May 2010

This dissertation may be made available for consultation within the Uni-versity of Bath Library and may be photocopied or lent to other librariesfor the purposes of consultation.

Signed:

Visualisation of tcpdump output

Submitted by: Alexander Page

COPYRIGHT

Attention is drawn to the fact that copyright of this dissertation rests with its author. TheIntellectual Property Rights of the products produced as part of the project belong to theUniversity of Bath (see http://www.bath.ac.uk/ordinances/#intelprop).This copy of the dissertation has been supplied on condition that anyone who consults itis understood to recognise that its copyright rests with its author and that no quotationfrom the dissertation and no information derived from it may be published without theprior written consent of the author.

Declaration

This dissertation is submitted to the University of Bath in accordance with the requirementsof the degree of Bachelor of Science in the Department of Computer Science. No portion ofthe work in this dissertation has been submitted in support of an application for any otherdegree or qualification of this or any other university or institution of learning. Exceptwhere specifically acknowledged, it is the work of the author.

Signed:

Abstract

Tcpdump is a unix command which prints out information from captured packet headers.The output from the command is verbose and difficult to read. This gave motivation to aproject to ease the interpretation of tcpdump data by displaying it diagrammatically withannotations to identify key networking (TCP) characteristics. This results in a clearerrepresentation and a reduction in the time taken to read the raw tcpdump data.

This document discusses the implementation details of the program which parses a givenlog file and produce both a PDF document and an on-screen representation of the data.The program is also capable of annotating the visualisation with colours and labels whichare generated as a result of executing user-defined rules which specify patterns to matchagainst the tcpdump.

The resultant program successfully achieves the outlined tasks and forms a basis for furtherdevelopments which are discussed as part of the evaluation.

Contents

1 Introduction 1

1.1 Example output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Project requirements specification . . . . . . . . . . . . . . . . . . . . . . . 2

1.4.1 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4.2 Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.3 Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.4 Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.5 Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.6 Further Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Literature Survey 4

2.1 About tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Uses for tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Methods of viewing tcpdump data . . . . . . . . . . . . . . . . . . . . . . . 5

2.5 Visualisation of tcpdump data . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.6 Conversion from data to image . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6.1 PGF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6.3 Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

ii

CONTENTS iii

3 Requirements 11

3.1 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.2 Project Supervisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Non-functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.5 Requirements Critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Design 14

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4 Module design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4.1 Log Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4.2 Rules Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.4.3 Graph Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.5 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.6 Design conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Implementation and Testing 20

5.1 Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Detailed explanation of implementation . . . . . . . . . . . . . . . . . . . . 21

5.2.1 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.2 Log parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2.3 Rules engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2.4 Graph rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Implementation conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4.2 Testing environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

CONTENTS iv

5.4.3 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.4.4 Requirements Verification . . . . . . . . . . . . . . . . . . . . . . . . 29

5.4.5 Non-functional requirements verification . . . . . . . . . . . . . . . . 30

5.4.6 Testing Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6 Conclusions 32

6.1 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.2 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.3 Future works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.3.1 Rules Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.3.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.3.3 Visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.3.4 Real-time analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.4 Critical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

A Design Diagrams 38

B Test Files 42

C Test cases 43

D Screenshots 55

E Code 60

E.1 File: dumphandler.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

E.2 File: main.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

E.3 File: packet.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

E.4 File: pattern.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

E.5 File: renderarea.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

E.6 File: rule.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

E.7 File: rulesengine.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

E.8 File: tcpgraph.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

E.9 File: types.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

CONTENTS v

E.10 File: dumphandler.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

E.11 File: packet.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

E.12 File: pattern.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

E.13 File: renderarea.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

E.14 File: rule.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

E.15 File: rulesengine.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

E.16 File: tcpgraph.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

E.17 File: types.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

List of Figures

1.1 A single line of output from tcpdump . . . . . . . . . . . . . . . . . . . . . 1

2.1 Stevens’ tcp graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 tcp state machine generated by TikZ and PGF . . . . . . . . . . . . . . . . 8

2.3 UML diagram generated by TikZ and PGF . . . . . . . . . . . . . . . . . . 9

4.1 Program modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.1 Rule and pattern matching algorithm for a pattern of type average . . . . . 25

A.1 Graph visualisation display window design . . . . . . . . . . . . . . . . . . . 38

A.2 Design of tcpdump graph without additional annotations . . . . . . . . . . 39

A.3 Design of tcpdump graph with coloured rule match . . . . . . . . . . . . . . 40

A.4 Design of tcpdump graph with additional labels . . . . . . . . . . . . . . . . 41

D.1 Screenshot of the GUI. This is the initial view that is shown once processingis complete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

D.2 Screenshot of the GUI. This is the view of the interface once the user hasscrolled down. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

D.3 Screenshot of the GUI. This is an example of both colouring and labellingannotations with rules 19.xml. . . . . . . . . . . . . . . . . . . . . . . . . . 58

D.4 This is a screenshot of the generated PDF open in Preview. . . . . . . . . . 59

vi

List of Tables

5.1 Attribute types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2 Results from execution of test cases . . . . . . . . . . . . . . . . . . . . . . . 29

5.3 Functional requirements verification . . . . . . . . . . . . . . . . . . . . . . 30

vii

Acknowledgements

I would like to thank my project supervisor Dr. Russell Bradford, for providing the projectmotivation. I would also like to thank my colleagues for providing support throughout theprocess.

viii

Chapter 1

Introduction

The use of tcpdump is prominent in the world of networking. It is a command line packetanalysing utility that prints out the header of packets sent over the network in which thecomputer is connected to. One of the most common uses for tcpdump is network debugging.This is mainly due to the configurability of the tool which allows users to specify variousoptions which allow for the selection of relevant data. The output can then be parsed intoother programs which analyse and report on problems or inconsistencies, resulting in anautonomous way to diagnose and troubleshoot network faults. Due to the nature of packetheaders, the instructions they contain are not intended to be human readable. It is difficultfor an administrator to quickly observe the current state of a network, instead they need tomentally decode each packet and build up a picture of the network communications thatare taking place. This has lead to an interest in trying to visualise this data in order tospeed up the process of deciphering tcpdump output.

1.1 Example output

09:57:58.262567 IP 138.38.174.243.58721 > 138.38.159.143.80: Flags [S],seq 3090222848, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val 54544112 ecr 0,sackOK,eol], length 0

Figure 1.1: A single line of output from tcpdump

Figure 1.1 shows the amount of information packed into just one line of a tcpdump output.The most commonly useful elements are the source and destination IP, flags, sequencenumber (seq), window size (win) and length. Given even just a few more of these lines andit is immediately clear that analysing these logs is a lengthy and tiresome process.

1

CHAPTER 1. INTRODUCTION 2

1.2 Aim

The purpose of this project is to develop a system which takes the output from the tcpdumpcommand and visualises it in such a way that improves the representation of the data tospeed up analysis. This representation should not only reproduce what is seen in the log filebut also include annotations which help to explain that data. The main use of this kind ofrepresentation is twofold. The first use is for network administrators who use the tcpdumpcommand as part of their job. This will help them to view the information in another wayand hopefully speed up fault diagnosis or help identify ways in which the efficiency of theirnetwork can be improved. Another use for this project is for educational purposes. Theteaching of networking (TCP/IP) concepts can be dry and difficult to illustrate. One wayof teaching phenomena such as TCP connection establishment would be to display real-lifepacket capture in a diagram with the relevant packets clearly displayed. This would helpstudent to understand what is occurring.

1.3 Objectives

• Execute the tcpdump command and study the output. Learn to understand thepacket structure and information.

• Investigate ways of visualising information graphically. Find graphics packages thatwill take a text input and create a diagram according to certain rules.

• Create a transformation between the raw tcpdump output and the required input tothe graphics application.

• Extend this transformation by applying some logic to the parsed tcpdump in orderto annotate the produced diagram.

1.4 Project requirements specification

1.4.1 Deliverables

There should be two main software milestones. The first implementation should produce adiagram given some static raw tcpdump data. The second version should extend the firstwith an annotated diagram to display more useful diagnostics which will be decided uponand specified at a later date. The minimum achieved should be a diagram which shows theclient and server communications.

CHAPTER 1. INTRODUCTION 3

1.4.2 Diagram

The diagrams should consists of the client and server addresses on opposite sides witharrows between the two and annotations along these arrows and alongside the client andserver address. As an example see Stevens’ Book (Stevens, 1996)

1.4.3 Annotations

The annotations should provide more information than the raw tcpdump itself. It shouldbe possible to derive useful information from the original dump that can then be displayedon the diagram. An example of this may be noting where a connection begins and ends andthen displaying this, perhaps with a colour coding. More details on this will be availablefurther into the project after researching the usage of tcpdumps.

1.4.4 Version

The version of tcpdump should be that developed by Van Jacobson, Craig Leres andSteven McCanne, all of the Lawrence Berkeley National Laboratory, University of Califor-nia, Berkeley, CA. This version is available at http://www.tcpdump.org/ (Jacobson, Leresand McCanne, n.d.b)

1.4.5 Exclusions

The scope of this project extends as far as a 2 dimensional diagram representing tcp com-munications. It is important to note that the focus is in providing as much useful detailas possible rather than producing more visually enticing graphics such as extending to 3dimensional representations.

1.4.6 Further Scope

If the requirements outlined above are met within the allowed timeframe, further workshould look at doing the same thing in real-time and also providing even more annotationsbased on the data.

Chapter 2

Literature Survey

2.1 About tcpdump

The tcpdump tool was developed at the Lawrence Berkeley Laboratory at the Universityof California, Berkeley, by Van Jacobson, Craig Leres, and Steven McCanne. It was origi-nally developed to improve the performance of TCP/IP by discovering problems that areexposed by analysing packet headers. The tool is freely available on most systems archi-tectures including most versions of Unix and Windows (O’Reilly, n.d.). This fact suggeststhat the tool developed for this project which will visualise the tcpdump data should becross-platform compatible, allowing any users of the tcpdump dump program to pipe theiroutput into the visualisation tool and view the results. The most obvious language that isappropriate for this would be Java. A program written in Java can be run on any machinewhich has the Java virtual machine.

It is also widely known that the output is difficult to read, particular in hexadecimal format(Kretchmar, 2004), this makes it necessary to have some other tool to aid deciphering theoutput.

2.2 Uses for tcpdump

As already mentioned the main use for tcpdump is for network debugging. The programcan also be used for troubleshooting network problems, intrusion detection, logging networktraffic, discovering a faulty network card and even for forensics and evidence (Fuentesand Kar, 2005). Tcpdump can also be used in educational environment to help studentsunderstand the communications between computers at a low level. This wide variety ofuses reinforces the importance of a tool which aids readability of the tcpdump output.

4

CHAPTER 2. LITERATURE SURVEY 5

2.3 TCP/IP

Development began on the TCP/IP protocol suite in the 1960s by government funded re-search (Stevens, 1996). This is now used as the standard system for networking computers.The protocol is divided into four different layers; Link, Network, Transport and Applica-tion. Each layer is responsible for a different task. It is the Transport layer which we areinterested in for this project.

Link: Responsible for the physical connection between computers.

Network: Controls the movements of packets around the network.

Transport: Responsible for the flow of data between hosts.

Application Handles the network data sent and received by applications.

The TCP protocol falls into the transport layer, this is the layer in which tcpdump allowsus to examine. Each TCP segment has the following information in its header, whichtcpdump records.

• Source address & port

• Destination address & port

• Sequence number

• Acknowledgment number

• Window Size

• Flags/Options

This is the information that needs to be visualised.

2.4 Methods of viewing tcpdump data

The tcpdump command allows the user to choose how the output is formatted. This rangesfrom how the timestamp is printed, to how much network information is included and theverbosity of the output. For example, the ’-a’ switch tells the tool to try and resolvenetwork addresses to names (Jacobson, Leres and McCanne, n.d.a). This demonstratesthat there is not one standard form of output which a tcpdump visualisation programwould need to parse. A tcpdump visualisation program would have to be able to adjust itsparsing technique to allow for the style of the given input. This could be done in a numberof different ways. An ideal way to do this would be that the parser i.e. the part of the


visualisation program that reads the input, recognises which type of input is present andso does not try to visualise data that it knows is not available in the input. This could beimplemented by using regular expressions to test for a set of rules which define what typeof input is given. A less automated way would be for the user to specify which switcheswere passed to the tcpdump command which generated the given output. This way theprogram would know what data is available. This is not ideal, but a feasible method.

From the above finding, one could conclude that the tcpdump visualisation program shouldbe flexible in parsing different forms of tcpdump data.

2.5 Visualisation of tcpdump data

The standard tcpdump output is just text. This is verbose and not very easy to read. It isnecessary to explore different ways of displaying this data.

There are already programs available which visualise tcpdump data. One of these attemptsto do this in 3D. An example is 3d-tcpdump (UKAI, n.d.) although it is not clear if thisproject was completed and does not appear to be available for download. There is howevera video demonstration of the program running. From this it is clear that the program runsin real-time and machines are only visible whilst they are interacting with the computerrunning tcpdump. As soon as communication ends, the representation of them disappearsfrom the 3d image. This is obviously done to avoid cluttering the image over time whenmany transactions have taken place. However, it means that one cannot analyse the dataafter this moment has passed. It is not clear if the program allows to playback partsof the capture to analyse what type of messages have been sent but from viewing thedemonstration it seems important for this feature to be available.

The most popular packet inspection tool is Wireshark. This program allows users to capturepackets and analyse the results. This does not visualise the data into an image in the waythat 3d-tcpdump does, but instead organises in such a way that allows the user to easily seethe different types of packet by colouring them according to ”colouring rules”(Combs, n.d.). It displays the list of packets in the top half of the window and then a detailed descriptionof the selected packet at in the bottom half of the window. This is different to 3d-tcpdumpin that it does not focus on the link between packet source and destination (although itdoes include these details) but rather the actual contents of the packets themselves. Itallows the user to filter the packets so only those of interest are shown. For example,one could filter for HTTP packets or DNS. This tool could be considered not so much as atcpdump visualisation but more of an interface to filter and organise tcpdump data makingit more searchable and easier to navigate. This could speed up the process of debugginga particular problem. For example, if the user knows that a problem lies with DNS, theycould filter for those packets in particular. This program seems good for helping a usernavigate captured packets, but doesn’t do much in the way of displaying actual activitygraphically between computers. The focus of this project is to visualise tcpdump datatherefore where 3d-tcpdump removes a large amount of information, Wireshark includes


all the data. The program developed for this project needs to be somewhere between theseprograms in terms of the way it displays the data.

Computer programs are not the only time in which visualisation of network communicationoccurs. This also happens in text books to explain the theory behind networking. Stevensuses a particular method of graphing TCP which may well be beneficial for this project(Stevens, 1996).

Figure 2.1: Stevens’ tcp graph

Figure 2.1 demonstrates this technique of displaying the client on the left and the server onthe right. It shows the direction in which the packet was sent and also displays tcp actioninformation such as ’ack’. This information is more relevant to the scope of the projectbecause it allows a user to see an overview of what is happening in TCP communicationrather the more granular view given by Wireshark, which shows individual packet contents.

If the program is to produce output as in figure 2.1, there is a requirement for some methodof translating between tcpdump data and an image like the one shown.


2.6 Conversion from data to image

2.6.1 PGF

There seem to be a limited number of programs available that allow you to create graphicsprogrammatically but one that does exist is TikZ and PGF. PGF is a macro package forLatex which is for generating graphics. TikZ is a user-friendly syntax layer. This wouldmean that a program could parse the tcpdump data and convert it into a format readableby the PGF macro (Tantau, n.d.). This would then convert the text into a graphic. Hereare some examples of what is achievable by using this macro.

CLOSED

LISTEN

SYN SENTSYN RCVD

ESTABLISHED

FIN WAIT 1

FIN WAIT 2

CLOSE WAIT

CLOSINGLAST ACK

TIME WAIT

Passive open Close

SYN/SYN + ACK Send/SYN

Timeout/RSTClose

Active open/SYN

SYN/SYN + ACK

Close/FIN

ACK SYN + ACK/ACK

Close/FIN FIN/ACK

ACK

ACK

FIN +ACK/ACK

FIN/ACK

ACK

Close/FIN

ACK

Timeout after two maximumsegment lifetimes (2*MSL)

Figure 2.2: tcp state machine generated by TikZ and PGF

Figure 2.2 is a much more complicated example than those used in Stevens’ text, butactually illustrates tcp data and is therefore relevant.


:SimulationServer :SimControlNode :PhysicsServer :SenseServer:SimulationServer :SimControlNode :PhysicsServer :SenseServer

Initialize()

StartCycle()

ActAgent()

Update()

PrePhysicsUpdate()

state

PhysicsUpdate()

PostPhysicsUpdate()

EndCycle()

SenseAgent()

Run LoopRun Loop

Figure 1: UML sequence diagram demo.

Figure 2.3: UML diagram generated by TikZ and PGF

The style of figure 2.3 is much similar to the image in (Stevens, 1996) text, but is of coursemore complicated. The first part of the image (Initialize()) would be the style of graphicgenerated by tcpdump visualisation. I.e. direct communication between client and serverwith no intermediary.

Both images are very specific in the way the data is displayed. After some amount ofexperimentation it is clear that we will not be able to adapt the macro to display the graphin the way Stevens’ represents TCP data. As a result, it is necessary to explore alternativesto visualising information.


Many high-level programming languages provide libraries that can be used to draw images.Two of these languages are explored.

2.6.2 Java

The java.awt.geom package (Microsystems, n.d.) is designed for drawing of 2D geometricshapes.

The abstract class Line2D is the superclass of Line2D.Double and Line2D.Float. Either ofthese classes could be used to draw the lines which represents packets, going from right-to-left and left-to-right and also any other other lines required in the image. These classesrepresent straight lines, where as arrows are required. To achieve this a similar class couldbe used that will produce a polygon (triangle) given three coordinates. This would bepositioned at the tip of the arrow.

2.6.3 Qt

The QPainter class (Corporation, n.d.) provides support for drawing many different shapesonto paint devices. This would include a graphical user interface and also a file that wouldbe used store the tcpdump visualisation. Unlike Java, it has functions rather than classesthat are used to draw the various shapes necessary to produce a visualisation.

2.7 Conclusion

From the survey of available literature it can be concluded that the tcpdump data shouldbe represented in a graphical way with arrows pointing between communicating computers.This graph should be annotated with relevant tcp information.

The research into TCP has highlighted the relevant fields which we we wish to display onthe graph.

The research into visualisation has revealed that PGF is far too restrictive in how it gen-erates images. This means it will not give enough control to produce the image which issimilar to Stevens’ graph. We have learnt that the QPainter class that is part of Qt allowspainting using a coordinate system which will allow us to produce images exactly as wewant them.

The tcpdump data will be parsed and converted into a representation that is easier tovisualise. This means that the program should easily be able to discover the direction ofthe arrow and the information that should be displayed alongside it.

Chapter 3

Requirements

3.1 Sources

In order to produce reasonable requirements the sources selected for requirement deductionare important. Due to the developmental nature of the project rather than one that isresearch oriented, most requirements have to be formed from own decisions and have notstemmed from surveying potential users and asking questions like ‘what would make packet-analysis easier?’.

3.1.1 Literature Review

The literature survey allowed for identification of what had already been achieved in thisfield and what would be possible to develop upon. It was discovered that there were applica-tions in existence which made the process of running a tcpdump simpler and displayed thedata in different text forms but there is little in the way of packet analysis and visualisation.

3.1.2 Project Supervisor

The project supervisor has advanced experience within this field of study and was able tomake suggestions as to where to focus the project. For example, it was suggested that theanalysis feature was more important than real-time visualisation.

3.2 Functional Requirements

The following functional requirements have been decided upon.

1. The program should be capable of parsing the output from the tcpdump command

11

CHAPTER 3. REQUIREMENTS 12

executed on a Unix computer.

1.1 The system will only be able to handle tcpdump data between two computers,source and destination.

1.2 The first packet in the tcpdump output will be declared the source and the nextpacket that does not match the source address will be declared the destination.

2. The program will produce a graph which represents communication between sourceand destination computers.

2.1 The graph will consists of straight lines with arrow tips indicating a packettravelling from source to destination or vice versa.

2.2 Packets originating from the source address will begin on the left hand side ofthe graph.

2.3 Packets originating from the destination address will being on the right handside of the graph.

3. The program will accept an optional rules file which will define one or more patternsto look for in the input log file.

3.1 The rules file should be written in XML.3.2 The rules file will contain one or more rules.3.3 Each rule will contain patterns to match the rule upon.3.4 A pattern contains information explaining the following information;

3.4.1 Which field in tcpdump log file to examine.3.4.2 Which value to compare it to.3.4.3 Which order this packet should occur in relation to other patterns within

the rule. For example, 1st, 2nd, 3rd etc.3.5 If the program is passed an invalid rules file it should display an error and exit.

4. When rules from the input rules file are matched, various annotations will be addedto the graph.

4.1 It should be possible to specify within the rules file the annotations to be added.4.2 Colouring of the relevant packets should be one of the annotations.4.3 Labelling of the relevant packets should be one of the annotations.

5. The graph should be displayed both on screen and written to a file for later viewing.

5.1 The file format for the saved graph should be PDF.

6. The program will be executed from the command line and will take a series of argu-ments defining the following things.

6.1 The location of the tcpdump file.6.2 Optionally: The location of the rules file.6.3 Optionally: The filename and location of the output file.

CHAPTER 3. REQUIREMENTS 13

3.3 Non-functional Requirements

1. The program should run on as many operating systems as possible.

2. The program should be useable by those who are colourblind.

3. The program should not crash when given an invalid log file.

3.4 Conflicts

The decision had to be made as to whether the program should focus on ease of use orfunctionality. Ultimately, it would be preferable that both options were fulfilled completelybut little development time meant the focus had to be given to one or the other. Choosingfunctionality over user interface would give more control over the tool for developers asthey would be able to better automate graph generation. This could be done by havingscripts which call the program with different arguments and rule files. Although having auser interface would make the tool more accessible to those with less technical experience.Arguably, it is those with experience of the command line interface that would find tcpdumpvisualisation most beneficial. It was this reason that led to the decision to have the programrun solely from the command line. Adding a user interface at a later stage would be arelatively trivial process due to the model, view, control paradigm.

3.5 Requirements Critique

The requirements gathering and specification process for a software project is useful as aguideline to begin design. However it is difficult to stick to these requirement entirely aslater on in the software cycle discoveries are made that mean requirements must change.Due to the short time-span of this project it was decided that the waterfall model as de-scribed by (Sommerville, 2006) would be used with little iteration. Perhaps more usefulrequirements could have been obtained by sending out questionnaires to network admin-istrators in order to obtain specific data identifying their needs and wants. Instead, theprogram was developed in a way that made it as customisable as possible (with the intro-duction of the rules system).

Chapter 4

Design

4.1 Introduction

The previous section outlined the requirements for the program. This section will refer tothose requirements and discuss how those requirements will be implemented.

4.2 Architecture

The program consists of four major modules (figure 4.1). These are log parsing, rules engineand graph rendering. They are driven from a control class. The design of each componentis given in detail. It was important to separate each of these modules because this allowsfor easy maintenance and simplifies future development of the system.

Graph Rendering

Control Module Rules EngineLog Parsing

Figure 4.1: Program modules

14

CHAPTER 4. DESIGN 15

4.3 Data Types

The following custom data types are required.

Packet - Each instance of this class represents one line of the input tcpdump file. Itcontains variables which hold the values of each field and also additional information setby the rules engine defining how the packet should be visualised.

Rule - Each instance represents a rule in the input rules file. The object holds the infor-mation stating what to do when the rule is matched and also one or more Patterns.

Pattern - This represents a pattern in the input file. This contains information specifyingwhich fields to look for and what values to compare them with in order to decide whethera rule is matched or not.

4.4 Module design

4.4.1 Log Parsing

In order to process the tcpdump output. It must be transformed to a representation whichis more suitable for use within the program. This is done by the log parsing module. ThePacket type described above is the end-goal representation for each line of the tcpdump.A list of these Packets will give an exact representation of the log.

Different versions of the tcpdump command along with the various switches that can beused to filter and transform the data mean that the output from the command varies.With this in mind, it was necessary to decide how to account for the different formats. Thedevelopment environment for the project is Mac OS X and the program is hard coded toread tcpdump files produced on this machine. This means that it will not read files createdon other operating systems. A solution to this problem has been found which involvescreating a template file which defines the format of the tcpdump output i.e. the order offields and the regular expressions which identifies those fields. This file would then be readby the log parser in order to learn where to find each field in the given tcpdump.

It is the responsibility of the log parsing module to handle file open, read and close for therules file.

4.4.2 Rules Engine

The rules engine is responsible for handling the part of the program which allows users tospecify patterns which are then matched against the tcpdump file.

It was decided that the program should be as dynamic as possible with regards to recog-nising TCP/IP characteristics. Users are likely to have their own requirements and maywish to look for things which are not a standard TCP/IP activity. There were two options;


hardcode as many patterns to look for as possible or create a system which allows usersto specify their patterns. The latter option was the obvious choice. This meant that theexact requirements of the user could be implemented by the user themselves allowing for amore flexible tool which does not stick to the rigid rules of our own development.

It is as a result of this design decision that the rules engine was devised. The system wasis given the following tasks:

• Process the user-defined rules file.

• Analyse packets to decide whether they match any rules.

• Add details to packets which match rules so that render area can display correctdetails.

The module must read the file into a list of the Rule/Pattern objects (described earlier).This allows access to the rules for the next stage, processing.

Once the log parsing module has completed its task, the Packet objects should be examinedfor those which match rules.

Rules File

The rules engine accepts an XML file (defined in listing 4.1) which contains the rules definedby the user. The program would be distributed with a template file which contains rulesfor discovering some simple TCP characteristics. An example file is shown in listing 4.2which will identify packets that contain the ACK flag.

Explanation of rules file:

<rule name="ACK">

Introduce a new rule and give it a name.

<pattern type="average" match="win" order="1" count="5" origin="source">5200-5500</pattern>

Add a pattern to the rule. Each pattern has the following attributes:

• type:constant - match the given string for each packet.average - (for integer fields) calculate the average and compare to given number orrange.

• match: Which field in the packet header to examine.


• order: The order the pattern should appear (for use with rules that have multiplepatterns). Default = 1

• count: (for patterns of type average) How many consecutive packets to include in theaverage calculation.

• origin: Specify whether to look only at packets originating from the source (thecomputer that initated the connection) or destination machine. If left blank, willmatch both.

The above pattern would match on five consecutive packets originating from the sourcemachine with an average window size between 5200 and 5500 inclusive.

<result type="colour" value="blue"/>

Define what will be done when this rule is matched.

• type:colour - Change the colour of the corresponding packets.label - Add a label to the corresponding packets.

• value: The colour or label to add.

The above result would colour blue any packets that match the rule.

<?xml ve r s i on=” 1 .0 ”?><xs : schema>

<xs : element name=” ru l e s ”><xs : complexType>

<xs : sequence><xs : element name=” ru l e ” maxOccurs=”unbounded”><xs : complexType>

<xs : a t t r i b u t e name=”name” type=”xs : s t r i n g ”/><xs : a l l >

<xs : element name=” pattern ” maxOccurs=”unbounded”><xs : complexType>

<xs : a t t r i b u t e name=” type” type=”xs : s t r i n g ”/><xs : a t t r i b u t e name=”match” type=”xs : s t r i n g ”/><xs : a t t r i b u t e name=” order ” type=”xs : i n t e g e r ”/><xs : a t t r i b u t e name=”count” type=”xs : i n t e g e r ”/><xs : a t t r i b u t e name=” o r i g i n ” type=”xs : s t r i n g ”/>

</xs : complexType></xs : element><xs : element name=” r e s u l t ”>

<xs : complexType><xs : a t t r i b u t e name=” type” type=”xs : s t r i n g ”/>

<xs : a t t r i b u t e name=”value ” type=”xs : s t r i n g ”/></xs : complexType>

</xs : element></xs : a l l >

</xs : complexType>


</xs : element></xs : sequence>

</xs : complexType></xs : element>

</xs : schema>

Listing 4.1: XML Schema Definition for rules file

<?xml ve r s i on=” 1 .0 ” encoding=”ISO−8859−1”?><ru l e s >

<r u l e name=”ACK”><pattern type=” constant ” match=” f l a g ” order=”1” count=”1”>.</pattern><r e s u l t type=” co lour ” value=”blue ”/>

</ru le></ru l e s >

Listing 4.2: Example rules file for identifying packets containing ACK

4.4.3 Graph Rendering

This module is responsible for drawing the graph, displaying it on screen and generatingthe PDF file. The input will be a list of Packets created by the log parser and modified bythe rules engine.

The main problem for the graph rendering component is how to display the data. Therequirements specify that packets must be displayed as arrows from source to destinationand back. A decision must also be made as to how to display the additional labels i.e. thepacket headers and any information from the rules engine.

The program is executed from the command line with arguments and xml files controllingthe functionality. Therefore the interface to display the graph does not need to be inter-active. It only serves one purpose, as stated in the requirements; “to display the graphon screen”. Figure A.1 illustrates the desired look for this interface. Noticeably, the onlyinteraction that the user will have with the program is with the scroll bar which will allowthe user to see the entirety of the image.

Figure A.2 shows the design for the basic graph without any added data from the rulesengine. The source IP address will be displayed on the left and the destination on theright. To the left hand side of each arrow is the time the packet was sent which must beconverted to a relative time in seconds and milliseconds rather than the actual time givenin the packets timestamp.

The two ways which are going to be implemented for the rules engine to display resultsare colouring of the packets and adding a label next to the corresponding packets. This isshown in the design figures A.3 and A.4.


4.5 Usage

The program must be executed from the command line, as stated by the requirementsdocument. It should be possible to run it in the following way:

./tcpdumpvis <tcpdump_filename> [-r rules_filename] [-o pdf_filename]

This means that the only mandatory argument is the tcpdump filename. Optionally, therules file can be specified with the -r switch and giving the filename and the pdf specifiedwith -o and its filename.

4.6 Design conclusion

The design stage highlighted the main modules of the program and discussed their tasks ata high level. This abstraction allowed for identification of the interfaces between moduleswithout worrying about implementation details.

The design stage could have been reinforced at this point by referring back to the require-ments and verifying that each requirement has been considered in the design.

Chapter 5

Implementation and Testing

This chapter is a review of the implementation algorithms, issues, testing and a critique ofthese processes.

5.1 Language

Consideration of which language to use was taken in order to achieve a successful develop-ment. The main technical features which the language must provide for were examined.

• Reading from text files.

• Parsing XML files.

• Drawing graphs.

• Creating PDF documents.

It is of course possible to perform these tasks in the majority of high-level languages,perhaps by using additional libraries, therefore the task was selection of a language mostappropriate based on simplicity, minimal dependencies and ease of use.

Java was the initial language of choice, with a vast collection of libraries to choose from,however this language was rejected in favour of Qt. Qt is a cross-platform frameworkusing C++. The reason it was chosen instead of Java is because it provides better supportfor drawing with the use of the QPainter class. The language is heavily designed aroundcross-platform support and is not dependant on a virtual machine. This would allow forextension amongst all variants of unix/linux operating systems which is crucial for thesuccess of the tool.

20

CHAPTER 5. IMPLEMENTATION AND TESTING 21

5.2 Detailed explanation of implementation

5.2.1 Control

This is the module (class TCPGraph) which is responsible for interfacing between the otherfunctional modules (see figure 4.1).

The process begins with the sorting of command line arguments. There must be a minimumof two arguments for the program to function, this is the location of the tcpdump log fileand the command used to run the program (which by default is always the first elementin the argument list). The maximum number of expected arguments is six, anything moreand the program prints usage information and exits. The third argument is examined, if itis “-r” then the following argument is the location of the rules file and if it is “-o” then thefollowing argument is the desired name of the PDF output. The same process is appliedto the 5th and 6th arguments.

The control module now initialises the graph rendering class (RenderArea) which is alsoresponsible for the Packet list. A pointer to this list is retrieved from RenderArea and passedto the rules engine which is initialised and parses the rules file. This allows both modulesto access the same Packet list, the list of Packet objects which contain the informationabout each line of the input file.

The log parsing module (DumpHandler) is now initialised and receives an argument whichcontains the location of the log. The DumpHandler parsing function is called repeatedlyand each time it returns a hash table of the fields contained in the next line of tcpdumpoutput. The control module takes the values in this hash and creates a new Packet object.This Packet is passed to the RenderArea which adds it to the Packet list).

Once this process is complete, all Packets have been created and are processed by the rulesengine.

Finally, the visualisation must be generated. The size of the window must be set - thewidth is always constant but the length varies depending on the number of packets. It isknown how much space each packet takes up on-screen so this is multiplied by the numberof packets to get the total length of the window which is enclosed in a scroll area. AQPrinter is created and passed to a function within the rendering module which createsthe PDF. The RenderArea is then displayed on the screen.

5.2.2 Log parsing

The only function this module has is to read the tcpdump log file line by line and return ahash table (QHash) of the fields (packet headers) which are contained within that line. Thedecision which had to be made was how to separate those fields. Each field is separated bywhitespace. Therefore the line is split into an array by whitespace character.

10:55:39.474882 IP 192.168.2.148.53249 > 192.168.2.57.hbci: Flags [S],


seq 3176377061, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TSval 33437871 ecr 0,sackOK,eol], length 0

When the line above is split, it produces the following array (only first part shown):

[0] 10:55:39.474882

[1] IP

[2] 192.168.2.148.53249

[3] >

[4] 192.168.2.57.hbci:

[5] Flags

[6] [S],

[7] seq

[8] 3176377061,

We can use the known positions for each of the standard fields to assign their values into theQHash. For example, timestamp will always be at position 0 and source address at position2. Notice, in the example line given and all other lines that the timestamp is followed bythe word “IP” and the source and destination are separated by the character “>”. It isknown that these characters are stored in the array at position 1 and 3 respectively so wejust ignore these. Note that for the destination address at position 4 we have to removethe last character, the ‘:’ before adding the value to the QHash.

From position 5 onwards, the order in which fields appear is not certain. To tackle thesefields we look at each position and compare the string to different possibilities. If thestring is identifiable then we know that the i+1 position holds the value for that field. Forexample, we discover that position 5 matches the word “Flags” which means position 6holds the flags value to add into the QHash. We apply the same logic to positions 7 and 8to get the sequence number and continue with this for the remaining elements.

Once all fields are added, the hash table is returned to the control module which builds thePacket.

5.2.3 Rules engine

The rules engine is responsible for both parsing the rules file and processing the packets tospot sequences which match the user-defined rules.


Processing rules

This begins by opening the rules file and reading it into memory (QDomDocument). Eachrule element is extracted into a list. We now wish to process each rule in order to createa representation of it within the program. For each rule we create a new Rule object.Every child of rule is either a pattern or a result. The Rule and Pattern classes containaccessors and mutators for each of their properties where as pattern and result elementsrepresents each of their properties as an XML attribute. In order to find their associatedaccessor and mutator, a programming feature called reflection is used. This works bybuilding a string based on the attribute name, which will then match the mutator functionname. For example, the attribute count would mean construction of the function namesetcount(). This enables the rules engine to call the correct mutator based on the attributename and improves maintainability. If we need to add a new attribute to the Pattern or Ruleclass, it is just a matter of adding the variable and its associated accessors and mutatorsand the rules engine will be able to process those attributes without any of its code beingchanged.

It does get slightly more complicated because attributes have different types and thereforedifferent mutators will have different parameter types. Table 5.1 shows the different typesan attribute could hold. This is important because when calling the mutator function usingreflection we cannot just specify empty parenthesis as shown in the example above, we haveto give the correct parameter type also in order to be able to call that function. We mustalso find out whether to convert the attribute value to an enumerated type or leave the valueas it is. This is done by building three different strings, one for each type. For the examplegiven above we would build; setcount(QString), setcount(int), setcount(long). Qthas a function which allows us to find the index of a given function name, it returns -1 ifno such function exists. Therefore we call this lookup on all three of the built strings. Twowill return -1 and one will return a valid index. We now know the type of the attribute weare dealing with and can convert it to an enumerated type if necessary (when the type isint) and call the correct mutator to set the value.

Table 5.1: Attribute typesType Used For ExampleQString Custom strings for colours; “blue”, “green”long Any integer For defining expected window size: 1335int Enumerated types {ACK, SYN, WIN}

The program uses enumerated types to represent the different packet headers or patterntypes (constant or average). This allows for faster integer comparisons rather than stringcomparisons when iterating over data. Naturally, in the rules XML, the different headersare referred to by their names. We need to convert these names to their enumerated type.In Qt it is not possible to convert from a string to the enumerated type that has alreadybeen associated with it. In order to do this a helper function has been implemented to


store a mapping between the string itself and its integer representation.

Finally, to call a function using reflection you must pass in the object that holds thefunctions you wish to access. In order to pass in the correct object depending on whetherthe child is a pattern or a result, we perform a string comparison on it’s node name andassign either the pattern or the rule object to a parent variable QObject which is thenpassed into the reflection call. This means we do not have to have two sets of reflectivecalls for both patterns and results.

This is repeated for all other rules and completes the rule parsing stage.

Rule matching

Once all rules and packets have been parsed. The program applies the rules to the packets.The rule matching works by iterating over rules, patterns and packets. It begins by takingeach rule in turn and setting a ‘base’ index into the list as 0, the first packet in the list.The rule is applied to the packets beginning from the base index, any matches are handledand then the base increments.

When a rule is applied, each pattern within the rule is taken in turn. If a pattern is oftype constant, i.e. a comparison between the value of a field with one given in the patterndefinition, then the order attribute specifies which packet to examine in relation to thebase. This is calculated the following way:

Packet index = base + (pattern order attribute - 1)

For example, if the base is 0, the following pattern would examine the packet at index 2which is the third packet in the list.

<pattern type="constant" match="win" order="3" origin="source">5200</pattern>

If the pattern is of type average then in addition to the order attribute being used tocalculate the first packet to examine, the count attribute is also used to decide how manyconsecutive packets to include in the average calculation.

Figure 5.1 shows this process taking place for a rule with one pattern which is of typeaverage, with order = 1 and count = 3. The first iteration shows that the average iscalculated with packets 1, 2 and 3 (because the base is 0), then this group of three shiftsdown the list by one and the average is calculated again. This continues until the end ofthe list is reached. The second iteration starts at packet 2, 3 and 4 and works in the sameway. The iterations continue until there is not enough packets below the base to satisfythe value of count. This means the given example ends after the third iteration because ifattempting a fourth iteration, only packet 4 and packet 5 remain in the list which does notallow us to take an average over three packets.


Packet 1

Packet 2

Packet 3

Packet 4

Packet 5

Packet 1

Packet 2

Packet 3

Packet 4

Packet 5

Packet 1

Packet 2

Packet 3

Packet 4

Packet 5

Packet 1

Packet 2

Packet 3

Packet 4

Packet 5

Packet 1

Packet 2

Packet 3

Packet 4

Packet 5

Packets being compared with current pattern.

Legend

Packets not being compared with current pattern.

Packets already compared with this rule.

Packet 1

Packet 2

Packet 3

Packet 4

Packet 5

First iteration, base = 0

Second iteration, base = 1

Third iteration, base = 2

Figure 5.1: Rule and pattern matching algorithm for a pattern of type average

At this stage, the necessity of the order attribute may be unclear. Remember that rulescan have multiple patterns. For example, a rule which identifies a connection-open wouldneed to specify the order of which its patterns should occur; SYN (order = 1), SYN-ACK(order = 2) ACK (order = 3).

In order to decide whether a rule has entirely matched, when each packet is examined anddeclared a match, it is added to a new list of packets, called matched. As soon as a packetis found to not match the rule, the base is incremented, the matched list is cleared andprocessing begins again. Once all patterns have been matched for the current rule, weapply the result to all packets in the matched list. The packets in the list will have theresult specified within the rule applied to them, for example, a colour. Each element in thematched list just holds a pointer to the original packet - any changes made to the packets inthis list will be reflected by the packets held in the original list held by the graph rendering


module. This allows the graph rendering module to recognise the changes that the rulesengine has applied to the packets.

5.2.4 Graph rendering

The RenderArea class is responsible for displaying the packets on the graph. The moduleis used to add packets when they are created. The first packet that is added is declaredthe source address, as outlined in the requirements.

When the drawGraph() function is called, it calculates the coordinates for the first line.Lines are drawn by using four coordinates. x1, y1 represents the starting point of the line,x2, y2 represents the end point.

Each packet is drawn onto the graph by using the following algorithm:

1. Calculate time difference between this packet and last.

2. Construct the line label.

This is done by checking whether each of the header variables within the packet objecthave a value assigned to them. If they have, the header name and value is appendedto the label. The flags are a special case and must be handled differently. Generally,each flag is added to the label and they are surrounded by square brackets. The ’.’flag which indicates the packet is an ACK is not added to the label because the ACKvalue is displayed separately anyway. Therefore, if this is the only flag held by thatpacket we must know not to draw the surrounding square brackets. This is done byfirst checking that there are flags, then checking the number of flags is is not equalto one (will only be greater than 1 if the ack flag is present) OR the the first flag isnot ’.’ (the ack flag will always be the second flag). If both of these conditions aretrue, draw the first square bracket, append each flag as long as it is not the ack flagand then draw the closing square bracket.

3. Compare the direction of this line with the last and calculate coordinates.

The program compares the source field of the packet and the address we rememberedfrom the first packet to decide whether this is a packet originating from the source ordestination. If the packet originates from the source, it begins on the left hand sideof the screen. The set of the coordinates for the line must be calculated based on thelast packet drawn. An integer is used to represent the direction of the last packet. 0means left to right, 1 means right to left. If the last packet drawn originated from thesource and so does the packet we are currently drawing then the y-axis only needs tobe increased. Where as if the last packet drawn originated from the right, the x-axismust be set back to the correct value for drawing from left-to-right as well as they-axis increase. The same principle applies to lines changing direction the oppositeway.


4. Draw the line.

If the packet has the colour field set, the brush must be changed to that colour andthen reverted back to the original afterwards.

5. Draw the arrow head.

This is done by drawing a polygon based on the calculated coordinates.

6. Add the time.

Once again, this is based on the calculated coordinates

7. Add the line label.

If the rules engine has added an additional label display this to the right of the packet.

8. Set the previous line direction value, 0 or 1.

Drawing the PDF document

The algorithm above takes a QPaintDevice parameter which is used to initialise the QPainterobject which does the drawing. In order to draw the PDF document, the same function iscalled but a QPrinter is passed which has been setup to write to a pdf document.

The difficulty with using QPrinter is that we have to manually control pagination. Thismeans that the painting system is not aware that it has reached the end of the page andtherefore does not know to create a new one. When calculating the coordinates for paintingon-screen we can just keep incrementing for each new packet that is drawn. It is not assimple as this for printing. Each page is represented as a new set of coordinates with 0,0being the top left corner of the page.

In order to differentiate our algorithm to work with the QPrinter we can check if we arecurrently painting an image onto the graphical user interface or the PDF document. Thisis done by attempting to cast the QPaintDevice to a QPrinter. Succeeding to do so meanswe have a QPrinter and therefore we need to control the pages and coordinate system.Each packet has a standard size on-screen. It was calculated that 18 packets fit onto a pageof A4. Each time we cross 18 packets, a new page is created and the coordinate systemis set back to the original coordinates. We must also print the side lines and the hostand destination label at the top of the page. This is done for every page, unlike for theon-screen representation where it is only done once.


5.3 Implementation conclusion

Issues

The main issue that the solution does not address is the variation in tcpdump log filesbetween different operating systems. Currently the implementation is only programmed tohandle the mac version of tcpdump. This works by having knowledge of additional char-acters that should be ignored when parsing the input. A proposed solution to the problemhas been developed. This is discussed in the improvements section of the conclusion.

Due to unfamiliarity with the language their may be parts of the program which are notwritten as succinctly as they could be. Therefore the source code would benefit fromrefactoring.

Summary

This chapter has provided a detail description of the workings of the program. This wouldallow someone who wishes to extend the project to understand every aspect of the currentimplementation.

5.4 Testing

This section demonstrates correct operation of the program and verifies the requirements.

5.4.1 Methodology

The testing method used focuses around the requirements and aims of the project. Testcases were written. Each test case specifies the input to the program; the command toexecute, associated rules file and the expected output. The test cases are are designedto verify that each of the requirements have been correctly implemented. Test cases werewritten to provide for both positive and negative testing. This is to ensure that the programdoes what is supposed to do and does not do anything it shouldn’t. Following developmentand execution of test cases, requirements were individually examined in order to determinesuccess or failure. This style of testing results in discovery of any bugs that are presentand also reveals parts of the implementation that are missing.

5.4.2 Testing environment

The test cases were executed on a computer running OS X. The Qt framework is cross-platform compatible so code should also compile on any computer with Qt installed.


5.4.3 Test Cases

These are the results from the test cases that are listed in the appendix.

Table 5.2: Results from execution of test casesTest # Pass/Fail Test # Pass/Fail1 PASS 2 PASS3 PASS 4 PASS5 PASS 6 PASS7 PASS 8 PASS9 PASS 10 PASS11 PASS 12 PASS13 PASS 14 PASS15 PASS 16 PASS17 PASS 18 PASS19 PASS 20 PASS21 PASS 22 PASS23 PASS 24 PASS25 PASS 26 PASS27 PASS 28 PASS29 PASS

5.4.4 Requirements Verification

Table 5.3 examines each requirement and marks each as pass or fail according to evidencegiven from test cases.


Table 5.3: Functional requirements verification

Requirement # Pass/Fail Evidence1 PASS Testing environment was OS-X, a unix based operating sys-

tem1.1 PASS Graphs clearly show interaction between two computers1.2 PASS This logic can be seen by comparing example files with output

graphs2 PASS The graph shows the tcpdump data on each line2.1 PASS Screenshots demonstrate the arrows2.2 PASS Screenshots2.3 PASS Screenshots3 PASS Test cases show using rules files3.1 PASS The example rules files (see appendix) are XML3.2 PASS Test case using rules 16.xml passes3.3 PASS The example rules files (see appendix) contain patterns3.4 PASS Example rules files3.4.1 PASS This is the match attribute within pattern, rules XSD (List-

ing 4.1)3.4.2 PASS This is text of pattern element, rules XSD (Listing 4.1)3.4.3 PASS This is the order attribute of pattern element, rules XSD

(Listing 4.1)3.5 PASS Test case using rules 17.xml passes4 PASS Screenshots show annotations added to graph4.1 PASS Example rules files and test cases4.2 PASS Example rules files and test cases4.3 PASS Labelling demonstrated in test cases5 PASS Test cases5.1 PASS Test cases6 PASS Test cases6.1 PASS Test cases6.2 PASS Test cases6.3 PASS Test cases

5.4.5 Non-functional requirements verification

The first requirement specifies that the program should run on as many operating systemsas possible. In order to achieve this, the program was developed in Qt. Whilst thisrequirement has been achieved from an execution perspective, there are still limitationswith parsing the tcpdump created by different architectures. This is something which mustbe rectified in order to both execute the program and parse a tcpdump created on the same


machine.

The program should be useable by those who are colourblind. In order to tackle thisrequirement, the user is able to change the colours of packets within the rules system.They also have the ability to label packets rather than use colours at all.

The program should not crash when given an invalid log file. This is requirement has beenmet because test case 3 uses a tcpdump with a malformed line.

5.4.6 Testing Conclusion

The test results clearly demonstrate that the requirements set out before implementationhave been met. This demonstrates a successful design and implementation.

Although all test cases passed, there were some issues that were identified. The mainproblem was when multiple rules matched the same packet. The rule which was appliedlast overwrote any changes made by previous rules. For example, if a rule matched a packetand coloured it blue and is followed by a rule matching the same packet and colouring itred; the packet would be displayed in red and colour related to the first rule would be lost.A solution to this problem is suggested later, in the evaluation section. There is also apeculiar problem with rendering that when scrolling down and then returning to the topof the image, the host and destination label along with the first arrow is distorted.

In critique of the testing process, it is noted that the program has only undergone white-box testing. The requirements have been verified and the program is shown to be working,but this does not do anything to ensure usability. There was no qualitative testing ofthe program by potential users. Further testing in this area would have been helpful indeciding what could be improved from a user interface stand point. There is no test oraclefor these test cases because an image is produced therefore a mechanism could not bewritten which compares actual text output with expected output. This made the testinga time consuming process because each rule match had to be compared by hand with thetcpdump input file in order to validate it.

Chapter 6

Conclusions

In this chapter we review the success of the project in relation to the aims and objectivesoutlined in the introduction. This is followed by identification of improvements and furtherworks. Finally, we critically analyse the project process and critique our own learning.

6.1 Achievements

The project implementation was successful in achieving the objective given in the projecttitle, the visualisation of tcpdump data. This allows users to capture tcpdump data to a fileand the implemented program will transform this file into a graph. The graph is successfullydisplayed both on-screen and in a PDF file, allowing for distribution of the visualisation. Amajor objective was to provide the ability to display additional information in the form ofcolours, labels and other methods on the visualisation. This goal was also achieved, withthe screenshots showing evidence of the colours and labels.

The literature survey analysed the ability of graphics systems such as PGF which allowsfor generation of images from text instructions. It was suggested that this system wasused to generate the image. In actual fact, the project achieves the result by using part ofthe Qt framework to draw the image manually i.e. by specifying coordinates for paintingand building the image up this way. From this we achieved graphs that were tailored toour exact requirements and they were not limited to assumptions on the way somethingshould look which would be made by other graphics systems. This will allow for muchmore flexible development of the program if further improvements and works were to beimplemented. This task was quite difficult because the coordinates had to be calculated todraw everything in the correct place and according to the size of the window.

Initially, it was planned that the program will have built in procedures for identifyinguseful or interesting characteristics within the tcpdump data. This objective was developedfurther and instead a system was developed which allows the user to manually definepatterns which are of interest to them. This even allows them to specify the way in which

32

CHAPTER 6. CONCLUSIONS 33

they wish the additional data to be visualised. This is a massive achievement compared towhat was originally expected. This makes the system much more flexible for an individualsneeds because it allows them unlimited selection of patterns to suit their own requirements.

The implementation of the rules system is an achievement because the concentration wason producing code that is as dynamic as possible. As a result, the parsing of the rulesfile is impressive in that the name of each attribute is used to generate code to store theattributes value into the corresponding variable.

6.2 Improvements

Naturally, there are improvements that could be made in order to enhance the system.The program works well for the functionality that has been implemented. As the test caseresults show, there are not any known bugs.

The correct way of handling rules which match the same packets is currently not defined.This means that rules can clash with each other and overwrite the changes to the packetdetails that have been made by one another. A simple solution to this would be to set asalience attribute for each rule. This would allow prioritising rules so that if multiple rulesmatch the same packet(s) then the rule with the highest salience can be applied.

When designing the system, the names given to attributes within the rules file were notgiven enough thought. This means that they are potentially confusing for the user. Thisis something that user acceptance testing would have discovered. For example, the originattribute allows the user to specify either ‘source’ or ‘destination’. Arguably the source isthe computer which the packet originated from but in this context it actually means whetherthe packet originates from the computer initiating the connection and running tcpdump(source) or the computer that is being connected to (destination). This could be clearer byusing the terms ’local’ and ’remote’. Another example is the match attribute which allowsthe user to specify which field they wish to compare to, this is perhaps better representedas ‘field’. A third example is the pattern type ‘constant’ which is used to compare theexact value of a field with the value given in a pattern. This doesn’t particularly relate tothem term constant so perhaps ’equality’ would be better. These are just three examplesof confusing names, but more exist.

The way the system parses tcpdump data is hardcoded. This could be improved by usingregular expressions to match each of the fields in the tcpdump file and even allowing theuser to specify their own regular expressions to support different output formats of tcpdumpversions.

Finally, there are areas of the code that are not satisfactory in terms of maintainability. Thebest example of this is the graph rendering module. The RenderArea class has completelyduplicated code (other than coordinates) for drawing a line from left-to-right and right-to-left. This should be re-factored to use the same code and calculate different coordinatesaccording to direction of line.


6.3 Future works

The project provides a good foundation for further development. There were ideas thatwere had before, during and after implementation that give scope for further work on thisproject.

6.3.1 Rules Engine

The rules engine provides the fundamental workings of a system for defining and executingrules. This should be extended further to allow for definition of different pattern typesother than ‘constant’ and ‘average’. A suggestion for a different type is one which allowsthe user to specify a percentage range for increase or decrease of a particular value over anumber of packets. If the increase or decrease of a value is within the specified range, it isconsidered a match. This would allow users to look for a gradual increase in window size,perhaps an indication of tcp slow start. Adding more different types will result in a farmore flexible system.

Currently the only way users can create rules is if they know how the XML should bewritten. An extension to the project would be to create a rules generator which would be agraphical user interface that allows easy specification of different patterns. This would thengenerate the XML automatically. This would make the program easier to use for those notas experienced with creating XML files.

6.3.2 Interface

There is another development that could be done to make the system easier to use for thosethat dislike the command line. It would be useful to have a part of the user interface whichallows users to locate and load a tcpdump file. This would work alongside the suggesteduser interface for defining rules.

6.3.3 Visualisation

There are a few things which could be done to extend the visualisation. Firstly, it would beuseful for the program to generate a legend which shows the colour of packets and the ruleassociated with that colour. This would make it much easier for users to identify whichpackets matched which rule by cross-referencing the colours with the legend rather thanthe rules file.

Currently, there are only two ways of adding annotations to rules - colours and labels. Aworthwhile further work would be to add many ways of annotating the graph. One exampleof such would be having information shown in tooltips when the mouse is hovered over eachpacket. The system is limited on how much information can be added to the graph withoutmaking it more complicated and difficult to read than the raw tcpdump data itself.


The graph only shows data between two computers. It would be useful to extend theprogram to work with more than two computers i.e. to show the connections betweenone computer and any other computer it communicates with. This has the potential ofproducing cluttered graphs if arrows start overlapping each other.

6.3.4 Real-time analysis

An exciting extension would be to incorporate the capture of tcpdump data into the pro-gram. This would allow for creation of the graph in real-time whilst maintaining a con-nection to the tcpdump data. This would be relatively simple to implement. Instead ofthe current action of reading from a file, the system would need to be modified to readfrom a process’ standard output. Controls would be implemented to start and stop capturefrom the user interface. For the rules engine to successfully operate in this environmentthe system would need to constantly evaluate rules against packets. This would be fairlyresource heavy so there should be an option to display packets in realtime and then oncecapture stops, apply the rules. Once this is implemented, we have the basis of a real-timemonitoring system that could be extended to generate alerts if particular rules are matchedagainst captured packets.

6.4 Critical Analysis

Requirements were difficult to complete fully without any experience of this kind of system.Ideally there would have been another iteration of requirements and design after someimplementation had been completed. This would have allowed for incorporation of ideasthat were discovered at the implementation phase.

The design stage was extremely useful to implementation. It meant that the programwas planned at a high-level meaning that implementation was easy to begin because eachmodule had to be programmed and then connected to each other. Ideally, the design stagewould have gone into even more detail to inform implementation. This would have lead tobetter code which perhaps wouldn’t need refactoring as the current version does.

A lot of the implementation time was spent learning the correct syntax of the programminglanguage. This cannot be helped but it does mean that similar projects would be imple-mented faster. If the program was to be written again from scratch, each module wouldbe more streamlined with much less code duplication and there would be shorter functionsdefinitions with high cohesion by introducing more helper functions.

The rules system was an extension to the project after conception, originally these ruleswere going to be hardcoded into the system. Upon reflection, this was without doubt agood decision. Much of the code that would have to be written to hardcode rules was alsoused as part of the rules engine anyway. This did increase the amount of development timethat had to be spent on rules though. As a result, there was less time available to spendon visualisation. This meant that the graphs produced are not quite perfect. For example,


any tcpdump spanning a large period of time will mean that the time displayed on the lefthand side will over run into the graph area. Also, any labels that are added to the righthand side of the graph have the potential of spilling of the edge of the page i.e. there is notext wrapping. The label running along the line of each packet was intended to follow theangle of the line (see A.2) but instead remains horizontal.

It is not obvious what the correct syntax of the rules file is. In order for users to effectivelyoperate the program, it should be supplied with pre-written rules, these could not only beused for visualisation but also to provide an explanation for users to learn how to developtheir own rules.

In summary, the project outcome is the successful visualisation of tcpdump data. Theresulting program is a cross-platform compatible tool that could be used by network ad-ministrators or education institutions to help with their understanding of tcpdump.

Bibliography

Combs, G. (n.d.), ‘Wireshark coloring rules’, http://wiki.wireshark.org/ColoringRules.

Corporation, N. (n.d.), ‘Qpainter class reference’, http://doc.trolltech.com/4.6/qpainter.html.

Fuentes, F. and Kar, D. C. (2005), ‘Ethereal vs. tcpdump: a comparative study on packetsniffing tools for educational purpose’, J. Comput. Small Coll. 20(4), 169–176.

Jacobson, V., Leres, C. and McCanne, S. (n.d.a), ‘tcpdump manpage’, http://www.tcpdump.org/tcpdump_man.html.

Jacobson, V., Leres, C. and McCanne, S. (n.d.b), ‘tcpdump website’, http://www.tcpdump.org.

Kretchmar, J. (2004), ‘Tcpdump: An open source tool for analyzing packets’, inform IT .

Microsystems, S. (n.d.), ‘java.awt.geom library’, http://java.sun.com/javase/7/docs/api/java/awt/geom/package-summary.html.

O’Reilly (n.d.), ‘Network troubleshooting tools’, http://docstore.mik.ua/orelly/networking_2ndEd/tshoot/ch05_04.htm.

Sommerville, I. (2006), Software Engineering: (Update) (8th Edition), Addison Wesley.

Stevens, W. R. (1996), TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP,NNTP, and the UNIX Domain Protocols, Addison-Wesley Professional.

Tantau, T. (n.d.), ‘Pgf sourceforge’, http://sourceforge.net/projects/pgf/.

UKAI, F. (n.d.), ‘3d-tcpdump website’, http://www.3d-tcpdump.org.

37

http://wiki.wireshark.org/ColoringRules

http://wiki.wireshark.org/ColoringRules

http://doc.trolltech.com/4.6/qpainter.html

http://doc.trolltech.com/4.6/qpainter.html

http://www.tcpdump.org/tcpdump_man.html

http://www.tcpdump.org/tcpdump_man.html

http://www.tcpdump.org

http://www.tcpdump.org

http://java.sun.com/javase/7/docs/api/java/awt/geom/package-summary.html

http://java.sun.com/javase/7/docs/api/java/awt/geom/package-summary.html

http://docstore.mik.ua/orelly/networking_2ndEd/tshoot/ch05_04.htm

http://docstore.mik.ua/orelly/networking_2ndEd/tshoot/ch05_04.htm

http://sourceforge.net/projects/pgf/

http://www.3d-tcpdump.org

Appendix A

Design Diagrams

TCPDump Visualisation

< GRAPH >

Figure A.1: Graph visualisation display window design

38

APPENDIX A. DESIGN DIAGRAMS 39

0ms

4ms8ms

10ms

packet information

packet information

packet information

packet information

Source Destination

Figure A.2: Design of tcpdump graph without additional annotations


0ms

4ms8ms

10ms

packet information

packet information

packet information

packet information

Source Destination

Figure A.3: Design of tcpdump graph with coloured rule match


0ms

4ms8ms

10ms

packet information

packet information

packet information

packet information

Source Destination

Figure A.4: Design of tcpdump graph with additional labels

Appendix B

Test Files

dump 1.txt and dump 2.txt are included on the accompanying compact disk.

42

Appendix C

Test cases

Test 1

Execution steps

Start program without any arguments

./tcpdumpvis

Expected result

Usage information printed and program exit

Test 2

Execution steps

Start program with 1 argument - an invalid tcpdump location.

./tcpdumpvis dump_1.txt

Expected result

Error message and usage information printed, exit

43

APPENDIX C. TEST CASES 44

Test 3

Execution steps

Start program with 1 argument - tcpdump location. tcpdump file has invalid line (times-tamp malformed).


Expected result

Print specific error and exit

Test 4

Execution steps

Start program with 1 argument - tcpdump location.


Expected result

Graph should be displayed with no rules annotations. pdf output with default filename

Test 5

Execution steps

Start program with 2 arguments - tcpdump location and rules file location (missing -rswitch)

./tcpdumpvis dump_1.txt rules_1.txt

Expected result

Print usage and exit


Test 6

Execution steps

Start program with 2 arguments - tcpdump location and output pdf location (missing -oswitch)

./tcpdumpvis dump_1.txt out.pdf

Expected result

Print usage and exit

Test 7

Execution steps

Start program with 3 arguments - tcpdump location, output switch and output filename

./tcpdumpvis dump_1.txt -o test.pdf

Expected result

Show graph, PDF produced - filename as given in args

Test 8

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location.rules 1.xml is a simple rules file with one rule containing one pattern matching on thelength field.

./tcpdumpvis dump_1.txt -r rules_1.xml


Expected result

Show graph with any packets which have length = 0, highlighted in red, pdf output withdefault filename

Test 9

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location.rules 2.xml is as rules 1.xml but with the colour set to blue.


Expected result

Show graph with any packets which have length = 0, highlighted in blue, pdf output withdefault filename

Test 10

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisrule tests labelling for matching rules (no colouring).


Expected result

Show graph with any packets which have length = 0, labelled from rule, pdf output withdefault filename


Test 11

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisrule tests labelling AND colouring for matching rules.


Expected result

Show graph with any packets which have length = 0, labelled and coloured red from rule,pdf output with default filename

Test 12

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’constant’ on the ack field. Will match any packets with ack =1.


Expected result

Show graph with any packets which have ack = 1, highlighted in blue, pdf output withdefault filename

Test 13

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’constant’ on the win field. Will match any packets with win =65535.



Expected result

Show graph with any packets which have win = 1, highlighted in blue, pdf output withdefault filename

Test 14

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’constant’ on the flags field. Will match any packets with S flagset.


Expected result

Show graph with any packets which have S flag highlighted in blue, pdf output with defaultfilename

Test 15

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. This isto test the pattern type ’constant’ but only include packets originating from source address.


Expected result

Show graph with any packets which have length = 0 AND originate from source addresshighlighted in blue, pdf output with default filename


Test 16

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. This isto test the pattern type ’constant’ but only include packets originating from source address.


Expected result

Show graph with any packets which have length = 0 AND originate from destination ad-dress highlighted in blue, pdf output with default filename

Test 17

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’average’. Taking the length field and average over 3 packets,looking for an average of 965


Expected result

Show graph with all occurrences (there is at least one) highlighted in blue pdf output withdefault filename

Test 18

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’average’ with an average range specified. Taking the lengthfield and average over 3 packets, looking for an average between 500-1000



Expected result


Test 19

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’average’ with origin=destination. Taking the length field andaverage over 3 packets that originate from the destination, looking for an average of 506.


Expected result


Test 20

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’average’ with origin=source. Taking the length field and averageover 3 packets that originate from the source, looking for an average of 130.


Expected result

Show graph with all occurrences (there is at least one) highlighted in blue. Pdf outputwith default filename


Test 21

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis to test the pattern type ’average’ and using count = 1. This means taking the averageof 1 packet which is equivalent to using the constant pattern type. This rule will colour allpatterns with 0 length.


Expected result

Show graph with all occurrences coloured in blue pdf output with default filename

Test 22

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thispattern tries to match the average type on a field which is non-integer: flags


Expected result

Error message and no rule matches.

Test 23

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis a more complex rule with two patterns. Both of which are constants. The rule matchesfor two packets in a row with length = 0.



Expected result

Show graph with all occurrences highlighted in blue. Pdf output with default filename

Test 24

Execution steps

Start program with 3 arguments - tcpdump location, rules switch and rules location. Thisis another complex rule with a constant followed by an average.


Expected result

Show graph with all occurrences highlighted in blue. Pdf output with default filename

Test 25

Execution steps

This a test of having multiple rules in a file. The rules have different colours assigned tothem.


Expected result

The graph should have all three colours displayed on it correctly identifying each of thematched rules. Pdf output with default filename

Test 26

Execution steps

Start program with 5 arguments - tcpdump location, rules switch, rules location, outputswitch, output filename. rules 1.xml is a simple rules file with one rule containing one


pattern matching on the length field.

./tcpdumpvis dump_1.txt -r rules_1.xml -o output.pdf

Expected result

Show graph with any packets which have length = 0, highlighted in red, pdf output withfilename: output.pdf

Test 27

Execution steps

Start program with 5 arguments - tcpdump location, output switch, output filename, rulesswitch, rules location. I.e. testing having the switches in reverse order to previous rule.rules 1.xml is a simple rules file with one rule containing one pattern matching on thelength field.

./tcpdumpvis dump_1.txt -o output.pdf -r rules_1.xml

Expected result

Show graph with any packets which have length = 0, highlighted in red, pdf output withfilename: output.pdf

Test 28

Execution steps

Start program with 3 arguments - tcpdump location, rules switch, rules location. This is arule designed to recognise tcp connection establishment.

./tcpdumpvis dump_1.txt -r rules_connection_open.xml

Expected result

Show graph with tcp open coloured in blue, pdf output with filename: output.pdf


Test 29

Execution steps

Start program with 5 arguments - tcpdump location, rules switch, rules location. This is arule file with malformed XML, negative test.

./tcpdumpvis dump_17.txt -r rules_connection_open.xml

Expected result

Print error malformed XML and exit

APPENDIX D. SCREENSHOTS 56

Appendix D

Screenshots

Figure D.1: Screenshot of the GUI. This is the initial view that is shown once processingis complete.


Figure D.2: Screenshot of the GUI. This is the view of the interface once the user hasscrolled down.


Figure D.3: Screenshot of the GUI. This is an example of both colouring and labellingannotations with rules 19.xml.


Figure D.4: This is a screenshot of the generated PDF open in Preview.

Appendix E

Code

60

AP

PE

ND

IXE

.C

OD

E61

E.1 File: dumphandler.cpp

#include ”dumphandler . h”

DumpHandler : : DumpHandler ( QString f i leName ) :dump( f i leName ) ,t s (&dump) ,out ( stdout )

{dump . open ( QIODevice : : ReadOnly ) ;

}

DumpHandler : : ˜ DumpHandler ( ) {dump . c l o s e ( ) ;

}

QHash<QString , QString> DumpHandler : : readLine ( ){

QString l i n e ;QString d e s t i n a t i on ;QStr ingLi s t p a i r s L i s t ;QHash<QString , QString> pairTable ;QTextStream out ( stdout ) ;i f ( t s . atEnd ( ) ) {

return pairTable ;}l i n e = t s . readLine ( ) ;/∗ S p l i t s t r i n g by whi tespace ∗/p a i r s L i s t = l i n e . s p l i t ( ” ” , QString : : SkipEmptyParts )

;i f ( p a i r s L i s t . s i z e ( ) == 0)

return pairTable ;/∗ Put the en t r i e s with a f i x e d l o c a t i on in to t a b l e

∗/pairTable [ ” timestamp” ] = ( QString ) p a i r s L i s t . at (0 ) .

trimmed ( ) ;pa i rTable [ ” source ” ] = p a i r s L i s t . at (2 ) . trimmed ( ) ;d e s t i n a t i on = ( QString ) p a i r s L i s t . at (4 ) . trimmed ( ) ;d e s t i n a t i on . chop (1 ) ;pa i rTable [ ” d e s t i n a t i on ” ] = de s t i n a t i on ;

/∗ Look at each other entry and put in to t a b l e ∗/for ( int i = 5 ; i < p a i r s L i s t . s i z e ( ) ; i++) {

QString cPair = ( QString ) p a i r s L i s t . at ( i ) . trimmed( ) ;

QString trimmed ;i f ( cPair == ”Flags ” ) {

trimmed = pa i r s L i s t . at ( i +1) ;trimmed . chop (1 ) ;pa i rTable [ ” f l a g s ” ] = trimmed ;

}else i f ( cPair == ” seq ” ) {

trimmed = pa i r s L i s t . at ( i +1) ;trimmed . chop (1 ) ;pa i rTable [ ” seq ” ] = trimmed ;

}else i f ( cPair == ”win” ) {

trimmed = pa i r s L i s t . at ( i +1) ;trimmed . chop (1 ) ;pa i rTable [ ”win” ] = trimmed ;

}else i f ( cPair == ”ack” ) {

trimmed = pa i r s L i s t . at ( i +1) ;trimmed . chop (1 ) ;pa i rTable [ ”ack” ] = trimmed ;

}else i f ( cPair == ” length ” ) {

trimmed = pa i r s L i s t . at ( i +1) ;pa i rTable [ ” l ength ” ] = trimmed ;

}}

i f ( ! QRegExp( ” [0 −9 , : .A−Za−z ]+” ) . exactMatch (pa i rTable [ ” timestamp” ] ) )

{p r i n t f ( ”Malformed tcpdump f i l e here :\n” ) ;p r i n t f ( pa i rTable [ ” timestamp” ] . toLat in1 ( ) . data ( )

) ;e x i t (1 ) ;

}return pairTable ;

}

AP

PE

ND

IXE

.C

OD

E62

E.2 File: main.cpp

#include <QApplication>#include ” tcpgraph . h”

int main ( int argc , char ∗argv [ ] ){

QApplication app ( argc , argv ) ;QScrol lArea s c r o l l ;TCPGraph ∗graph = new TCPGraph( ) ;s c r o l l . setWidget ( graph ) ;s c r o l l . setGeometry ( ( int ) ( QApplication : : desktop ( )−>

width ( ) −

( QApplication : : desktop ( )−>width ( ) −( QApplication : : desktop ( )−>width ( ) / 2) ) ∗ 1 . 5 ) / 2 ,( int ) ( QApplication : : desktop ( )−>he ight ( ) −

( QApplication : : desktop ( )−>he ight ( ) −( QApplication : : desktop ( )−>he ight ( ) / 2) ) ∗ 1 . 5 ) /

2 ,( int ) ( ( QApplication : : desktop ( )−>width ( ) −

( QApplication : : desktop ( )−>width ( ) / 2) ) ∗ 1 . 5 ) ,( int ) ( ( QApplication : : desktop ( )−>he ight ( ) −

( QApplication : : desktop ( )−>he ight ( ) / 2) ) ∗ 1 . 5 ) ) ;s c r o l l . show ( ) ;s c r o l l . setMinimumSize (855 , 200) ;s c r o l l . setMaximumSize (855 , 1000) ;return app . exec ( ) ;

}

AP

PE

ND

IXE

.C

OD

E63

E.3 File: packet.cpp

#include ”packet . h”

Packet : : Packet ( QString source , QString d e s t i n a t i on ){

QStr ingLi s t s o u r c e Sp l i t = source . s p l i t ( ’ . ’ ) ;QStr ingLi s t d e s t S p l i t = de s t i n a t i on . s p l i t ( ’ . ’ ) ;QString quad ;int count = 0 ;f o r each ( quad , s o u r c e Sp l i t ) {

i f ( count > 3)break ;

this−>source . append ( quad ) ;this−>source . append ( ” . ” ) ;count++;

}count = 0 ;f o r each ( quad , d e s t Sp l i t ) {

i f ( count > 3)break ;

this−>de s t i n a t i on . append ( quad ) ;this−>de s t i n a t i on . append ( ” . ” ) ;count++;

}this−>source . chop (1 ) ;this−>de s t i n a t i on . chop (1 ) ;

}

void Packet : : addFie ld ( int type , QString value ) {switch ( type ) {case SEQ:

seq = value ;break ;

case ACK:ack = value . toDouble ( ) ;break ;

case WIN:win = value . t o In t ( ) ;break ;

case COLOUR:co l ou r = value ;break ;

case FLAGS:

/∗Put each f l a g in to QChar array ∗/for ( int p = 0 ; p < value . l ength ( ) ; p++) {

i f ( va lue . at (p) == ’ [ ’ )continue ;

else i f ( va lue . at (p) == ’ ] ’ )break ;

elsef l a g s . append ( value . at (p) ) ;

}break ;

case TIMESTAMP:/∗ crea t e new timestamp QTime remove l a s t 3

decimal p l a c e s from mi l l i s e c ond s f i r s t ∗/value . chop (3) ;timestamp = QTime : : f romStr ing ( value , ”hh :mm: s s .

zzz ” ) ;break ;

case LENGTH:length = value . t o In t ( ) ;break ;

case LABEL:l a b e l = value ;break ;

}}

QString Packet : : g e tF i e l d ( int f i e l d ) {switch ( f i e l d ) {case SEQ:

return seq ;break ;

case ACK:return QString : : number ( ack ) ;break ;

case WIN:return QString : : number (win ) ;break ;

case COLOUR:return co l ou r ;break ;

case SOURCE:return source ;break ;

case DESTINATION:

AP

PE

ND

IXE

.C

OD

E64

return de s t i n a t i on ;break ;

case LENGTH:return QString : : number ( l ength ) ;break ;

}return ”” ;

}

AP

PE

ND

IXE

.C

OD

E65

E.4 File: pattern.cpp

#include ” pattern . h”

Pattern : : Pattern ( QObject ∗parent ) :QObject ( parent )

{}

void Pattern : : s e t type ( int type ) {this−>type = type ;

}

void Pattern : : setmatch ( int match ) {this−>match = match ;

}

void Pattern : : s e t o rd e r ( long order ) {this−>order = order ;

}

void Pattern : : s e t o r i g i n ( int o r i g i n ) {this−>o r i g i n = o r i g i n ;

}

void Pattern : : s e tcount ( long count ) {this−>count = count ;

}

void Pattern : : s e t va lu e ( QString value ) {this−>value = value ;

}

int Pattern : : gettype ( ) {return this−>type ;

}

int Pattern : : getmatch ( ) {return this−>match ;

}

long Pattern : : g e to rde r ( ) {return this−>order ;

}

int Pattern : : g e t o r i g i n ( ) {return this−>o r i g i n ;

}

long Pattern : : getcount ( ) {return this−>count ;

}

QString Pattern : : g e tva lue ( ) {return this−>value ;

}

AP

PE

ND

IXE

.C

OD

E66

E.5 File: renderarea.cpp

#include <QtGui>#include ” renderarea . h”#include <QPrinter>

RenderArea : : RenderArea (QWidget ∗parent ): QWidget ( parent )

{setBackgroundRole ( QPalette : : Base ) ;setAutoFi l lBackground ( true ) ;

}

QSize RenderArea : : minimumSizeHint ( ) const{

return QSize (800 , 500) ;}

QSize RenderArea : : s i z eH in t ( ) const{

i f ( y2 == 0)return QSize (800 , 1000) ;

elsereturn QSize (800 , ( packets . l ength ( ) ∗40 + 40) ) ;

}

int RenderArea : : getGraphHeight ( ) {return packets . s i z e ( ) ∗80 ;}

/∗ Add an arrow to the graphd i r e c t i on = 1 , hos t −> de s t i na t i ond i r e c t i on = 0 , hos t <− de s t i na t i on ∗/

void RenderArea : : addPacket ( Packet ∗packet ) {packets . append ( packet ) ;/∗ I f t h i s i s the f i r s t packet , s e t the hos t and

de s t i na t i on ∗/i f ( this−>host . compare ( ”” ) == 0) {

this−>host = packet−>source ;this−>de s t i n a t i on = packet−>de s t i n a t i on ;this−>f i r s tT ime = packet−>timestamp ;

}

}

QList<Packet∗>∗ RenderArea : : ge tPacketL i s t ( ) {return &packets ;

}

void RenderArea : : paintEvent ( QPaintEvent ∗ /∗ event ∗/ ){

drawGraph ( this ) ;}

void RenderArea : : drawGraph ( QPaintDevice ∗ paint ) {QPainter pa in t e r ( pa int ) ;pa in t e r . setPen (Qt : : b lack ) ;pa in t e r . setBrush (QBrush (Qt : : b lack ) ) ;pa in t e r . setRenderHint ( QPainter : : Ant i a l i a s i ng , true ) ;QFont painterFont = QFont ( ) ;

QString l a b e l ;pa interFont . s e tPo in tS i z e (8 ) ;pa in t e r . setFont ( painterFont ) ;

QString ms ;

int prev ious = −1;for ( int i = 0 ; i < packets . l ength ( ) ; i++) {

QPrinter ∗ p r i n t e r ;i f ( ( p r i n t e r = dynamic cast<QPrinter∗> ( pa int ) ) !=

0) {i f ( i%18==0 && i !=0) {

/∗Draw s i de l i n e s ∗/pa in t e r . drawLine (150 , 15 , 150 , y2+5) ;pa in t e r . drawLine ( width ( ) −150, 15 , width ( )

−150, y2+5) ;

/∗Draw host , d e s t i na t i on t e x t ∗/pa in t e r . drawText (150−(( host . l ength ( ) ∗4)

/2) , 10 , host ) ;pa in t e r . drawText ( width ( )−150−((

d e s t i n a t i on . l ength ( ) ∗4) /2) , 10 ,d e s t i n a t i on ) ;

p r in t e r−>newPage ( ) ;/∗ Set l i n e s t a r t p o s i t i on ∗/

AP

PE

ND

IXE

.C

OD

E67

x1 = 150 ; y1 = 20 ;x2 = width ( ) −150; y2 = 40 ;

}}

/∗Ca lcu la t e timestamp d i f f e r e n c e in ms then s ∗/int difms = f i r s tT ime . msecsTo ( packets . at ( i )−>

timestamp ) ;i f ( di fms >= 1000) {

double s e c s = f l o o r ( di fms /1000) ;double remainingMs = difms − s e c s ∗1000 ;ms = QString : : number ( s e c s ) ;ms += ” sec ” ;ms += QString : : number ( remainingMs ) ;ms += ”ms” ;

}else {

ms = QString : : number ( di fms ) ;ms += ”ms” ;

}

/∗Construct l i n e l a b e l based on g iven packet data∗/

l a b e l = ”” ;i f ( ! packets . at ( i )−> f l a g s . empty ( ) ) {

i f ( packets . at ( i )−> f l a g s . s i z e ( ) != 1 | |packets . at ( i )−> f l a g s . at (0 ) != ’ . ’ ) {l a b e l . append ( ” [ ” ) ;for ( int f = 0 ; f < packets . at ( i )−> f l a g s .

l ength ( ) ; f++) {i f ( packets . at ( i )−> f l a g s . at ( f ) == ’ . ’ )

continue ;i f ( f != 0)

l a b e l . append ( ” ” ) ;l a b e l . append ( packets . at ( i )−> f l a g s . at (

f ) ) ;}l a b e l . append ( ” ] ” ) ;

}}i f ( packets . at ( i )−>seq != 0) {

l a b e l . append ( ”SEQ ” ) ;l a b e l . append ( packets . at ( i )−>seq ) ;

}i f ( packets . at ( i )−>ack != 0) {

l a b e l . append ( ” ACK ” ) ;l a b e l . append ( QString : : number ( packets . at ( i )−>

ack , ’ f ’ , 0 ) ) ;}i f ( packets . at ( i )−>win != 0) {

l a b e l . append ( ” WIN ” ) ;l a b e l . append ( QString : : number ( packets . at ( i )−>

win ) ) ;}l a b e l . append ( ” l ength ” ) ;l a b e l . append ( QString : : number ( packets . at ( i )−>

l ength ) ) ;

i f ( packets . at ( i )−>source . compare ( this−>host ) ==0) {/∗Drawing l i n e from L−>R∗/switch ( prev ious ) {case −1:

/∗ Set l i n e s t a r t p o s i t i on ∗/x1 = 150 ; y1 = 20 ;x2 = width ( ) −150; y2 = 40 ;break ;

case 0 :x1 = 150 ; y1 = y2 + 20 ;x2 = width ( ) −150; y2 = y2 + 40 ;break ;

case 1 :x1 = 150 ; y1 = y1 + 40 ;x2 = width ( ) −150; y2 = y2 + 40 ;break ;

}i f ( pr intCoords )

p r i n t f ( ”Line %d : x1 = %d y1 = %d x2 =%d y2 = %d\n” , i , x1 , y1 , x2 , y2

) ;i f ( packets . at ( i )−>co l ou r != ”” ) {

pa in t e r . setPen (QColor ( packets . at ( i )−>co l ou r ) ) ;

pa in t e r . setBrush (QBrush ( QColor (packets . at ( i )−>co l ou r ) ) ) ;

}pa in t e r . drawLine ( x1 , y1 , x2 , y2 ) ;stat ic const QPoint po in t s [ 3 ] = {

QPoint (0 , 0) ,

AP

PE

ND

IXE

.C

OD

E68

QPoint (−5 , −5) ,QPoint (−5 , 5)

} ;

/∗Adding the arrow Head∗/pa in t e r . save ( ) ;pa in t e r . t r a n s l a t e ( x2 , y2 ) ;pa in t e r . drawPolygon ( points , 3) ;pa in t e r . r e s t o r e ( ) ;pa in t e r . setPen (Qt : : b lack ) ;pa in t e r . setBrush (QBrush (Qt : : b lack ) ) ;

/∗Adding the timestamp∗/pa in t e r . drawText ( x1−50, y1 , ms) ;

/∗Add a l a b e l ∗/pa in t e r . save ( ) ;pa in t e r . drawText ( x1 , y1−15, x2−x1 , 24 , Qt

: : AlignHCenter , l abe l , NULL) ;pa in t e r . r e s t o r e ( ) ;

/∗Add annotat ion from ru l e i f t he re i sone∗/

i f ( packets . at ( i )−> l a b e l != ”” )pa in t e r . drawText ( x2+20, y2 , packets .

at ( i )−> l a b e l ) ;

/∗Set t h i s l i n e as prev ious ∗/prev ious = 1 ;

}else {

/∗Drawing l i n e from R−>L∗/switch ( prev ious ) {case −1:

/∗ Set l i n e s t a r t p o s i t i on ∗/x1 = width ( ) −150; y1 = 20 ;x2 = 150 ; y2 = 40 ;break ;

case 0 :y1 = y1 + 40 ;x2 = 150 ; y2 = y2 + 40 ;break ;

case 1 :x1 = x2 ; y1 = y2 + 20 ;x2 = 150 ; y2 = y2 + 40 ;

break ;

}i f ( pr intCoords )

p r i n t f ( ”Line %d : x1 = %d y1 = %d x2 = %dy2 = %d\n” , i , x1 , y1 , x2 , y2 ) ;

i f ( packets . at ( i )−>co l ou r != ”” ) {pa in t e r . setPen (QColor ( packets . at ( i )−>

co l ou r ) ) ;pa in t e r . setBrush (QBrush ( QColor ( packets . at

( i )−>co l ou r ) ) ) ;}pa in t e r . drawLine ( x1 , y1 , x2 , y2 ) ;

/∗Adding the arrow Head∗/pa in t e r . save ( ) ;pa in t e r . t r a n s l a t e ( x2 , y2 ) ;stat ic const QPoint po int s2 [ 3 ] = {

QPoint (0 , 0) ,QPoint (5 , −5) ,QPoint (5 , 5)

} ;pa in t e r . drawPolygon ( points2 , 3) ;pa in t e r . r e s t o r e ( ) ;pa in t e r . setPen (Qt : : b lack ) ;pa in t e r . setBrush (QBrush (Qt : : b lack ) ) ;

/∗Adding the timestamp∗/pa in t e r . drawText ( x2−50, y2 , ms) ;

/∗Add a l a b e l ∗/pa in t e r . save ( ) ;pa in t e r . drawText ( x2 , y1−15, x1−x2 , 24 , Qt : :

AlignHCenter , l abe l , NULL) ;pa in t e r . r e s t o r e ( ) ;

/∗Add l a b e l from annotat ions ∗/i f ( packets . at ( i )−> l a b e l != ”” )

pa in t e r . drawText ( x1+20, y1 , packets . at ( i )−> l a b e l ) ;

/∗Set t h i s l i n e as prev ious ∗/prev ious = 0 ;

}

AP

PE

ND

IXE

.C

OD

E69

}

/∗Draw s i de l i n e s ∗/pa in t e r . drawLine (150 , 15 , 150 , y2+5) ;pa in t e r . drawLine ( width ( ) −150, 15 , width ( ) −150, y2

+5) ;

/∗Draw host , d e s t i na t i on t e x t ∗/

pa in t e r . drawText (150−(( host . l ength ( ) ∗4) /2) , 10 ,host ) ;

pa in t e r . drawText ( width ( )−150−(( d e s t i n a t i on . l ength( ) ∗4) /2) , 10 , d e s t i n a t i on ) ;

pa in t e r . end ( ) ;

updateGeometry ( ) ;}

AP

PE

ND

IXE

.C

OD

E70

E.6 File: rule.cpp

#include ” ru l e . h”

Rule : : Rule ( QObject ∗parent ) :QObject ( parent )

{index = counter ;counter++;

}

void Rule : : addPattern ( Pattern ∗pat ) {pat t e rns . append ( pat ) ;

}

void Rule : : s e t type ( int type ) {this−>type = type ;

}

void Rule : : s e t va l u e ( QString value ) {this−>value = value ;

}

QString Rule : : g e tva lue ( ) {

return value ;}

int Rule : : gettype ( ) {return type ;

}

QString Rule : : t oS t r i ng ( ) {QString s t r i n g ( ”Rule ” + QString : : number ( index ) + ”

type : ” + QString : : number ( type ) + ” value : ” +value ) ;

s t r i n g . append ( ”\n” ) ;for ( int i = 0 ; i < pat t e rns . s i z e ( ) ; i++) {

s t r i n g . append ( ”\ t ” ) ;s t r i n g . append ( ”Pattern : type : ” + QString : : number

( pat t e rn s . at ( i )−>gettype ( ) ) + ” match : ” +QString : : number ( pat t e rns . at ( i )−>getmatch ( ) ) +” order : ” + QString : : number ( pat t e rn s . at ( i )−>ge to rde r ( ) ) + ” o r i g i n : ” + QString : : number( pat t e rn s . at ( i )−>g e t o r i g i n ( ) ) + ” value : ” +pat t e rns . at ( i )−>getva lue ( ) ) ;

s t r i n g . append ( ”\n” ) ;}return s t r i n g ;

}

AP

PE

ND

IXE

.C

OD

E71

E.7 File: rulesengine.cpp

#include ” ru l e s eng i n e . h”

RulesEngine : : RulesEngine ( QList<Packet∗> ∗ packetL i s t ,QString r u l e s F i l e )

{this−>packets = packe tL i s t ;this−>r u l e s F i l e = r u l e s F i l e ;

}

int RulesEngine : : parseRules ( ) {QTextStream out ( stdout ) ;

QDomDocument doc ( ” r u l e s ” ) ;QFile f i l e ( r u l e s F i l e ) ;i f ( ! f i l e . open ( QIODevice : : ReadOnly ) )

return −1;i f ( ! doc . setContent ( &f i l e ) ){

f i l e . c l o s e ( ) ;p r i n t f ( ”Malformed r u l e s f i l e !\n” ) ;e x i t (1 ) ;

}/∗Get each Rule∗/QDomNodeList r u l e s = doc . elementsByTagName ( ” ru l e ” ) ;for ( int i = 0 ; i < r u l e s . s i z e ( ) ; i++) {

QDomNode ru l e = ru l e s . at ( i ) ;/∗Create new ru l e ∗/Rule ∗newRule = new Rule ( ) ;QDomNodeList ch i l d r en = ru l e . chi ldNodes ( ) ;for ( int j = 0 ; j < ch i l d r en . s i z e ( ) ; j++) {

QDomNode ch i l d = ch i l d r en . at ( j ) ;/∗Create a new pat t e rn ∗/Pattern ∗newPattern = new Pattern ( ) ;int i sPa t t e rn = 0 ;QDomNamedNodeMap a t t r i b u t e s = ch i l d .

a t t r i b u t e s ( ) ;for ( int k = 0 ; k < a t t r i b u t e s . s i z e ( ) ; k

++) {i f ( ! a t t r i b u t e s . item (k ) . i sNu l l ( ) ) {

/∗Bui ld method name with i n tparameter ∗/

QString intMethod = ” s e t ” +a t t r i b u t e s . item (k ) . nodeName ( )+ ” ( i n t ) ” ;

/∗Bui ld method name with longparameter ∗/

QString longMethod = ” s e t ” +a t t r i b u t e s . item (k ) . nodeName ( )+ ” ( long ) ” ;

/∗Bui ld method name with QStringparameter ∗/

QString str ingMethod = ” s e t ” +a t t r i b u t e s . item (k ) . nodeName ( )+ ” ( QString ) ” ;

/∗Bui ld method name wi thout theparameters f o r use withinvokeMethod ∗/

QString methodName = ” s e t ” +a t t r i b u t e s . item (k ) . nodeName ( );

out << methodName ;out << ” ” ;QObject ∗ ob j e c t ;const QMetaObject∗ meta ;i f ( c h i l d . nodeName ( ) == ” pattern ” )

{ob j e c t = newPattern ;meta = newPattern−>metaObject

( ) ;i sPa t t e rn++;out << ” pattern \n” ;

}else {

ob j e c t = newRule ;meta = newRule−>metaObject ( ) ;

}i f (meta−>indexOfS lot (QMetaObject

: : normal i zedS ignature (intMethod . toLat in1 ( ) . data ( ) ) )!= −1) {

QMetaObject : : invokeMethod (object , methodName .toLat in1 ( ) . data ( ) , Qt : :AutoConnection , Q ARG( int, Types : : lookupEnum(a t t r i b u t e s . item (k ) .

AP

PE

ND

IXE

.C

OD

E72

nodeValue ( ) ) ) ) ;}else i f (meta−>indexOfS lot (

QMetaObject : :normal i zedS ignature (longMethod . toLat in1 ( ) . data ( ) )) != −1) {QMetaObject : : invokeMethod (

object , methodName .toLat in1 ( ) . data ( ) , Qt : :AutoConnection , Q ARG(long , a t t r i b u t e s . item (k ) .nodeValue ( ) . toLong ( ) ) ) ;

}else i f (meta−>indexOfS lot (

QMetaObject : :normal i zedS ignature (str ingMethod . toLat in1 ( ) . data( ) ) ) != −1) {QMetaObject : : invokeMethod (

object , methodName .toLat in1 ( ) . data ( ) , Qt : :AutoConnection , Q ARG(QString , a t t r i b u t e s . item (k ) . nodeValue ( ) ) ) ;

}}

}/∗Set the va lue f o r t h i s pa t t e rn ∗/i f ( i sPa t t e rn ) {

newPattern−>s e t va lu e ( c h i l d . toElement( ) . t ex t ( ) ) ;

newRule−>addPattern ( newPattern ) ;}

}/∗Add Rule to r u l e s L i s t ∗/r u l e s L i s t . append ( newRule ) ;

}f i l e . c l o s e ( ) ;/∗Print out a l l r u l e s ∗/for ( int a = 0 ; a < r u l e s L i s t . s i z e ( ) ; a++) {

out << r u l e s L i s t . at ( a )−>t oS t r i ng ( ) ;out << ”\n” ;

}

return 0 ;}

void RulesEngine : : p roces sPacket s ( ) {QTextStream out ( stdout ) ;/∗ Take each ru l e ∗/for ( int r = 0 ; r < r u l e s L i s t . s i z e ( ) ; r++) {

Rule ∗ r u l e = r u l e s L i s t . at ( r ) ;/∗Move the base ( f i r s t packet to look at ) a long

the l i s t o f packe t s ∗/for ( int b = 0 ; b < packets−>s i z e ( ) ; b++) {

int ruleBroken = 0 ;QList<Packet∗> matched ;/∗ Look at each pa t t e rn . Process i t according

to the type ∗/for ( int p = 0 ; p < ru le−>pat t e rns . s i z e ( ) ; p

++) {Pattern ∗pat = ru le−>pat t e rns . at (p) ;/∗Work out which packet to look at

according to the order a t t r i b u t e inthe pa t t e rn and the current base ∗/

int pos = ( pat−>ge to rde r ( ) − 1) + b ;i f ( pos < packets−>s i z e ( ) ) {

Packet ∗pack = packets−>at ( pos ) ;i f ( pat−>gettype ( ) == CONSTANT) {

/∗Before doing any checks , makesure source / d e s t i na t i on match.

I f source / d e s t i na t i on nots p e c i f i e d in pa t t e rn thenassume we can match frome i t h e r ∗/

i f ( pat−>g e t o r i g i n ( ) == SOURCE) {/∗ I s the packet we have from

source ?∗/i f ( packets−>at (0 )−>ge tF i e l d (

SOURCE) != pack−>source ){out << ”No f l a g match

when b = ” + QString: : number (b) + ”\n” ;

ruleBroken++;break ;

}}

AP

PE

ND

IXE

.C

OD

E73

else i f ( pat−>g e t o r i g i n ( ) ==DESTINATION) {/∗ I s the packet we have from

de s t i na t i on ?∗/i f ( packets−>at (0 )−>ge tF i e l d (

DESTINATION) != pack−>source ) {out << ”No source /

d e s t i n a t i on matchwhen b = ” + QString: : number (b) + ”\n” ;


}}

i f ( pat−>getmatch ( ) == FLAGS) {/∗Compare each char ∗/QString ru l eF l ag s = pat−>

getva lue ( ) ;/∗Check number o f f l a g s in

packet i s the same as inpa t t e rn ∗/

i f ( ru l eF l ag s . l ength ( ) != pack−>f l a g s . l ength ( ) ) {/∗ Al l f l a g s not found ∗/out << ”No f l a g match

when b = ” + QString: : number (b) + ”\n” ;


}int foundCurrentFlag ;for ( int i = 0 ; i < ru l eF l ag s .

l ength ( ) ; i++) {foundCurrentFlag = 0 ;for ( int j = 0 ; j < pack−>

f l a g s . l ength ( ) ; j++){i f ( ru l eF l ag s . at ( i ) ==

pack−>f l a g s . at ( j) ) {/∗Found t h i s f l a g

∗/

foundCurrentFlag++;

out << ”Foundf l a g : ” ;

out << ru l eF l ag s .at ( i ) ;

out << ”\n” ;}

}i f ( ! foundCurrentFlag ) {

/∗ Al l f l a g s notfound ∗/

out << ”No f l a g matchwhen b = ” +

QString : : number (b) + ”\n” ;


}}/∗ I f a l l f l a g s found , add

packet to matched l i s t ∗/i f ( ruleBroken == 0)

matched . append ( pack ) ;}else {

i f ( pack−>ge tF i e l d ( pat−>getmatch ( ) ) == pat−>getva lue ( ) ) {/∗ This packet has

matched the pa t t e rn∗/

matched . append ( pack ) ;out << ”Made a match when

b = ” ;out << b ;out << ”\n” ;

}else {

/∗ Packet did not matchva lue in pa t t e rn ∗/

out << ”No match when b =” + QString : : number (

b) + ”\n” ;ruleBroken++;

AP

PE

ND

IXE

.C

OD

E74

break ;}

}}else i f ( pat−>gettype ( ) == AVERAGE) {

QString requ i r edSource = ”none” ;/∗Work out the requ i red source

address i f the packet i s to matchthe s p e c i f i e d o r i g i n ∗/

i f ( pat−>g e t o r i g i n ( ) == SOURCE) {r equ i r edSource = packets−>at (0 )−>

ge tF i e l d (SOURCE) ;}else i f ( pat−>g e t o r i g i n ( ) ==

DESTINATION) {r equ i r edSource = packets−>at (0 )−>

ge tF i e l d (DESTINATION) ;}/∗How many packe t s have been examined

and t h e i r sum − used fo raverages ∗/

int count = 0 ;int sum = 0 ;while ( count < pat−>getcount ( ) ) {

/∗ i f packet i s from cor r ec tsource or de s i r ed source i snot s p e c i f i e d then add toaverage ∗/

i f ( r equ i r edSource != pack−>ge tF i e l d (SOURCE) &&requ i r edSource != ”none” ) {i f (++pos >= packets−>s i z e ( ) )

break ;pack = packets−>at ( pos ) ;continue ;

}matched . append ( pack ) ;int va l = pack−>ge tF i e l d ( pat−>

getmatch ( ) ) . t o In t ( ) ;sum = sum + val ;out << ” value added to sum : ” +

QString : : number ( va l ) + ”\n” ;i f (++pos >= packets−>s i z e ( ) )

break ;count++;

pack = packets−>at ( pos ) ;}i f ( count >= pat−>getcount ( ) ) {

/∗Check average va lue . I f a rangecheck wi th in range ∗/

i f ( pat−>getva lue ( ) . conta in s ( ’− ’ ) ){

QString lower = pat−>getva lue( ) . s p l i t ( ’− ’ ) . at (0 ) ;

QString upper = pat−>getva lue( ) . s p l i t ( ’− ’ ) . at (1 ) ;

i f ( ! ( lower . t o In t ( ) <= sum/count && sum/count <=upper . t o In t ( ) ) ) {/∗ Packet did not match

average range inpa t t e rn ∗/

out << ”No average matchwhen b = ” + QString: : number (b) + ”\n” ;

ruleBroken++;matched . c l e a r ( ) ;break ;

}}else i f (sum/count != pat−>

getva lue ( ) . t o In t ( ) ) {/∗ Packet did not match

average va lue in pa t t e rn∗/

out << ”No average match whenb = ” + QString : : number (

b) + ” average : ” +QString : : number (sum/count) + ” sum : ” + QString : :number (sum) + ” count : ” +QString : : number ( count ) +”\n” ;

ruleBroken++;matched . c l e a r ( ) ;break ;

}}else {

AP

PE

ND

IXE

.C

OD

E75

/∗ Packet did not match va lue inpa t t e rn ∗/

out << ”No average match when b =” + QString : : number (b) + ”\n

” ;ruleBroken++;matched . c l e a r ( ) ;break ;

}}

}else {

/∗ Pos i t ion to check exceeds the numbero f packe t s ∗/

out << ” Pos i t i on to check exceeds numbero f packets \n” ;


}

}/∗ I f ruleMatched i s then mark r e l e v an t packe t s

with the r e s u l t ∗/i f ( ruleBroken == 0) {

out << ”Rule Matched ! ! ! ! when b = ” + QString: : number (b) + ”\n” ;

/∗Take each pa t t e rn in the ru l e and mark thecorresponding packet ∗/

for ( int i = 0 ; i < matched . s i z e ( ) ; i++) {matched . at ( i )−>addFie ld ( ru le−>gettype

( ) , ru l e−>getva lue ( ) ) ;}/∗ I f t h i s break i s removed , i t w i l l on ly

match once and then s top ∗/// break ;

}}

}}

AP

PE

ND

IXE

.C

OD

E76

E.8 File: tcpgraph.cpp

#include ” tcpgraph . h”#include <QPrinter>

TCPGraph : : TCPGraph( ){

QTextStream out ( stdout ) ;/∗Get program arguments∗/QStr ingLi s t args = QCoreApplication : : arguments ( ) ;i f ( args . l ength ( ) < 2 | | args . l ength ( ) > 6) {

pr intUsage ( ) ;}else {

dumpFile = args . at (1 ) ;for ( int arg = 2 ; arg < args . l ength ( ) −1; arg+= 2)

{i f ( args . at ( arg ) == ”−r ” ) {

r u l e s F i l e = args . at ( arg + 1) ;i f ( ! QFile : : e x i s t s ( r u l e s F i l e ) ) {

out << ” Inva l i d r u l e s f i l e s s p e c i f i e d” ;

pr intUsage ( ) ;}

}else i f ( args . at ( arg ) == ”−o” ) {

outputF i l e = args . at ( arg + 1) ;}else {

pr intUsage ( ) ;}

}}

renderArea = new RenderArea ;QGridLayout ∗mainLayout = new QGridLayout ;mainLayout−>setColumnStretch (0 , 1) ;mainLayout−>setColumnStretch (3 , 1) ;mainLayout−>addWidget ( renderArea ) ;mainLayout−>setRowMinimumHeight (1 , 6) ;setLayout ( mainLayout ) ;setWindowTitle ( t r ( ”TCPDump V i s u a l i s e r ” ) ) ;setBackgroundRole ( QPalette : : Dark ) ;

i f ( ! QFile : : e x i s t s ( dumpFile ) ) {p r i n t f ( ” Inva l i d tcpdump f i l e s p e c i f i e d .\n” ) ;pr intUsage ( ) ;

}DumpHandler ∗dumph = new DumpHandler ( dumpFile ) ;

QHash<QString , QString> returnedHash ;Packet ∗packet ;while ( ! ( returnedHash = dumph−>readLine ( ) ) . isEmpty

( ) ) {packet = new Packet ( returnedHash [ ” source ” ] ,

returnedHash [ ” d e s t i n a t i on ” ] ) ;packet−>addFie ld (FLAGS, returnedHash [ ” f l a g s ”

] ) ;packet−>addFie ld (SEQ, returnedHash [ ” seq ” ] ) ;packet−>addFie ld (ACK, returnedHash [ ”ack” ] ) ;packet−>addFie ld (WIN, returnedHash [ ”win” ] ) ;packet−>addFie ld (TIMESTAMP, returnedHash [ ”

timestamp” ] ) ;packet−>addFie ld (LENGTH, returnedHash [ ” l ength

” ] ) ;renderArea−>addPacket ( packet ) ;

}// I f a r u l e s f i l e has been s p e c i f i e di f ( r u l e s F i l e != ”” ) {

RulesEngine ∗ r u l e s = new RulesEngine (renderArea−>getPacketL i s t ( ) , r u l e s F i l e ) ;

ru l e s−>parseRules ( ) ;ru l e s−>proces sPacket s ( ) ;

}

QPrinter p r i n t e r ( QPrinter : : Sc reenReso lut ion ) ;i f ( outputF i l e == ”” )

p r i n t e r . setOutputFileName ( ”TCPDump V i s u a l i s a t i o n .pdf ” ) ;

else {QFi l e In fo f i ( outputF i l e ) ;p r i n t e r . setOutputFileName ( f i . f i leName ( ) ) ;

}p r i n t e r . s e tPageS i ze ( QPrinter : : A4) ;renderArea−>drawGraph(&p r i n t e r ) ;

}

void TCPGraph : : pr intUsage ( ) {

AP

PE

ND

IXE

.C

OD

E77

QTextStream out ( stdout ) ;p r i n t f ( ” usage : tcpdumpvis <dumpfi le> [− r r u l e f i l e ] [−o

pd f f i l ename ] ” ) ;

e x i t (1 ) ;}

AP

PE

ND

IXE

.C

OD

E78

E.9 File: types.cpp

#include ” types . h”

Types : : Type ( ){

addEnum(”ACK” , ACK) ;addEnum(”SEQ” , SEQ) ;addEnum(”WIN” , WIN) ;addEnum(”FLAG” , FLAG) ;addEnum(”SOURCE” , SOURCE) ;addEnum(”DESTINATION” , DESTINATION) ;addEnum(”CONSTANT” , CONSTANT) ;addEnum(”COLOUR” , COLOUR) ;

}

void Types : : addEnum( QString s t r , int enumInt ) {enumMap [ s t r ] = enumInt ;

}

int Types : : lookupEnum( QString s t r ) {i f (enumMap . conta in s ( s t r ) ) {

return enumMap [ s t r ] ;}else {

return −1;}

}

AP

PE

ND

IXE

.C

OD

E79

E.10 File: dumphandler.h

#ifndef DUMPHANDLERH#define DUMPHANDLERH

#include <QFile>#include <qtextstream . h>#include <iostream>#include <QStr ingList>#include <QLis t I t e ra to r >#include <QHash>

class DumpHandler

{public :

DumpHandler ( QString ) ;QHash<QString , QString> readLine ( ) ;˜DumpHandler ( ) ;

private :QFile dump ;QTextStream t s ;QTextStream out ;

} ;

#endif // DUMPHANDLERH

AP

PE

ND

IXE

.C

OD

E80

E.11 File: packet.h

#ifndef PACKET H#define PACKET H

#include <QString>#include <QTime>#include <QStr ingList>#include ” types . h”

class Packet{public :

Packet ( QString , QString ) ;void addFie ld ( int , QString ) ;

QString ge tF i e l d ( int f i e l d ) ;QTime timestamp ;QString source ;QString d e s t i n a t i on ;QString seq ;QString co l our ;QString l a b e l ;QList<QChar> f l a g s ;double ack ;int win ;int empty ;int l ength ;

} ;

#endif // PACKET H

AP

PE

ND

IXE

.C

OD

E81

E.12 File: pattern.h

#ifndef PATTERN H#define PATTERN H

#include <QObject>

class Pattern : public QObject{Q OBJECTpublic :

expl ic it Pattern ( QObject ∗parent = 0) ;

s i g n a l s :

public s l o t s :void s e t type ( int ) ;int gettype ( ) ;void setmatch ( int ) ;int getmatch ( ) ;void s e t o rd e r ( long ) ;long ge to rde r ( ) ;void s e t o r i g i n ( int ) ;int g e t o r i g i n ( ) ;

void se tcount ( long ) ;long getcount ( ) ;void s e t va lu e ( QString ) ;QString ge tva lue ( ) ;

private :/∗Type o f match e . g . equa l to s t r i n g va lue or average

va lue or % increase ∗/int type ;/∗ Which f i e l d to look at ∗/int match ;/∗ The packet number 1 , 2 , . . . , n I f matching on any

packet , use −1 ∗/long order ;/∗ Source or d e s t i na t i on ∗/int o r i g i n ;/∗ The number o f consecu t i v e packe t s we shou ld

inc lude f o r averages ∗/long count ;/∗ St r ing to match on i f e q u a l i t y check ∗/QString value ;

} ;

#endif // PATTERN H

AP

PE

ND

IXE

.C

OD

E82

E.13 File: renderarea.h

#ifndef RENDERAREA H#define RENDERAREA H

#include <QBrush>#include <QPen>#include <QPixmap>#include <QWidget>#include <QFont>#include <QList>#include <QString>#include <QTime>#include ”packet . h”#include <cmath>

// ! [ 0 ]class RenderArea : public QWidget{

Q OBJECT

public :RenderArea (QWidget ∗parent = 0) ;QSize minimumSizeHint ( ) const ;QSize s i z eH in t ( ) const ;

void addPacket ( Packet ∗) ;QList<Packet∗>∗ getPacketL i s t ( ) ;int getGraphHeight ( ) ;void drawGraph ( QPaintDevice ∗ paint ) ;

public s l o t s :

protected :void paintEvent ( QPaintEvent ∗ event ) ;

private :/∗ Line po s i t i on i n g ∗/int x1 ; int y1 ;int x2 ; int y2 ;/∗ Host and Des t ina t ion ∗/QString host ;QString d e s t i n a t i on ;QList<Packet∗> packets ;/∗Enable d i s a b l e p r i n t i n g coords ∗/stat ic const int pr intCoords = 0 ;/∗The f i r s t timestamp used to work out d i f f e r e n c e ∗/QTime f i r s tT ime ;

} ;// ! [ 0 ]

#endif

AP

PE

ND

IXE

.C

OD

E83

E.14 File: rule.h

#ifndef RULE H#define RULE H

#include <QObject>#include <QList>#include ” pattern . h”

stat ic int counter ;

class Rule : public QObject{Q OBJECTpublic :

expl ic it Rule ( QObject ∗parent = 0) ;QList<Pattern∗> pat t e rns ;

public s l o t s :void addPattern ( Pattern ∗) ;void s e t type ( int ) ;void s e t va lu e ( QString ) ;QString ge tva lue ( ) ;int gettype ( ) ;QString toS t r i ng ( ) ;

private :/∗ I d e n t i f i e s t h i s ru l e f o r matches ∗/int index ;/∗Set how to f l a g a match e . g . co lour ∗/int type ;/∗ Spec i f y what co lour ∗/QString value ;

} ;

#endif // RULE H

AP

PE

ND

IXE

.C

OD

E84

E.15 File: rulesengine.h

#ifndef RULESENGINE H#define RULESENGINE H

#include <QtXml>#include <QFile>#include <qtextstream . h>#include ” ru l e . h”#include ” types . h”#include <QHash>#include ”packet . h”

class RulesEngine

{public :

RulesEngine ( QList<Packet∗>∗ , QString ) ;int parseRules ( ) ;void proces sPacket s ( ) ;

private :QList<Rule∗> r u l e s L i s t ;QList<Packet∗> ∗ packets ;QString r u l e s F i l e ;

} ;

#endif // RULESENGINE H

AP

PE

ND

IXE

.C

OD

E85

E.16 File: tcpgraph.h

#ifndef TCPGRAPH H#define TCPGRAPH H

#include <QtGui>#include ” renderarea . h”#include <QWidget>#include ”packet . h”#include ” a s s e r t . h”#include ” types . h”#include <QGraphicsView>#include <QGraphicsScene>#include <QImage>#include ”dumphandler . h”#include <QHash>#include <QTextStream>#include <QScrollArea>#include <QStr ingList>#include ” ru l e s eng i n e . h”

QT BEGIN NAMESPACEclass QCheckBox ;

class QComboBox ;class QLabel ;class QSpinBox ;QT END NAMESPACEclass RenderArea ;

// ! [ 0 ]class TCPGraph : public QWidget{

Q OBJECT

public :TCPGraph( ) ;void pr intUsage ( ) ;

private s l o t s :

private :RenderArea ∗ renderArea ;QString dumpFile ;QString r u l e s F i l e ;QString outputF i l e ;

} ;// ! [ 0 ]

#endif

AP

PE

ND

IXE

.C

OD

E86

E.17 File: types.h

#ifndef TYPES H#define TYPES H

#include <QString>#include <QHash>

enum{/∗Tcpdump data f i e l d s ∗/ACK, SEQ, WIN, FLAGS, SOURCE, DESTINATION, TIMESTAMP,

LENGTH,/∗Types used fo r pa t t e rns ∗/CONSTANT, AVERAGE,/∗Rule r e s u l t t ypes ∗/COLOUR, LABEL

} ;

stat ic QHash<QString , int> enumMap ;

class Types {

public :stat ic int lookupEnum( QString s t r ) {

i f (enumMap . s i z e ( ) == 0)Types : : addEnums ( ) ;

return enumMap [ s t r ] ;}stat ic void addEnums ( ) {

enumMap [ ”ack” ] = ACK;enumMap [ ” seq ” ] = SEQ;enumMap [ ”win” ] = WIN;enumMap [ ” f l a g s ” ] = FLAGS;enumMap [ ” source ” ] = SOURCE;enumMap [ ” d e s t i n a t i on ” ] = DESTINATION;enumMap [ ” constant ” ] = CONSTANT;enumMap [ ” average ” ] = AVERAGE;enumMap [ ” co l ou r ” ] = COLOUR;enumMap [ ” l a b e l ” ] = LABEL;enumMap [ ”timestamp” ] = TIMESTAMP;enumMap [ ” l ength ” ] = LENGTH;

}} ;

#endif // TYPES H

visualisation of tcpdump output - bathmdv/courses/cm30082/projects.bho/2009-10/pag… ·...

Documents