Author Archives: Heidi-ann

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 ‘. 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 ‘. 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 ‘. 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 ‘. 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 ‘ 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 ‘. 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 ‘. 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 ‘. 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 ‘. 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 ‘.
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.

A new week, a new approach

I’m changing my approach from using tools like Iperf and ping to collect network data and then using my java program to analyses the output to writing the scripts for myself and working from the ground up.

It is new territory for me so it really exciting but also a bit daunting. Along side this new work, I now have just 7 days left to prepare for the Google Android Development Camp in London. The next week is looking like its going busy but interesting and by the end I hope to have overcome a steep learning curve.

PLAN FOR MONDAY

  • learn & practice using tcpdump
  • try using netcat to phase the output of tcpdump
  • work out which language is best for the job in hand

I’ll update you again soon…

(Testing) Network Data collection – Demo Pt 5.3

I am going to work through my last article, where I explained how to generate the required files to run my Java code here 

SETUP

I connect my laptop and android phone to the same Wi-Fi network and get there private IP addresses:

  • The server (my laptop) –  192.168.14.245
  • The client (my android phone) – 192.168.14.47

IperfOutput.txt 

If ./adb shell returns error:device not found then wait a few seconds before trying again. This is because there can be a slight delay between plugging an android device and its being recognised.

Terminal 1
heidi@ubuntu:~$ cd Downloads/android-sdk-linux/platform-tools/
heidi@ubuntu:~/Downloads/android-sdk-linux/platform-tools$ ./adb shell
# iperf -u -c 192.168.14.245 -t 100
————————————————————
Client connecting to 192.168.14.245, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  110 KByte (default)
————————————————————
[  3] local 192.168.14.47 port 52285 connected with 192.168.14.245 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-100.0 sec  12.5 MBytes  1.05 Mbits/sec
[  3] Sent 8918 datagrams
[  3] Server Report:
[  3]  0.0-100.0 sec  12.5 MBytes  1.05 Mbits/sec   1.783 ms   10/ 8918 (0.11%)
[Ctrl-C]

Terminal 2
heidi@ubuntu:~$ cd TestingSignpostAppOutput/
heidi@ubuntu:~/TestingSignpostAppOutput$ iperf -s -u >> IperfOutput.txt
[Ctrl-C]

Data Collection for Latency, Goodput & Jitter – Demo Pt 5.2

Everyone who I have spoken to about my work since yesterday, has asked me the same question. Why are you writing this in Java ? The answer is that I am going on the Google European Android Development Camp in a few weeks so I am using Java were possible in my work so that I can get familiar with the basics again.

To ensure that the server (my laptop) and the client (my android phone) can address each other I ensure that they are behind the same NAT so that private IP addresses can be used. This ensures that both devices can initialize an connect with the other

My Java code for analyzing and comparing Signpost Diagnostic Application to the results generated by Iperf and Ping, requires the following files:

  • SignOutput.txt – this is generated by the Signpost Diagnostic Application, It can be generated by:
    • Hard coding the server IP address into the application code, found here
    • Uninstall previous versions of the application and connect the android phone via USB
    • Within eclipse, load the application onto the android phone
    • cd into Downloads/android-sdk-linux/platform-tools
    • In another terminal, cd into the location of the demo server and start server using ./server.native
    • use “./adb logcat-s SIGPST >> SignOutput.txt”
    • The location of the file SignOutput.txt is now Downloads/android-sdk-linux/platform-tools, copy the file to /TestingSignpostAppOutput
  • IperfOutput.txt – this is generated by a remote shell on the Android phone, it can be generated by:
    • (In terminal 1) cd into Downloads/android-sdk-linux/platform-tools
    • connect android phone via USB
    • use “./adb shell” to start a remote shell
    • in another terminal (terminal 2), cd into /TestingSignpostAppOutput so output file is loaded straight into correct directory
    • (In terminal 2) use  iperf -s -u >> IperfOutput.txt
    • (In terminal 1) use iperf -u -c {insert laptop IP}
  • PingDownstreamOutput.txt – this is generated by the server sending pings to the client (the android phone), it can be generated by:
    • cd into  /TestingSignpostAppOutput so output file is loaded straight into correct directory
    • Run a bash script containing the following:
    • #!/bin/bashfor i in {1..10}
      do
      ping {insert phone IP} -c 10 -n -q >>

      PingDownstreamOutput.txt;
      done

  • PingUpstreamOutput.txt – this is generated by the client (android phone) sending pings to the server, it can be generated by:
    • cd into Downloads/android-sdk-linux/platform-tools
    • Save a bash script (lets call it pingUp) containing the following
    • #!/bin/bashfor i in {1..10}
      do
      ping {insert laptop IP} -c 10 -n -q >>

      PingUpstreamOutput.txt;
      done

    • Connect android phone via USB and copy script to SD cards using  ./adb push pingUp / sdcard/   “
    •  use “./adb shell” to start a remote shell
    • In the remote shell cd into /sdcard
    • In the remote shell run the script using ./pingUp
    • exit the remote shell
    • cd into  /TestingSignpostAppOutput
    • copy the PingUpstreamOutput.txt file to the laptop from the android phone using “./adb pull /sdcard/PingUpstreamOutput.txt

Once you have generated all of these files then you can run my program SignpostOutputAnalysis.java found here which should output the average true and estimated latency, goodput and jitter.
The code in SignpostOutputAnalysis.java is still incomplete and untested, I also have not yet tested my instructions for generating the correct files at the correct locations for the java code to be ran. I will be doing this testing next…

Data Collection for Latency – Demo Pt 5.1

Now its time for me to collect data from the Signpost Diagnostics Application and Iperf to see if there is a statistically significant difference between the Latency and Goodput data from the two applications. [Jitter will soon be added to the application so I will need to go back the test that]

THE PLAN…

Part A – Data from Signpost Application

  1. Connect the android phone (the client) and laptop (the server) to Internet in such a way that they are behind the same NAT box, so the client can initiate a connection with the server from a private IP address
  2. Set up the OCaml Server running on my laptop
  3. Change in client IP address in the client code and load onto android phone
  4. Running client with server, collecting data whilst viewing output from log files

Part B – Latency data from Ping

  1. Workout how to send pings bothways
  2. Workout how to use ping to get RRT bothways
  3. Collect some data on latency

Part C – Compare Data from Signposts Application and Ping

  1. Extract sufficient data from both methods
  2. Get data from both method into a suitable format
  3. If required, convert units for latency so all data in same units
  4. Compare data
  5. Answer the Question: Is there a significant difference between the data collected by Ping (assumed to be accurate) and the Signpost Application

AND THE REALITY…

Part A

I’ve just been send the most recent version of the Signpost Diagnostics Application as a .apk file. I uninstall the old version of the application using the Android GUI and install the new version using:

cd /android-sdk-linux/platform-tools
./adb install ~/Downloads/SigcommDemoAndroid.apk

I quick come to realize that the above is stage is useless. It will correctly install an application from the .apk file but I need to be able to edit the code of the application so that I can set the client IP address at a later stage

I connect both the client and server to the same Wi-FI network so that the client will be able in initiate an connection with the server

As per usual, to start up the OCaml Server, I will do

cd Downloads/sebastian-SignpostDemo-53ebd3e/SignpostServerOCaml/
./server.native

I uninstalled the last Signpost Application, change the IP address in the code and load onto phone, via Eclipse using the run as dialogue.

Pressing start on the Android application triggers a connection to be initiated with the server, this is successful as the sever outputs a link detailing the android phones name, IP address and port number used.

I can view the logs for this application live, using:

cd  Downloads/android-sdk-linux/platform-tools

./adb logcat-s SIGPST

To filter the output of logcat, I use the arguments -s SIGPST, this gives me a log output such as:

I/SIGPST  ( 1520): Received Latency Upstream: 25500
I/SIGPST  ( 1520): Received Goodput Downstream: 4026
I/SIGPST  ( 1520): Received Latency Downstream: 6008
I/SIGPST  ( 1520): Received Goodput Downstream: 1262925
I/SIGPST  ( 1520): Received Latency Upstream: 49000
I/SIGPST  ( 1520): Received Goodput Downstream: 4787
I/SIGPST  ( 1520): Received Latency Downstream: 10376
I/SIGPST  ( 1520): Received Latency Upstream: 50000
I/SIGPST  ( 1520): Received Goodput Downstream: 2735
I/SIGPST  ( 1520): Received Latency Downstream: 17004
I/SIGPST  ( 1520): Received Latency Upstream: 46500
I/SIGPST  ( 1520): Received Goodput Downstream: 4461
I/SIGPST  ( 1520): Received Latency Downstream: 4463
I/SIGPST  ( 1520): Received Goodput Downstream: 799720
I/SIGPST  ( 1520): Received Latency Upstream: 51000
I/SIGPST  ( 1520): Received Goodput Downstream: 3684
I/SIGPST  ( 1520): Received Latency Downstream: 6875
I/SIGPST  ( 1520): Received Latency Upstream: 307000
I/SIGPST  ( 1520): Received Goodput Downstream: 4670
I/SIGPST  ( 1520): Received Latency Downstream: 8749
I/SIGPST  ( 1520): Received Latency Upstream: 16500
I/SIGPST  ( 1520): Received Goodput Downstream: 2652
I/SIGPST  ( 1520): Received Latency Downstream: 6795
I/SIGPST  ( 1520): Received Goodput Downstream: 24060150
I/SIGPST  ( 1520): Received Latency Upstream: 72500
I/SIGPST  ( 1520): Received Goodput Downstream: 4190
I/SIGPST  ( 1520): Received Latency Downstream: 6809

A quick code inspection, highlights that the latency values are divided by 1000 to be converted into secs, which means that the latency values here are in ms
I will look at how to convert this to a more convenient form in part 3

I can append the output to the file Signoutput.txt using “>> Signoutput.txt”

I have added a sample of Signoutput.txt here 

Part B

I open a remote shell on the android phone using ./adb shell, I then use the ping unix commend from the client to the server, and i get an output such as

24 packets transmitted, 24 received, 0% packet loss, time 23070ms
rtt min/avg/max/mdev = 35.614/90.183/297.302/51.944 ms

The latency will be half the RRT so here it is 45.0915 ms

Then repeating the test from the server to the client and i get an output such as

43 packets transmitted, 40 received, 6% packet loss, time 42070ms
rtt min/avg/max/mdev = 33.371/93.812/241.825/45.579 ms

So the latency is similar to before at 46.906 ms

Now I want to collect the data from the ping output, so I wrote the following bash script to do this:

#!/bin/bash

for i in {1..10}
do
ping 192.168.14.47 -c 10 -n -q >> Pingoutput.txt;
done

This sents 100 pings, in 10 sets of 10 and sent the results of the 10 test to a file called Pingoutput.txt
The first line “#!/bin/bash” mean that this is a bash script, the ping argument “-c 10” means said 10 pings and “-q” means quiet output. >> means append to file.

I’ve added a sample of Pingoutput.txt here

Part C

To analysis the output files, I have written the Java code here. Currently this code is untested

Analysing the Android Demo Code – Pt 5

The following is a look at the code here on GitHub. If you’ve been following my progress so far you will know that I’ve so far managed to run this code, but I am let to take a proper look at the code and how it works.

The top level of the directory contains the following directories/files, typical to an Android project:

  1. directory called /res that contains the launcher icon, the xml file describing the layout, and two further xml files which hold the “values” associated with the application
  2. directory called /src that containing 4 java files LocalBinder.java, SigcommDemoAndroidActivity.java, SigcommDemoAndroidService.java and TestsSignpost.java and a collection of java files for different data views
  3. the AndroidManifest.xml file which highlights that the minimum SDK version is 10
  4. the lint.xml file which contains almost nothing
  5. the pom.xml file, I’m currently not sure what this does
  6. the project.properties file which just re-highlights that the SDK is version 10

I’m now going to take a closer look at the code:

SigcommDemoAndroidActivity.java

Public Methods

  • onCreate(Bundle savedInstanceState) – the method that is called when the application is first started
  • onDestroy() – the method that is called when the application is closed
  • onPause() – the method that is called when the application is paused
  • onClick(View v) – the method that is called when either of the two buttons on the application is pressed, v.getId() is then used to determine which button was pressed
  • updateTimestampArray (float [] array, float newval) – this method shifts all of the values in the array to the left by one position, disregarding the value at index 0 and inserting newval at the last place in the array. There are also minValBandwidth and maxValBandwidth which are updated according
  • updateHistoricValFloat (float [] array, float newval ) – this method shifts all the values in the array to the left by one position, disregarding the value at index 0 and inserting newval at the last place in the array. [Note: the difference between updateTimestampArray and updateHistoricValFloat is that only updateTimestampArray updates the minValBandwidth and maxValBandwidth ]
  • plotLatencyPairs (float [] timestampsDownstream, float [] arrayLatencyDownstream, float[] timestampsUpstream, float[] arrayLatencyUpstream) – this method plots latency pairs
  • plotBandwidthPairs (float [] timestampsDownstream, float [] arrayBandwidthDownstream, float[] timestampsUpstream, float[] arrayBandwidthUpstream) – this method plots bandwidth pairs
  • printVals(int [] array) – this method takes an array of integers, turns them into a string with the values separated by commas and sends them to the INFO log file [Note: API on the log output for android is available here and further information is here]
  • updateHistoricValInt (int [] array, int newval ) – this method shifts all the values in the array to the left by one position, disregarding the value at index 0 and inserting newval at the last place in the array.  [Note: the difference between updateHistoricValInt and updateHistoricValFloat is that updateHistoricValFloat takes a float array and updateHistoricValInt takes a int array]

SigcommDemoAndroidService.java


Public Methods

  • setMainActivity(SigcommDemoAndroidActivity activity, int [] server, int tcpPort) – this method is how SigcommDemoAndroidActivity.java calls this java file. SigcommDemoAndroidActivity.java calls this method when the user click on the start test button on the UI. This method using the data from SigcommDemoAndroidActivity to initialise some of the variables in SigcommDemoAndroidService such as server ip address and port number
  •  stopThread() – this method simply just re-sets the boolean flag testAlive
  •  onBind(Intent arg0) – this method calls the constructor of LocalBinder.java and passes the current instance of SigcommDemoAndroidService to LocalBinder.java
  • onUnbind(Intent intent) – this method seems to do nothing :S
  • onDestroy () – this method calls the onDestroy() on the class Service that SgcommDemoAndroidService inherits from
  • onCreate() – this method calls the onCreate() on the class Service that SgcommDemoAndroidService inherits from and creates a new thread called th
  • callFinalize() – this method calls System.exit(0)
  • notifyActivity (int value, int caseId) – this method refreshs values
  • run () – this method connects to the server and measures the time for packets to be transported between client and server

Iperf on Andriod, a new approach – Pt 4.3

This is blog post number 4, on try to run Iperf on Android, my previous attempts were:

  • Method 1 – getting the Google Play Store on a CyanogenMod phone and downloading the Iperf for Android application
  • Method 2 – SSHing into an Android phone and trying to run Iperf from the command line
  • Method 3 – repeating method 1 & 2 on another Android phone and trying a different application called Aperf
  • Method 4 – trying to run a cross-compiled version of Iperf on the Android phone
  • Potential Method 5 – cross-compile Iperf myself and try to run that version
  • Potential Method 6 – install Linux on android, following instructions here.
  • Potential Method 7 – write my own version of Iperf

THE PLAN

  1. Get to grips with the basics of Android Debug Bridge (adb)
  2. Download the cross compiled Iperf and push it onto SD card
  3. Copy Iperf over the correct location in the system

THE REALITY

1
Android Debug bridge (adb) is a command line tool for communicating with an android device via USB or an emulator instance. adb is not installed in the machine so it must be ran from the correct location, for me this was android-sdk-linux/platform-tools/.

I connect my android phone via USB and run ./adb devices to test that the device is connected. If multiple emulators/device instances are running then I will need to specify with device to use when using adb so for simplicity, I close all running emulators so that I have only my android phone running.

I can install applications from the .apk file using “adb install ” and I can copy files between my device and computer using “adb pull   _location>” and adb push _location> _location>”
2/3
I’ve downloaded Iperf compiled for android and I do the following:
 ./adb push ~/Downloads/iperf / sdcard/   
(* copy iperf from downloads to SDcard *)
./adb shell

(* starts a remote shell on the android device, the command prompt becomes #   *)

mount -o rw,remount /system
(* remount the /system filesystem so that its now read-write *)

cp /sdcard/iperf /system/bin
(*copy the iperf code over to newly remounted /system filesystem *)

mount -o ro,remount /system
(* remount the /system filesystem so that its now read-only *)

Now I try iperf, from the remote shell and IT WORKS !
Yes, that’s right, it works perfectly. This time it was 4th time lucky.

And this right here, is the reason that I’m a computer scientist. For the high, that you get when something finally works and you know that it works because you made it work. Looking back over the past few days, I feel like I’ve learned so much about Android and given the opportunity I would definitely do it all over again but now its time for a coffee.

Another Day, Another Andriod Phone – Pt 4.2

My current aim is to get Iperf running on an Android phone so that I can collect “accurate” network data to compare to the network data produced by Signpost Demo Application that I’m currently trying to test.

The problem is that I can’t get the Iperf for Android application to run on any of the available android phones. I have also tried SSHing into the phone and running Iperf, this also did not work.

I need to get Iperf working on android to collect the data for comparison to data produced by the demo code. The back up plan will be to write my own application to collect the required network data, but I would like to have Iperf working so that I can test my own application.

If anyone has suggestions of tools to collect network data like bandwidth, latency, goodput and jitter, that work on linux and android using a client server architecture, then comment below.

So, I’ve got my hands on yet another android phone, I think this is phone number 6 or something like that. It is a HTC Magic, that is currently not rooted. I boot it up, get it going and download the Iperf for Android application and …

…. it still will not work

So, I do some research and I come across another application that claims to also act as an Iperf cleint, this one is called Aperf. I install it on two different android phones, test and …

…. it still will not work

Repeating the tests, changing Wi-Fi networks and finally it works, The following results are from the Iperf server

[ ID] Interval       Transfer     Bandwidth

[  4] local port 5001 connected with port 58204
[  4]  0.0- 8.9 sec  30.0 KBytes  27.6 Kbits/sec
[  5] local port 5001 connected with port 37831
[  5]  0.0- 6.0 sec  47.0 KBytes  64.3 Kbits/sec
[  4] local port 5001 connected with port 43876
[  4]  0.0- 6.6 sec   132 KBytes   164 Kbits/sec
[  5] local port 5001 connected with port 56253
[  5]  0.0- 6.6 sec   400 KBytes   496 Kbits/sec
[  4] local port 5001 connected with port 55373
[  4]  0.0- 6.5 sec   103 KBytes   131 Kbits/sec
[  5] local port 5001 connected with port 50778
[  5]  0.0- 8.6 sec   697 KBytes   662 Kbits/sec
[  4] local port 5001 connected with port 42511
[  4]  0.0- 5.1 sec  59.0 KBytes  94.3 Kbits/sec
[  5] local port 5001 connected with port 42474
[  5]  0.0- 5.9 sec   386 KBytes   539 Kbits/sec
[  4] local port 5001 connected with port 38663
[  4]  0.0- 8.6 sec  35.0 KBytes  33.3 Kbits/sec
[  5] local port 5001 connected with port 38036
[  5]  0.0- 8.2 sec   332 KBytes   331 Kbits/sec

The information above dose not show the complete picture. This data was collected from the server, in each case the client has only transmitted data for 5 seconds, this means that the bandwidth values above as incorrect. To calculate the correct bandwidth values I need to take amount of data transferred and divide by 5 seconds.

The client dose not seem to output any data except that required to calculate bandwidth. Using UDP instead of TCP dose not seem to allow me to collect any more information.

Ironically the network statistics collected by the Signpost diagnosis android app are latency, goodput and jitter but the only network statistics that I am able to collect is bandwidth.

I do not know where to go forward from here, I need accurate network statistics between a android client and Linux server so I can test the code. I could write my own application to collect the data, but then I will have the same problem again as I need accurate network statistics to check my application is working correctly

Any suggestions ??

Another Failed attempt to set up iperf on Andriod Phone – Demo Pt 4.1

Due to the issues with the Iperf application for android and part of the touch screen on my andriod phone not working properly, I’ve decided that it would be best to set up SSH to remote access on android phone, to make working with the phone easier.

To application that I decided to use to help get my SSH running on as quickly as possible was SSHDroid. This is an excellent application that I would highly recommend. The steps in setting up SSH access where:

  • Install SSHDroid and launch application
  • Change the password from its default which is “admin”
  • Install OpenSSH on your linux computer
  • run ssh root@
  • Enter password when requested

Now I have the command line of the android phone, I downloaded iperf and extracted the contains of the .tar.gz file to the SD card. The next stage in my plan was to use ./configure then make then make install as per usual.

But as ever, thing are never that straight forward.

  • on doing ./configure, I get permission denied
  • on doing sudo ./configure, I get sudo: not found
  • on doing echo $USER, I get root
  • on doing ls -l | grep configure, I get —xrwxr-x

so why will it not work ?

UPDATE:

I’ve managed to deal with the “Permission Denied” error despite having root access and the correct permission by prefixing ./configure with sh. This then fails to compile due to the lack of a C++ compiler

Using Iperf for Collecting Data – Demo Pt 4

Today, I am going to take a look at Iperf and get it running between my server (written in Ocaml and running my laptop) and client (on an android phone). To avoid the issues with IP addresses, I will use the same Wi-Fi network for both the client and server so that both devices are behind the same NAT box and can address each other using the private IP addresses. In this case, (like before) I only need the IP address of the server, which I will get from connection information in Ubuntu 12.04.

Iperf is already installed the server (my laptop) from when I was using Iperf to test the network properties of Tor such as latency, bandwidth and packet-loss. This was before starting this blog. I assume that Iperf was not included in Ubuntu 12.04 and that I got it via “sudo apt-get install iperf” (someone please correct me if I am wrong in this assumption)

Getting on Iperf on the client (an android phone) is a little more complex. Iperf has an android application at the google play store but my android phone does not have an app store as its running CyanogenMod. The paragraph at the top of this wikipedia article explains why there is no build in google play store

The following instruction where taken from this YouTube video. To do this you will need a micro SD card and a USB adaptor

To get the Google Play Store on CyanogenMod:

  1. Download the correct version of gapps from here
  2. Copy the .zip file of gappy onto the micro SD card and put SD back into phone
  3. Reboot in recovery mode
  4. Select flash zip from SD card and then the gapp file
  5. Reboot android phone
  6. Sign-in to your Google account

Then I simply get the Iperf application from the Google Play Store by searching Iperf.

But…
The Iperf application on android don’t seem to work,  The application will load and allow me to enter an Iperf command, in this example I am simply entering -s and click Done, but then nothing happens. If I click the button with “off” on, it momentary turns green and says on before returning to off.
So as per usual its time for some trouble shooting checks:

  • Is the application for my version of andriod ? Yes, the application requirement is 1.5 or up and my version is 2.3.7
  • Is there network connectivity ?  Yes
  • Is the command that I’m test correct ? Yes -s is the example used for screenshots on Google play, also other commands like -c also don’t work
  • Is this a known bug ? nope, source here

I’ve posted the question on stackoverflow here

Whilst I wait and see if anyone can help with my problem. I am going to take a look into the world of Android terminal emulators to see if I could run Iperf this way instead if the android application still fails to work or maybe I can ssh into the phone and run iperf. CyanogenMod comes with a terminal emulator, which I will use for now