- Posts: 161
- Thank you received: 0
ARP traffic in Wireshark is not as I expected
17 years 1 month ago #23791
by SteveP
ARP traffic in Wireshark is not as I expected was created by SteveP
Hi Everyone
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!).
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!).
17 years 1 month ago #23800
by Smurf
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx
Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
Replied by Smurf on topic Re: ARP traffic in Wireshark is not as I expected
Mine does the same. It doesn't appear to be showing the CRC
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx
Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
17 years 1 month ago #23814
by TheBishop
Replied by TheBishop on topic Re: ARP traffic in Wireshark is not as I expected
Hmm. Never noticed that. Is that a bug?
17 years 1 month ago #23826
by Smurf
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx
Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
Replied by Smurf on topic Re: ARP traffic in Wireshark is not as I expected
It looks more like the padding is missing. This could be due to a vulnerability in some tcp/ip stacks where data can leak through the padding ?
xforce.iss.net/xforce/xfdb/10996
xforce.iss.net/xforce/xfdb/10996
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx
Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
17 years 1 month ago #23827
by Smurf
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx
Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
Replied by Smurf on topic Re: ARP traffic in Wireshark is not as I expected
Also, Wireshark doesn't display the FCS see
wiki.wireshark.org/Ethernet
Not sure where the rest as gone (must be padding)
Not sure where the rest as gone (must be padding)
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx
Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
17 years 1 month ago #23829
by SteveP
Replied by SteveP on topic Re: ARP traffic in Wireshark is not as I expected
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.
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.
Time to create page: 0.130 seconds