| Subcribe via RSS

Tcpdump – Usage and operators

April 30th, 2010 | No Comments | Posted in Networking

“tcpdump”: Installation and Options

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

Tags:

Path MTU Discovery

April 29th, 2010 | No Comments | Posted in Networking

Path MTU  Discover (PMTUD) from herein is a technique for determining the MTU size on a network path beetween 2 IP addresses; the source IP and the destination IP (reference the previous blog post on TCP flows).

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

Tags: ,

TCP Flow Control

April 24th, 2010 | 1 Comment | Posted in Networking

There is a deep misunderstanding of flow control in the industry amongst people; i liken it to subnetting, most people have a hard time understanding it because they dont have the time to sit down and study it.

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.

Tags: ,