Sign in to follow this  
Followers 0
Gregor

Wireshark or Ethereal capture

17 posts in this topic

I have XP Pro SP2 connected wirelessly to an ADSL router. I've been using WinDump and Wireshark to capture my own network traffic and have seen something which I don't understand.

As far as I'm aware, an ethernet frame contains up to 1518 bytes (header/trailer = 18 and payload = up to 1500). If the payload is less than 46 bytes, padding is appended to the end of the data so the smallest ethernet frame is 64 bytes. I captured some ARP traffic and also following ping 192.168.0.1 -l 1 (to send just one byte to my router). I was surprised to see the ARP traffic had only 42 (decimal) bytes and the ICMP had only 43 bytes. There was no padding appended to the end of the data.

I wondered if it was my wireless network card so I tried it on a different PC (wired, W2K) and got exactly the same result. The only common hardware is the router.

I've scouted around for an explanation but zilch. I have the most recent version of Wireshark and the version of Wincap that it recommended. I wonder if someone could repeat my experiment to see what results they get? I don't have an earlier version of the software (or Ethereal) so don't know if it's a bug or "facility" in the current Wireshark. If someone still has Ethereal, I wonder if they could try it to see if padding is displayed?

Finally, I saw an educational video from Wireshark University which captured ARP traffic with Wireshark (I don't know if it's the same version as mine) and it *did* display padding to fill the frame to 64 bytes. I don't know if there's a way to set Wireshark to ignore the padding.

Thanks for your time.

0

Share this post


Link to post
Share on other sites

i think i have ethereal installed on a computer at my house i don't use much. ill check it out later today or tommorrow.

0

Share this post


Link to post
Share on other sites

When I capture with Wireshark, I don't get the preamble, SFD, or FCS. I only get the source, destination, type, and payload. Minimum length of this should be 6 + 6 + 2 + 46 = 60. The ARP packets I'm seeing here are padded out to meet this, however I have noticed some frames (TCP ACK's mostly) that only have 40 bytes of payload, resulting in an Ethernet frame that's only 54 bytes (without the preamble, SFD, or FCS).

0

Share this post


Link to post
Share on other sites

Thanks guys for the quick responses. I look forward to learning what happens with Ethereal, as opposed to Wireshark.

As for the preamble and FCS, the Wireshark wiki states that these are not displayed and it's something to do with the network driver. I'm happy not to be able to see them but I'm somewhat miffed that, on some systems, ARP traffic *is* padded! Having said that, it doesn't seem entirely consistent if some Ethernet frames (TCP ACKs, as described) are shown as less than 60 (or 64 if the FCS is included in the calculation). As a matter of interest, which version of Wireshark/Winpcap did you use? Mine is v0.99.6a (SVN Rev 22276)/v4.0.1 respectively on XP Pro SP2. I just wonder if there's a bug in Wireshark which results in the inconsistencies. I'll wait for more feedback from folks here (hopefully!) before I approach the Wireshark guys and hilight this inconsistency.

0

Share this post


Link to post
Share on other sites
Thanks guys for the quick responses. I look forward to learning what happens with Ethereal, as opposed to Wireshark.

As for the preamble and FCS, the Wireshark wiki states that these are not displayed and it's something to do with the network driver. I'm happy not to be able to see them but I'm somewhat miffed that, on some systems, ARP traffic *is* padded! Having said that, it doesn't seem entirely consistent if some Ethernet frames (TCP ACKs, as described) are shown as less than 60 (or 64 if the FCS is included in the calculation). As a matter of interest, which version of Wireshark/Winpcap did you use? Mine is v0.99.6a (SVN Rev 22276)/v4.0.1 respectively on XP Pro SP2. I just wonder if there's a bug in Wireshark which results in the inconsistencies. I'll wait for more feedback from folks here (hopefully!) before I approach the Wireshark guys and hilight this inconsistency.

Ethereal and Wireshark's behavior should be identical on this. I think it'll actually have more to do with pcap and your network drivers.

I haven't done a lot of testing, but it may be that some clients aren't padding out their frames correctly.

Edit: Oh, and my wireshark version is .99.4 on this machine, and my libpcap is 0.9.5 (note that I'm not doing this in Windows, this is on an Ubuntu Feisty machine)

Edited by McGrewSecurity
0

Share this post


Link to post
Share on other sites
Wireshark is Ethereal...

Yes, I know. I simply meant it would be good if someone could use a previous version of the software - it was Ethereal and now it's Wireshark. I don't have a copy of Ethereal.

I think it'll actually have more to do with pcap and your network drivers.

Thanks. I see the same result whether I use my XP Pro laptop (wireless) or W2K desktop (wired). I suspect it's the software version(s) so it'll be interesting to see if anyone with Ethereal (on Windows) sees padding.

It may seem that I'm "thrashing" this one, but the concern that I have is "what if it's not the only bug in my combination of hardware and software when I'm sniffing network traffic?".

0

Share this post


Link to post
Share on other sites

I can definitely understand the concern. Tried booting off a Linux livecd like backtrack and seeing if you get the padding or not then?

0

Share this post


Link to post
Share on other sites

i just grabbed a bit of traffic with ethereal 0.10.14, and winpcap 3.1 ARP packets are showing as either 60 bytes or 42 bytes ICMP packets are 74 bytes. I've never really noticed all that but i just got an arp request from an ip address i don't think should be on my network </paranoid> im going to go make my girlfriend type ipconfig on her laptop

0

Share this post


Link to post
Share on other sites

Well then I imagine it's different clients respecting or disrespecting the minimum lengths.

0

Share this post


Link to post
Share on other sites

It's interesting about finding a possible "rogue" IP address. I hope it doesn't turn out to be anything to worry about in terms of illegal or illicit activity!

I'm getting a little more comfortable about this, particularly as an older version of the packet sniffer also reports some packets as being shorter than the books lead us to believe that they should be. I'll hilight this to the Wireshark folks - ideally so they address it in future releases but, if not, so it might end up in the Wireshark wiki.

0

Share this post


Link to post
Share on other sites

According to the RFC, there is no minimum length. Or a required length at all. I agree there should be. So the difference in your lengths and the padding comes from the network drivers. At least that would be my guess. Only 22 Bytes are fixed, the rest is variable.

http://www.faqs.org/rfcs/rfc826.html

	Ethernet transmission layer (not necessarily accessible to
the user):
48.bit: Ethernet address of destination
48.bit: Ethernet address of sender
16.bit: Protocol type = ether_type$ADDRESS_RESOLUTION
Ethernet packet data:
16.bit: (ar$hrd) Hardware address space (e.g., Ethernet,
Packet Radio Net.)
16.bit: (ar$pro) Protocol address space. For Ethernet
hardware, this is from the set of type
fields ether_typ$<protocol>.
8.bit: (ar$hln) byte length of each hardware address
8.bit: (ar$pln) byte length of each protocol address
16.bit: (ar$op) opcode (ares_op$REQUEST | ares_op$REPLY)
nbytes: (ar$sha) Hardware address of sender of this
packet, n from the ar$hln field.
mbytes: (ar$spa) Protocol address of sender of this
packet, m from the ar$pln field.
nbytes: (ar$tha) Hardware address of target of this
packet (if known).
mbytes: (ar$tpa) Protocol address of target.

0

Share this post


Link to post
Share on other sites

Thanks Thespis

Now I'm confused! This RFC relates to ARP and the books that I've seen which discuss Ethernet frames mention the encapsulation process and the fact that the data section has to have between 46 and 1500 bytes. If this is less than 46, padding should be applied to the end to ensure this minimum size. This applies to ARP, as well as other higher protcols involved in the encapsulation process. As far as I'm aware, having a minimum frame size has something to do with identifying collisions.

0

Share this post


Link to post
Share on other sites

Just a shot in the dark here, but does changing the MTU size in the router config affect the padding?

The 1500 rang a bell , thats usually the default on most linksys, if the box is unchecked maybe it uses the smallest size for efficiency on the lan? Maybe?

Probably not.

0

Share this post


Link to post
Share on other sites
Here's a page I found that explains the relationship between short Ethernet frames and collision detection:

<a href="http://www.industrialethernetu.com/courses/101_4.htm" target="_blank">http://www.industrialethernetu.com/courses/101_4.htm</a>

Nice site - thanks.

I tried a live linux CD with Wireshark to capture traffic. It still shows Ethernet/ARP as less than it *should* be. I suspect either my wireless network card or the netgear router is the cause of this behaviour.

...does changing the MTU size in the router config affect the padding?...

I'm sure that I set the MTU to be 1492 before but I just can't find the setting now. I'll continue to search and, if I find it, I'll change it to see if that makes any difference.

Edited by Gregor
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0