ARP - Address Resolution Protocol
What is ARP?
ARP stands for Address Resolution Protocol. It’s a network protocol used to map an IP address to a physical MAC address on a local area network (LAN). This is essential for devices to communicate over Ethernet/wifi.
Why is ARP useful?
Devices communicate using IP addresses, but data is actually sent using MAC addresses at the hardware level. ARP bridges this gap by helping a device find the MAC address that corresponds to a known IP address. Without ARP, devices wouldn’t know how to deliver packets on the local network.
How it works?
Device wants to send data – It knows the destination IP address but not the MAC address.
Sends ARP request – A broadcast message is sent to all devices on the LAN: “Who has this IP address?”
Receives ARP reply – The device with that IP replies with its MAC address.
Saves the mapping – The sender stores the IP-to-MAC mapping in its ARP cache for future use.
Where is ARP used?
Local networks (LANs) – To enable communication between devices like computers, printers, and routers.
Home and office networks – Every time a device sends data to another on the same subnet.
Network troubleshooting – Tools like arp -a help diagnose connectivity issues.
Which OSI layer does this protocol belong to?
It deals with MAC addresses, which are hardware-level identifiers.
It enables the delivery of packets within the same local network segment.
It works below the IP layer, translating IP addresses into MAC addresses for Ethernet communication.
Topics in this section,
In this section, you are going to learn
Terminology
Version Info
ARP Version |
ARP Number |
Year |
Core Idea / Contribution |
|---|---|---|---|
ARP (Original) |
RFC 826 |
1982 |
Defined the basic ARP mechanism for mapping IP addresses to MAC addresses on a local network. |
Reverse ARP (RARP) |
RFC 903 |
1984 |
Introduced RARP, allowing devices to discover their IP address from a known MAC address, useful for diskless workstations. |
Transparent Subnet ARP |
RFC 1027 |
1987 |
Proposed using ARP to implement transparent subnet gateways, enhancing routing flexibility. |
Fault-Tolerant ARP |
RFC 1029 |
1987 |
Suggested improvements for ARP in multi-LAN environments to increase reliability and fault tolerance. |
Proxy ARP Test Case
This test verifies that the router responds to ARP requests on behalf of another host when Proxy ARP is enabled. Succesfull ping from the router confirm Proxy ARP functionality.
Step-1 : Configure router to enable proxy ARP.
test:~$sudo sysctl -w net.ipv4.conf.all.proxy_arp=1 net.ipv4.conf.all.proxy_arp = 1 test:~$sudo sysctl -w net.ipv4.conf.wlp2s0.proxy_arp=1 net.ipv4.conf.wlp2s0.proxy_arp = 1Step-2: From Host A, Ping Host B.
test:~ping 192.168.50.204 PING 192.168.50.204 (192.168.50.204) 56(84) bytes of data. 64 bytes from 192.168.50.204: icmp_seq=1 ttl=64 time=125 ms 64 bytes from 192.168.50.204: icmp_seq=2 ttl=64 time=224 ms 64 bytes from 192.168.50.204: icmp_seq=3 ttl=64 time=320 ms 64 bytes from 192.168.50.204: icmp_seq=4 ttl=64 time=143 ms 64 bytes from 192.168.50.204: icmp_seq=5 ttl=64 time=166 msStep-3: See ouput of arp -a command. You should able to target IP mapped with its MAC address.
test:~arp -a RT-AX3000-ED38 (192.168.50.1) at c8:7f:54:37:ed:38 [ether] on wlp2s0 realme-12-Pro-5G (192.168.50.204) at 8a:5c:39:7a:20:7b [ether] on wlp2s0Step-4: Capture the response on Wireshark.
Expected result:
When Proxy ARP is enabled on the router, it should respond to ARP requests on behalf of another device (Host B).
Ping from Host A to Host B succeeds, and arp -a shows the correct MAC mapping.
Step-5: Wireshark Capture
ARP Cache Test Case
This test checks if the ARP cache is correctly populated after flushing it. When a device is pinged, its MAC address is dynamically learned and added to the ARP table, confirming proper ARP resolution.
Step-1 : Clear ARP table
test:~$sudo ip -s -s neigh flush all 192.168.50.1 dev wlp2s0 lladdr c8:7f:54:37:ed:38 ref 1 used 6/6/2probes 1 REACHABLE 192.168.50.6 dev wlp2s0 lladdr 8a:5c:39:7a:20:7b used 3893/3893/3873probes 4 STALE *** Round 1, deleting 2 entries *** *** Flush is complete after 1 round ***Step-2: Check arp table, only gateway MAC would be seen.
test:~$arp -a RT-AX3000-ED38 (192.168.50.1) at c8:7f:54:37:ed:38 [ether] on wlp2s0Step-3: Ping another local device.
test:~$ping 192.168.50.183 PING 192.168.50.183 (192.168.50.183) 56(84) bytes of data. 64 bytes from 192.168.50.183: icmp_seq=1 ttl=64 time=125 ms 64 bytes from 192.168.50.183: icmp_seq=2 ttl=64 time=224 ms 64 bytes from 192.168.50.183: icmp_seq=3 ttl=64 time=320 ms 64 bytes from 192.168.50.183: icmp_seq=4 ttl=64 time=143 ms 64 bytes from 192.168.50.183: icmp_seq=5 ttl=64 time=166 msStep-4: Run arp -a
test:~$arp -a shilpa (192.168.50.183) at 0c:9a:3c:9f:17:71 [ether] on wlp2s0 RT-AX3000-ED38 (192.168.50.1) at c8:7f:54:37:ed:38 [ether] on wlp2s0Step-5: Capture the response on wireshark.
Expected result:
After flushing the ARP cache, only the default gateway’s MAC address should remain.
Pinging a local device should trigger ARP resolution and dynamically populate its MAC in the ARP table.
Step-6: Wireshark Capture
Static ARP entries Test Case
This test verifies that manually added static ARP entries persist in the ARP table even after a reboot or timeout. The entry is marked as PERM, confirming it wont be aged out or replaced.
Step-1: Add Static ARP.
test:~$sudo arp -s <target_IP> <target_MAC>Step-2: Reboot or wait timeout period.
Step-3: Chech arp table , entry should remain.
test:~$arp -a RT-AX3000-ED38 (192.168.50.1) at c8:7f:54:37:ed:38 [ether] on wlp2s0 realme-12-Pro-5G (192.168.50.6) at 8a:5c:39:7a:20:7b [ether] PERM on wlp2s0Step-4: Capture the response on wireshark.
Expected result:
Static ARP entry should persist in the ARP table with a PERM flag, even after reboot or timeout.
No ARP request should be seen in Wireshark for the static IP, confirming the MAC is already known and not resolved dynamically.
Step-5: Wireshark Capture
ARP Request Handling Test Case
This test checks if a device correctly responds to a valid ARP request sent using arping. The target device replies with its MAC address, confirming successful ARP resolution and communication.
Step-1: Use arping to send ARP request to known IP.
test:~$sudo arping -c 1 192.168.50.117 ARPING 192.168.50.117 42 bytes from 70:cd:0d:c9:9b:c7 (192.168.50.117): index=0 time=359.440 msec --- 192.168.50.6 statistics --- 1 packets transmitted, 1 packets received, 0% unanswered (0 extra) rtt min/avg/max/std-dev = 359.440/359.440/359.440/0.000 msStep-2: Capture the response on wireshark.
Expected result:
The target device should reply to the ARP request with its MAC address, confirming it is reachable.
Wireshark capture should show an ARP request from the source and a matching ARP reply from the target.
Step-3: Wireshark Capture
ARP Reply Handling Test Case
Step-1: Use arpspoof to send unsolicited ARP reply
This test checks if a device accepts unsolicited ARP replies (sending fake ARP reply without a request) using arpspoof. The target updates its ARP table with the attacker’s MAC, confirming the reply was accepted.
test1:~$sudo arpspoof -i wlp2s0 -t 192.168.50.122 192.168.50.113Step-2: Ping your IP on target machine.
test2:~$ping 192.168.50.113Step-3: Check arp table.
test2:~$arp -aStep-4: Capture the response on wireshark.
Expected result:
The target device should update its ARP table with the attacker’s MAC address upon receiving the unsolicited ARP reply.
Wireshark capture should show an unsolicited ARP reply from the attacker and no corresponding ARP request from the target.
Step-5: Wireshark Capture
ARP Timeout/Aging Test Case
This test Verifies that the ARP entries expire after a timeout period if unsed. After pinging a device and waiting, the ARP entry transitions to STALE and eventually disappers, confirming proper aging behaviour.
Step-1: Clear ARP table
test:~$sudo ip -s -s neigh flush allStep-2: Ping a device to populated ARP cache.
test:~$ping 192.168.50.6 PING 192.168.50.6 (192.168.50.6) 56(84) bytes of data. 64 bytes from 192.168.50.6: icmp_seq=1 ttl=64 time=125 ms 64 bytes from 192.168.50.6: icmp_seq=2 ttl=64 time=224 ms 64 bytes from 192.168.50.6: icmp_seq=3 ttl=64 time=320 ms 64 bytes from 192.168.50.6: icmp_seq=4 ttl=64 time=143 ms 64 bytes from 192.168.50.6: icmp_seq=5 ttl=64 time=166 ms
Step-3: Wait ARP timeout period (1-2mins)
Step-4: Run ip neigh command, shows STALE for ping IP, represents that will disappear if we dont use)
test:~$ip neigh 192.168.50.1 dev wlp2s0 lladdr c8:7f:54:37:ed:38 REACHABLE 192.168.50.6 dev wlp2s0 lladdr 8a:5c:39:7a:20:7b STALE
Step-5: Capture the response on wireshark.
Expected result:
After pinging, the ARP entry should transition from REACHABLE to STALE and eventually be removed if unused, confirming proper aging.
Step-6: Wireshark Capture
ARP Table Overflow Test Case
This test simulates ARP cache overflow by adding 100 fake static entries to the ARP table. The system accepts and retains these entries as PERM, confirming its ability to handle a large ARP table without errors.
Step-1: Use a script or tool to ARP many fake enries.
test:~$for i in {1..100}; do sudo ip neigh add 192.168.0.$i lladdr 02:00:00:00:00:$((i % 100)) dev wlp2s0 2>/dev/null done
Step-2: Monitor ARP table. Many ARP entries (including real and fake ) should succesfully added and shows as PERM.
test:~$arp -a
Step-3: Capture the response on wireshark.
Expected result:
The ARP table should accept and retain all 100 static (PERM) entries without dropping or overwriting existing ones.
Wireshark should show no ARP traffic for these static entries, confirming they were not dynamically resolved.
Step-4: Wireshark Capture
ARP Rate Limiting Test Case
This test checks if the system limits excessive ARP traffic by sending 50 rapid ARP requests. A significant portion of requests are dropped, confirming that ARP rate limiting is active and effective.
Step-1: Send 50 ARP rquests using arping.
test:~$sudo arping -c 50 192.168.50.6 ARPING 192.168.50.6 Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=0 time=214.414 msec 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=1 time=144.378 msec Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=2 time=204.545 msec Timeout Timeout Timeout Timeout Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=3 time=501.430 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=4 time=491.688 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=5 time=368.760 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=6 time=252.911 msec Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=7 time=158.205 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=8 time=309.092 msec 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=9 time=127.322 msec Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=10 time=174.753 msec 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=11 time=199.963 msec 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=12 time=132.498 msec Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=13 time=187.470 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=14 time=170.034 msec Timeout Timeout Timeout 42 bytes from 8a:5c:39:7a:20:7b (192.168.50.6): index=15 time=470.797 msec Timeout --- 192.168.50.6 statistics --- 50 packets transmitted, 16 packets received, 68% unanswered (0 extra) rtt min/avg/max/std-dev = 127.322/256.766/501.430/126.860 ms
Step-2: Capture response on wireshark.
Expected result:
The system should drop or ignore a large number of rapid ARP requests, resulting in partial replies (e.g., 16/50), confirming rate limiting.
Wireshark capture should show that only a subset of ARP requests receive replies, with increasing delays or silent drops for excessive traffic.
Step-3: Wireshark Capture
ARP Retry Behaviour Test Case
This test verfies that the system retries ARP requests when pinging a nonexistent IP. Multiple ARP requests (typically 3-5) are sent before the system marks the host unreachable, confirming standard retry behaviour.
Step-1: Ping a Non-Existent IP on local Subnet.
test:~$ping -c 5 192.168.50.200 PING 192.168.50.200 (192.168.50.200) 56(84) bytes of data. From 192.168.50.110 icmp_seq=1 Destination Host Unreachable From 192.168.50.110 icmp_seq=2 Destination Host Unreachable From 192.168.50.110 icmp_seq=3 Destination Host Unreachable From 192.168.50.110 icmp_seq=4 Destination Host Unreachable From 192.168.50.110 icmp_seq=5 Destination Host Unreachable --- 192.168.50.200 ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4081ms pipe 4
Step-2: Use Wireshark to count ARP retries.
Expected result:
The system should send multiple ARP requests (typically 3 to 5) before declaring the host unreachable, confirming standard retry behavior.
Wireshark capture should show repeated ARP requests with no replies, followed by ICMP “Destination Host Unreachable” messages.
Step-3: Wireshark Capture
ARP Filtering Test Case
This test verifies that ARP replies are blocked using nftables on a specific interface, preventing the system from responding to ARP requests. As a result, ping attempts from another device fail due to unresolved IP-to-MAC mapping.
Step-1: Create the arpfillter table.
test1:~$sudo nft add table netdev arpfilter
Step-2: Attach the ARP filtering rule to incoming traffic on the network interface. Hooks into the ingress of interface.
test1:~$sudo nft add chain netdev arpfilter input { type filter hook ingress device wlp2s0 priority 0 \;}
Step-3: Attach the ARP filtering rule to drop all ARP traffic arriving on that interface.
test1:~$sudo nft add rule netdev arpfilter input ether type arp drop
Step-4: Send ARP request to that interface.
test2:~$ping 192.168.50.113
Step-5: Capture the response on wireshark.
Expected result:
All ARP packets arriving on the filtered interface should be dropped, preventing ARP replies and IP-to-MAC resolution.
Ping attempts from other devices should fail due to unresolved MAC addresses, and Wireshark should show ARP requests without replies on that interface.
Step-6: Wireshark Capture
ARP on Bridged Interfaces Test Case
This test verifies that ARP requests and replies should pass through the virtual bridge, allowing to resolve each other’s MAC addresses.
Step-1: Create a bridge interface. (veth pairs- virtual ethernet cables)
test1:~$sudo ip link add veth1 type veth peer name veth1-br test1:~$sudo ip link add veth1 type veth peer name veth2-brStep-2: Create bridge and attach interfaces.
test1:~$sudo ip link add name br0 type bridge test1:~$sudo ip link set br0 up test1:~$sudo ip link set veth1-br master br0 test1:~$sudo ip link set veth2-br master br0 test1:~$sudo ip link set veth1-br up test1:~$sudo ip link set veth2-br upStep-3: Create network namespaces
test1:~$sudo ip netns add ns1 test1:~$sudo ip netns add ns2
Step-4: Move veth1 and veth2 into namespaces
test1:~$sudo ip link set veth1 netns ns1 test1:~$sudo ip link set veth2 netns ns2
Step-5: Assign IP address.
test1:~$sudo ip netns exec ns1 ip addr 192.168.1.10/24 dev veth1 test1:~$sudo ip netns exec ns1 ip link set veth1 up test1:~$sudo ip netns exec ns1 ip link set lo up test1:~$sudo ip netns exec ns2 ip addr 192.168.1.20/24 dev veth2 test1:~$sudo ip netns exec ns2 ip link set veth2 up test1:~$sudo ip netns exec ns2 ip link set lo up
Step-6: Test ARP behaviour by pinging between connected devices.
test1:~$ping -c 2 192.168.1.20 PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data. 64 bytes from 192.168.1.20: icmp_seq=1 ttl=64 time=413 ms 64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=314 ms --- 192.168.1.20 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 314.165/363.574/412.984/49.409 ms
Step-7: Capture the response on wireshark.
Expected result:
ARP requests and replies should successfully traverse the virtual bridge, enabling MAC address resolution between namespaces.
Wireshark should capture proper ARP exchanges between the bridged interfaces, confirming seamless L2 communication through the bridge.
Step-8: Wireshark Capture
Duplicate IP detection Test Case
To verify how the network handles a situation where two devices are assigned the same IP address, which should trigger an IP conflict and prevent proper communication.
Step-1: Assign Same IP to two devices. Here I have used 2 Laptops and mobile.
Step-2: Check your laptop’s IP address
test1:~$ifconfig br0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 62:47:a9:f6:2b:ca txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 2 overruns 0 carrier 0 collisions 0 enp1s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether b4:a9:fc:7b:e4:ee txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 102152 bytes 9652412 (9.6 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 102152 bytes 9652412 (9.6 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether 52:54:00:1a:ed:e4 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 344 overruns 0 carrier 0 collisions 0 wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.50.110 netmask 255.255.255.0 broadcast 192.168.50.255 inet6 fe80::48f0:513:7352:fd4a prefixlen 64 scopeid 0x20<link> ether e8:6f:38:71:f1:e3 txqueuelen 1000 (Ethernet) RX packets 5317022 bytes 7116415323 (7.1 GB) RX errors 0 dropped 19116 overruns 0 frame 0 TX packets 919187 bytes 146487549 (146.4 MB) TX errors 0 dropped 707 overruns 0 carrier 0 collisions 0
Step-3: Assign the same IP address to your mobile device manually (192.168.50.110) (via Wi-Fi settings -> Static IP).
Step-4: Reconnect both devices to the same network (Wi-Fi or LAN)
Step-5: From a third device (Laptop 3), try to ping the duplicate IP.
test3:~$ping 192.168.50.110
Step-6: Open Wireshark on any device and capture traffic to observe ARP conflict or duplicate IP detection packets.
Expected result:
An IP conflict should occur, resulting in unstable communication — ARP replies may alternate between devices or trigger conflict messages.
Wireshark should show multiple ARP replies for the same IP from different MAC addresses, indicating a duplicate IP on the network.
Step-7: Wireshark Capture
One-Way ARP spoofing to Client/poisoning detection Test Case
To test if a client device can be tricked into associating the gateway’s IP with the attacker’s MAC address, effectively rerouting traffic through the attacker.
Step-1: Connect three devices (Attacker-L1, Client-L2, Gateway-L3) to the same network.
Step-2: Disable firewalls on L1 and L2.
Step-3: On L1(attacker), run.
test1:~$sudo arpspoof -i <interface> -t <Client_IP> <Gateway_IP>
Step-4: On L2(client), ping the gateway (Triggering network activity).
test2:~$ping <Gateway_IP>
Step-5: On L2, check the ARP table.
test2:~$arp -a
Step-6: Use wireshark to capture unsolicited ARP replies from attacker.
Expected result:
L2’s(Client) ARP table shows the attacker’s MAC for the gatewa’s IP.
Wireshark shows repeated ARP replies from Attacker claiming to be Gateway.
Step-7: Wireshark Capture
One-Way ARP spoofing to Gateway/poisoning detection Test Case
To test if the gateway device can be tricked into associating the client’s IP with the attacker’s MAC address, effectively rerouting traffic through the attacker.
Step-1: Connect three devices (Attacker-L1, Client-L2, Gateway-L3) to the same network.
Step-2: Disable firewalls on L1 and L3.
Step-3: On L1(attacker), run.
test1:~$sudo arpspoof -i <interface> -t <Gateway_IP> <Client_IP>
Step-4: On L3(gateway), ping the client (Triggering network activity).
test3:~$ping <Client_IP>
Step-5: On L3, check the ARP table.
test3:~$arp -a
Step-6: Use wireshark to capture unsolicited ARP replies from attacker.
Expected result:
L3’s(Gateway) ARP table shows the attacker’s MAC for the Client’s IP.
Wireshark shows repeated ARP replies from Attacker claiming to be Client.
Step-7: Wireshark Capture
ARP Ping Test Case
To verify that ARP resolution only when needed-i.e., the first ping triggers ARP requests, but subsequent pings use the cached MAC address without sending new ARP packets.
Step-1: Ping the target device from your system
test1:~$ping 192.168.50.122
Step-2: Check the arp table to confirm the MAC address is cached.
test1:~$arp -a
Step-3: Ping the target device from your system again.
test1:~$ping 192.168.50.122
Step-4: Capture traffic using wireshark during both pings.
Expected result:
During the first ping, Wireshark should show ARP request and reply packets, as your system resolves the MAC address of the target.
The ARP table should now contain the target’s IP and MAC.
During the second ping, Wireshark should show only ICMP (ping) packets, with no ARP traffic, since the MAC is already cached.
Step-5: Wireshark Capture
ARP Static Assign MAC and Ping Test Case
To verify that when a static ARP entry is manually added, the system uses if for communication without sending ARP requests.
Step-1: Add a static ARP entry for the target IP and MAC
test1:~$sudo arp -s <target_IP> <target_MAC>Step-2: Verify the ARP table to confirm the entry is present and marked as PERM (permanent)
test1:~$arp -a
Step-3: Ping the target IP.
test1:~$ping <target_IP>Step-4: Capture traffic using wireshark during the ping.
Expected Result:
The ARP table shows the static entry with correct MAC address.
No ARP packets are seen in wireshark during the ping.
Only ICMP request and reply packets are visible, confirming that the system used the static ARP entry directly.
Step-5: Wireshark Capture
Persistent ARP Cache Poisoning (Static ARP Entry Bypass) Test Case
This test whether continuous ARP spoofing can bypass or overwrite a manually added static ARP entry on a victim device, depending on the operating system’s ARP cache behaviour.
Step-1: Enable IP forwarding on the attacker’s device to allow packet routing.
test1:~$sudo sysctl -w net.ipv4.ip_forward=1Step-2: On the client device, add a static ARP entry for the gateway.
test2:~$sudo arp -s <gateway_IP> <gateway_MAC>Step-3: Verify the static ARP entry
test2:~$arp -aStep-4: Start continuous ARP spoofing from the attacker, targeting both the client and the gateway. Run this two commands on different terminals.
test1:~$sudo arpspoof -i <interface> -t <client_IP> <gateway_IP> test1:~$sudo arpspoof -i <interface> -t <gateway_IP> <client_IP>Step-5: On the client, ping the gateway.
test2:~$ping <gateway_IP>Step-6: Capture traffic using wireshark on any device to observe spoofed ARP replies.
Expected result:
Wireshark shows repeated unsolicited ARP replies from the attacker, mapping both the gateway and client IPs to the attacker’s MAC.
On the client side, the static ARP entry may not be overwritten(depending on OS behaviour), but spoofed packets are still visible.
Some systems may show duplicate entries or ignore spoofed replies due to the static entry.
Step-7: Wireshark Capture
ARP poisoning on Non-Existent IP Address Test Case
This test how a client device reacts when an attacker sends spoofed ARP replies from an IP address that dosen’t exist on the network.
Step-1: Choose a non-existent IP address.(e.g., one not currently used in the subnet)
Step-2: On the client , clear the arp cache.
test2:~$sudo ip -s -s neigh flush allStep-3: On the attacker, start spoofing ARP replies for the non-existent IP.
test1:~$sudo arpspoof -i <interface> -t <Client_IP> <Non-Existent_IP>Step-4: On the Client, check the ARP table.
test2:~$arp -a
Step-5: Ping the non-existent IP from the client.
test2:~$ping <Non-Existent_IP>Step-6: Capture traffic using wireshark on attacker or client.
Expected result:
The non-existent IP appears in the client’s ARP table, mapped to the attacker’s MAC address.
Wireshark shows spoofed ARP replies from the attacker for the non-existent IP.
when the client pings the non-existent IP, the ICMP request is redirected to the attacker, who cannot route it, resuting in Destination Host Unrechable.
This confirms taht the attacker can poison the ARP cache even for unused IPs.
Step-7: Wireshark Capture.
ARP “Healing” and Restoration Test Case
To demonstrate how ARP spoofing can be reversed - either manually by sending correct ARP replies or automatically when spoofing stops-allowing devices to restore accurate IP-to-MAC mappings.
Step-1: Enable IP forwarding on the attacker to allow traffic routing
test1:~$ sudo sysctl -w net.ipv4.ip_forward=1
Step-2: Start ARP spoofing from the attacker to poison both the client and the gateway.
test1:~$sudo arpspoof -i <interface> -t <client_IP> <gateway_IP> test1:~$sudo arpspoof -i <interface> -t <gateway_IP> <client_IP>
Step-3: On the client, ping the gateway.
test2:~$ping <gateway_IP>
Step-4: Check the ARP tables on both client and gateway
test2:~$arp -a test3:~$arp -a
Step-5: Stop spoofing on the attcker by pressing Ctrl+C in both spoofing terminals.
Step-6: Recheck ARP tables on client and gateway to observe if correct MAC addresses are restored.
Step-7: Use wireshark to capture traffic during and after spoofing.
Expected result:
While Spoofing is active, ARP tables on both client and gateway show the attacker’s MAC for each other’s IP.
When spoofing is stopped, the attacker sends “healing” ARP replies with the correct MAC addresses.
ARP tables on both the devices are restored to correct mappings.
Wireshark shows a burst of ARP replies with valid MACs after spoofing stops.
Step-8: Wireshark Capture.
Gratuitous ARP Test Case
This test verify that a device sends a Gratuitous ARP when it is assigned a new IP address or reconnects to the network-helping other devices update their ARP tables with the correct MAC-IP mapping.
Step-1: Assign a new IP address to the device or reconnect it to the network.
test1:~$sudo ifconfig <interface> <new_IP> upStep-2: Optionally bring the interface down and up again to simulate reconnection.
test1:~$sudo ip link set <interface> down test1:~$sudo ip link set <interface> upStep-3: Send a Gratuitous ARP manually
test1:~$sudo arping -A -I <interface> <new_IP>Step-4: capture traffic using wireshark on another device or the same device.
Expected result:
Wireshark should show an ARP request where the source and target IP are the same- this is a Gratuitous ARP.
Step-5: Wireshark Capture.
Setup
ARP Request Packet
S.No |
Protocol Packets |
Description |
Size(Bytes) |
|---|---|---|---|
1 |
ARP Request Packet |
Used to request the MAC address corresponding to a known IP address. |
28 |
Hardware Type (HTYPE) |
Specifies type of hardware (1 for ethernet) |
2 |
|
Protocol Type (PTYPE) |
type of protocol (e.g., 0x0800 for IPv4). |
2 |
|
Hardware Address Length (HLEN) |
Length of the hardware address (e.g., 6 for MAC Address) |
1 |
|
Protocol Address Length (PLEN) |
Length of the protocol address (e.g., 4 for IPv4). |
1 |
|
Operation (OPER) |
Specifies the operation the sender is performing: 1 for request, 2 for reply. |
2 |
|
Sender Hardware Address (SHA) |
MAC address of the device sending the ARP packet. |
6 |
|
Sender Protocol Address (SPA) |
IP address of the device sending the ARP packet. |
4 |
|
Target Hardware Address (THA) |
MAC address of the target (set to 0 in ARP requests). |
6 |
|
Target Protocol Address (TPA) |
IP address of the target. |
4 |
ARP Reply Packet
S.No |
Protocol Packets |
Description |
Size(Bytes) |
|---|---|---|---|
2 |
ARP Reply Packet |
Used to respond to an ARP request with the MAC address corresponding to the requested IP address. |
28 |
Hardware Type (HTYPE) |
Specifies type of hardware (1 for ethernet) |
2 |
|
Protocol Type (PTYPE) |
type of protocol (e.g., 0x0800 for IPv4). |
2 |
|
Hardware Address Length (HLEN) |
Length of the hardware address (e.g., 6 for MAC Address). |
1 |
|
Protocol Address Length (PLEN) |
Length of the protocol address (e.g., 4 for IPv4). |
1 |
|
Operation (OPER) |
Specifies the operation the sender is performing: 1 for request, 2 for reply. |
2 |
|
Sender Hardware Address (SHA) |
MAC address of the device sending the ARP packet. |
6 |
|
Sender Protocol Address (SPA) |
IP address of the device sending the ARP packet. |
4 |
|
Target Hardware Address (THA) |
MAC address of the target (set to 0 in ARP requests). |
6 |
|
Target Protocol Address (TPA) |
IP address of the target. |
4 |
S.no |
Use Case |
Description |
|---|---|---|
1 |
IP to MAC Address Mapping |
ARP is primarily used to resolve an IP address to a MAC address so that data can be sent over a local network. |
2 |
Local Network Communication |
Enables devices on the same LAN to communicate by discovering each other’s hardware addresses. |
3 |
Network Troubleshooting |
Tools like arp -a help network administrators diagnose connectivity issues by showing ARP tables. |
4 |
Dynamic Address Resolution |
ARP dynamically updates its table as devices join or leave the network, ensuring up-to-date address mappings. |
5 |
Proxy ARP |
A router can respond to ARP requests on behalf of another device, allowing communication across subnets without reconfiguration. |
6 |
Gratuitous ARP |
Devices send ARP replies without a request to update other devices ARP tables, often used for IP conflict detection or failover. |
7 |
Security Monitoring |
ARP traffic can be monitored to detect spoofing or man-in-the-middle attacks in a network. |
8 |
Virtualization and Cloud |
Virtual machines and containers use ARP to discover and communicate with other virtual or physical devices on the same network. |
S.no |
Feature |
Description |
|---|---|---|
1 |
IP to MAC Resolution |
ARP translates IP addresses into MAC addresses, enabling communication within a local network. |
2 |
Dynamic Address Mapping |
ARP automatically updates its table as devices join or leave the network, ensuring current mappings. |
3 |
Broadcast-Based Requests |
ARP sends broadcast messages to all devices on the LAN to find the MAC address corresponding to an IP address. |
4 |
Caching Mechanism |
ARP stores resolved addresses in a cache to reduce network traffic and speed up future communications. |
5 |
Gratuitous ARP |
A device can send an ARP reply without a request to announce or update its IP-MAC mapping, useful for conflict detection. |
6 |
Stateless Protocol |
ARP does not maintain a session or connection; it simply sends requests and receives replies. |
7 |
No Authentication |
ARP does not verify the authenticity of responses, which makes it vulnerable to spoofing attacks. |
8 |
Essential for IPv4 Networks |
ARP is a fundamental part of IPv4 networking, enabling basic communication between devices on the same subnet. |
IP to MAC Resolution - Testcases
# |
Test Case |
Description |
Expected Result |
|---|---|---|---|
1 |
Resolve known IP |
IP exists in ARP cache |
MAC address returned |
2 |
Resolve unknown IP |
IP not in ARP cache |
ARP request sent |
3 |
ARP reply received |
Valid ARP reply received |
MAC address updated in cache |
4 |
ARP reply timeout |
No reply received |
Resolution fails |
5 |
Broadcast ARP request |
Send ARP request to broadcast address |
All devices receive request |
6 |
Unicast ARP reply |
Target replies directly |
Only sender receives reply |
7 |
Duplicate IP detection |
Two devices respond to same IP |
Conflict detected |
8 |
Static ARP entry |
Manually configured entry |
MAC resolved without request |
9 |
Remove static ARP |
Delete static entry |
Entry removed from cache |
10 |
ARP cache timeout |
Entry expires after timeout |
Entry removed |
11 |
ARP cache refresh |
Re-request after timeout |
New MAC resolved |
12 |
Gratuitous ARP |
Device announces its IP/MAC |
Cache updated |
13 |
ARP spoofing attempt |
Malicious reply with wrong MAC |
Security alert triggered |
14 |
ARP poisoning detection |
Detect inconsistent MACs |
Alert or block |
15 |
ARP request for self |
Device sends ARP for its own IP |
No reply expected |
16 |
ARP request for unreachable IP |
No device owns IP |
No reply |
17 |
ARP request on different subnet |
IP not in local subnet |
No ARP request sent |
18 |
ARP request on VLAN |
Request within VLAN |
MAC resolved |
19 |
ARP request on trunk port |
Tagged VLAN ARP |
MAC resolved correctly |
20 |
ARP request with invalid IP |
Malformed IP address |
Request dropped |
21 |
ARP reply with invalid MAC |
Malformed MAC address |
Reply ignored |
22 |
ARP cache overflow |
Too many entries |
Oldest entries purged |
23 |
ARP cache flush |
Manual flush command |
Cache cleared |
24 |
ARP with proxy enabled |
Router replies on behalf |
Proxy MAC returned |
25 |
ARP with proxy disabled |
No proxy reply |
No MAC returned |
26 |
ARP on loopback interface |
Request on 127.0.0.1 |
No ARP sent |
27 |
ARP on point-to-point link |
No MAC layer |
No ARP used |
28 |
ARP on Wi-Fi |
Wireless ARP request |
MAC resolved |
29 |
ARP on Ethernet |
Wired ARP request |
MAC resolved |
30 |
ARP on bridge interface |
Bridged network |
MAC resolved correctly |
31 |
ARP on bonded interface |
Bonded NICs |
MAC resolved from bond |
32 |
ARP on virtual interface |
Virtual NIC |
MAC resolved |
33 |
ARP on Docker container |
Container IP |
Host resolves MAC |
34 |
ARP on VM |
Virtual machine IP |
MAC resolved |
35 |
ARP on firewall |
Firewall IP |
MAC resolved if allowed |
36 |
ARP on router |
Router IP |
MAC resolved |
37 |
ARP on switch |
Switch IP |
MAC resolved |
38 |
ARP with ACL blocking |
ARP blocked by ACL |
No reply |
39 |
ARP with NAT |
Translated IP |
No ARP for external IP |
40 |
ARP with DHCP |
IP assigned dynamically |
MAC resolved |
41 |
ARP with DHCP reservation |
Static IP via DHCP |
MAC resolved |
42 |
ARP with IP conflict |
Two devices same IP |
Conflict detected |
43 |
ARP with MAC conflict |
Two IPs same MAC |
Warning or error |
44 |
ARP with IPv6 |
Use of NDP instead |
No ARP used |
45 |
ARP with multicast IP |
Multicast address used |
No ARP sent |
46 |
ARP with broadcast IP |
255.255.255.255 |
No ARP sent |
47 |
ARP with zero IP |
0.0.0.0 |
No ARP sent |
48 |
ARP with loop detection |
ARP storm |
Loop detected |
49 |
ARP with security policy |
Policy restricts ARP |
Request blocked |
50 |
ARP with logging enabled |
Log ARP activity |
Logs recorded |
Dynamic Addressing Mapping - Testcases
# |
Test Case |
Description |
Expected Result |
|---|---|---|---|
1 |
Add new device to network |
New device joins |
ARP table updated with new entry |
2 |
Remove device from network |
Device disconnects |
ARP entry times out |
3 |
Device changes IP |
Same MAC, new IP |
ARP table updated |
4 |
Device changes MAC |
Same IP, new MAC |
ARP table updated |
5 |
Device reboots |
MAC re-announced |
ARP table refreshed |
6 |
ARP entry timeout |
Entry expires naturally |
Removed from table |
7 |
ARP entry refresh |
Device sends ARP again |
Entry refreshed |
8 |
ARP cache overflow |
Too many devices |
Oldest entries purged |
9 |
ARP cache flush |
Manual flush |
All entries removed |
10 |
ARP cache rebuild |
After flush |
New entries added dynamically |
11 |
Device joins via DHCP |
IP assigned |
ARP entry created |
12 |
Device joins with static IP |
Manual IP config |
ARP entry created |
13 |
Device leaves abruptly |
No graceful disconnect |
Entry removed after timeout |
14 |
Device moves to new subnet |
IP changes |
Old entry removed, new added |
15 |
Device joins via VPN |
Virtual MAC/IP |
ARP entry created |
16 |
Device joins via Wi-Fi |
Wireless MAC |
ARP entry created |
17 |
Device joins via Ethernet |
Wired MAC |
ARP entry created |
18 |
Device joins via bridge |
Bridged MAC |
ARP entry created |
19 |
Device joins via container |
Docker container |
ARP entry created |
20 |
Device joins via VM |
Virtual machine |
ARP entry created |
21 |
Device joins via mobile hotspot |
Mobile MAC |
ARP entry created |
22 |
Device joins with duplicate IP |
Conflict |
ARP conflict detected |
23 |
Device joins with duplicate MAC |
Conflict |
ARP conflict detected |
24 |
Device joins with spoofed MAC |
Malicious intent |
Security alert triggered |
25 |
Device joins with spoofed IP |
Malicious intent |
ARP poisoning detected |
26 |
Device joins and sends gratuitous ARP |
Announces presence |
ARP table updated |
27 |
Device joins and sends ARP request |
Requests MAC |
ARP table updated |
28 |
Device joins and sends ARP reply |
Responds to request |
ARP table updated |
29 |
Device joins and is silent |
No ARP activity |
No entry created |
30 |
Device joins and is blocked by firewall |
No ARP allowed |
No entry created |
31 |
Device joins and is on different VLAN |
VLAN separation |
No entry created |
32 |
Device joins and is on same VLAN |
VLAN match |
ARP entry created |
33 |
Device joins and is on same subnet |
Subnet match |
ARP entry created |
34 |
Device joins and is on different subnet |
No ARP exchange |
No entry created |
35 |
Device joins and uses proxy ARP |
Router responds |
Proxy MAC added |
36 |
Device joins and uses static ARP |
Manual entry |
No dynamic update |
37 |
Device joins and uses dynamic ARP |
Auto entry |
ARP table updated |
38 |
Device joins and sends malformed ARP |
Invalid packet |
Entry rejected |
39 |
Device joins and sends frequent ARPs |
ARP storm |
Rate limiting triggered |
40 |
Device joins and sends ARP with invalid MAC |
Invalid format |
Entry rejected |
41 |
Device joins and sends ARP with invalid IP |
Invalid format |
Entry rejected |
42 |
Device joins and sends ARP with broadcast IP |
255.255.255.255 |
Entry rejected |
43 |
Device joins and sends ARP with multicast IP |
Multicast not allowed |
Entry rejected |
44 |
Device joins and sends ARP with 0.0.0.0 |
Invalid source |
Entry rejected |
45 |
Device joins and sends ARP with loopback IP |
127.0.0.1 |
Entry rejected |
46 |
Device joins and sends ARP with link-local IP |
169.254.x.x |
Entry created |
47 |
Device joins and sends ARP with APIPA |
Auto IP |
Entry created |
48 |
Device joins and sends ARP with IPv6 |
Uses NDP |
No ARP entry created |
49 |
Device joins and is logged |
Logging enabled |
Entry logged |
50 |
Device joins and triggers alert |
Monitoring enabled |
Alert generated |
Broadcast-Based Requests - Testcases
# |
Test Case |
Description |
Expected Result |
|---|---|---|---|
1 |
Send ARP request for unknown IP |
IP not in cache |
Broadcast ARP sent |
2 |
Send ARP request for known IP |
IP in cache |
No broadcast sent |
3 |
Send ARP request on LAN |
Local subnet |
Broadcast sent to all devices |
4 |
Send ARP request on different subnet |
IP outside subnet |
No ARP broadcast |
5 |
Send ARP request with valid IP |
Proper format |
Broadcast sent |
6 |
Send ARP request with invalid IP |
Malformed IP |
Request dropped |
7 |
Send ARP request with 0.0.0.0 |
Invalid source IP |
Request dropped |
8 |
Send ARP request with 255.255.255.255 |
Broadcast IP |
Request dropped |
9 |
Send ARP request with loopback IP |
127.0.0.1 |
No broadcast sent |
10 |
Send ARP request with multicast IP |
Multicast not supported |
Request dropped |
11 |
Send ARP request with link-local IP |
169.254.x.x |
Broadcast sent |
12 |
Send ARP request with APIPA |
Auto IP |
Broadcast sent |
13 |
Send ARP request with static IP |
Manually configured |
Broadcast sent |
14 |
Send ARP request with DHCP IP |
Dynamically assigned |
Broadcast sent |
15 |
Send ARP request from VM |
Virtual machine |
Broadcast sent on virtual NIC |
16 |
Send ARP request from container |
Docker container |
Broadcast sent |
17 |
Send ARP request from mobile device |
Wi-Fi connected |
Broadcast sent |
18 |
Send ARP request from wired device |
Ethernet connected |
Broadcast sent |
19 |
Send ARP request from bridge interface |
Bridged network |
Broadcast sent |
20 |
Send ARP request from bonded interface |
Bonded NICs |
Broadcast sent |
21 |
Send ARP request from VLAN |
Tagged VLAN |
Broadcast within VLAN |
22 |
Send ARP request from trunk port |
Multiple VLANs |
Broadcast in correct VLAN |
23 |
Send ARP request with spoofed IP |
Malicious intent |
Request logged or blocked |
24 |
Send ARP request with spoofed MAC |
Malicious intent |
Request logged or blocked |
25 |
Send ARP request with large payload |
Oversized packet |
Request dropped |
26 |
Send ARP request with minimal payload |
Valid format |
Broadcast sent |
27 |
Send ARP request with corrupted checksum |
Invalid packet |
Request dropped |
28 |
Send ARP request during network congestion |
High traffic |
Broadcast delayed or dropped |
29 |
Send ARP request during ARP storm |
Excessive ARP |
Rate limiting triggered |
30 |
Send ARP request with logging enabled |
Monitor ARP traffic |
Request logged |
31 |
Send ARP request with firewall enabled |
ARP allowed |
Broadcast sent |
32 |
Send ARP request with firewall blocking ARP |
ARP blocked |
Request dropped |
33 |
Send ARP request with ACL blocking IP |
IP restricted |
Request dropped |
34 |
Send ARP request with ACL allowing IP |
IP permitted |
Broadcast sent |
35 |
Send ARP request with proxy ARP enabled |
Router responds |
Proxy reply received |
36 |
Send ARP request with proxy ARP disabled |
No proxy |
Broadcast sent |
37 |
Send ARP request with static ARP entry |
Entry exists |
No broadcast sent |
38 |
Send ARP request with dynamic ARP entry |
Entry expired |
Broadcast sent |
39 |
Send ARP request with ARP cache full |
No space |
Old entries purged |
40 |
Send ARP request with ARP cache empty |
No entries |
Broadcast sent |
41 |
Send ARP request with ARP cache flush |
Manual flush |
Broadcast sent |
42 |
Send ARP request with duplicate IPs |
Conflict |
Multiple replies |
43 |
Send ARP request with duplicate MACs |
Conflict |
Inconsistent replies |
44 |
Send ARP request with no response |
No device owns IP |
No reply received |
45 |
Send ARP request with valid response |
Device replies |
MAC address resolved |
46 |
Send ARP request with delayed response |
Slow network |
MAC resolved after delay |
47 |
Send ARP request with multiple responses |
IP conflict |
Alert triggered |
48 |
Send ARP request with security monitoring |
IDS/IPS active |
Request analyzed |
49 |
Send ARP request with SNMP monitoring |
SNMP trap enabled |
ARP event logged |
50 |
Send ARP request with network analyzer |
Wireshark running |
Broadcast visible in capture |
Caching Mechanism - Testcases
# |
Test Case |
Description |
Expected Result |
|---|---|---|---|
1 |
Cache new ARP entry |
Resolve unknown IP |
Entry added to cache |
2 |
Retrieve from cache |
IP already resolved |
MAC returned from cache |
3 |
Cache timeout |
Entry expires |
Entry removed |
4 |
Refresh cache entry |
Re-resolve IP |
Entry updated |
5 |
Flush ARP cache |
Manual flush |
All entries removed |
6 |
Static ARP entry |
Manually added |
Entry persists |
7 |
Dynamic ARP entry |
Auto-resolved |
Entry added temporarily |
8 |
Cache overflow |
Too many entries |
Oldest entries purged |
9 |
Duplicate IP in cache |
Same IP, different MAC |
Conflict detected |
10 |
Duplicate MAC in cache |
Same MAC, different IP |
Entry updated or flagged |
11 |
Cache entry after reboot |
System restart |
Cache cleared |
12 |
Cache entry after sleep |
Wake from sleep |
Cache retained or refreshed |
13 |
Cache entry after network reconnect |
Interface down/up |
Cache refreshed |
14 |
Cache entry after DHCP renewal |
IP reassigned |
Entry updated |
15 |
Cache entry after IP conflict |
Conflict detected |
Entry removed or flagged |
16 |
Cache entry after spoofed ARP |
Malicious update |
Entry rejected or logged |
17 |
Cache entry with logging enabled |
Monitor ARP cache |
Entry logged |
18 |
Cache entry with SNMP monitoring |
SNMP trap |
Entry change reported |
19 |
Cache entry with security policy |
Policy restricts updates |
Entry blocked |
20 |
Cache entry with ACL |
IP/MAC restricted |
Entry not added |
21 |
Cache entry with proxy ARP |
Router responds |
Proxy MAC cached |
22 |
Cache entry with VLAN |
VLAN-specific cache |
Entry added per VLAN |
23 |
Cache entry with trunk port |
Tagged VLANs |
Entry added correctly |
24 |
Cache entry with bridge interface |
Bridged network |
Entry added |
25 |
Cache entry with bonded NICs |
Bonded interface |
Entry added |
26 |
Cache entry with virtual NIC |
VM or container |
Entry added |
27 |
Cache entry with Wi-Fi |
Wireless device |
Entry added |
28 |
Cache entry with Ethernet |
Wired device |
Entry added |
29 |
Cache entry with mobile hotspot |
Mobile device |
Entry added |
30 |
Cache entry with Docker container |
Container IP |
Entry added |
31 |
Cache entry with VM |
Virtual machine |
Entry added |
32 |
Cache entry with IPv6 |
NDP used |
No ARP cache entry |
33 |
Cache entry with loopback IP |
127.0.0.1 |
No entry added |
34 |
Cache entry with broadcast IP |
255.255.255.255 |
No entry added |
35 |
Cache entry with multicast IP |
Multicast address |
No entry added |
36 |
Cache entry with 0.0.0.0 |
Invalid IP |
No entry added |
37 |
Cache entry with malformed ARP |
Invalid packet |
Entry rejected |
38 |
Cache entry with large ARP table |
Stress test |
Performance monitored |
39 |
Cache entry with frequent updates |
High churn |
Cache handles updates |
40 |
Cache entry with ARP storm |
Excessive traffic |
Rate limiting triggered |
41 |
Cache entry with manual override |
Static entry replaces dynamic |
Static entry retained |
42 |
Cache entry with same IP, new MAC |
Device replaced |
Entry updated |
43 |
Cache entry with same MAC, new IP |
Device reconfigured |
New entry added |
44 |
Cache entry with no response |
No reply to ARP |
No entry added |
45 |
Cache entry with delayed response |
Slow network |
Entry added after delay |
46 |
Cache entry with multiple responses |
IP conflict |
Alert triggered |
47 |
Cache entry with audit logging |
Track changes |
Logs recorded |
48 |
Cache entry with monitoring tool |
Wireshark or similar |
Entry visible in logs |
49 |
Cache entry with system policy |
OS-level ARP rules |
Entry behavior enforced |
50 |
Cache entry with network restart |
Switch/router reboot |
Cache rebuilt |
Gratuitous ARP - Testcases
# |
Test Case |
Description |
Expected Result |
|---|---|---|---|
1 |
Send gratuitous ARP on boot |
Device starts up |
ARP reply broadcasted |
2 |
Send gratuitous ARP on IP change |
IP address updated |
ARP reply broadcasted |
3 |
Send gratuitous ARP on MAC change |
MAC address updated |
ARP reply broadcasted |
4 |
Send gratuitous ARP manually |
Admin triggers |
ARP reply broadcasted |
5 |
Receive gratuitous ARP |
Other device sends |
ARP cache updated |
6 |
Detect IP conflict |
Duplicate IP detected |
Conflict alert triggered |
7 |
Detect MAC conflict |
Duplicate MAC detected |
Conflict alert triggered |
8 |
Ignore unsolicited ARP |
Policy blocks updates |
ARP reply ignored |
9 |
Accept unsolicited ARP |
Policy allows updates |
ARP cache updated |
10 |
Log gratuitous ARP |
Logging enabled |
Event logged |
11 |
Block gratuitous ARP |
Firewall rule |
ARP reply dropped |
12 |
Allow gratuitous ARP |
Firewall allows |
ARP reply processed |
13 |
Send gratuitous ARP with static IP |
Manual IP config |
ARP reply sent |
14 |
Send gratuitous ARP with DHCP |
IP assigned |
ARP reply sent |
15 |
Send gratuitous ARP with spoofed MAC |
Malicious intent |
Alert triggered |
16 |
Send gratuitous ARP with spoofed IP |
Malicious intent |
Alert triggered |
17 |
Send gratuitous ARP with invalid MAC |
Malformed packet |
Dropped |
18 |
Send gratuitous ARP with invalid IP |
Malformed packet |
Dropped |
19 |
Send gratuitous ARP with 0.0.0.0 |
Invalid source |
Dropped |
20 |
Send gratuitous ARP with 255.255.255.255 |
Broadcast IP |
Dropped |
21 |
Send gratuitous ARP with loopback IP |
127.0.0.1 |
Dropped |
22 |
Send gratuitous ARP with multicast IP |
Not supported |
Dropped |
23 |
Send gratuitous ARP with APIPA |
169.254.x.x |
ARP reply sent |
24 |
Send gratuitous ARP from VM |
Virtual machine |
ARP reply sent |
25 |
Send gratuitous ARP from container |
Docker container |
ARP reply sent |
26 |
Send gratuitous ARP from mobile device |
Wi-Fi connected |
ARP reply sent |
27 |
Send gratuitous ARP from wired device |
Ethernet connected |
ARP reply sent |
28 |
Send gratuitous ARP on reconnect |
Interface re-enabled |
ARP reply sent |
29 |
Send gratuitous ARP on resume |
Wake from sleep |
ARP reply sent |
30 |
Send gratuitous ARP on DHCP renewal |
Lease renewed |
ARP reply sent |
31 |
Send gratuitous ARP on failover |
Redundant system takes over |
ARP reply sent |
32 |
Send gratuitous ARP on IP reassignment |
New IP assigned |
ARP reply sent |
33 |
Send gratuitous ARP on MAC reassignment |
New MAC assigned |
ARP reply sent |
34 |
Send gratuitous ARP with VLAN tagging |
Tagged VLAN |
ARP reply sent in VLAN |
35 |
Send gratuitous ARP on trunk port |
Multiple VLANs |
Sent in correct VLAN |
36 |
Send gratuitous ARP on bridge interface |
Bridged network |
ARP reply sent |
37 |
Send gratuitous ARP on bonded NICs |
Bonded interface |
ARP reply sent |
38 |
Send gratuitous ARP with proxy ARP |
Router responds |
Proxy MAC updated |
39 |
Send gratuitous ARP with static ARP entry |
Entry exists |
No update |
40 |
Send gratuitous ARP with dynamic ARP entry |
Entry updated |
Cache refreshed |
41 |
Send gratuitous ARP with ARP cache full |
No space |
Old entry purged |
42 |
Send gratuitous ARP with ARP cache empty |
No entries |
Entry added |
43 |
Send gratuitous ARP with ARP cache flush |
Cache cleared |
Entry added |
44 |
Send gratuitous ARP with monitoring tool |
Wireshark or similar |
Packet visible |
45 |
Send gratuitous ARP with SNMP monitoring |
SNMP trap |
Event logged |
46 |
Send gratuitous ARP with IDS/IPS |
Security system active |
Event analyzed |
47 |
Send gratuitous ARP with ACL |
IP/MAC restricted |
ARP reply blocked |
48 |
Send gratuitous ARP with system policy |
OS-level rule |
Behavior enforced |
49 |
Send gratuitous ARP with network restart |
Switch/router reboot |
ARP reply sent |
50 |
Send gratuitous ARP with high frequency |
Repeated sends |
Rate limiting triggered |
Stateless Protocol - Testcases
# |
Test Case |
Description |
Expected Result |
|---|---|---|---|
1 |
Send ARP request |
No prior session |
Request sent without connection |
2 |
Receive ARP reply |
No session tracking |
Reply processed independently |
3 |
Multiple ARP requests |
Sent in sequence |
Each handled separately |
4 |
ARP request without reply |
No retry mechanism |
No session maintained |
5 |
ARP reply without request |
Gratuitous ARP |
Reply accepted if valid |
6 |
ARP request from new device |
No history |
Request processed |
7 |
ARP request from known device |
No session reuse |
Treated as new request |
8 |
ARP request with invalid MAC |
No session validation |
Request dropped |
9 |
ARP request with invalid IP |
No session validation |
Request dropped |
10 |
ARP reply with spoofed MAC |
No session check |
May be accepted |
11 |
ARP reply with spoofed IP |
No session check |
May be accepted |
12 |
ARP request after timeout |
Previous entry expired |
New request sent |
13 |
ARP request after reboot |
No session memory |
New request sent |
14 |
ARP reply after delay |
No session timeout |
Reply still processed |
15 |
ARP request with no state tracking |
Stateless by design |
Request processed |
16 |
ARP reply with no state tracking |
Stateless by design |
Reply processed |
17 |
ARP request with duplicate IP |
No session awareness |
Conflict may occur |
18 |
ARP request with duplicate MAC |
No session awareness |
Conflict may occur |
19 |
ARP request with logging enabled |
Stateless behavior logged |
Logs show no session |
20 |
ARP request with firewall |
Stateless nature preserved |
Request allowed/blocked |
21 |
ARP request with ACL |
Stateless nature preserved |
Request allowed/blocked |
22 |
ARP request with IDS/IPS |
Stateless detection |
Anomaly flagged |
23 |
ARP request with spoofed source |
No session validation |
May be accepted |
24 |
ARP reply with spoofed destination |
No session validation |
May be accepted |
25 |
ARP request with malformed packet |
No session check |
Dropped |
26 |
ARP reply with malformed packet |
No session check |
Dropped |
27 |
ARP request with VLAN tagging |
Stateless per VLAN |
Request processed |
28 |
ARP request on trunk port |
Stateless per VLAN |
Request processed |
29 |
ARP request on bridge interface |
Stateless behavior |
Request processed |
30 |
ARP request on bonded NICs |
Stateless behavior |
Request processed |
31 |
ARP request from VM |
Stateless behavior |
Request processed |
32 |
ARP request from container |
Stateless behavior |
Request processed |
33 |
ARP request from mobile device |
Stateless behavior |
Request processed |
34 |
ARP request from wired device |
Stateless behavior |
Request processed |
35 |
ARP request with static IP |
Stateless behavior |
Request processed |
36 |
ARP request with DHCP IP |
Stateless behavior |
Request processed |
37 |
ARP request with proxy ARP |
Stateless behavior |
Proxy reply processed |
38 |
ARP request with static ARP entry |
No request sent |
Cache used |
39 |
ARP request with dynamic ARP entry |
Entry expired |
Stateless request sent |
40 |
ARP request with cache flush |
Stateless request sent |
New entry added |
41 |
ARP request with no response |
Stateless behavior |
No retry |
42 |
ARP request with delayed response |
Stateless behavior |
Reply processed |
43 |
ARP request with multiple responses |
Stateless behavior |
Conflict detected |
44 |
ARP request with monitoring tool |
Stateless packets visible |
No session info |
45 |
ARP request with SNMP monitoring |
Stateless behavior logged |
Trap generated |
46 |
ARP request with system policy |
Stateless behavior enforced |
Policy applied |
47 |
ARP request with network restart |
Stateless behavior resumes |
Requests sent anew |
48 |
ARP request with high frequency |
Stateless behavior |
Rate limiting may apply |
49 |
ARP request with spoofed reply |
Stateless behavior |
May be accepted |
50 |
ARP request with no connection state |
Stateless protocol |
Request processed independently |
No Authentication - Testcases
# |
Test Case |
Description |
Expected Result |
|---|---|---|---|
1 |
Accept ARP reply from unknown source |
No prior request |
Reply accepted |
2 |
Accept ARP reply with spoofed MAC |
Malicious MAC |
Entry updated |
3 |
Accept ARP reply with spoofed IP |
Malicious IP |
Entry updated |
4 |
Accept unsolicited ARP reply |
No request sent |
Entry updated |
5 |
Accept duplicate ARP reply |
Same IP, different MAC |
Entry overwritten |
6 |
Accept ARP reply from attacker |
Attacker sends fake reply |
Entry poisoned |
7 |
Accept ARP reply with invalid checksum |
Malformed packet |
May be accepted |
8 |
Accept ARP reply with broadcast MAC |
Invalid MAC |
Entry added |
9 |
Accept ARP reply with multicast MAC |
Invalid MAC |
Entry added |
10 |
Accept ARP reply with 0.0.0.0 IP |
Invalid IP |
Entry added |
11 |
Accept ARP reply with 255.255.255.255 IP |
Broadcast IP |
Entry added |
12 |
Accept ARP reply with loopback IP |
127.0.0.1 |
Entry added |
13 |
Accept ARP reply with link-local IP |
169.254.x.x |
Entry added |
14 |
Accept ARP reply with spoofed gateway |
Attacker mimics gateway |
Entry updated |
15 |
Accept ARP reply with spoofed DNS |
Attacker mimics DNS |
Entry updated |
16 |
Accept ARP reply with spoofed DHCP |
Attacker mimics DHCP |
Entry updated |
17 |
Accept ARP reply with spoofed proxy |
Attacker mimics proxy |
Entry updated |
18 |
Accept ARP reply with spoofed server |
Attacker mimics server |
Entry updated |
19 |
Accept ARP reply with spoofed client |
Attacker mimics client |
Entry updated |
20 |
Accept ARP reply with spoofed MAC/IP pair |
Both spoofed |
Entry updated |
21 |
Accept ARP reply with no validation |
No checks performed |
Entry accepted |
22 |
Accept ARP reply with no session |
Stateless protocol |
Entry accepted |
23 |
Accept ARP reply with no authentication |
No identity check |
Entry accepted |
24 |
Accept ARP reply with no encryption |
Plaintext packet |
Entry accepted |
25 |
Accept ARP reply with no integrity check |
No hash or signature |
Entry accepted |
26 |
Accept ARP reply with no origin verification |
Source not verified |
Entry accepted |
27 |
Accept ARP reply with no MAC filtering |
No MAC whitelist |
Entry accepted |
28 |
Accept ARP reply with no IP filtering |
No IP whitelist |
Entry accepted |
29 |
Accept ARP reply with no ARP inspection |
No security feature |
Entry accepted |
30 |
Accept ARP reply with no logging |
No audit trail |
Entry accepted silently |
31 |
Accept ARP reply with no alerting |
No IDS/IPS |
Entry accepted silently |
32 |
Accept ARP reply with no rate limiting |
Flood of replies |
All accepted |
33 |
Accept ARP reply with spoofed MAC in VLAN |
VLAN attack |
Entry updated |
34 |
Accept ARP reply with spoofed MAC on trunk |
Trunk port attack |
Entry updated |
35 |
Accept ARP reply with spoofed MAC on bridge |
Bridged network |
Entry updated |
36 |
Accept ARP reply with spoofed MAC on bonded NIC |
Bonded interface |
Entry updated |
37 |
Accept ARP reply with spoofed MAC from VM |
Virtual attacker |
Entry updated |
38 |
Accept ARP reply with spoofed MAC from container |
Container attacker |
Entry updated |
39 |
Accept ARP reply with spoofed MAC from mobile |
Mobile attacker |
Entry updated |
40 |
Accept ARP reply with spoofed MAC from wired device |
Wired attacker |
Entry updated |
41 |
Accept ARP reply with spoofed MAC from Wi-Fi |
Wireless attacker |
Entry updated |
42 |
Accept ARP reply with spoofed MAC from same subnet |
Local attacker |
Entry updated |
43 |
Accept ARP reply with spoofed MAC from different subnet |
Misconfigured network |
Entry updated |
44 |
Accept ARP reply with spoofed MAC from same VLAN |
VLAN attacker |
Entry updated |
45 |
Accept ARP reply with spoofed MAC from different VLAN |
VLAN hopping |
Entry updated |
46 |
Accept ARP reply with spoofed MAC during ARP storm |
Flood attack |
Entry updated |
47 |
Accept ARP reply with spoofed MAC during failover |
Redundant system spoofed |
Entry updated |
48 |
Accept ARP reply with spoofed MAC during DHCP lease |
Lease hijack |
Entry updated |
49 |
Accept ARP reply with spoofed MAC during login |
Session hijack |
Entry updated |
50 |
Accept ARP reply with spoofed MAC during file transfer |
MITM attack |
Entry updated |
Essential for IPv4 Networks - Testcases
# |
Test Case |
Description |
Expected Result |
|---|---|---|---|
1 |
IPv4 device sends packet to local IP |
Same subnet |
ARP used to resolve MAC |
2 |
IPv4 device sends packet to remote IP |
Different subnet |
ARP resolves gateway MAC |
3 |
IPv4 device starts up |
Joins network |
Sends ARP to resolve peers |
4 |
IPv4 device receives ARP request |
Target IP matches |
Sends ARP reply |
5 |
IPv4 device receives ARP reply |
Valid response |
Updates ARP cache |
6 |
IPv4 device with static IP |
No DHCP |
ARP still used |
7 |
IPv4 device with DHCP |
Dynamic IP |
ARP used after lease |
8 |
IPv4 device with no ARP support |
ARP disabled |
Communication fails |
9 |
IPv4 device on same subnet |
Peer-to-peer |
ARP resolves MAC |
10 |
IPv4 device on different subnet |
Needs router |
ARP resolves router MAC |
11 |
IPv4 ping to local IP |
ICMP echo |
ARP resolves MAC |
12 |
IPv4 TCP connection to local IP |
TCP handshake |
ARP resolves MAC |
13 |
IPv4 UDP packet to local IP |
Stateless protocol |
ARP resolves MAC |
14 |
IPv4 DNS query to local server |
DNS over UDP |
ARP resolves MAC |
15 |
IPv4 HTTP request to local server |
TCP-based |
ARP resolves MAC |
16 |
IPv4 FTP session to local server |
TCP-based |
ARP resolves MAC |
17 |
IPv4 SSH session to local server |
Secure shell |
ARP resolves MAC |
18 |
IPv4 device joins LAN |
New device |
ARP used to discover peers |
19 |
IPv4 device leaves LAN |
Removed |
ARP entry expires |
20 |
IPv4 device reboots |
Rejoins network |
ARP used again |
21 |
IPv4 device changes IP |
New address |
ARP used to update peers |
22 |
IPv4 device changes MAC |
New NIC |
ARP used to update peers |
23 |
IPv4 device sends broadcast |
ARP request |
All devices receive |
24 |
IPv4 device sends unicast |
Known MAC |
No ARP needed |
25 |
IPv4 device sends multicast |
Special MAC |
No ARP used |
26 |
IPv4 device sends to 127.0.0.1 |
Loopback |
No ARP used |
27 |
IPv4 device sends to 0.0.0.0 |
Invalid |
No ARP used |
28 |
IPv4 device sends to 255.255.255.255 |
Broadcast |
No ARP used |
29 |
IPv4 device sends to 169.254.x.x |
Link-local |
ARP used |
30 |
IPv4 device sends to 192.168.x.x |
Private IP |
ARP used |
31 |
IPv4 device sends to public IP |
Routed |
ARP resolves gateway MAC |
32 |
IPv4 device with firewall |
ARP allowed |
Communication works |
33 |
IPv4 device with firewall blocking ARP |
ARP blocked |
Communication fails |
34 |
IPv4 device with VLAN |
Same VLAN |
ARP used |
35 |
IPv4 device with different VLAN |
Routed |
ARP resolves gateway MAC |
36 |
IPv4 device with proxy ARP |
Router responds |
ARP reply received |
37 |
IPv4 device with static ARP |
Manual entry |
No ARP request sent |
38 |
IPv4 device with dynamic ARP |
Auto entry |
ARP request sent |
39 |
IPv4 device with ARP cache flush |
Cache cleared |
ARP request sent |
40 |
IPv4 device with ARP cache full |
New entry needed |
Oldest purged |
41 |
IPv4 device with ARP spoofing |
Malicious reply |
Entry poisoned |
42 |
IPv4 device with ARP inspection |
Security enabled |
Spoofing blocked |
43 |
IPv4 device with SNMP monitoring |
ARP activity logged |
Events recorded |
44 |
IPv4 device with IDS/IPS |
ARP monitored |
Anomalies flagged |
45 |
IPv4 device with DHCP renewal |
Lease updated |
ARP used |
46 |
IPv4 device with failover |
New MAC/IP |
ARP used |
47 |
IPv4 device with NAT |
Internal IP |
ARP used locally |
48 |
IPv4 device with VPN |
Tunnel endpoint |
ARP used on local LAN |
49 |
IPv4 device with Docker |
Container IP |
ARP used |
50 |
IPv4 device with VM |
Virtual NIC |
ARP used |
Reference links