I booted from another Linux OS and trawled through xorg.logs in /var/log/ and found it was struggling to discover my Screen0 for some reason. For fun, i decided to run “yum remove nvidia-x11-xorg..” (cant remember the exact syntax):

xorg-x11-drv-nvidia.i686 : NVIDIA’s proprietary display driver for NVIDIA graphic cards

I then tinkered with rewriting xorg.conf etc and managed to get it back to a running X session, granted at 800×600 (shudder).

I then ran “nvidia-xconfig” to regenerate my xorg.conf for Nvidia now the drivers were re-installed, and then rebooted. Same problem again. Hmm.

After rinse-repeating this process, I twigged the problem – the “xorg-x11-drv-nvidia” drivers were showing as “…2.6.32.12-115″ whereas my new kernel was definitely a 2.6.32.14-127. After rebooting and choosing the 2.6.32.12-115 kernel, automagically everything sprang back into life again.

Moral of the story – dont be a feckwit like me and do something like this, but if you do, try and boot from the kernel which matches the version of Nvidia drivers as above.

HTH

Now Rhythmbox doesnt particularly make it easy for users to add their own plugins via the GUI, so you will need to do it via the terminal / CLI. In this example, I will be installing the “Jump to playing” plugin for Rhythmbox (download here jump-to-playing-0.3.1.tar.gz ).

First, download the file to your standard directory. Mine is /home/Sam/Downloads . Then, fire open a CLI / Terminal window and change directory to where you downloaded the file to, i.e.

cd /home/Sam/Downloads

Now, you will need to extract the .tar.gz file using a command like below:

tar -zxvf jump-to-playing-0.3.1.tar.gz

In situations like the above, tab complete is your best friend. You will now have a folder created with files inside at the location /home/Sam/Downloads/jump-to-playing . You now need to get these files into Rhythmbox in order to get the plugins to work. Fortunately, Rhythmbox in this sense has been kind and made it fairly simple. All you need to do, is copy the folder and all its contents to /usr/lib/rhythmbox/plugins using a command such as:

sudo cp -R jump-to-playing/ /usr/lib/rhythmbox/plugins/

This command needs to be ran when your current directory is the Downloads folder. Once you have done this, Close/re-open Rhythmbox and go to “Edit -> Plugins” and voila, your new plugin is available to use.

Sam

If a packet capture is over a certain file size, i.e. 300Mb+, it may be beneficial for processing / distribution purposes to split it into smaller chunks. You can do this using the “editcap” Wireshark command.

(For Windows) – Firstly, copy the packet capture to your “C:\Program files\Wireshark” folder. Then use the “capinfos -c” command on the packet capture to find out how many packets it contains, as below:

C:\Program Files\Wireshark>capinfos -c samplepacketcapture.cap
File name: samplepacketcapture.cap
Number of packets: 1070031

As we have 1,070,031 packets, it may be beneficial to split them into pcaps of 50,000 each:

C:\Program Files\Wireshark>editcap -c 50000 samplepacketcapture.cap

When the command has completed succesfully, there will be an amount of small .cap files in the same directory of 50,000 packets each.

Merging lots of packet captures into a single Pcap

Sometimes we may wish to merge multiple packet captures i.e. 4-5 100Mb Packet Captures into a single one for analysis and to remove errors such as “Ack received for unknown packet” etc. To do this, (For Windows) – Firstly, copy the packet capture to your “C:\Program files\Wireshark” folder. Then, we can use the “mergecap.exe” program, similar to how editcap works.

C:\Program Files\Wireshark\mergecap.exe -w master-cap.cap subcap1.cap
subcap2.cap subcap3.cap

In this command, we are merging subcap1 – subcap3 into a few file, called master-cap.cap.

Thats all there is to it. For references, some useful operators are:

Usage: mergecap [options] -w <outfile>|- <infile> ...
Output:
 -a                concatenate rather than merge files.
                   default is to merge based on frame timestamps.
 -s <snaplen>      truncate packets to <snaplen> bytes of data.
 -w <outfile>|-    set the output filename to <outfile> or '-' for stdout.
 -F <capture type> set the output file type; default is libpcap.
                   an empty "-F" option will list the file types.
 -T <encap type>   set the output file encapsulation type;
                   default is the same as the first input file.
                   an empty "-T" option will list the encapsulation types.
 -h                display this help and exit.
 -v                verbose output.

TCPDump is a de facto packet capturing tool for Linux, Unix etc. Its usage is outlined below.

Installation is very often not required as it is bundled with most operating systems; if not then there are various ways to install using apt-get install, yum install, etc or you can download the source and compile accordingly.

To run tcpdump, you simple need to run the command “tcpdump” from CLI as such:

root@SRM-TAC-2010:~# tcpdump

There are many TCP dump flags which are useful operators; a list of which can be found here [13].

Normal usage would be:

1. List all interfaces we are able to listen on, using the command:

root@SRM-TAC-2010:~# tcpdump -D

This will give you an output such as:

root@SRM-TAC-2010:~# tcpdump -D
1.eth0
2.any (Pseudo-device that captures on all interfaces)
3.lo

As above, the NIC we want to listen to is “eth0″ as the other 2 are “all NIC’s” and the loopback interface. As such, we will note the integer on the far left, in this example “1″.

2. Now we know we want to listen on interface “1″, we run the command:

root@SRM-TAC-2010:~# tcpdump -i 1

This will kick off the windump capture on interface 3, giving an output like so:

root@SRM-TAC-2010:~# tcpdump -i 1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

[traffic removed for blog]

10 packets captured
13 packets received by filter
0 packets dropped by kernel

3. Obviously, we dont want to output it to CMD as its very hard to process in tools such as Wireshark and we dont want to be copying and pasting etc. So we run the command using the -w switch which tells the program to write (-w) to the file specified directly after (parameter), as such:

root@SRM-TAC-2010:~# tcpdump -i 1 -w outputfile.txt

This will write the packets to the file “outputfile.txt” to where you are running the program FROM i.e. in my example here, i am in the directory /root running the command “tcpdump” therefore my “outputfile.txt” is saved in /root/outputfile.txt. If i wanted to, i could create “/root/files/”, change directory there “cd /root/files/” and then run the command and the logs would be saved there.

If you try and open the “outputfile.txt” in vi, cat, etc you will see something along the lines of:

Ôò¡???*?½?E :#&à–›#P?úð€`

However, if you change it from “outputfile.txt” to “outputfile.cap” – you can then open it in Wireshark no problem at all for analysis.

4. However, in Wireshark if you run the command above, you may see the following packet header errors:

14	0.001629	10.1.1.102	10.1.3.42
SMB	NT Trans Response, <unknown>[Packet size limited during capture]

This is regarding the “Snarf” (-s) operator for the program. If the packet size is left at default (96) it should be ok for IP/TCP/ICMP/UDP, but may provide errors on things such as SMB, etc. You may need to increase the snarf (snaplen) to avoid seeing this error message; using “-s 150″ i havent ran into any errors so far. To use the -s flag, use the following:

root@SRM-TAC-2010:~# tcpdump -i 1 -s 150 -w outputfile.txt

This will result in packet captures being actually usable in Wireshark as below:

14	0.001500	10.1.1.102	10.1.3.42
SMB	NT Trans Response, NT NOTIFY

5. We may be inclined to use the option “-vvv” (“even more, even more verbose”) – this will give us more in-depth information in the packets i.e. printing telnet options in Hex etc – the command syntax as below:

root@SRM-TAC-2010:~# tcpdump -i 1 -s 150 -w outputfile.txt -vvv

This should give a very readable, useful packet capture. Finally, we may wish to limit the amount of packets we capture, we can do this using the -c (small c) flag, as such:

root@SRM-TAC-2010:~# tcpdump -i 1 -s 150 -w outputfile.txt -vvv -c 15000

This will limit the # of packets captured to 15000.

Hope this helps!

Sam

The network path is the path in which the packets/datagrams have to traverse in order get from sourceip:port to destinationip:port. This path can include router interfaces, firewall interfaces, switch interfaces, etc. All of which will have an MTU value (Maximum Transmission Unit). This MTU value is simply a filter, which if the packet exceed it will be dropped. Say for example, the router interface we are going via has an MTU of 1422 (this is in bytes). If we transmit packets with a size of 1522, the packets will either be dropped if the sending TCP stack has the DF (Dont Fragment) bit set; or the packet will be fragmented which does affect network performance.

Now the problem is you need to either set all MTU’s to a fixed value on your ethernet LAN (1500, for example) and then ensure all packets transmitted comply with this, accept that fragmentation will happen – for example when using an MTU of 9000 with jumbo frames, or use PMTUD.

PMTUD is relatively simple in its complexity. If enabled, the packet will be sent out with a size of 1522. When it hits the interface with a MTU 1422, which it cannot pass through, the packet is dropped and a message is sent back to the sender saying “It was too big, the MTU of the interface was 1422″. The sender will then update their MTU to 1422, and re-send. It will now pass through the first interface as its size is now =< 1422.

It does this repeatedly until it reaches the destination IP; once it can achieve such a path it can be said the path MTU is 1422 (if no further interfaces with lower MTU’s are found).

Delving a little more into the details, the way this “It was too big, the MTU of the interface was 1422″ message is relayed back to the source IP is via ICMP. The router will send an ICMP “Fragmentation Needed” message back to the source IP, containing the MTU value in question (1422). The ICMP “Fragmentation Needed” message, for reference, is Type 3, Code 4.

The problem with such a feature is the fact that ICMP is often misunderstood and misconfigured. Some security personnel see it as the devil and as such block all ICMP. If this happens, the connections will complete at a TCP level (SYN, SYNACK, ACK) and establish a flow, however the connection will “hang” when the data begins transfer. This state is often referred to as a “black hole connection”. Therefore i stress that if you are indeed going to use PMTUD, ensure that the ICMP path beetween hosts is also clear and alive.

Sam

Basically, to establish a TCP connection, you will need 4 things:
1. A Destination IP Address
2. A port on that Destination IP Address
3. A Source IP Address
4. A port on that Source IP Address

As you may be aware, an IP Address with a port listening on it is referred to as a “Socket”; for example 192.168.1.1:80 is a socket, listening on port 80 typically means this is a HTTP Server.

To establish a TCP connection, you need 2 sockets to be able to talk to each other in order to initiate what is known as a “flow”; think of it as a 100m running track, its a straight line with 2 points, a start and a finish. If you dont have a start you cant send anything, if you dont have a finish it’ll never get there.

This “flow” between the 2 sockets is why TCP is typically referred to as a connection oriented protocol, as opposed to UDP which is referred to as connection less.

Anyway, before I digress too far from the crux of the matter: In order to establish a connection to transmit “data” over, you must first complete the three way handshake between the 2 sockets. This 3 way handshake consists of two vital flags used in a TCP conversation:

1. SYN (Synchronise)
2. ACK (Acknowledgement)

In the first stage, the Client (Establisher) sends a TCP SYN control segment to the Server (Recipient). This is the first stage of the handshake.

The Server receives this SYN, and in turn sends a SYN-ACK to the client. This ACK confirms Server has recieved the SYN, and in turn he has sent out his own SYN to synchronise with the client. This is the second stage of the three way handshake.

Finally, the client receives the SYN-ACK, and knows that Server got his SYN so he is good to receive communications. Client responds with an ACK to the Servers SYN, saying that he confirms the SYN packet sent by Server. This is the third and final stage of the handshake. Once this is done, it is said that a TCP Connection is “Established”.

To give this a metaphorical twist; Joe wants to communicate with Harry over a two-way radio. To ensure that Harry is listening on his send frequency, Joe shouts “Hello can you hear me?” down the radio (Stage 1, SYN).
On hearing this, Harry answers with “Yes, Can you hear me?” (ACKnowledges Joes original transmission, and sends a SYN of his own).
Finally, Joe knows Harry is listening as he has confirmed his question (ACK’d), so Joe answers Harrys question (SYN) with a “Yes” (ACK). It can now be said that Joe and Harry in an established communication.

Now, you may ask – what is being done in this SYN stage? Well, technically they are allocating buffer sizes, synchronising sequence numbers and various other variables. You can think of it using the metaphor as they are tweaking the frequency in which they are going to communicate on.

For further background information, there is a very good introductory page here:

http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml

It has some good graphics, etc which help convey the concept.

Hope this helps!
Sam

Flow control is simple in its abstract view: Basically the person sending the packets wont send so many as to over flow the “buffers” of the reciever by sending too many packets / too quickly.

By enabling flow control, the receiving party has a way to control this by *explicitly* telling the sender how much buffer space they have available (Note: This is dynamic i.e. constantly changing so the receiver needs to be in constant communication sending updates). This is known as the “RcvWindow” field in the TCP segment. If you look in Wireshark you can see a “WIN” field which speaks to this:

578 22.020649 192.168.0.3 69.63.176.179 TCP 36272 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=877827 TSER=0 WS=6

“WIN” of 5480 means that my local client 192.168.0.3 is telling the BBC Server during my “SYN” packet (1st packet of three during the “Three way handshake” (Covered later)) that I can receive 5840 bytes at a time.

Now, the sender, when flow control is enabled, will keep the amount of transmitted, but un ACKnowledged (no ACK response from reciever to confirm receipt of packet) data less than the most recently received RcvWindow from the client. In TCP, there are 2 key fields for this topic; “RcvWindow” which is the amount of spare room in the buffer, and “RcvBuffer” which is the size of the receive buffer.

Now, Flow control is interesting in performance environments as sometimes users / architects can see negative results when enabling flow control. Key point here, is that flow control MUST be enabled END TO END. That means that from the NIC on the PC, to the switchport attached to the PC, to the switchport attached to the server (for example) to the NIC on the server in use. If end to end flow control is not in use then you will end up with bottle necks and high rates of retransmissions causing congestion on certain LAN segments.

Congestion is typically detected by lost packets (high retransmit / RETX rate), and large delays in the time stamps beetween packets (again, could cause send mechanisms to hit timer and RST and RETX the packets).

There is a really good powerpoint presentation available here:

http://www.cs.fsu.edu/~zzhang/CNT5505_Fall_2008_files/week12_2.ppt

This talks to the reasons of Congestion and has some great diagrams which talk to how it can occur and how flow control helps.