 | 1 | initial version |
In your trace I see DHCP requests from the mentioned iPad (filter on dhcp.option.hostname == "Abids-iPad"). Then looking at DHCP and ARP traffic to/from the mac-addess of the iPad (filter on eth.addr == c4:c3:6b:0e:dd:e2 && (dhcp || arp)), I can see that the iPad declines the use of the offered address. This is done after sending ARP probes. I do not see responses to the ARP probes, but based on the DHCP-DECLINE, I assume there was another device on the network that is using the address 192.168.178.100 which sent ARP responses directly to the iPad.
The DHCP-DECLINE message should tell the DHCP server to NOT hand out this address anymore, but the DHCP server keeps handing out this address to the iPad. This is a BUG in the DHCP server as far as I can tell. So the root cause is a duplicate address on the network that should be resolved by the DHCP-DECLINE messages, but because of the BUG on the DHCP server, it prevents the iPad from getting an IP address.
To find the device with the IP address 192.168.178.100, you can disable WiFi on the iPad and then ping 192.168.178.100 and look at the ARP entry for it in your ARP table. Then look for that mac address on your network (for finding out the vendor OUI for that mac-address, visit https://www.wireshark.org/tools/oui-lookup.html)
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
