Here we will examine the common network/server problem faced by users.. Before Starting, you need to Download the trace file here.. And you’ll need Wireshark for opening the trace files, download wireshark app here
While reading the following, simultaneously look at the trace file ( name of the file to be looked is mentioned within braces near each subtopic)
Slow Browsing: (Trace file: slow browsing.pcap)
The trace begins with slow DNS response. The client browser sends first DNS request at packet no.2 but there is no response from the DNS server 4.2.2.1 and so the client sends another DNS query about 1 sec later. The DNS server 4.2.2.1 responds for the second query at packet No. 4. The client on receiving the response initiates the HTTP communication with the server. The response for the first DNS query arrives 1.6 sec later. Since the hostname has already been resolved the listening port (1031) is closed. The client sends an ICMP port unreachable message (Type:3 Code:3) back to the DNS server 4.2.2.1 (Packet No.10). The delay might have caused due to slow route path selected by the first request and/or response packet.
Also note that the server responded with [SYN][ACK] packet during handshake with a delay of .5 sec (Time diff between Packet No. 5 & 6).
Also note that there is a HTTP GET Request retransmission at packet No. 11 and 12 for packet No. 8. It’s about 9 sec delay! until the packet is received by the client browser. There are many more packet retransmissions in the packet capture which makes browsing slow.
Expert info shows 31 retransmissions, which is not expected.
Slow DHCP: (Trace File: Slow DHCP.pcap)
The client is configured to receive IP address information from DHCP server and has just sent out its first DHCP Discovery packet(Packet No.1) to the all-broadcast address. But there is no response, about 6 sec later the client sends the second DHCP discovery packet(Packet No.2) to know the DHCP server’s IP. The client receives the DHCP Offer from 72.68.136.1 (Packet No.3) with a client IP offer. Note the response was from a relay agent and not from the DHCP server… as it could be seen in the packet details when examined more carefully in the Boot-Strap protocol filed. The DHCP server IP is also contained in the packet. The client on not satisfied with the information provided and sends the DHCP packet(Packet No.4) with various parameters request list. – Subnet Mask, Router IP, DNS Server IP, Domain Name, Broad Cast Address, Host Name, Log Server IP, LPR server IP, NTP server IP, Xwindow font and display manager server IP. The client also requires Lease time of 12 Hrs, as seen in the packet No.4 options field of the Boot strap protocol.
The server responds(Packet No.5) with few and not all information requested by the client and a lease time of 1hr against client request of 12 hrs lease time. The client is still not happy with what is offered and sends DHCP request packet(Packet No.6) with same options in parameters request list and a lease time of 12 hrs. The server responds with DHCP ACK with replies to most of the requests by the client but 1 hr lease time. The client has to comfort with this packet. The entire process took about 6 sec. The host system IP address was not set for 6 sec which is not good sign.
Failed FTP: (Trace File: Failed FTP.pcap)
A FTP session has failed; let’s examine the packets for error. At Packet No. 28, the client had requested for Passive mode to the server of the established FTP connection. And the server responded with code:227 allowing client to make use of passive mode. The client on getting acknowledged, initiated a new connection. The trace looks clean until packet No.33. The client sends [SYN] request to the server, but the server doesn’t respond with a [SYN][ACK]. The client resends the [SYN] request multiple times and gives up by sending an [FIN] packet to the server. Later the client resets the connection. The problem here seems to be at the server, which is trying to ignore the passive mode connection.
Unable to connect with the local server: (Trace File: Bad Network.pcap)
In this packet capture, the client 62.177.154.141 is sending DNS query to DNS server 62.177.154.141. But another device with ip 100.100.100.100 responds with ICMP message of destination unreachable and Fragmentation required. On analyzing the Packet No.1, the Don’t Fragment bit was not set! The packet size is quite small (78 Bytes) and is sending the data to the MAC address: 80:05:5d:7d:1b:a0. The ICMP message at Packet No.2 also comes from the same MAC address. The client keeps sending DNS queries. It seems some kind of spoofing attack being performed using the IP address 100.100.100.100.
Comments are welcome… Please let me know if u find more interesting stuffs in these trace files.
P.S : You’ll need Wireshark application to view the .pcap files.
