Hi not sure for the life of me what I've done as this was working, basically when entering "bootp" filter to capture DHCP data I get nothing, the data is shown as ARP as opposed to offer, ACK etc and I believe this is why it's not being shown with a bootp filter, if I run a trace from another PC this is shown correctly as offer, ACK etc. I have uninstalled the application including personal settings and reinstalled but this has not cleared the issue not sure if this is a red herring but if I "Analyze" the packet and "Decode as" I don't get the same options (tabs) as on a working machine, my operationg system is windows 7. Any help would be greatly appreciated. 28 16.703822 Dell_85:3a:78 Netgear_3e:eb:44 ARP 42 192.168.254.8 is at f0:4d:a2:85:3a:78 asked 21 Oct '11, 06:18  livewired |
4 Answers:
Do you have capture filters applied? Are you sure your machine does get an offer at all? There may be an IP address conflict preventing the DHCP server to offer you anything. Hence the ARPs. answered 21 Oct '11, 07:34  Jaap ♦ |
are you entering the filter in the capture options dialog or the filter box once you have started the capture?. if its the first one, clear the capture filter box in the capture options dialog and then enter bootp in the filter textbox just below the menu & buttons and hit apply. answered 21 Oct '11, 08:30  tobbe Hi sorry there's some confusion here the above example is with no filter applied, as stated on another PC the trace shows DHCP XXXXX instead of ARP, as the trace shows ARP instead of the various DHCP offer, accept, reject etc it fails to show if a bootp filter is applied. It's a shame I can't screen capture on here picture paints a thousand words etc (21 Oct '11, 08:40) livewired |
As Guy states, it is an ARP packet what you see. What you don't see is the DHCP offer being unicast to the requesting host. That is caused by your capture setup that only exposes broadcast, some multicast and link local frames. This is what switching is all about. You'll need to use the monitor port to see it. answered 21 Oct '11, 14:18 Jaap ♦ |
Are you sure your machine does get an offer at all? There may be an IP address conflict preventing the DHCP server to offer you anything. Hence the ARPs. IP address conflict occurs when two or more computers on the same LAN network end up with the same IP address. When this occurs, both computers end up not being able to connect to network.There are a few ways in which this problem can be fixed.If it is Static IP request your ISP for a change of IP.If it is a Dynamic IP you can try resetting your modem by switching ON and OFF the modem or open the command prompt and type "ipconfig /release," which dumps the automatic address it had, and then "ipconfig /renew," which gets a new address.To check for the change in IP you can visit http://www.ip-details.com which gives your public IP when you visit the site. answered 13 Jun '13, 23:32  frozengal |
Hi thank you for your answer, I have no filters applied (unless when trying to apply the bootp one)I am not trying to capture my PC obtaining DHCP and through the logs I can read that there is an offer confirming the IP Address is correct and that there are no conflicts, it's just that in the Protocol description it is identified as "ARP" as opposed to DHCP "Offer" or "ACK".
Just to explain myself better this is not a network issue I'm having but a wireshark issue.
i.e. the bellow should have DHCP XXXX instead of ARP
28 16.703822 Dell_85:3a:78 Netgear_3e:eb:44 ARP 42 192.168.254.8 is at f0:4d:a2:85:3a:78
The packet in question says ARP because it's an ARP packet. It's not a DHCP packet. Trust me.
Yes, this is either a network issue or a Wireshark capturing issue wherein it is somehow not capturing the DHCP packets. It is not an issue of Wireshark misidentifying DHCP packets as ARP packets.
On the machine where you are capturing the DHCP packets, are they being sent to or from the machine that's not seeing the DHCP packets, are they being sent as broadcasts or multicasts from some other machine, or are they being sent between other machines?