ASSIGNMENT 1 - COMPUTER NETWORKS

SHREE KRIPA SHANKARI S

B211269EC

1 c) a)

b)
The length/size of P is 74 bytes and it matches with the length information in P’s
header which is also 74 bytes.
If the lengths match, indicating a total size of 74 bytes, it signifies that the declared
length in the UDP header aligns with the actual length of the captured packet. This
consistency assures the integrity of the packet, affirming that the UDP header's
Length field accurately represents the combined size of the header and payload. In
this case, the UDP packet is well-formed and has not undergone truncation or
corruption, reinforcing the reliability of the captured network data.

c)

The UDP header has a fixed structure. The first 4 bytes represent the source port, the next 4
bytes represent the destination port, and the subsequent bytes include other UDP header fields.

i) Destination port number from hex dump

82 6d 68 e4 06 c1
ii) Source port number from hex dump
3c 55 76 fb 97 c1

d) DNS (Domain Name System) typically uses UDP as a transport protocol, and the
well-known port for DNS is 53. Filtering on destination port number 53 helps you
focus on DNS-related traffic.

e) 55084

f)

i)
ii) Source port number: 53
Destination port number: 55084
The source port in packet R matches the destination port in packet P, and
vice versa. This is because in a typical DNS exchange, the source port of
the query becomes the destination port in the response, and vice versa.

iii) UDP payload = 48bytes for both packets P and R

When comparing the payloads of packets P and R in the context of DNS
communication, it's essential to focus on whether the DNS responses in R
align with the corresponding DNS queries in P.
2. c)

i)
Packet P1 :
Packet P2 :
Packet P3 :

ii)

S.N Pack Source Port Destination Port

o et
1. P1 52256 8
0
2. P2 52256 8
0
3. P3 52256 8
0

The consistent use of destination port 80 in packets P1, P2, and P3 suggests that
these packets are likely associated with HTTP communication and the
destination port 80 indicates that these packets are involved in web-related
communication, possibly representing web page requests or other HTTP
transactions.
iii)

P2 Relative Sequence Number Relative to P1:

The sequence number in P2 (681) is the next sequence number after the last sequence
number in P1 (1). This indicates that P2 is the continuation of the data stream from where
P1 left off.

P3 Relative Sequence Number Relative to P2:

The sequence number in P3 (13389) is the next sequence number after the last
sequence number in P2 (681). This indicates that P3 is the continuation of the data
stream from where P2 left off.
P1 to P2 to P3 Sequence Number Flow:
There is a consistent and incremental flow of sequence numbers from P1 to P2 to P3.

P2's sequence number is the next in line after P1, and P3's sequence number is the next
after P2.
Acknowledgment Number:
The acknowledgment number is consistently 1 in all three packets, indicating that the
receiver has received the data up to that acknowledgment number.

iv) Identify response TCP packets R1, R2,...,Rm from server

indicating acknowledgement. Include screenshot of R1 depicting
TCP header fields. How did you identify the response packets?
On observing the time line of the packets being sent and received (after
adding the filter “ip.addr== 128.119.245.12 && tcp.port==80” ).I can observe
that there are many Acks received for each packet sent.
I am atta
to filter the responses alone from this I used the following filter “ip.addr==
128.119.245.12 && tcp.srcport==80”

Screenshot of R1 depicting TCP header fields :

Assuming R1 to be the first acknowledgment from receiver.
V) Relationship between R1 and P1 :-
P1 have the following properties R1 have the following

properties Seq=1 Seq=1

Ack=1 Ack=2
Len=680 Len=0
Here R1 is sent by receiver saying that everything till 2(excluding 2) is received

successfully, And requesting the sender to send the next packet.

But sender is waiting for Ack 681 or time out , (sender received the Ack 681
after sometime before time out).
Vi)
Time | Source Port | Dest Port | Protocol | Info

| | | |

0.748297| | 80 | | [FIN, ACK] Seq=1 Ack=1 Win=508 Len=0

52256 TCP
0.748818| | 80 | | [PSH, ACK] Seq=1 Ack=1 Win=512 Len=680
52256 TCP
0.748975| | 80 | | [ACK] Seq=681 Ack=1 Win=512 Len=12708
52256 TCP
1.124465| 80 | | | [ACK] Seq=1 Ack=2 Win=2351 Len=0
52256 TCP
1.124605| | 80 | | [PSH, ACK] Seq=13389 Ack=1 Win=512
52256 TCP Len=26828
1.533191| 80 | | | [ACK] Seq=1 Ack=14801 Win=461 Len=0
52256 TCP
... (Acknowledgment packets continue)

1.942933| | 80 | | POST /wireshark-labs/lab3-1-reply.htm

52256 HTTP HTTP/1.1 (text/plain)
2.353059| 80 | | | [TCP Window Update] Seq=1 Ack=93873
52256 TCP Win=1432 Len=0
SLE=122113 SRE=123525

... (TCP Dup ACKs and Retransmissions)

2.817006| 52256 | 80 | TCP | [ACK] Seq=153027 Ack=778 Win=509 Len=0

... (Final packet exchanges)

7.780245| 80 | 52256 | TCP | [FIN, ACK]

Acknowledgment Status:

 Some acknowledgments are successfully received.

 Some data packets are acknowledged after retransmissions.
 There are instances where acknowledgments are not received, indicating
potential data loss or corruption.
 Sequence of Events:

 P1 initiates the connection by sending a SYN packet.

 R1 responds with a SYN-ACK packet to acknowledge P1's SYN.
 P1 acknowledges the SYN-ACK from R1 and establishes the connection.
 Data packets are exchanged between P1 and R1.
 Termination requests are initiated by both P1 and P2.
Some data packets might be retransmitted due to lack of acknowledgment
or corruption. Connection termination is initiated by R1, acknowledged by
P1, and further acknowledged by R1. Data Retransmission and Loss:

P2's data packet is retransmitted, possibly due to lack of

acknowledgment or corruption. ACKs for subsequent data packets
indicate successful transmission and reception.
R1's data packet might be the last in the sequence, acknowledged by P1.
The exchange concludes with a graceful termination initiated by R1, acknowledged by
P1, and finally acknowledged by R1.

This detailed overview provides insight into the communication dynamics, including
acknowledgment status, retransmissions, and potential data loss or corruption
issues during the TCP communication between P1 and R1.

Vii)

In a TCP connection, the establishment and termination phases involve specific flags
in the TCP header. Here's how you can identify packets used in connection
establishment and connection termination:

Connection Establishment:

Flags Used: SYN, ACK

1. Client
to Server (First Packet):
Flags: SYN

Description: The client initiates the connection by sending a TCP packet with the
SYN (Synchronize) flag set.

2. Serverto Client (Second Packet):

Flags: SYN, ACK

Description: The server responds with a TCP packet that has both the SYN and
ACK (Acknowledgment) flags set. This indicates the server's agreement to
establish the connection.

3. Client
to Server (Third Packet):
Flags: ACK

Description: The client acknowledges the server's response by sending a TCP packet
with the ACK flag set.

Connection Termination:

Flags Used :FIN, ACK

1.Initiator (either Client or Server):

Flags: FIN

Description: The initiator of the connection termination sends a TCP packet with the
FIN (Finish) flag set. This indicates the intention to close the connection.

Responder (the other end):

Flags: ACK

Description: The responder acknowledges the termination request by sending a

TCP packet with the ACK flag set.
Responder (either Client or Server):

Flags: FIN
Description: The responder also initiates the termination by sending a TCP packet
with the FIN flag set.

Initiator (the other end):

Flags: FIN, ACK

Description: The initiator acknowledges the responder's termination request by

sending a TCP packet with both FIN and ACK flags set.