Lots of things to be getting on with ...

Friends often wonder what I'm working (and so do I sometimes) so here's my to-do list for the rest of this week:

DOCUMENTING OCAML 

• Review some examples of ocaml code and hows its documented
• Investigate if ocamldoc is worth implementing
• using ocaml-dns as an example of documentation
• put together a blog post of methods of documenting OCaml code and decide a style of documentation that you be useful in Signposts
• Next week, work through the core signposts core, adding documentation

SIGNPOSTS INSTALLATION

• working through the process of installing signposts from a scratch, currently do as far as key generation
• Generate the keys required for signpost and potential write a script to help automate the process
• Run Signposts on my main machine, test client and server implementation
• Next week, follow documentation to set up signposts on an Eee PC  
• Produce a clear set on instruction on how to install, set up and run signposts

UPnP TACTIC FOR SIGNPOSTS

• Research the UPnP interface provided by routers
• Review the other signposts tactics to generate an outline of the API for implementing tactics
• Next week, Write a tactic in OCaml for signposts that makes use of UPnP, use the method of documenting OCaml highlights earlier

FRAMEWORK FOR ANALYSIS OF URBAN WI-FI

• finish reading and taking notes on "Usage Patterns in an Urban Wi-Fi network"
• Produce a draft outline of the framework for analyzing urban Wi-Fi
• Next week, reading though some other papers in the area and add detail to framework

PAWS ROUTER TRIAL SETUP

• once permission for the network is granted, set up the router using the provided interface 
• install and set-up OpenWRT on the router
• Investigate best firmware for ftp, ssh and vpn on the router
• produce results and share, before 15th Nov

INTERLEAVING OF SIGNPOSTS & PAWS

• consider the overlap of signposts & paws
• find use cases that highlight the potential for inter connection
• produce some slides/blog post on findings and ideas, before 15th Nov

TCPdump - An introduction

As per usual, if you find any mistakes, concepts that could be explained better or have something to add, then please comment below and I'll correct it.

What is TCPdump ?

TCPdump is a command line tool that is used to look at packets on the network. TCPdump does not generate the packets itself but instead it analyzes the packets generated by other applications and from this, it can determine network behaviour and performance.

Despite being called TCPdump, you can choose from a range of protocols including IP,ARP, TCP and UDP.

How do I get TCPdump ?

From Ubuntu, I simply got it via 'sudo apt-get install tcpdump'. Otherwise the public repo is located here, along side some useful information and the manual pages.

You can also check the dependencies of TCPdump using 'apt-cache depends tcpdump'. The output that this returns for me is:

  Depends: libc6

  Depends: libpcap0.8

  Depends: libssl1.0.0

  Suggests: apparmor

  Conflicts: tcpdump:i386

 

If you get the package for the public repo, then you need will extract the content of the .tar.gz file using 'tar -zxf tcpdump-4.3.0.tar.gz' after using cd to move to the directory that you downloaded the file to, then install the program.

So I've got it.. but how do I use it ?

To start with use 'sudo tcpdump' to output to the terminal, this gives the standard output of TCPdump, using the default arguments since you have not passed TCPdump any arguments yet. To the output will be printed to the terminal, until you stop the program using Ctrl-C.

Don't be scared ... we will now begin the break this output down into understandable section (if you not scared then try 'sudo tcpdump -v' or 'sudo tcpdump -vv'  for a verbose output).

Changing network interface

When I'm using tcpdump, it listened on eth0 by default, but you can change this. Entering 'sudo tcpdump -D' will return a list of network interfaces that you can choose between. For me this returns:
        1.eth0
        2.wlan0
        3.usbmon1 (USB bus number 1)
        4.usbmon2 (USB bus number 2)
        5.any (Pseudo-device that captures on all interfaces)
        6.lo
The first item in the list is the Ethernet port, the 2nd is the Wireless card and the 3,4,5th is self explanatory. The 6th is the loopback virtual interface (more information here on wikipedia)

You can then change the interface, by calling TCPdump using 'sudo tcpdump -i <name-of-interface> '. For most of my work, I use the local Wi-Fi so can change the interface from Ethernet to wireless using 'sudo tcpdump -i wlan0'. 

Creating a file to store the tcpdump arguments

So far, we have only added one argument when we call TCPdump, but there will be a lot more to come. We can save these arguments, which filter the output of TCPdump to a file and then use the file when we call TCPdump.

Create the file using your favourite text editors (mine in gedit at the moment) and then pass the file to TCP dump using 'sudo tcpdump -F <my-file>'. The file dose not need any special file extension or layout.

You may need to change the file permissions so that TCPdump can extract the file. You can view the file premissions using 'ls -l <my-file>'. The 'ls' part is command line tool to list the files in a directory and the argument -l means use long format so the file permissions will be included. The file 10 characters are the file permissions, they are decoded as follows:

1. 'd' means this is a directory and '-' means this is a file
2. 'r' means that the file owner can read the file, '-' means they can't
3. 'w' means that the file owner can write to the file,  '-' means they can't
4. 'x'  means that the file owner can execute the file,  '-' means they can't. If this is a directory then 'x' means that the owner can list the files in directory, '-' means they can't.
5. 'r' means that the file group can read the file, '-' means they can't
6. 'w' means that the file group can write to the file,  '-' means they can't
7. 'x'  means that the file group can execute the file,  '-' means they can't. If this is a directory then 'x' means that the owner can list the files in directory, '-' means they can't.
8. 'r' means that everyone else can read the file, '-' means they can't
9. 'w' means that everyone else can write to the file,  '-' means they can't
10. 'x'  means that everyone else can execute the file,  '-' means they can't. If this is a directory then 'x' means that the owner can list the files in directory, '-' means they can't.

For me, the default file permissions are '-rw-rw-r--'. This therefore means that the file owner doesn’t have permission to execute the file. This can be changed using 'chmod u+x <my-file>'. The command line tool is chmod, this is used for changing file permissions, 'u' means we are considering the users permissions, '+' means we are granting a permission and 'x' means we can considering the execute permission. Now, if I redo 'ls -l <my-file>' the new result is -rwxrw-r--.

  

Sending the output to file

You can send the output of tcpdump to a file instead of printing it to the terminal using 'sudo tcpdump -w <my-file>'. This output is not saved as a plain text so you can't just read it in a text editor instead you need to use a special program to read the file and extract information from it. You can do this using tcpdump by 'tcpdump -r <my-file>'. Alternatively you can open it using wireshark, launch wireshark and using File>Open.

 

Filtering information by protocol

To filter packets by protocol, add the name of protocol to the arguments of tcpdump so use something like 'sudo tcpdump <name-of-protocol>'. The main protocols that I'm likely are use are IP, ARP, TCP and UDP but others are available, see the man pages for a full list

Filtering information by direction to different hosts

To filter packets by a direction and host, add the direction and then the host name. Possible direction options are src, dst, src or dst, src and dst. You specify the host using its IP address. You can use the logical operators not, or and and. For example, you can look up the local IP address of your machine using 'ifconfig <name-of-interface>'. If you don't specify the name of the interface, then all interfaces will be listed. Now if you only want to view incoming traffic you can use 'sudo udpdump dst <ip-address>'.

Change the level of detail 

Compared to the level of detail provided by the standard query, The detail can be reduced using '-q' for quiet output or increased using '-v' for verbose, '-vv' for more verbose and '-vvv' for even more verbose.

The opinion '-t' means do not print timestamp on each line and the option '-a' allows you to display each packet in ASCII or '-x' to display in hex or '-X' to display in hex and ASCII

View IP address instead of domain names

You can stop the translation of IP address to domain names using the '-n' opinion and you can stop the translation of port number too using the '-nn' opinion

Sources of Info

Wikipedia article, which contains very little information

Official public repo, including the man pages and FAQ 

Useful online tutorial at openmaniak, this site also has good tutorials on networking tools that I've previously covered including wireshark, OpenVPN, Iperf and ping.

Getting Client & Server Talking - Demo Pt 3

Now I have an Android phone running the client and my laptop running the server, its time to get them taking.

A quick inspection of the client code shows the line "public static final int [] IP_ADDR = {128,2362,110,172}; " I change this to the IP address of my laptop and reload the code onto my android phone.

I launch the server on my laptop, the client on the Android phone and here the troubleshooting begins. Nothing appears to happen on either the client or server so I:

1. check the network connection on both client and server  ✓
2. un-install the client application and re-install it ✓
3. check the IP address of the server is correct ✓
4. Try running client on emulator ✓ just got the exact same problem 

Taking a closer look at the IP address used:

I tried to find out the IP address of the server by visiting here but i thought that I should try to take a more technical approach. Visiting connection information in Ubuntu gives me a different IP address. Now I'm fairly sure that my server is behind a NAT as is my client.

Initally I assume that the different IP address are caused by the NAT, therefore the IP address from the website, is my public IP address (the IP address of the NAT) and the IP address given to my by my OS is the private IP address, that I am referred to by machines also behind the NAT.

This explaination fails to explain why using the IP address from the website didn't work and the IP address given to me by my OS doesn't have the normal structure that I would accociate with a private IP address.

So I now repeat my initial test using the different IP address (previously I used the address provided by a website and now I am using the one provided by the OS) and it works on both the android phone and the emulator.

But by use of the word "works" I mean that the server recognises that a client has connected and the GUI on the android client provides graphs showing latency and goodput, it unfortunately doesnt mean that I've yet found a good way to extract the data to make a comparision to the data provided by Iperf to test accuracy and reliably, on the assumption that Iperf will always produce accurate results that we can assume to be the true value.

The next useful step will be to continue to explore why this IP address works and the other one doesn't. As the client and server are now able to connect I can test if this IP address is working only because both client and server are behind the same NAT or is there something more complex going on. Currently both the laptop and android phone are making use of the same Wi-FI network, so the next step in testing if this will work when the client and server are not behind the same NAT is to change the network that either is using.

The plan for testing with would be:

• move server onto another WiFi network
• find out new IP address and update client code
• test if emulator can connect to server, it should do as it used same network connection as the host computer, which in this case is the server
• test if android phone can connect to server, it should not as its now not behind the same NAT as the server
• move the android phone onto the other WiFi network
• test if android phone can connect to server, it should now be able to 

As this test is not critical for now, I will move onto Part 4 next week, where I get Iperf collecting the same data between the android client and then compare the data collected