exercise 5

Following is the screen shots of the traffic captured by the wire shark while sending the mail.

The protocol used to perform the sending the mail while capturing the traffic is HTTP and TCP protocol. The IP address of the machine is 10.1.1.2 and the IP address of the mail server is shown as 66.102.11.19. while performing this task I found that the mail server I am using is in the secure communication and as well it is using the HTTP post command. According to the wire shark my system is using two protocol and they are TCP and HTTP protocol.

exercise 4

While capturing the live data from the web site www.google.com, found the following informations.

The IP address 10.1.1.2 sends the request to 10.1.1.1 through the DNS. Here 10.1.1.1 is the IP address to the LAN port, and the IP address 10.1.1.2 is the address of the machine which sends the request to the LAN port to access the www.google.com. Once the IP address 10.1.1.1 gets the request from the IP address 10.1.1.2 the IP address 10.1.1.1 sends the common name of the websites. While the IP address 10.1.1.2 gets the common name of the website then it sends the another query to the IP address 10.1.1.1 about the safebrowsing and ask to allow the IP address of the cname. Once the IP 10.1.1.1 gets the request it sends the IP address of the cname which is 66.102.11.101 and 66.102.11.100

once the IP address got the IP of the google it will directly sends the request to the IP of the google. While performing all this transaction both the IP were using the DNS protocol.

10.1.1.2 sends the request to the 10.1.1.1 throught DNS

10.1.1.1 sends the reply to the 10.1.1.2 through DNS

10.1.1.2 sends the request to the 10.1.1.1 through DNS

10.1.1.1 sends the reply to the 10.1.1.2 through DNS

Here as previously mention that the 10.1.1.2 is the IP address if the machine which sends the request and the IP address 10.1.1.1 is belongs to the LAN port of the machine.

To complete this transaction the system passes the 11 frames to get the required website by the machine.

Following is the screen shot of the Live capture

exercise 3 question C

Frame 6 is running under the Hypertext Transfer Protocol with the Get method. The data for the frame 6 is given below:
Request Method: GET
Request URI: /
Request Version : Http/1.1
Host: www.yahoo.com
Similarly frame 21 is running under Secure Socket Layer
RLSv1 Record Layer: application data protocol: http
content type: Application Data (23)
Version : TLS 1.0 (0x0301)
Length: 432
Encrypted Application Data: FE6B3CD259B796669F2767DF9972DCDA2541F030D9B3D4E9...
Due to the above information frame 21 can't read the same as in frame 6. Frame 6 is using HTTP to complete the transaction while the frame 21 is using the secure socket layer to complete the transactions.

exercise 3 question B

In row three there is no frame listed in row iii. The only frame listed on the row iii was 13-20 which belongs to the web page my.usf.edu. The main reason for not to listing the frame in row iii for the web page www.yahoo.com is that the there is no protocol performing in the row iii. If there is no protocol shown in the table given the destination and the source address will not know to send the request through which protocol.

exercise 3 question A

While comparing the TCP packet in the frame 3 and the frame 12 we found the following difference :
Frame 3:
Transmission Control Protocol, src port: omilink-port (3904), dst port:http (80), seq:0, len:0

Flags: 0x02 (SYN)
0... ....=congestion window reduced (CWR): not set
.0.. ....=ECN-echo: not Set
..0. ....=Urgent: not set
...0....=Acknowledgment: not set
.... 0...=Push:Not set
.... ..1.=Syn: set
.... ...0=Fin: not set
windows size= 65535
Checksum: 0x6405 [correct]
Options: (8 bytes)
Maximum segment size: 1406 bytes
NOP
NOP
SACK permitted


FRAME 12
Transmission Control Protocol, src port:mpl-gprs-port (3924), dst port: https (443), seq:1, ACK:1, Len=0
Flags : 0x10 (ACK)
0... .... = Congestion window reduced (CWR): Not set
.0.. .... = ECN-Echo: not set
..0. .... = Urgent: Not Set
...1 .... = Acknowledgment :set
.... 0... = Push : Not Set
.... .0.. =Reset: Not Set
.... ..0. = Syn: not set
.... ...0 = Fin: Not Set
Window size: 65535
Checksum: 0xa956 [correct]

[SEQ/ACK analysis]
This ACK was been segmented in frame 11. With the RTT to ACK and the Segment was: 0.000105000 seconds.

While comparing this two frame what we found is that the frame 3 is been segmented through byte process while the frame 12 is been segmented through the time process analysis. Frame 3 shows how much byte it will occur wile segment the and the frame 12 shows how many time they need to segment. In flags section the frame only sets for the SYN and the rest of the flags was not been set similarly in frame 12 Acknowledgment was been set and rest of the flag were not set.

exercise 2 question H

The frame 141 and frame 142 got same source address and request graphic file from the same destination IP address . The information on both the frame is HTTP//1.0 200 ok (GIF89a). Following are the information from which the client can differentiate in the image requested by the same IP address with the same kind of information.

FRAME 141:

Transmission Control Protocol, src port: http (80), Dst port: stgxfws (1226), seq: 15765, Ack:3930, len:1045

FRAME 142

Transmission Control Protocol, src port: http (80), Dst port: slinkysearch (1225), seq: 25777, Ack:4253, len: 863

The above information show the different data hold by the two frame with same source IP address and the same information. The destination port for frame 141 and 142 are different and the seq and the acknowledgment were different to each other. By this difference the client can differentiate the about the graphic to match with the get statement in the frame.

exercise 2 question G

In frame 139 the IP address 64.21.46.134 sends the request to the IP address 131.247.95.216 through the TCP protocol and the information given was that the segmented TCP will be reassembled PDU in frame 160. Similarly request send by the IP address 64.21.46.137 to the 131.247.95.216 and the information is acknowledgment and is been segmented in frame 133. This shows that the segmented TCP is not being reassemble in the frame 160. Similarly the information on frame 142 shows that in 134 the ACK is been segmented and not going to be reassembled in the the frame 160. But in the frame 143 the information given is bit different than the information in frame 141 and 142. The information on this frame is that ACK is been segmented in the frame 140 and will be reassemble the PDU in frame 160.
If the packets that are suppose to be reassembled do not arrive in a continuous stream than the the there will be error and the IP address could not send the proper data to the requested IP address. In this case the TCP will get the incorrect data or some time TCP error may caused due to checksum offload. This shows that the failure of the reassembled of the segmented data in different frames and fail to send requested data to the desired IP address.
For example: whenever we get the information like “page could not be displayed” in our web page is the example of this error.