I'm in the middle of some network courses (CompTIA N+ and CCNA) and my main area of interest is network security. I have XP Pro SP2 connected via wireless to an ADSL router and I've examined traffic on my network with WinDump and Wireshark. I understand that the minimum and maximum length of an ethernet frame is 64 and 1518 bytes respectively (destination MAC = 6, source MAC = 6, type = 2, data = 46 to 1500 and CRC = 4).
I launched Wireshark then ran some commands at the CMD console and navigated to some new web pages. I examined the capture and, in particular, ARP in the protocol column. I was surprised to see that each frame was reported as "42 bytes on wire, 42 bytes captured" and the protocols in the frame were reported as "eth:arp" (I checked carefully and counted the number of bytes in the frame as 42 decimal rather than 42 hex). I was under the impression that, if the data section of the ethernet frame is less than 46 bytes, padding is added to fill up to 46 bytes.
I've seen a video by Laura Chappell (expert at Wireshark University) which shows an ethernet/arp frame and it does show padding to fill the ethernet data section to the minimum necessary.
I have the most recent version of Wireshark (0.99.6a) and have installed WinPcap version 4.0.1 which the Wireshark installation recommended.
Does anyone have any idea why the padding isn't shown on my system?
One final things is I realise that the preamble and CRC of the ethernet frame aren't displayed (confirmed in the Wireshark wiki). Is there any way that I could see this information? It's of no practical value, I'd just like to know if it can be displayed in some way.
Thanks for your time (and patience!).
Re: ARP traffic in Wireshark is not as I expected
10 years 10 months ago #23800
Thank you for the feedback. Here's the video by Laura Chappell (hxxp://www.wireshark.org/news/20070924.html) which shows padding (zeros as well as faulty padding, as concurred by Smurf).
I don't know which version of Wireshark is used in the video. I wonder if anyone has a different version (or a previous version of Ethereal) to check if this behaviour is only demonstrated in Wireshark v0.99.6a and Winpcap v4.0.1? If eveything's OK with a different version, I think I'll report it as a bug which they can investigate.