Wireshark)Looking.into.the.Packet. … · document to help you understand how read a ... Wireshark expanded on the ... This method will be based on a system that I helped design and

WIRESHARK-‐LOOKING INTO THE PACKET 1

Wireshark-‐Looking into the Packet

Henry A. McKelvey, MIS

Blacks in Technology


Wireshark-‐Looking into the Packet

Protocol Analysis is one of the best methods for troubleshooting network problems in

and out of the cloud. Having designed, created and implemented technology for analyzing the

cloud network. I think it is time to look at ways of defining the cloud from the inside out.

One of the most interesting things about networks is that they usually tell you if there is a

problem. Three basic issues occur with networks; slow throughput, no throughput, and corrupted

data. Many things cause these issues to occur, and many events may occur because of these three

issues, but these are the core. Incorrect configuration of switches/routers may cause these issues

to occur. Incorrectly configured servers may also cause these issues to occur. The important

thing is to be able to tell what is happening and why. This is where protocol analysis comes in.

Protocol analyzers allows the network, or systems administrator to see what is occurring on the

network, or what their systems are responding to and how. For instance, the protocol analyzer

divides the transaction of packets up into usually 5 -6 divisions of function based on the TCP/IP

protocol stack.


The Background

First, you have Frame data (bytes on the wire) which constitutes the information linked to the

Frame (Interface ID, Encapsulation Type, Time data, Frame Number, Frame Length, Protocols

in Frame, etc...) This data can be used to help troubleshoot Layer 1 issues and situations if the

network (Physical Layer) baseline is known.

Second, you have the Data Link Layer data (Based on Encapsulation Type) which constitutes

the information linked to the data link mode of your system, usually Ethernet, but can include

Frame Relay, ATM, or other Layer two technologies. The sections covered in Ethernet are

Source Media Access Control Address, Destination Media Access Control Address. Information

gathered from Address Resolution Protocol (Source MAC Address, and Destination Internet

Protocol Address linked to MAC Address, Source and Destination LG and IG bits used to show

globally unique address and individual address positions (Extracted from the MAC Address) and

then the Ether Type for Ethernet, this is 0x0800.


Third, you have the Internet-working Layer data. This section includes the IP Version (4 or

6), header length, Differentiated Services, Explicit Congestion Notification (ECN), total length

of packet, packet identification, flags (Reserved bit, Don’t Fragment, More Fragments,

Fragment Offset, Time To Live, Protocol (TCP/UDP), header checksum, checksum data, source

and destination domain to IP link.)

Fourth, you have the Transmission Control Protocol layer data, which gives you the source

and destination port data, sequence number, acknowledgement number, header length, flags

(reserved, nonce, congestion window reduced, ECN-echo, urgent, acknowledgement, push, reset,

synchronization, and finish), window size, checksum, and analysis of sequence and

acknowledgement

Fifth, you have the data, which is sent or as it is called the payload. The data also includes its

length.

Now, you might ask, “What is this review of the protocol stack for?” Well it is to show you,

the reader, that the protocol analyzer can contain data that you need to complete your work or at

least tell you where a problem may exist. For instance, I was working on a project and one of the

programmers was having a problem getting her program to run. The young woman was a pure

programmer with no knowledge of network or other data resources experience. She knew how to

program and that was it. Therefore, it was no surprise when she made a call to a process to

execute a command on another system her program would fail. She traced the fault to a


command that made a system call using a socket (IP Address: Port). She was told by her project

manager to talk to one of the network people (me) about the issue, so what did I do. On her

system, I installed a protocol analyzer and looked at her interface, just as expected the program

could not locate the asset online. Therefore, I told her that the program was working fine and that

before the system call she should write some code to do a resource check that would either put

the program into a wait condition with periodic checks or throw an exception that states that the

resource is busy and to try again later. She wrote the code to do both and when the remote

system was back up and running the program ran without a problem. This is one example of

how protocol analysis can be used to aid in network troubleshooting that extends into the realm

of programming. The program was making use of cloud assets, which permitted the use of a

protocol analyzer.

Why is this important? As more programming ventures into remote or virtual connections, as

in connecting to virtualized and cloud-based systems, the use of protocol analysis will become

more commonplace. A once ignored facet of network troubleshoot is going to become a widely

used method of verifying network connectivity of virtualized and cloud based systems.

There are many Protocol analyzers out there and they all function in and about the same.

However, there is a complexity involved with using a protocol analyzer to troubleshoot network

wide issues and events. I experienced this while working at Verizon. I was helping a colleague

troubleshoot a network problem, which required the use of multiple protocol analyzers installed

to provide data as to correlate network events with network problems, using the multiple analysis


systems was easy but correlating the data was not, because the units were not synced up and the

data was captured at different times. It was during this “comedy of errors” that an idea emerged,

that leads to a method being developed to provide correlation to the protocol analysis/ capture

process. After some time and effort, we (Jimmie Peterman, Rosa Underwood, Emory Young, and

I) developed a way to capture, and correlate data that could be used on Enterprise Networks to

troubleshoot events in such a way a person could tell what was happening without having to have

an extensive knowledge of the network. The method and device was the subject of patent

application 20110317562 and the subsequent granting of United States Patent US8064350.

Understanding the layout of the protocol analyzer is one thing, but looking at it for the data that

can be harvested from a capture is the power of the analyzer. I have attached a file to this

document to help you understand how read a protocol analyzer during a simple troubleshooting

exercise that will be discussed in the latter part of this paper. For now let us discuss the

technology of protocol analysis.

The Technology

To some of you this may appear to be a mundane exercise, but one thing I have seen

consistently is the writing of programs for use on the Internet/Cloud and people having problems

with the application of remote sockets. This is a problem made for the use of a protocol analyzer.

There was a time where the protocol analyzer was used only for network troubleshooting. To use


a protocol analyzer you had to invest in a system that may have cost thousands of dollars, but

because of the open source movement, you now have a choice of free very well coded software

based protocol analyzes such as Wireshark (I use this one so this will be about Wireshark).

Like I had mentioned in the past your choices were limited to some very costly

equipment such as the Hardware based Radcom Protocol Analyzer, Teledyne LeCroy Analyzer,

and the HP/Agilent LAN Analyzer, on the software side you have EtherPeek and Agilent’s

analyzer software. The fact was to do protocol analysis you had to spend a lot of money, which

put the proper troubleshooting of network problems out of the range of most small companies.

Then the Security Administrator Tool for Analyzing Networks (SATAN) was invented.

“SATAN is a tool to help systems administrators. It recognizes several common networking-

related security problems, and reports the problems without actually exploiting them”

(porcupine.org, 1995).

SATAN permitted for the first time (open source tool wise) the viewing of network

activity in response to network stimuli. This opened the door for other advancements such as

Ethereal, which was the first full, featured open source protocol analyzer. Now, take into mind

that it was not the first open source protocol analyzer, it was the first full featured protocol

analyzer (there is a difference). Ethereal remained the number 1 free open source protocol

analyzer for years, before finally being surpassed by Wireshark. Now, this is another gotcha’

Wireshark is Ethereal all grown up. Wireshark expanded on the feature sets of Ethereal and


added a lot of support for other network technologies that were left out of the Ethereal feature

set.

Now since we all like free stuff, I am going to guess that Wireshark is looking good to

you now as a possible alternative to the standard protocol analyzers. If so, go on line and

download it. It will load two major pieces of code the first is the Wireshark package, which

includes the analyzer and the protocol modules. The next piece of code is the subsystem that

permits the capture of packets over the network interface, this code is called pcap (for

UNIX/Linux) or to be more inclusive WinPcap (For Windows). I would be amiss if I did not

discuss pcap and its role in the use of protocol analysis.

Packet capture (pcap) is a command line tool that contains the APIs, which permit the

capturing of packets over the network interface of a system. The program itself from what I

know is written in C. This permits higher-level languages (Java, TCL, .Net, and other scripting

type languages) to pass and receive variables/data-sets and to interact with the pcap program in

an almost seamless fashion. In fact, on Linux and UNIX systems TCPDUMP uses the pcap

library (libpcap) to provide packet capture output. *Note: The TCPDUMP group wrote pcap.

Packet Capture (pcap) can be used as a standalone program or a wrapper (Ethereal, Wireshark)

that permits GUI use of the library can access it. Many programs use the pcap library, which

makes it one of the most used programs in the network arena.


Now since we have discussed the histories of Wireshark and Pcap, let’s get into the actual

use technology embodied by these two programs.

When used in unison the two programs are able to provide information as to the condition

of the packets in a network. The next part of this three-part blog will be how Wireshark works. I

will be examining a way of troubleshooting a web site problem using two Protocol Analyzers.

This method will be based on a system that I helped design and was the topic of US patent #

7,899,323, MULTI-INTERFACE PROTOCOL ANALYSIS SYSTEM. Now take into mind that

I will not be doing the full implementation of patent #7,899,323 just a subset that will permit me

to show how to use Wireshark and TCPDUMP to troubleshoot problems in the cloud.

The Application

This is the fun part; first we need to know what a good web site session looks like using

Wireshark. This paper has attached to it a file containing a Wireshark capture of a good web site

session to www.google.com and other sites. The start of all troubleshooting begins with the

development of a baseline capture to level-set readings. This is done to provide a comparison

between a good reading and a possible bad reading. I will use a real life problem I experienced

troubleshooting a problem on an executive’s computer at a company where I use to work.

Starting off here is an analog of a baseline capture file:


To use this file you must first have Wireshark and WinPcap installed on your Windows machine. If you

do not have it please install it now. If you have Linux it will come with your Linux distribution if not use

one of the two methods of installation on the Wireshark web site to install Wireshark on your Linux or

Windows machine. Once Wireshark and Pcap are installed. Click on the Baseline.pcap file. This will

open the file up in you Wireshark program. At this point the output will look like this: (See Next Page)

Figure 2


Wireshark Capture without Network Layer Decode

This will give you the raw TCP\IP data without decoding it for URL viewing. To allow network decoding to

take place, follow these instructions:

1) On the menu bar item View

2) Select Name Resolution

3) Click on Enable for Network Layer

4) On menu bar click on Reload symbol

The screen should now look like this:


Figure 3

Wireshark Capture with Network Layer Decode

Notice in Figure 2 on line 4 you have the IP address of 75.75.75.75, then on line 4 of Figure 3 you have

the domain name of cdns.comcast.net this shows that the system decoded the IP Address into its

domain name equivalent. This is vital in troubleshooting this problem. Since this is the baseline we can

consider this file to be good in comparison to the next capture (The infected machine). (See Figure 4)


The infected machine has the following problem. When the user selects www.google.com they are sent

to a failsafe page for yahoo.com. This in and of itself is no problem but it denotes a possible issue with

web site locals. The following is a lesson in how to use protocol analysis to solve this problem.

The following is a copy of the infected.pcap file:

From your machine open up the infected.pcap file Click on the infected.pcap file. This will open the file

up on your Wireshark program. At this point the output will look like this: (See Next Page):


Figure 4

Wireshark Capture without Network Layer Decode

This will give you the raw TCP\IP data without decoding it for URL viewing. To allow network decoding to

take place, follow these instructions:

1) On the menu bar item View

2) Select Name Resolution


3) Click on Enable for Network Layer

4) On menu bar click on Reload symbol

The screen should now look like this:

Figure 5


Wireshark Capture with Network Layer Decode

If you notice what is happening on the wireshark screen it is telling you that the IP Address of

98.139.144.130 is connected to the yahoo.com site and not the google.com.

By performing an nslookup on the infected machine you get this:

Figure 6

nslookup of Google on the Infected Machine


Taking into mind what is happening; here we can see that the nameserver lookup and the domain name

that occurred as the result of the web search are not the same. In fact the IP Addresses to google.com

are in the 75.125.131.xxx range.

Performing nslookup on your machine you get:

Figure 7

nslookup of Google and Yahoo on the Baseline Machine


Using simple logic at this point you can surmise something other than the nslookup is supplying the

errant IP Address, the question is what can do this? Granted this was a simple problem, but it shows the

use of Wireshark in proving there was a problem within the system.

In conclusion, it can be said that wireshark is one of the most useful tools in finding out what problems

may exists on your network. However there are many features that Wireshark has which must be learnt

to master this tool. Here is some suggested reading material and web sites for those who may want to

develop further skill in using Wireshark:

http://www.wiresharktraining.com/

http://www.amazon.com/s/?ie=UTF8&keywords=wireshark&tag=googhydr-‐

20&index=aps&hvadid=21387143575&hvpos=1t1&hvexid=&hvnetw=g&hvrand=1041059935155915014

7&hvpone=&hvptwo=&hvqmt=b&hvdev=c&ref=pd_sl_2789p0sl8p_b

Read and enjoy using Wireshark.

Documents

Wireshark)Looking.into.the.Packet. … · document to help you understand how read a ... Wireshark expanded on the ... This method will be based on a system that I helped design and