Forem: Manoj Kumar Vemula

Understanding DHCP: How I Configured and Captured It in a GNS3 Lab

Manoj Kumar Vemula — Tue, 17 Mar 2026 17:20:58 +0000

One of the best ways to truly understand a protocol is to build it yourself, watch the packets, and ask "why does each field exist?" This post walks through a DHCP lab I set up in GNS3 — configuring a Cisco router as the DHCP server, a switch in the middle, and two PCs as clients — then captures and explains every packet in the DORA handshake using Wireshark.

Lab topology
The setup is intentionally simple: one router acting as DHCP server, one switch forwarding traffic, and two VPCS clients requesting addresses.

R1
Router / DHCP server → SW1 Switch → PC1 Client·PC2 Client
Router configuration
On R1, I assigned a static IP to the interface facing the LAN, created a DHCP pool for the 192.168.1.0/24 subnet, and excluded a range so the router's own address and a few reserved IPs wouldn't be handed out.

interface GigabitEthernet1/0
ip address 192.168.1.254 255.255.255.0

ip dhcp pool LAN
network 192.168.1.0 255.255.255.0

ip dhcp excluded-address 192.168.1.2 192.168.1.10

The DORA handshake — explained packet by packet
DHCP works through four messages, collectively called DORA. I captured all four in Wireshark, and here's exactly what each one contained and why.

1 — DISCOVER
Client broadcasts for a server

Source: 0.0.0.0 → Dest: 255.255.255.255 · UDP 68→67

Message type
Boot Request (1)
Client IP : 0.0.0.0
Client MAC : 00:50:79:66:68:01
Transaction ID : 0x7db99e22
Hops :0

2 — OFFER
Server proposes an IP address

Source: 192.168.1.254 → Dest: 192.168.1.1 · UDP 67→68

Message type :Boot Reply (2)
Your (client) IP :192.168.1.1
Server identifier :192.168.1.254
Subnet mask : 255.255.255.0
Options included :Router, DNS, Lease

3 — REQUEST
Client accepts the offer

Source: 0.0.0.0 → Dest: 255.255.255.255 · UDP 68→67

Message type : Boot Request (1)
Client IP : 192.168.1.1
Requested IP :192.168.1.1
Server ID : 192.168.1.254
Still broadcast?
Yes — 255.255.255.255

4 — ACK
Server confirms the lease

Source: 192.168.1.254 → Dest: 192.168.1.1 · UDP 67→68

Message type :Boot Reply (2)
Your (client) IP :192.168.1.1
Lease time :Option 51
Renewal time :Option 58
Rebind time :Option 59

Things I noticed in the capture
Why does the Request still broadcast, even after getting an Offer?
The client broadcasts the Request (instead of unicasting directly to the server) so that any other DHCP servers on the network also see it and know their offer was not accepted. This lets them release the IP they had tentatively reserved — a small but important detail that keeps address pools clean.

Why is 0.0.0.0 the source in Discover and Request?
The client doesn't have an IP yet at this point — that's the whole reason it's sending DHCP messages. It uses 0.0.0.0 as a placeholder source, which the IP stack allows specifically for DHCP bootstrap situations.

What is the Transaction ID for?
The Transaction ID (0x7db99e22 in this capture) is a random number the client generates to match Offers and ACKs back to its own Discover and Request. This is important because in a busy network, multiple clients may be running DORA simultaneously — the Transaction ID tells each client which replies belong to them.

What about the Gratuitous ARP after the ACK?
Right after receiving the DHCP ACK, PC1 sent three Gratuitous ARP broadcasts for 192.168.1.1. This is the client announcing its new IP to the network and simultaneously checking whether any other device is already using that address. If something responds, there's a conflict. If nothing responds, the address is safely claimed.

DHCP options visible in the Offer and ACK
Both the Offer and ACK carried the following options beyond just the IP address — this is what makes DHCP a full network configuration protocol, not just an IP assignment tool.

Options in DHCP :
From the Discover (Images 2 & 3):

Option 53 — DHCP Message Type (Discover)
Option 12 — Host Name
Option 61 — Client Identifier
Option 255 — End

From the Offer (Image 4):

Option 53 — DHCP Message Type (Offer)
Option 54 — DHCP Server Identifier (192.168.1.254)
Option 51 — IP Address Lease Time
Option 58 — Renewal Time Value
Option 59 — Rebinding Time Value
Option 1 — Subnet Mask (255.255.255.0)
Option 3 — Router
Option 6 — Domain Name Server
Option 255 — End

From the Request (Image 5):

Option 53 — DHCP Message Type (Request)
Option 54 — DHCP Server Identifier (192.168.1.254)
Option 50 — Requested IP Address (192.168.1.1)
Option 61 — Client Identifier
Option 12 — Host Name
Option 55 — Parameter Request List
Option 255 — End

From the ACK (Image 6):

Option 53 — DHCP Message Type (ACK)
Option 54 — DHCP Server Identifier (192.168.1.254)
Option 51 — IP Address Lease Time
Option 58 — Renewal Time Value
Option 59 — Rebinding Time Value
Option 1 — Subnet Mask (255.255.255.0)
Option 3 — Router
Option 6 — Domain Name Server
Option 255 — End
Result on the client
After the handshake completed, running ip dhcp on the VPCS client confirmed it received 192.168.1.11/24 with a gateway of 192.168.1.254 — as expected, since .1 through .10 were excluded from the pool.

What I took away from this lab
Reading about DHCP in a textbook and actually watching the four packets flow through Wireshark are very different experiences. Seeing the Transaction ID stay consistent across all four messages, watching the source IP go from 0.0.0.0 to the assigned address, and noticing the post-ACK Gratuitous ARPs made the protocol feel concrete rather than abstract. The next step is to add a second subnet and configure a DHCP relay (ip helper-address) to see how DORA behaves when the server and client are on different networks.

DHCP Explained

Manoj Kumar Vemula — Thu, 26 Feb 2026 10:28:04 +0000

The main purpose of this post is to find
How devices automatically get their IP address — from discovery to release.
Let's start from here:
1. What Is DHCP?
Every device that connects to a network — whether it's your laptop, phone, printer, or smart TV — needs an IP address to communicate. Without one, it is invisible to the rest of the network. The question is: how does every device get that address without someone manually typing it in?

The answer is DHCP — Dynamic Host Configuration Protocol. DHCP is a network management protocol that automatically assigns IP addresses and other network configuration settings to client devices the moment they connect to a network. It is what makes "plug in and it just works" possible.

Before DHCP existed, network administrators had to manually configure every single device with an IP address, subnet mask, gateway, and DNS server. On a network with hundreds of devices, this was an enormous and error-prone task. DHCP eliminated that entirely.

What DHCP Configures
DHCP does more than just hand out IP addresses. A full DHCP lease delivers a complete network configuration package to the client:

-->DHCP uses a client-server model. The DHCP server owns a pool of available IP addresses (called a scope) and leases them out to clients on a temporary basis. The IP is not permanently owned — it is borrowed for a defined lease time.

Where DHCP Is Used
•Home routers — your home router runs a DHCP server that hands out IPs to every device on your Wi-Fi
•Enterprise networks — dedicated DHCP servers manage hundreds or thousands of devices per site
•ISP networks — DHCP assigns IPs to customer routers when they connect to the ISP
•Data centers and cloud — DHCP or its cloud equivalents provision virtual machine networking automatically
•Wi-Fi hotspots — coffee shops, airports, and hotels use DHCP to assign temporary IPs to guests

2. The DORA Process — How IP Addresses Are Allocated
When a client device boots up and needs an IP address, it goes through a four-message exchange with the DHCP server. Networking engineers call this the DORA process — an acronym for the four messages involved: Discover, Offer, Request, and Acknowledge.

Understanding why each message is a broadcast or a unicast — and why — is essential to deeply understanding DHCP.

Step 1 — DHCP Discover
When a client device first boots up or connects to a network, it has no IP address, no knowledge of the default gateway, and no idea where a DHCP server is. It is essentially blind to the network. The only thing it can do is shout — and that is exactly what it does.

The client broadcasts a DHCP Discover message to every device on the local subnet, hoping a DHCP server will hear it and respond.

Source MAC: Client's own hardware MAC address
Destination MAC: FF:FF:FF:FF:FF:FF (Ethernet broadcast — everyone receives it)
Source IP: 0.0.0.0 (client has no IP yet)
Destination IP: 255.255.255.255 (IP broadcast)

The use of 0.0.0.0 as the source IP is significant — it is the standard notation for "I have no IP address." The message essentially says: "I just joined this network. My hardware address is [MAC]. Is there a DHCP server out there?"

So Why Broadcast? The client does not know the IP address of the DHCP server — it may not even know if a DHCP server exists. A broadcast is the only way to reach every device on the subnet simultaneously. All devices receive the frame, but only DHCP servers process and respond to it.

Step 2 — DHCP Offer
Any DHCP server on the subnet that receives the Discover message responds with a DHCP Offer. This message is the server saying: "I heard you. I am available. Here is an IP address I am reserving for you, along with all the configuration you need."

The Offer contains a full proposed network configuration:
•The IP address being offered to the client
•Subnet mask
•Default gateway IP address
•DNS server IP address
•Lease duration (how long the client may keep this IP)
•The DHCP server's own IP address (so the client knows who made the offer)

Source MAC: DHCP Server MAC
Destination MAC: FF:FF:FF:FF:FF:FF (broadcast — client still has no IP)
Source IP: 192.168.1.254 (DHCP server's IP)
Destination IP: 255.255.255.255 (broadcast — client can't receive unicast yet)

At this point the server internally reserves the offered IP address, temporarily removing it from its available pool. This prevents the same IP from being offered to another client while this negotiation is in progress.

--> What If There Are Multiple DHCP Servers?
In some networks, more than one DHCP server may exist for redundancy. All of them receive the Discover broadcast and may each send a separate Offer. The client receives multiple Offers and simply picks one — usually the first to arrive. The selection is handled in the next step.

Step 3 — DHCP Request
After receiving one or more Offer messages, the client selects a DHCP server and formally requests the offered configuration. It broadcasts a DHCP Request message to the entire subnet.

This message serves two purposes simultaneously:

It tells the chosen DHCP server: "I accept your offer. Please confirm this configuration for me."
It tells all other DHCP servers (the ones whose offers were not selected): "I chose a different server. You can release the IP address you had reserved for me."

Source MAC: Client's MAC address
Destination MAC: FF:FF:FF:FF:FF:FF (broadcast — informing ALL servers)
Source IP: 0.0.0.0 (still no IP until Ack is received)
Destination IP: 255.255.255.255 (broadcast)

Key field: DHCP Server Identifier (Option 54) = IP of chosen server

The DHCP Server Identifier field (Option 54) is what tells every server which one was selected. The chosen server reads this field, sees its own IP, and knows it should proceed. Every other server reads the field, sees a different IP, and releases its reserved address back to its pool.

Why Is the Request Still a Broadcast?
Even though the client now knows the chosen server's IP, it must still broadcast — because non-selected servers also need to receive this message so they can free up their reserved IPs. A unicast to only the chosen server would leave the other servers holding reserved addresses indefinitely.

Step 4 — DHCP Acknowledge (ACK)
The selected DHCP server receives the Request message, confirms that the DHCP Server Identifier matches its own IP, and responds with a DHCP Acknowledge (ACK) message. This is the server's final confirmation: "The IP is yours. Your lease starts now."

The ACK contains the same configuration data as the Offer — IP address, subnet mask, gateway, DNS, and lease time — but now it is official. Upon receiving the ACK, the client configures its network interface using this data and becomes a fully functional member of the network.

Source MAC: DHCP Server MAC
Destination MAC: FF:FF:FF:FF:FF:FF (broadcast — client still has no confirmed IP)
Source IP: 192.168.1.254 (DHCP server)
Destination IP: 255.255.255.255 (broadcast)

After the client processes the ACK, it performs one final check — an ARP (Address Resolution Protocol) probe — to make sure no other device on the network is already using the assigned IP. If a conflict is detected, the client sends a DHCP Decline message and the process starts over.

What Is a DHCP NAK?
If the DHCP server receives a Request but something is wrong — the requested IP is no longer available, or the client's lease has already expired — it sends a DHCP NAK (Negative Acknowledge) instead of an ACK. The client must then restart the DORA process from the beginning.

3. IP Address Renewal — Keeping Your Lease
Why Leases Expire
DHCP does not permanently assign IP addresses — it leases them. This is by design. Temporary leases allow the DHCP server to reclaim IP addresses from devices that have left the network without formally releasing them, keeping the address pool healthy and preventing exhaustion.

Imagine a hotel with 100 rooms. If guests could check in forever and never check out, the hotel would eventually have no rooms to offer new guests. DHCP lease times work the same way — they ensure addresses cycle back into the pool.

The Renewal Timeline
The DHCP lease renewal process follows a predictable timer schedule that every network engineer should know:

For example, with a 24-hour (86,400 second) lease: T1 fires at 12 hours, T2 at ~21 hours. If the client successfully renews at T1, the full lease duration resets and the cycle starts again.

The Renewal Exchange
When T1 fires, the client sends a DHCP Request directly to its DHCP server to renew the lease. This is one of the key differences from the initial allocation — renewal uses unicast, not broadcast.

Client ──── DHCP Request (Unicast) ──────────→ Server
Destination IP: 192.168.1.254 (server's IP — now known)
Client IP: 192.168.1.105 (the IP being renewed)

Client ←─── DHCP Ack (Unicast) ───────────── Server
Destination IP: 192.168.1.105 (client's IP — now known)

Because both the client and server already know each other's IP addresses from the original lease, there is no need for broadcasts. The renewal is a clean, direct two-message exchange: Request and Ack. The client includes its current IP in the "Client IP Address (ciaddr)" field, and notably does NOT include Option 50 (Requested IP) or Option 54 (Server Identifier) — these are only used in initial allocation.

Broadcast vs. Unicast Comparison: Initial allocation uses broadcast because the client has no IP and does not know the server's address. Renewal uses unicast because both sides now know each other. This is an important distinction for exam questions and troubleshooting.

What Happens If Renewal Fails?
If T1 fires and the DHCP server does not respond (perhaps it is down for maintenance), the client does not immediately panic. It keeps using the current IP and waits until T2.

At T2 (87.5% of lease), the client escalates — it broadcasts a DHCP Request to any DHCP server on the network, hoping a backup or secondary server can renew the lease. If that also fails and the lease fully expires, the client stops using the IP entirely and falls back to the full DORA process.

During this fallback window, Windows devices will often assign themselves an APIPA address (169.254.x.x) — a self-assigned link-local address that allows basic local communication but provides no internet access. Seeing a 169.254.x.x address is a reliable indicator that DHCP has failed.

4. IP Address Release — Returning the Lease
What Is a DHCP Release?
When a device gracefully disconnects from the network — whether you shut down your computer cleanly, disconnect from Wi-Fi, or run the ipconfig /release command on Windows — it should inform the DHCP server that it no longer needs its IP address. It does this by sending a DHCP Release message.

The Release is a unicast message sent directly to the DHCP server:

Client ──── DHCP Release (Unicast) ─────────→ Server
Destination MAC: DHCP Server MAC
Destination IP: 192.168.1.254 (DHCP server)
Client IP field: 192.168.1.105 (the IP being returned)

Upon receiving the Release, the DHCP server marks that IP address as available again in its pool, ready to be offered to the next client that needs it. The releasing client immediately loses network access — it no longer has a valid IP, gateway, or DNS server.

Graceful vs. Abrupt Disconnection
DHCP Release only happens during a graceful shutdown. If a device loses power suddenly, crashes, or is simply removed from the network without warning, it cannot send a Release message. In this case:

•The DHCP server keeps the IP listed as leased until the lease timer expires
•No other device can be assigned that IP during this time
•Once the lease expires, the server reclaims the IP and returns it to the pool

This is why DHCP lease times matter. A very long lease time (say, 7 days) means an IP can be "stuck" for a week after a device disappears. A shorter lease time means faster reclamation, but more frequent renewal traffic on the network.

-->ipconfig /release and /renew On Windows, you can manually trigger these processes. 'ipconfig /release' sends a DHCP Release and removes the IP configuration. 'ipconfig /renew' then starts a new DORA process to get a fresh IP. This is a common first step when troubleshooting "no internet" issues on Windows.

5. Broadcast vs. Unicast — The Full Picture
One of the most important concepts in DHCP is understanding why each message is either a broadcast or unicast. Here is the complete summary:

6. DHCP Relay — What About Multiple Subnets?
There is an important limitation to standard DHCP: the Discover and Offer messages are broadcasts, and routers do not forward broadcasts between subnets by default. This means a single DHCP server on one subnet cannot normally serve clients on other subnets.

In a real enterprise network with dozens of subnets, you cannot deploy a DHCP server on every single subnet — that would be an administrative nightmare. The solution is a DHCP Relay Agent.

How DHCP Relay Works
A DHCP Relay Agent (also called an IP Helper) is software running on a router or Layer 3 switch that intercepts local DHCP broadcasts and forwards them as unicast messages to a centralized DHCP server on a different subnet. The server replies to the relay agent, which then forwards the response back to the client.

Client (VLAN 10)
|
| broadcasts DHCP Discover
↓
Router (Relay Agent) DHCP Server (VLAN 1)
| ──── unicast DHCP Discover ──────→ |
| ←─── unicast DHCP Offer ──────────-|
|
| broadcasts DHCP Offer back to client
↓
Client receives Offer and continues DORA normally

On Cisco routers, the DHCP relay is configured with the 'ip helper-address' command on the client-facing interface, pointing to the DHCP server's IP. This is one of the most commonly configured features in enterprise networking.

-->Real-World Implication: When troubleshooting DHCP failures in enterprise environments, always check the relay agent configuration first. A misconfigured or missing 'ip helper-address' is one of the most common reasons clients on a subnet cannot get an IP address despite a healthy DHCP server.

7. DHCP Security Risks
Because DHCP operates on trust — clients accept configuration from whoever responds first — it is vulnerable to several attack types that every network engineer should understand.

DHCP Snooping is a Layer 2 security feature available on managed switches. It designates specific ports as "trusted" (connected to the real DHCP server) and "untrusted" (connected to clients). DHCP Offer and Ack messages from untrusted ports are dropped, preventing rogue servers from poisoning client configurations.

8. Complete DHCP Flow — From Boot to Internet
Putting it all together, here is the full sequence from a device powering on to it having internet access:

3.Device boots up — no IP address, no network configuration
4.Client broadcasts DHCP Discover — looking for any DHCP server on the subnet
5.DHCP server receives Discover — reserves an IP from its pool, sends a Broadcast Offer
6.Client receives Offer — selects the server, broadcasts a DHCP Request
7.All DHCP servers receive the Request — unchosen servers release their reserved IPs; chosen server sends ACK
8.Client receives Ack — performs ARP conflict check, then configures the network interface
9.Client is now online — uses the IP address, subnet mask, gateway, and DNS from the lease
10.At 50% of lease time — client unicasts a Renewal Request to extend the lease
11.Server responds with Renewal Ack — lease timer resets, process repeats at T1 again
12.When done — client sends DHCP Release (unicast) and loses network access

Key Takeaways
•DHCP automates network configuration — IP address, subnet mask, gateway, DNS, and lease time are all delivered automatically
•The four-step DORA process (Discover → Offer → Request → Ack) is the foundation of every IP allocation
•Initial allocation uses broadcast throughout because the client has no IP and doesn't yet know the server's address
•Renewal uses unicast because both sides already know each other's addresses from the original lease
•Lease times are intentional — they let the server reclaim IPs from devices that leave without releasing them
•T1 (50%) triggers renewal; T2 (87.5%) is the fallback if T1 fails; expiry resets the whole process
•DHCP Release is optional but courteous — abrupt disconnections leave addresses tied up until the lease expires
•DHCP Relay Agents (ip helper-address) allow a single DHCP server to serve clients across multiple subnets
•DHCP Snooping on managed switches prevents rogue DHCP servers from hijacking client configurations
•A 169.254.x.x address on a client almost always means DHCP failed — the client fell back to APIPA self-assignment
==>Remember the DORA acronym: Discover → Offer → Request → Acknowledge. Every DHCP allocation follows this exact sequence, every time, on every network in the world.

How DNS, TCP, TLS & HTTP Actually Work

Manoj Kumar Vemula — Wed, 25 Feb 2026 07:47:33 +0000

Hey guys, this post is a massive one for any beginner or for intermediate one's in security field as i am sure of it. I explained all the concepts in detail and recommended to complete this post and have a good understanding about How things work behind your device, as of this post we discuss only about DNS ,TCP,TLS,HTTP.

Every time you type a URL into your browser and hit Enter, a surprisingly complex sequence of events unfolds in milliseconds. Most people think "the page just loads" — but underneath there are at least four distinct protocols working together in a precise order.

The full journey looks like this:
1.DNS Resolution — translate the human-readable domain name into an IP address
2.TCP Handshake — open a reliable connection to that IP address
3.TLS Handshake — secure the connection with encryption
4.HTTP Request/Response — fetch and receive the actual web content
5.TCP Termination — cleanly close the connection

This guide walks through each stage in depth. By the end you will understand not just what happens, but why each step exists and what goes wrong when it fails.

1. DNS — Domain Name System
What Is DNS and Why Does It Exist?
Computers communicate using IP addresses (like 93.184.216.34), but humans are far better at remembering names (like example.com). DNS is the system that bridges this gap — it is essentially the internet's phone book, translating human-readable domain names into machine-readable IP addresses.

Without DNS, you would need to memorize a numerical IP address for every website you visit. DNS automates that lookup invisibly, every single time you load a page.

The DNS Resolver
The DNS Resolver (also called the Recursive Resolver) is the DNS client that works on your behalf. When you type a URL, your operating system contacts a resolver — usually provided by your ISP or a public service like Google (8.8.8.8) or Cloudflare (1.1.1.1).

Think of the resolver as a detective. It receives your question ("what is the IP for example.com?"), goes out and finds the answer by talking to other DNS servers, and then delivers the final IP address back to your browser. The resolver does all the legwork so your PC doesn't have to.

--> The resolver is the only server your PC directly talks to during DNS resolution. Everything else — Root servers, TLD servers, Authoritative servers — is handled by the resolver behind the scenes.

The DNS Hierarchy
DNS is organized as a strict hierarchy, like a tree. Every domain name is read from right to left, matching this hierarchy exactly.

            Root  (invisible — the "." at the end of every domain)
             |
    ─────────────────────
    |         |         |
   .com      .org      .in        ← Top-Level Domains (TLD)
    |
example.com                        ← Second-Level Domain
    |

www.example.com ← Hostname / Subdomain

The Four Types of DNS Servers
Each level of the hierarchy has a corresponding type of server with a specific, limited job:

A crucial detail: Root servers and TLD servers never know IP addresses. They only know "who to ask next." This delegation model is what makes DNS scalable to billions of domains.

The DNS Resolution Process — Step by Step
Let's trace exactly what happens when your browser needs the IP for www.example.com. Assume the resolver has no cached answer.

6.Your PC sends the query ("what is www.example.com?") to the Resolver
7.Resolver asks a Root Server: "Where can I find .com?"
8.Root Server replies: "I don't know the IP — ask the .com TLD server at this address"
9.Resolver asks the .com TLD Server: "Where can I find example.com?"
10.TLD Server replies: "I don't know the IP — ask example.com's authoritative server"
11.Resolver asks the Authoritative Server: "What is the IP for www.example.com?"
12.Authoritative Server replies: "93.184.216.34" — this is the actual answer
13.Resolver returns 93.184.216.34 to your PC and caches it for future requests

PC → Resolver → Root → TLD (.com) → Authoritative (example.com) → IP

But why 13 Root Servers? There are 13 logical root server addresses in the world, labeled A through M. But "logical" is key — each is actually a cluster of hundreds of physical servers distributed globally via anycast routing, giving the system enormous redundancy.

DNS Caching — The Speed Optimization
After a resolver retrieves an answer, it stores (caches) it for a period of time defined by the domain owner — this is called the TTL (Time to Live). On the next request for the same domain, the resolver returns the cached answer instantly without walking up the hierarchy again.

Your browser and operating system also maintain their own DNS caches. This is why DNS changes (like pointing a domain to a new server) can take time to propagate — old cached records need to expire first.

2. TCP — Transmission Control Protocol
What Is TCP and Why Is It Used?
Once the resolver returns an IP address, the browser needs to establish a connection to that server before sending any data. TCP (Transmission Control Protocol) is the protocol that creates this connection.

TCP is a connection-oriented protocol, meaning both sides must formally agree to open a session before any data flows. It guarantees reliable, ordered delivery — if a packet is lost, TCP automatically retransmits it. This reliability is why HTTP (and HTTPS) runs over TCP rather than UDP.

The 3-Way Handshake — Opening the Connection
Before a single byte of HTTP data is sent, TCP performs a 3-way handshake to synchronize both sides and establish a reliable session. The process uses special control flags in the TCP header: SYN (Synchronize) and ACK (Acknowledge).

Client ──── SYN ────────────────────→ Server
Client ←─── SYN + ACK ────────────── Server
Client ──── ACK ────────────────────→ Server
↓
Connection established — ready for data

Step 1 — SYN (Client → Server)
The client sends a TCP segment with the SYN flag set and an Initial Sequence Number (ISN) — a random starting number for tracking data order. The ISN is critical for reassembling packets in the right order and for detecting retransmissions.

Step 2 — SYN-ACK (Server → Client)
The server acknowledges the client's ISN by sending back SYN + ACK. The ACK confirms the client's sequence number (client ISN + 1). The server also sends its own ISN so the client can track the server's data stream.

Step 3 — ACK (Client → Server)
The client acknowledges the server's ISN (server ISN + 1). Both sides have now exchanged sequence numbers and confirmed each other is reachable. A full-duplex, reliable TCP session is open. Data can flow in both directions simultaneously.

So, Why do we need Sequence Numbers?
->Sequence numbers let TCP detect lost packets, reorder out-of-sequence segments, and prevent old duplicate packets from being accepted. Without them, TCP would have no way to guarantee ordered, reliable delivery.

The 4-Way Termination — Closing the Connection
Because TCP is full-duplex (data flows independently in both directions), each direction must be closed separately. This requires 4 steps instead of 3.

Client ──── FIN ────────────────────→ Server (client done sending)
Client ←─── ACK ──────────────────── Server (server acknowledges)
Client ←─── FIN ──────────────────── Server (server done sending)
Client ──── ACK ────────────────────→ Server (client acknowledges)
↓
Connection closed

Modern HTTP uses a Connection: keep-alive header to avoid this teardown overhead. With keep-alive, the same TCP connection is reused for multiple HTTP requests to the same server — significantly speeding up page loads that require many resources.

3. TLS — Transport Layer Security
What Is TLS and Where Does It Fit?
After the TCP connection is open, the browser initiates a TLS (Transport Layer Security) handshake before sending any HTTP data. TLS is the cryptographic protocol that turns HTTP into HTTPS — securing communication so that no one eavesdropping on the network can read or tamper with the data.

Protocol Layer Purpose
HTTP Application Web content — requests and responses
TLS Presentation / Security Encryption, integrity, and authentication
TCP Transport Reliable, ordered delivery
IP Network Routing packets across networks

The formula is: HTTPS = HTTP + TLS + TCP + IP. TLS sits between the application and transport layers, wrapping all HTTP data in an encrypted envelope before TCP transmits it.

What the TLS Handshake Achieves
Before any encrypted data can flow, the client and server must agree on three things:
•Confidentiality — which encryption algorithm to use so data cannot be read by outsiders
•Integrity — which hashing algorithm to use so tampering can be detected
•Authentication — verifying the server is genuinely who it claims to be (via certificates)

Cipher Suites — Agreeing on the Algorithms
A cipher suite is a named combination of cryptographic algorithms that defines how the TLS session will be secured. For example:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The client sends a list of all cipher suites it supports. The server picks the strongest one it also supports. If there is no overlap, the TLS handshake fails and the connection is rejected.

TLS 1.2 Handshake — Step by Step

Client ──── ClientHello ────────────────────────→ Server
Client ←─── ServerHello + Certificate ────────── Server
[Client verifies certificate]
Client ──── Key Exchange ───────────────────────→ Server
[Both derive session keys]
Client ──── ChangeCipherSpec + Finished ────────→ Server
Client ←─── ChangeCipherSpec + Finished ──────── Server
↓
Encrypted HTTPS channel established

Step 1 — ClientHello
The client opens TLS negotiation by sending a ClientHello message. This contains the supported TLS versions, the list of cipher suites the client supports, a client random number (used later in key derivation), and extensions like SNI (Server Name Indication — tells the server which domain is being requested, allowing one server to host multiple TLS certificates).

Step 2 — ServerHello + Certificate
The server responds by selecting the TLS version and cipher suite, then sends its own server random number. It also sends its digital certificate, which contains the server's public key, the domain name it is valid for, the Certificate Authority (CA) that issued it, the validity period, and a digital signature.

*Step 3 — Certificate Verification *(The Critical Security Step)
Before proceeding, the client must verify that the server's certificate is legitimate. This is the step that prevents man-in-the-middle attacks. The client checks:
•CA signature — was the certificate signed by a trusted Certificate Authority?
•Domain match — does the certificate's domain name match the URL being visited?
•Expiry — is the certificate still within its valid date range?
•Chain of trust — does the certificate trace back through intermediate CAs to a Root CA the browser already trusts?

Root CA (pre-installed in your OS/browser)
↓ signs →
Intermediate CA
↓ signs →
Server Certificate (presented during TLS handshake)

If any check fails — expired certificate, wrong domain, unknown CA — your browser shows a security warning and blocks the connection. This is not an inconvenience; it is the system working as intended.

Why a Chain? Root CAs are extremely sensitive. If a Root CA private key is compromised, every certificate it ever signed becomes untrusted. Intermediate CAs add a buffer — only the intermediate's key is used day-to-day, limiting exposure if it's ever compromised.

Step 4 — Key Exchange
With the server authenticated, the client and server now need to establish a shared secret that neither side transmitted in plaintext. This is where RSA or ECDHE key exchange comes in.

In RSA key exchange, the client generates a pre-master secret, encrypts it with the server's public key (from the certificate), and sends it over. Only the server can decrypt this using its private key. Both sides then independently compute the same session keys using:

Session Keys = PRF(pre-master secret, client random, server random)

This produces several keys: one for encrypting client-to-server data, one for server-to-client data, and MAC keys for integrity checking. The random values from each side ensure that even if the same pre-master secret were reused, the session keys would be different every time.

Why Not Encrypt Everything with the Public Key? Public key (asymmetric) cryptography is mathematically expensive — it can be hundreds of times slower than symmetric encryption. TLS uses asymmetric crypto only for the key exchange, then switches to fast symmetric ciphers (like AES) for all actual data. This hybrid approach gives you the security of asymmetric with the speed of symmetric.

Step 5 — ChangeCipherSpec + Finished
Both client and server send a ChangeCipherSpec message signaling "I'm switching to encrypted mode now." They then each send a Finished message — the first message encrypted with the newly derived session keys — which contains a hash of the entire handshake transcript. If both sides can successfully decrypt and verify each other's Finished message, the handshake is complete and the session keys are confirmed correct.

TLS 1.3 — A Faster Modern Alternative
TLS 1.3 (the current standard) reduces the handshake to fewer round trips — it can often complete in 1-RTT (one round trip) instead of 2-RTT for TLS 1.2. It also removed weaker cipher suites entirely, making the negotiation simpler and more secure. If you see TLS 1.3 in browser dev tools, this is what is running.

4. HTTP — HyperText Transfer Protocol
What Happens After TLS?
With a TCP connection open and TLS encryption active, the browser can finally request the actual web content. HTTP (HyperText Transfer Protocol) is the application-layer protocol that defines how browsers and servers ask for and deliver web resources.

Everything from this point forward — the request, the response, all the HTML/CSS/JS — travels inside TLS-encrypted envelopes. An attacker monitoring the network can see that you are talking to a server, but cannot read the content of any request or response.

HTTP Request — What the Browser Sends
Every HTTP request has three parts: a request line, headers, and an optional body.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 Chrome/120
Accept: text/html,application/xhtml+xml
Cookie: sessionID=abc123
Connection: keep-alive

**The Request Line
**The first line contains three pieces: the HTTP method (what the browser wants to do), the resource path (which file or endpoint is being requested), and the HTTP version.

Method Purpose Has Body? Common Use
GET Retrieve a resource No Loading pages, images, files
POST Send data to the server Yes Form submission, logins, API calls
PUT Replace a resource Yes Updating a record via API
DELETE Remove a resource No Deleting via API
HEAD Get headers only (no body) No Check if resource exists/changed

Request Headers
Headers carry metadata about the request. They tell the server who is asking, what formats are acceptable, what language is preferred, and what cookies are stored. Key headers to know:

HTTP Response — What the Server Sends Back
The server processes the request and sends back a response, also in three parts: a status line, response headers, and the body (the actual content).

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 4521
Cache-Control: max-age=3600
Set-Cookie: sessionID=xyz; HttpOnly; Secure
Server: nginx/1.24

Example
...

Status Codes
The three-digit status code tells the browser exactly what happened with the request. They are grouped by the first digit:

One Page = Many HTTP Requests
A common misconception is that loading a webpage is a single request. In reality, the initial HTML response contains references to dozens of other resources — each requiring its own HTTP request.

A typical page load sequence looks like:

GET /index.html — the main HTML document
GET /styles/main.css — stylesheet referenced in the HTML
GET /scripts/app.js — JavaScript file
GET /images/logo.png — logo image
GET /images/banner.jpg — hero image
GET /fonts/roboto.woff2 — web font
GET /api/user — API call for dynamic data (if logged in)

Modern browsers handle these in parallel using multiple TCP connections or HTTP/2 multiplexing (which allows many requests over a single TCP connection). This parallelism is why HTTP/2 provides a meaningful performance boost over HTTP/1.1 for content-heavy pages.

Browser Rendering — What Happens With the Response
Once the browser starts receiving the HTML, it begins parsing and rendering before the entire response even arrives. The process:

21.Parse HTML → Build DOM (Document Object Model) — a tree of every element on the page
22.Parse CSS → Build CSSOM (CSS Object Model) — style rules for every element
23.Execute JavaScript — which may modify the DOM or trigger additional network requests
24.Combine DOM + CSSOM → Render Tree — only the visible elements with their computed styles
25.Layout — calculate the exact position and size of every element on screen

Paint — draw pixels to the display

Performance Note: JavaScript blocks HTML parsing by default. This is why performance-conscious developers place script tags at the bottom of the HTML body, or use async and defer attributes — so JS doesn't delay page rendering.

5. The Complete End-to-End Flow
Here is the full sequence from URL to rendered page, with every protocol in order:

User types URL in browser
Browser checks its own DNS cache
If no cache → Resolver query → Root → TLD → Authoritative → IP
TCP 3-way handshake (SYN → SYN-ACK → ACK)
TLS handshake (ClientHello → ServerHello → Cert verify → Keys → Finished)
HTTP GET request (encrypted inside TLS)
Server processes request
HTTP response with HTML (encrypted inside TLS)
Browser parses HTML, requests additional resources (CSS, JS, images)
Browser renders the page
TCP connection kept alive for further requests (or closed with FIN)

6. Security Risks at Each Stage

Key Takeaways
•DNS translates domain names to IPs through a hierarchy: Resolver → Root → TLD → Authoritative
•The Resolver is your PC's single point of contact — it walks the hierarchy on your behalf
•DNS caching (TTL) prevents this full lookup on every request — most lookups are instant cache hits
•TCP's 3-way handshake (SYN/SYN-ACK/ACK) establishes a reliable, ordered connection before any data flows
•TLS provides confidentiality, integrity, and authentication — it is the reason HTTPS is trustworthy
•Certificate verification is the critical security step — it prevents you from being fooled by fake servers
•TLS uses hybrid cryptography: asymmetric (RSA/ECDHE) for key exchange, symmetric (AES) for data — the best of both worlds
•HTTP is a request/response protocol — one page load triggers many individual requests for resources
•Modern browsers pipeline and parallelize requests; HTTP/2 multiplexes them over one TCP connection
•Every stage has a corresponding attack surface — understanding the protocol is the first step to understanding the security

-->The full order is always DNS → TCP → TLS → HTTP. You cannot skip steps. Each layer depends on the one before it being established correctly.

SUBNETTING EXPLAINED

Manoj Kumar Vemula — Tue, 24 Feb 2026 17:22:10 +0000

Here in this blog i made complete guide to IP subnetting — from theory to practical problem solving. Let's Start
1. What is Subnetting?
Subnetting is the process of dividing one large IP network into multiple smaller, logical subnetworks (subnets). This is done by borrowing bits from the host portion of an IP address and assigning them to the network portion — effectively shrinking each network's host space to create more networks.

Think of it like splitting a large apartment building into separate floors. Each floor (subnet) has its own numbered units (hosts), and the building's address (network ID) identifies which floor you're on.

Why Do We Subnet?
•Efficient IP address usage — avoid wasting large blocks of addresses on small networks
•Reduce broadcast traffic — broadcasts stay confined within each subnet
•Improve performance — less unnecessary traffic on each segment
•Better security segmentation — isolate departments or systems
•Easier network management — logical groupings make troubleshooting simpler

2. IPv4 Address Structure
An IPv4 address is 32 bits long, written in dotted-decimal notation — four groups of 8 bits (called octets), each ranging from 0 to 255.

Example: 192.168.1.10
Binary: 11000000.10101000.00000001.00001010

Every IPv4 address is split into two logical parts:
•Network bits — identify which network the device belongs to
•Host bits — identify the specific device within that network

The subnet mask determines where the boundary between network bits and host bits falls. A /24 mask means the first 24 bits are the network portion and the last 8 bits are for hosts.

IP: 192.168.1.10
Mask: 255.255.255.0 (/24)
|--Network----|Host|

3. The Subnet Mask
The subnet mask is a 32-bit number that tells both routers and hosts which part of an IP address is the network ID and which part is the host ID. In binary, it is always a sequence of 1s followed by 0s — no mixing.

255.255.255.0 = /24
11111111.11111111.11111111.00000000
1s = network bits 0s = host bits

Devices use the subnet mask to decide whether a destination IP is on the same local network (send directly) or a different network (send to the gateway router).

4. How Devices Use the AND Operation
When a device wants to communicate with another IP address, it needs to determine if that address is on the same subnet. It does this using a bitwise AND operation — comparing each bit of the IP address against the corresponding bit of the subnet mask.

The rule is simple: 1 AND 1 = 1, anything AND 0 = 0. The result is the Network ID.

Source IP: 192.168.1.10
Subnet Mask: 255.255.255.0

IP: 11000000.10101000.00000001.00001010
Mask: 11111111.11111111.11111111.00000000
AND: 11000000.10101000.00000001.00000000

Result: 192.168.1.0 (this is the Network ID)

The device performs this AND operation on BOTH the source and destination IPs. If both results match, they are on the same subnet — communicate directly. If they differ, the packet goes to the default gateway.

This AND logic is performed in hardware at wire speed — it happens on every single packet a device sends or receives.

5. Network ID and Broadcast Address
Network ID (First Address)
The Network ID is the address where all host bits are set to 0. It identifies the subnet itself — you cannot assign this address to any device.
192.168.1.0/24 → Host bits = 00000000 → Network ID

Broadcast Address (Last Address)
The broadcast address is where all host bits are set to 1. Any packet sent to this address is delivered to every device on the subnet. You cannot assign this address to any device either.
192.168.1.255/24 → Host bits = 11111111 → Broadcast

6. Usable Host Addresses
Since the first address (Network ID) and the last address (Broadcast) in any subnet are reserved and cannot be assigned to hosts, the formula for usable hosts is:

Usable Hosts = 2^H − 2

Where H = the number of host bits remaining after subnetting.

Example for /24:
Host bits (H) = 32 - 24 = 8
Usable hosts = 2^8 - 2 = 256 - 2 = 254
Range: 192.168.1.1 to 192.168.1.254

7. Subnetting Formulas
Two core formulas drive every subnetting decision:

For number of subnets needed:
2^N ≥ required subnets (N = bits to borrow)

For hosts per subnet:
2^H − 2 ≥ required hosts (H = remaining host bits)

You borrow N bits from the host portion of the original mask, which increases the prefix length by N. The remaining H bits define how many hosts each subnet can hold.

8. Borrowing Bits — What It Actually Means
When you "borrow" bits, you are shifting the boundary between network and host portions further into the host space. This creates more network addresses (subnets) but reduces the host space in each one.

Original network: 192.168.1.0/24
Original mask: 11111111.11111111.11111111.00000000

Borrow 2 bits: 11111111.11111111.11111111.11000000
New mask: 255.255.255.192 (/26)

Borrowing 2 bits gives us 2² = 4 subnets, each with 2^6 − 2 = 62 usable hosts. More subnets, fewer hosts per subnet — that's the fundamental trade-off.

9. Block Size — The Most Useful Trick
The block size tells you how many IP addresses each subnet contains (including Network ID and Broadcast). It's the increment between subnet starting addresses, and it makes finding subnet ranges fast without binary math.

Block Size = 256 − (interesting octet value)

The "interesting octet" is the octet where the subnet mask is neither 255 (fully network) nor 0 (fully host) — it is the octet being split.

Example: /26 → Mask = 255.255.255.192
Interesting octet value = 192
Block size = 256 - 192 = 64

Subnets start at: 0, 64, 128, 192

-->Memorize block sizes: /25→128, /26→64, /27→32, /28→16, /29→8, /30→4. These come up in every subnetting problem.

10. Solving Subnet Problems — Step by Step
This is where most people get stuck. The key is following a repeatable process every single time. Here is the universal method with full explanation of each step.

The 6-Step Method

1.Identify the prefix length (/x) from the problem
2.Determine the interesting octet (where the split happens)
3.Calculate the block size: 256 − mask value in that octet
4.List the subnet ranges by adding block size repeatedly
5.Find which range your IP falls into
6.Read off Network ID (first), Broadcast (last), and host range (between)

Worked Example 1 — /26 subnet

Problem: Given IP address 192.168.1.70/26, find the Network ID, Broadcast, and usable host range.

Step 1 — Identify the prefix
/26 → 26 network bits, 6 host bits

Step 2 — Find the interesting octet
Mask for /26: 255.255.255.192
Octets 1,2,3 = 255 (fully network — not interesting)
Octet 4 = 192 (this is the interesting octet)

Step 3 — Calculate block size
Block size = 256 - 192 = 64

Step 4 — List the subnet ranges
Subnet 1: 0 to 63
Subnet 2: 64 to 127 ← our IP (70) falls here
Subnet 3: 128 to 191
Subnet 4: 192 to 255

Step 5 — Confirm which range contains 70
70 is between 64 and 127, so we are in the second subnet.

Step 6 — Read off the answers
Network ID: 192.168.1.64 (first address in range)
Broadcast: 192.168.1.127 (last address in range)
First host: 192.168.1.65
Last host: 192.168.1.126
Usable hosts: 62 (2^6 - 2)

Worked Example 2 — /22 subnet

Problem: Given IP address 10.205.79.90/22, find the Network ID, Broadcast, and host range.

Step 1 — Identify the prefix
/22 → 22 network bits, 10 host bits

Step 2 — Find the interesting octet
Mask for /22: 255.255.252.0
Octet 1 = 255, Octet 2 = 255 (not interesting)
Octet 3 = 252 (this is the interesting octet!)
Octet 4 = 0 (fully host — not interesting)

Step 3 — Calculate block size
Block size = 256 - 252 = 4

Step 4 — List subnet ranges in the 3rd octet
...72-75, 76-79, 80-83, 84-87...

Step 5 — The 3rd octet of our IP is 79
79 falls in the range 76–79. So the network starts at 76 in the third octet.

Step 6 — Read off the answers
Network ID: 10.205.76.0 (3rd octet = 76, 4th = 0)
Broadcast: 10.205.79.255 (3rd octet = 79, 4th = 255)
First host: 10.205.76.1
Last host: 10.205.79.254
Usable hosts: 1022 (2^10 - 2)

When the interesting octet is not the last one (like /22), the full host range spans multiple values of the last octet. The network starts at (block_start).0 and ends at (block_end).255.

Worked Example 3

Problem: A company has the network 192.168.1.0/24 and needs to divide it into at least 3 departments.

Step 1 — Find how many bits to borrow
We need 3 subnets
2^1 = 2 (not enough)
2^2 = 4 (enough — borrow 2 bits)

Step 2 — Calculate the new mask
Original: /24
Borrow 2 bits → /24 + 2 = /26
New mask: 255.255.255.192

Step 3 — List the available subnets
Subnet 1: 192.168.1.0/26 Hosts: .1 to .62
Subnet 2: 192.168.1.64/26 Hosts: .65 to .126
Subnet 3: 192.168.1.128/26 Hosts: .129 to .190
Subnet 4: 192.168.1.192/26 Hosts: .193 to .254 (spare)

You now have 4 subnets (we needed 3 minimum), each supporting 62 hosts. Assign three to departments and keep one as a spare.

11. CIDR Notation
CIDR (Classless Inter-Domain Routing) notation is the compact /x format that replaces the older class-based system. Instead of writing out the full subnet mask, you write the number of network bits after a slash.

192.168.1.0/24 means 24 network bits, 8 host bits
10.0.0.0/8 means 8 network bits, 24 host bits
172.16.0.0/12 means 12 network bits, 20 host bits

CIDR is used everywhere — routing tables, firewall rules, cloud security groups, and IP allocation. Understanding /x notation instantly tells you the block size and host capacity of any subnet.

12. Quick Reference Table

CIDR Subnet Mask Block Size Total IPs Usable Hosts
/24 255.255.255.0 256 256 254
/25 255.255.255.128 128 128 126
/26 255.255.255.192 64 64 62
/27 255.255.255.224 32 32 30
/28 255.255.255.240 16 16 14
/29 255.255.255.248 8 8 6
/30 255.255.255.252 4 4 2

13. Key Takeaways

Here is everything you need to carry away from this guide:

•Subnetting divides one network into many by borrowing host bits — more subnets means fewer hosts per subnet
•Devices find their subnet using bitwise AND: IP AND Mask = Network ID
•The Network ID (all host bits = 0) and Broadcast (all host bits = 1) are always reserved — never assignable
•Block size = 256 − mask octet value — this is your fastest tool for finding subnet ranges
•Usable hosts = 2^H − 2 where H is the number of host bits
•CIDR /x notation tells you how many bits are network bits — everything else is host bits
•When designing subnets, always prioritize number of networks first, then hosts per network.

Address Resolution Protocol (ARP) and Communication Flow Analysis

Manoj Kumar Vemula — Mon, 23 Feb 2026 07:28:01 +0000

Hello guys, You know I used to get stuck thinking about how devices communicate each other, because unlike humans they don't have any senses right. But this concept answered all my questions and i am really excited to share my learning.
So the very important Topic is ARP, here it works at layer 2 with MAC addresses and there are different types in ARP requests like reverse ARP, Gratuitous ARP.
These are the contents i am going to discuss in this blog:
-->ARP Fundamentals
-->ARP Operation in Same Subnet Communication
-->ARP Operation Across Different Networks (via Router)
-->Switch MAC Learning Behavior
-->ICMP Communication Flow
-->Default Gateway Logic
-->Network Addressing Concepts
-->NIC, Network ID, Host ID
-->CCNA Key Concepts

1]Address Resolution Protocol (ARP)

The Address Resolution Protocol (ARP) is defined in RFC 826 and is used to resolve a Layer 3 IPv4 address into a corresponding Layer 2 MAC address within an Ethernet network segment.

In Ethernet LAN communication, devices send frames using MAC addresses, but applications and routing decisions use IP addresses. ARP provides the necessary mapping between these two address types.

ARP entries are temporarily stored in an ARP cache on Layer 3 devices such as hosts and routers.

ARP Operational Behavior:
When a sender needs to discover the MAC address associated with an IP address:
The sender transmits an ARP Request as a Layer 2 broadcast.
All devices in the broadcast domain receive and process the request.
The device that owns the requested IP responds with an ARP Reply.
The ARP Reply is sent as a Layer 2 unicast to the original sender.

Thus:
ARP Request → Broadcast
ARP Reply → Unicast

2. Scenario 1 — Communication Within Same Subnet
Topology:

PC1 (10.1.1.1/24, MAC AAAA) — Switch — PC2 (10.1.1.2/24, MAC BBBB)

All devices initially have empty ARP caches and the switch has an empty MAC address table.

Step-by-Step Communication Process
Step 1 — Layer 3 Subnet Decision (PC1)

When PC1 attempts to ping 10.1.1.2, it first determines whether the destination is local or remote.

Using the subnet mask 255.255.255.0, PC1 performs a logical AND operation on both its own IP address and the destination IP address.

Both results produce the same network ID (10.1.1.0), confirming that the destination is on the same subnet.

PC1 therefore decides that it must send the packet directly to the destination host rather than via a router. To do this, it requires the destination MAC address.

Step 2 — ARP Cache Lookup and Request Generation

PC1 checks its ARP cache and finds no entry for 10.1.1.2.

The ICMP Echo Request packet is temporarily queued while PC1 initiates ARP resolution.

PC1 constructs an ARP Request frame with:
Destination MAC: FF:FF:FF:FF:FF:FF (broadcast)
Source MAC: PC1’s MAC
Sender IP: 10.1.1.1
Target IP: 10.1.1.2
Target MAC: unknown (all zeros)

The broadcast nature ensures all devices in the LAN receive the request.

Step 3 — Switch Processing of ARP Request
The switch receives the broadcast frame on PC1’s port.

Before forwarding, the switch learns the source MAC address and records that PC1’s MAC resides on that port.

Because the destination MAC is broadcast, the switch floods the frame out all ports except the incoming port. PC2 therefore receives the ARP Request.

Step 4 — PC2 Processes ARP Request
PC2 examines the ARP packet and finds that the target IP matches its own IP address.

PC2 therefore:

Updates its ARP cache with PC1’s IP–MAC mapping.

Generates an ARP Reply containing its own MAC address.

The ARP Reply is sent as a unicast frame directly to PC1’s MAC address.

Step 5 — Switch Forwards ARP Reply
The switch receives the ARP Reply on PC2’s port.

It learns PC2’s MAC address location and adds it to the MAC table.

Because the destination MAC (PC1) is known, the switch forwards the frame only to PC1’s port rather than flooding.

Step 6 — PC1 Receives ARP Reply and Sends ICMP

PC1 updates its ARP cache with the mapping:

10.1.1.2 → PC2 MAC

With ARP resolution complete, PC1 retrieves the queued ICMP Echo Request and encapsulates it in an Ethernet frame addressed to PC2’s MAC.

Step 7–10 — ICMP Echo Exchange
The switch forwards the unicast ICMP frame to PC2.

PC2 validates the packet and generates an ICMP Echo Reply.

The reply is sent back through the switch to PC1, completing successful ping communication.

Key Concepts from Same-Subnet Communication:
-->Direct communication occurs when network IDs match.
-->ARP resolves the destination host MAC.
-->Switches learn MAC addresses from source fields.
-->Broadcast frames are flooded; known unicast frames are forwarded selectively.
-->ICMP communication depends on successful ARP resolution.

3. Scenario 2 — Communication Across Different Networks
Topology
PC1 (10.1.1.1/24) — Switch1 — Router — Switch2 — PC2 (10.1.2.2/24)

PC1 default gateway: 10.1.1.254
PC2 default gateway: 10.1.2.254

*Step-by-Step Inter-Network Communication
Step 1 — PC1 Determines Destination is Remote
*
PC1 compares network IDs:

PC1 network: 10.1.1.0

Destination network: 10.1.2.0

Since they differ, PC1 concludes the destination is on another network.

Therefore, the packet must be sent to the default gateway rather than directly to the destination host.

Step 2 — ARP for Default Gateway
PC1 checks its ARP cache for the gateway IP 10.1.1.254 and finds no entry.

PC1 sends an ARP Request asking:

“Who has 10.1.1.254?”

This request is broadcast on the local LAN.

Step 3–5 — Gateway ARP Resolution
The router’s interface with IP 10.1.1.254 receives the request and recognizes the target IP as its own.

The router:

Learns PC1’s MAC

Sends an ARP Reply with its own MAC

PC1 updates its ARP cache with:

10.1.1.254 → Router MAC

Step 6 — Critical Encapsulation Concept
PC1 now sends the ICMP packet.

Important distinction:

Layer 3 destination IP: 10.1.2.2 (PC2)

Layer 2 destination MAC: Router MAC

Thus the frame is addressed to the router, but the IP packet remains addressed to PC2.

*Router Forwarding Process
*
When the router receives the frame:
Layer 2 header is removed.
Router examines IP destination.
Routing table lookup identifies outgoing interface.
Router resolves destination MAC via ARP on the new network.
Router forwards packet with new Layer 2 header.
TTL is decremented by one.
This is the fundamental router forwarding workflow.

4. ARP Across Multiple Networks

Each network segment has its own ARP domain.

Key rule:
Hosts ARP only for devices in their own subnet.
Routers perform ARP on behalf of remote networks.

Thus:
PC1 ARPs for gateway
Router ARPs for PC2

5. Default Gateway Logic
Host decision process:

If destination network = local → direct ARP
If destination network ≠ local → send to gateway

The default route (0.0.0.0/0) in the routing table defines the gateway used for unknown networks.

6. Switch MAC Learning Principles
Switches operate at Layer 2 and learn MAC addresses dynamically.

Rules:
Learn source MAC on ingress
Flood broadcast and unknown unicast
Forward known unicast to specific port
Aging timer removes inactive entries

7. Network Addressing Concepts
NIC (Network Interface Card)

A NIC is the physical hardware that connects a device to a network and contains a unique MAC address.

It converts digital data into electrical or optical signals for transmission.

Network ID
The Network ID is the portion of an IP address that identifies the network.

It is obtained by performing a logical AND between the IP address and subnet mask.

Devices with the same Network ID can communicate directly.

Host ID
The Host ID uniquely identifies a device within a network.

Valid host range excludes:
Network address (all host bits 0)
Broadcast address (all host bits 1)

Default Gateway
The default gateway is the router IP used to reach external networks.

All inter-network communication passes through this gateway.

8. TTL Behavior

Routers decrement the TTL field by one for each hop.
Thus a packet sent with TTL 128 and received with TTL 127 confirms traversal through one router.

9. Complete Communication Model

Same subnet:
Host → ARP → Direct MAC → Destination

Different subnet:
Host → ARP gateway → Router → ARP destination → Destination

CCNA Key Takeaways:
ARP maps IP to MAC within a broadcast domain.
ARP Request is broadcast; ARP Reply is unicast.
Same subnet hosts communicate directly.
Different subnet hosts communicate via gateway.
Routers rewrite Layer 2 headers at each hop.
Switches learn MAC from source addresses.
Each network segment has a separate ARP domain.
TTL decrement proves router traversal.

Introduction to TCP/IP and Data Flow

Manoj Kumar Vemula — Sun, 22 Feb 2026 09:16:25 +0000

1. Data Flow
Data flow in computer networks refers to the structured movement, management, and transformation of data packets between devices, ensuring efficient, error-free transmission.
Data flow generally involves preparing data at the source, moving it through network infrastructure (routers/switches),, and reconstructing it at the destination.
Direction of Transfer: Data flow can be categorized by direction:
Simplex: One-way only (e.g., computer to printer).
Half-Duplex: Two-way, but not at the same time (e.g., walkie-talkie).
Full-Duplex: Simultaneous two-way communication (e.g., telephone call).

Encapsulation and Decapsulation

Encapsulation
Encapsulation is the process of adding protocol information (headers and trailers) to data as it moves down the network stack from the sender.

Decapsulation
Decapsulation is the reverse process at the receiver, where each layer removes its corresponding header/trailer to reveal the original data.

2. Network Layers Overview
Layer 1 — Physical Layer

The Physical Layer is responsible for transmitting raw binary data (0s and 1s) over the physical medium.

Transmission Types

Radio transmission — Wi-Fi, Bluetooth (short distance)

Microwave transmission — Cellular networks (4G, 5G)

Fiber optic transmission — High-speed long-distance communication

Fiber Splicing Machine

A fiber optic splicing machine joins two fiber cables permanently using an electric arc, minimizing signal loss.

Layer 2 — Data Link Layer

The Data Link Layer (Layer 2 of the OSI model) handles local network communication and uses MAC addresses for device identification.
The data link layer ensures reliable, node-to-node data transfer across a physical link by organizing raw bits from the physical layer into frames.

Key Aspects of the Data Link Layer:
Sublayers: Comprised of the Logical Link Control (LLC), which handles network protocols and flow control, and the Media Access Control (MAC), which manages hardware addressing and medium access.
Framing: The process of encapsulating packets from the network layer into frames with a header (source/destination MAC) and trailer (error checking) to define boundaries.
Physical Addressing: Utilizes MAC addresses to identify devices on the local area network (LAN).
Error Control: Detects and/or corrects errors caused by physical layer transmission (e.g., using Frame Check Sequence/CRC).
Flow Control: Regulates the amount of data transmitted to prevent a fast sender from overwhelming a slow receiver.
Access Control: Determines which device has control over the physical medium at any given time.

Key Points

Devices: Switches

Address type: MAC address (48-bit hexadecimal)

Frame format: Ethernet header

Scope: Local network (LAN)

Important Note

MAC addresses were designed for delivery, not security.
They can be spoofed.

MAC Address Spoofing
Can a device claim another MAC?

Yes. A device can impersonate another MAC address.
This is called MAC spoofing.

Why switches accept it

Switches operate at Layer 2 and do not authenticate the MAC source.

Layer 2 Security Mechanisms

Port Security

Limits MAC addresses per port

Binds MAC to specific port

Can disable port on violation

802.1X Authentication

Requires device authentication

Uses RADIUS server

Stronger than MAC-based security

DHCP Snooping

Tracks legitimate DHCP assignments

Blocks rogue DHCP servers

Dynamic ARP Inspection (DAI)

Validates ARP packets

Prevents ARP spoofing

Network Access Control (NAC)

Checks device compliance

Enforces policies

Layer 2 Security Conclusion

Layer 2 was designed for efficient communication, not security.
Real security uses multiple layers (defense-in-depth).

Layer 3 — Network Layer

The Network Layer (Layer 3) enables communication between networks using IP addressing and routing.
The network layer of the OSI model manages logical addressing, packet routing, and forwarding to ensure data traverses different, interconnected networks. It converts transport layer segments into packets, determines the best path, and enables end-to-end communication, primarily using the Internet Protocol (IP).

Key aspects of the network layer include:
Routing: Determining the most efficient path for data to travel from source to destination.
Logical Addressing: Using IP addresses to uniquely identify devices across networks, distinct from physical (MAC) addresses.
Packetizing: Encapsulating segments from the transport layer into packets on the sending device and reassembling them at the destination.
Forwarding: Moving packets from a router's input interface to the appropriate output interface.
Protocols: Key protocols include Internet Protocol (IP), Internet Control Message Protocol (ICMP), and Internet Group Message Protocol (IGMP).

Devices:
Routers
Address Type
IP address
Function:
Routing packets between networks (WAN)

IP Address Spoofing (Layer 3)
Similar to MAC spoofing, IP addresses can also be faked.

Scenario A — Same Network Conflict
Two devices use the same IP → IP conflict → network instability.

Scenario B — Fake Source IP
A device sends packets pretending to be another IP → impersonation attack.

This is more dangerous and used in:

DDoS

Session hijacking

Man-in-the-middle attacks

Layer 3 Security Mechanisms

Ingress / Egress Filtering

Drops packets with invalid source IP ranges

Unicast Reverse Path Forwarding (uRPF)

Checks if packet arrived on correct interface

Drops spoofed packets

IPSec

Adds authentication and encryption

Verifies sender identity cryptographically

TTL Monitoring

Detects abnormal hop distance

Firewall Rules

Blocks private IP from public side

Blocks internal IP from external interface

Layer 4 — Transport Layer

The Transport Layer provides communication between applications.
The transport layer (Layer 4 in OSI) enables end-to-end communication between devices, ensuring data is delivered reliably, in order, and without errors. It manages data segmentation, flow control, and error correction, taking data from the session layer and passing it to the network layer via protocols like TCP and UDP.

Key Responsibilities & Functions
Segmentation and Reassembly: Breaks large data packets from the session layer into smaller chunks called segments at the source, and reassembles them at the destination.
Service-Point Addressing (Ports): Uses port numbers to direct data to specific applications (e.g., HTTP, FTP) on a host.
Connection Control: Provides connection-oriented (TCP) service for reliable, guaranteed delivery, or connectionless (UDP) service for faster, best-effort delivery.
Flow Control: Manages data transmission speed between devices to prevent a fast sender from overwhelming a slow receiver.
Error Control: Detects errors and handles retransmissions to ensure data integrity.
Multiplexing and Demultiplexing: Allows multiple applications to share a single network connection simultaneously.

Protocols:
TCP(Transmission Control Protocol): Connection-oriented, reliable, used for web browsing, email, and file transfers.

UDP(User Datagram Protocol): Connectionless, unreliable (best-effort), used for streaming, gaming, and VoIP.

Key Concept
Port numbers identify applications/services.

Layer 5 - Session Layer
Layer 5 is the Session Layer, which manages, maintains, and terminates connections (sessions) between applications on different network devices. It enables dialogues, establishes checkpoints for recovery, and supports data exchange in simplex, half-duplex, or full-duplex modes.

Key Aspects of the Session Layer:
Session Management: Establishes, maintains, and terminates connections between applications.
Dialogue Control: Acts as a controller to manage communication, allowing devices to communicate in full-duplex or half-duplex.
Synchronization & Recovery: Adds checkpoints to data streams; if a failure occurs, only data after the last checkpoint needs retransmission.
Protocols: Common protocols include NetBIOS, RPC (Remote Procedure Call), and PPTP.

Layer 6 - Presentation Layer
The Presentation Layer acts as a "translator" for the network, ensuring that data sent from the application layer of one system can be read by the application layer of another. Its primary roles include:

Data Translation: Converts data between different formats (e.g., EBCDIC to ASCII) so that systems with different character encoding can communicate.
Encryption and Decryption: Secures data by encoding it before transmission and decoding it upon receipt, often using protocols like SSL/TLS (Secure Sockets Layer/Transport Layer Security).

Data Compression: Reduces the size of data to improve transmission speed and efficiency, commonly used for multimedia formats like JPEG, MPEG, and GIF.

Common Protocols and Standards
Text/Data: ASCII, EBCDIC, XML, JSON.
Security: SSL, TLS.
Images: JPEG, PNG, GIF, TIFF.
Video/Audio: MPEG, AVI, MIDI.

Layer 7 - Application Layer
Layer 7, the Application Layer of the OSI model, is the topmost layer that directly interfaces with end-user software applications (like web browsers or email clients) to initiate network communication. It interprets user intent and manages application-level protocols such as HTTP, HTTPS, SMTP, FTP, and DNS, allowing for data exchange, service authentication, and resource sharing.

Key Aspects of Layer 7:
Function: It enables communication by providing services directly to applications, allowing software to send/receive data, rather than being the application itself.
Protocols: Common protocols include HTTP/HTTPS (web browsing), SMTP/IMAP (email), FTP (file transfer), and DNS (name resolution).
Interaction: It acts as the intermediary between network services and software, transforming user requests into network-compatible formats.
Security & Load Balancing: Layer 7 is critical for security, with Web Application Firewalls (WAFs) protecting against application-level attacks (e.g., HTTP floods). It also enables content-based load balancing, where traffic is distributed based on user requests.
Examples: When a user clicks a link, the web browser uses HTTP/HTTPS (Layer 7) to request the page

Splunk Basics

Manoj Kumar Vemula — Tue, 16 Dec 2025 11:35:12 +0000

Splunk Architecture

In splunk logs are Collected, Processed, Stored, Searched & Analyzed through 3 main components :

Data Source → Forwarder → Indexer → Search Head → User

I] Data Input Stage

1}Splunk Forwarder (Data Collection Stage) :
It is a lightweight agent installed on machines where logs are generated.
Examples of machines :
Linux servers, Windows servers, Web servers, Firewalls, Routers, Databases, Applications.

Its job is to collect logs and send them to splunk Indexer.
We need forwarders because :
Imagine :
5,000 servers generating logs, we cannot manually copy logs from each server. So Splunk Forwarder does this job.
Advantages :
Very Low CPU usage.
Runs in background.
Can scale up to tens of thousands of machines.
Secure(SSl/TLS) real time log forwarding.

Types of Splunk Forwarders :
Universal Forwarder : In short, its non-intelligent and only forwards logs no other job
Heavy Forwarder : It filters logs based on our requirement.

At this point data is not event, data is just raw.
EX : JULY date sever2 sshd[1234]: Failed Password for root from

Key Points
->Splunk doesn't process the entire file at once, It cuts incoming data into 64 kilobyte chunks. These are data blocks.
->Splunk adds labels[metadata] to each 64k block.
Metadata : Information about the data, like :
host
source
source type

After the data/logs reached to splunk they must be stored right!!. They store in indexes.
2}Indexes : It's crucial, as it decides which index data goes into. There are different indexes by your choice and also default indexes.
Example :
index = security, index = firewall, index = authentication.

End of Data Input Stage :
Data is still raw.
Data is tagged with meta data.
Data is not searchable yet.

II] Data storage Stage(RAW data becomes usefull)

This stage has 2 phases
i)Parsing
ii)Indexing

Parsing :
Parsing can be done in automated and manual, if the logs are in non-standard forward manual parsing through regex is recommended. For standard format of logs splunk automates parsing phase.

Raw Text --> Individual Searchable Events.

Sub-Phases of Parsing :
-->Breaking the stream into individual lines where one event ends & where next event begins.
-->Identifying, Parsing, Setting Timestamps.
-->Annotating individual events with meta data.(Splunk copies meta data generated from i/p stage)
-->Transforming event data using regex. This uses
props.config, transforms.config.

Indexing Process
Splunk decides which parts are timestamp, message. what fields exists...
This process also known as Event Processing.
Indexing = Event Processing
Splunk does the following:
Step 1: Event Breaking
Splits continuous data stream into individual events
Example:
One log file → 1,000 separate events
Step 2: Timestamp Identification
Finds time for each event
Uses:
Event timestamp
Or system time
This allows:
Time-based searches
Timeline analysis
Step 3: Field Extraction
Splunk extracts default fields like:
host
source
sourcetype
Example:
host=webserver1
source=/var/log/auth.log
sourcetype=linux_secure

Step 4: User-Defined Processing
At index time, Splunk can:
Mask sensitive data (passwords, credit cards)
Create custom fields
Drop unwanted events
Route logs to specific indexes
Apply multi-line rules

Step 5: Store Data in Indexes
Indexer stores data in Buckets
Each bucket contains:
Raw data (compressed)
Index files (tsidx)
Metadata

WHAT ARE BUCKETS IN SPLUNK?
Splunk does NOT store all data in one folder.
Instead, it stores data in multiple folders called BUCKETS.

What is a Bucket : A bucket is a directory on disk contains :
1}Raw log data
2}Index files
3}Metadata

1}Hot Bucket :
Contains newly arriving data
Currently being written
Always open

2}Warm Bucket
A Hot bucket becomes warm when
Size limit is reached OR
Time limit is reached OR
Splunk is restarted

Contains recent but stable data
No longer writable
Still searched very often

3]Cold Bucket
When does data move to Cold?
When:
Warm bucket count exceeds configured limit

What is a COLD bucket?
Contains older data
Rarely searched
Stored on slower & cheaper storage
Think:
Cold = old logs, used occasionally

4}Frozen Bucket
What is Frozen bucket :
Data is removed from Splunk indexes
IMPORTANT:
Frozen data is NOT searchable
It may be:
Deleted permanently
Archived to external storage
Why Frozen exists?
Because:
Storage is expensive
Compliance rules define retention
Old logs are useless after some time
Think:
Frozen = dead / archived data

3}Data Searching Stage

The data searching stage is the phase where users query, analyze and visualize indexed data to extract insights.
This stage happens after data is already indexed.

During the data searching stage, Splunk :
->Searches events stored in indexes.
->Filters relevant data.
->Transform and analyze data
->Visualize results

SPL : SPL (Search Processing Language): It is the core engine of Splunk, used to search, filter, analyze, and visualize indexed data, and it primarily runs on the Search Head.
In the next blog I'll be discussing about top 25 commands in SPL.

Quick Summary Table
| Component | Role |
| ------------------ | ------------------------ |
| Forwarder | Collects & sends data |
| Indexer | Stores & indexes data |
| Index | Logical storage location |
| Search Head | Search & visualization |
| Deployment Server | Manage forwarders |
| License Master | License tracking |
| Cluster Manager | Indexer clustering |
| Monitoring Console | Health monitoring |

How To Read Logs From Windows using python

Manoj Kumar Vemula — Fri, 12 Dec 2025 10:12:32 +0000

Hello there!
In this blog post, I am sharing one of the steps from my SOAR project.
By completing this guide, you will be able to retrieve Windows logs using Python.

1}Understanding Windows Logs
Before retrieving logs using Python, you must understand where Windows stores logs and how they are structured.

Open Event Viewer → expand Windows Logs.
You will see:
Application
Security
Setup
System
Forwarded Events
Each category contains events stored in a structured format.

2}Windows Event Structure
Windows event has 5 parts.
Log Name : Application, Security, System, Setup.
Level : The level of security e.g, Info, warning, Critical, Verbose.
Data and Time : When event has occurred.
Source : The program, service or component that generated the event.
Event ID : A unique Identification of number.

Event Log Structure:
Every Windows event has 5 important parts.

Event ID : You already saw this (e.g., 4624 = logon).
Level :
This tells how serious the event is:
Information
Warning
Error
Critical
Audit Success
Audit Failure
4624 = Audit Success
4625 = Audit Failure
Time Created
The exact timestamp when the event happened.
This tells you when the action occurred.
Provider (Source)
This tells you who created the event.
Examples:
Microsoft-Windows-Security-Auditing
Service Control Manager
Application Error
Event Details (Description / XML)
Scroll down to the bottom and you will see a section called “Details”.
Click Details → Select XML view.
This XML view is exactly what Python reads using libraries like pywin32 or win32evtlog.

2}Python Libraries for Windows Logs
There are three major options
-->Option 1: pywin32
Allows Python access to Windows APIs.
Offers win32evtlog and win32evtlogutil.
Learn:
Installing: pip install pywin32
Reading event logs using win32evtlog.OpenEventLog
Parsing event records

-->Option 2: win32com / WMI
Use WMI to query logs.
Learn:
Installing: pip install wmi
Basic WMI queries (e.g., SELECT * FROM Win32_NTLogEvent)

-->Option 3: subprocess + PowerShell
Run PowerShell command Get-WinEvent or Get-EventLog from Python and parse output.
Learn:
Using subprocess.run
Reading command output (stdout)

I choose option 3, here i use python(subprocess) and power shell.
Let's start with power shell basics, Basic level of power shell learning is necessary for this.
PowerShell : It is a cross-platform command-line shell and object-oriented scripting language used for system administration.

3} Power Shell Basics
-->Core Log Reading Commands
1}Get-WinEvent
2}Get-EventLog
3}wevtutil qe
4}Get-Wmiobject win32_NTLogEvent
5}Get-CimInstance Win32_NTLogEvent

-->Core Log Filtering Commands
1}Where-Object
2}Select-Object
3}Sort-Object
4}Group-Object
5}Measure-Object
6}Select-String

-->Log Exporting Commands
1}Out-File
2}Export-Csv
3}ConvertTo-Json
4}wevtutil epl
5}Out-GridView

-->Log Management Command
1}wevtutil cl
2}wevtutil gl
3}New-EventLog
4}Write-EventLog
5}Remove-EventLog

-->Log File / Folder Commands
1}Get-ChildItem
2}Set-Location
3}New-Item
4}Test-Path
5}Get-Content
6}Get-Content-Wait
7}Get-Content-Tail

-->System/Metadata Commands
1}Get-EventSubscriber
2}Get-Service
3}Get-Process
4}Get-WinEvent -ListLog *
5}Get-WinEvent -ListProvider *

-->PowerShell "Thinking Tools"
1}Get-Help
2}Get-Help -Examples
3}Get-Command
4}Get-Member
5}Get-Alias

Each commands accepts only certain parameter. view them by
Get-Help
Example :

Get help for Get-EventLog

->Get-Help Get-EventLog

I recommend learn it online and complete some tasks to get familiar with it like ask AI tools to assign some tasks for power shell commands and complete them.

But Not all commands will work for normal user in power shell you need to run it at Administrative level.

4}How Windows Admin Rights Actually Work
Windows does not allow any program to just become admin out of no where.
Instead :
Every program is launched with a security token.
That token is either:
-- A standard User.
-- Administrator.
If your script starts as a normal user, the only way to become Admin is:
Show a UAC popup.
Or run the script inside a session that is already elevated.
Or use a scheduled task that runs elevated.

Understanding the Admin Check Code:
ctypes : A python module that lets python call windows system DLLs
ctypes.windll.shell32 means:
Access the Windows system DLL shell32.dll

Code :

import ctypes
import sys
def is_admin():
try:
return ctypes.windll.shell32.IsUserAnAdmin()

except:
return False
if not is_admin():
ctypes.windll.shell32.ShellExecuteW( None, "runas", sys.executable, " ".join(sys.argv),None, 1)

print("Running as admin!")

-->ctypes.windll.shell32.IsUserAnAdmin()
This line check whether user or admin

How Python Elevates Itself :
If Python is not already admin,
if not is_admin():
ctypes.windll.shell32.ShellExecuteW(
None, "runas", sys.executable, " ".join(sys.argv),None, 1)
sys.exit()

ShellExecuteW : A windows API function that can launch a new program.
The above mentioned parameters :
None --> No parent Window
runas --> Tells windows "Run As Administrator"
sys.executable -->Path to python.exe

" ".join(sys.argv) -->Arguments of your script and Because ShellExecuteW CANNOT accept a list.

sys.argv is a list.
So you cannot pass it directly.
Example:
['retrivelogs.py']

ShellExecuteW does not understand lists.
It only understands strings like:
"retrivelogs.py"
So we convert:
sys.argv → " ".join(sys.argv)

That is the ONLY reason.

We used " ".join(sys.argv)
because Windows API requires ONE STRING
not a Python list.

" ".join(sys.argv) = "retrivelogs.py"

None -->Working directory
1 -->Shows the windows

Now you can guess what are we trying to do,
We are just executing power shell commands but in python code.

Subprocess module makes our work even easier.

5}Subprocess Module
The subprocess module lets you run external commands, spawn new processes, interact with their input/output and retrieve results.

Python offers four main ways to run subprocesses but here we discuss main two:
1}subprocess.run() : Recommended High-Level Function.
This is the best way to run a command and collect the result.

Signature :
subprocess.run(args, *,
stdin=None,
input=None,
stdout=None,
stderr=None,
capture_output=False,
shell=False, cwd=None,
timeout=None,
check=False,
text=False, encoding=None, errors=None)

Example :
import subprocess
res = subprocess.run(["ls","-l"],
capture_output = True,
text = True,
check =True #raise error if command fails)

2}subprocess.Popen() :
This is the advanced, fully configurable way.
Signature :
subprocess.Popen(args,
bufsize=0,
executable=None,
stdin=None,
stdout=None, stderr=None,
preexec_fn=None,
close_fds=True, shell=False,
cwd=None, env=None,
universal_newlines=False, text=None,

startupinfo=None, creationflags=0,
pipesize=-1)

Example :
from subprocess import Popen, PIPE

p = Popen(["grep", "hello"],
stdin=PIPE,
stdout=PIPE,
text=True)
out = p.communicate("hello world")[0]
print(out)

2}Important Classes
Returned by run()
Attributes:
args
returncode
stdout
stderr

Returned by Popen()
Methods:
poll() — check if process ended
wait() — wait until finished
communicate() — send input & read output
terminate() — graceful stop (SIGTERM)
kill() — force kill (SIGKILL)

NOTE : Popen can stream real time output but run can't.
1) Stream real-time output
from subprocess import Popen, PIPE
p = Popen(["ping", "google.com"], stdout=PIPE, text=True)
for line in p.stdout:
print("LIVE:", line, end="")

run() cannot do this — it waits until the command finishes.

*Python Code *:
import subprocess
import json
import ctypes
import sys

def is_admin():
try:
return ctypes.windll.shell32.IsUserAnAdmin()
except:
return False

if not is_admin():
ctypes.windll.shell32.ShellExecuteW(
None, "runas", sys.executable, " ".join(sys.argv),None, 1)
print("Running as admin!")

command = [
"powershell",
"-Command",#you can change the commands here
"Get-WinEvent -LogName System -MaxEvents 5 | "
"Select-Object Id, @{Name='TimeCreated';Expression={$_.TimeCreated.ToString('yyyy-MM-dd HH:mm:ss')}} | "
"ConvertTo-Json -Depth 4"
]

result = subprocess.run(command, capture_output=True, text=True)

output = result.stdout

try:
events = json.loads(output)
except json.JSONDecodeError:
print("Error parsing JSON. Raw output:")
print(output)
exit()

//Ensure output is always a list
if isinstance(events, dict):
events = [events]

for event in events:
print(f"ID: {event['Id']} Time: {event['TimeCreated']}")