I was interested in figuring out the time taken for a HTTP SSL handshake and the following file download time and after a discussion with colleagues decided in utilizing ssldump.
The ssldump utility can either read the output of tcpdump or could simply be set to listen on a particular interface as well. Some examples follow:
Listen on the Loopback interface “lo”:
Note that if the client and server are on the same machine then this is what you might need to do.
Listen on a particular interface:
It could also read the generated output of tcpdump:
ssldump -r tcp1 [here tcp1 is the file that was generated
as a result of running tcpdump]
However if you have network traffic captured as a result of running tcpdump and running ssldump on it leads to “ERROR: Length mismatch” message, then one needs to increase the packet capture size. This is what I did for a quick check:
tcpdump -nnvvXSs 0 -w tcp1 [write to file tcp1]
Here the value “0” is assocated with the “snarflen” (-s) argument and it implies that we “use the required length to catch whole packets” (from the man page of tcpdump).
For ssldump troubleshooting, please refer to:
To use a later version of Python to what the RPM is available for, one needs to build and install it.
This is what I did and it was a breeze to get that to up:
[I am installing in this folder]</li>
And that is it. If you run into issues, one can always start from scratch by running:
<li>./configure -h [to print out the help]</li>
and then continue with the 3 steps that were outlined earlier viz.
./configure [Specify options to fine tune the deployment]
There are a myriad of tools and scripts that one runs on Linux to figure out the important question of how much free memory is left viz. “how much RAM is available?”.
And to answer the query, we use the following 3 tools that are almost guaranteed to be on all Linux systems and some Unix variants:
The following command line demonstrates the invocation of the “free” command to display the amount of free and used physical and swap memory in the system in megabytes – borrowing the description from the man pages.
$ free -m
total used free shared buffers cached
Mem. 3887 3731 155 0 314 1171
-/+ buffers/cache: 2245 1641
Swap: 501 0 501
Free memory => free + buffers + cached = 155 + 314 + 1171 = 1640 =~ 1641 [the value in 3rd row. 4th col]
---- removed the top two lines from brevity -----
Mem: 3980704k total. 3821604k used, 159100k free. 321752k buffers
Swap: 514040k total. 368k used. 513672k free. 1199916k cached
Free memory => 159100k + 321752k + 1199916k = 1680768k =~ 1641M (this is the value that we arrived at from the “free” coammand above]
Using vmstat with the ‘s’ switch to display the memory statistics, we have the following:
$ vmstat -s
3980704 total memory
3823000 used memory
2604536 active memory
791544 inactive memory
167704 free memory
322028 buffer memory
1201220 swap cache [This is the swap that has been loaded
into RAM - it is not the ‘cache from the output of top.
It is RAM that was swapped out but is now back in RAM]
514040 total swap
368 used swap
513672 free swap
1185336 non-nice user cpu ticks
3479 nice user cpu ticks
345953 system cpu ticks
2193981008 idle cpu ticks
361097 I0-wait cpu ticks
27842 IRQ cpu ticks
65187 softirq cpu ticks
0 stolen cpu ticks
9239003 pages paged in
43636292 pages paged out
8 pages swapped in
94 pages swapped out
2617332222 CPU context switches
1344272629 boot time
Free memory => free memory + buffer memory + swap cache = 157704 + 322028 + 1201220 = 1680952 = 1641.554M =~ 1640M
The paths to discovering memory statistics are many but they ultimately lead to the same figures.