Ethereal-users: RE: [Ethereal-users] Ping packet sizes

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Stewart, Damien" <damien.r.stewart@xxxxxxxxxxxxxxx>
Date: Mon, 24 Oct 2005 10:30:43 +1000
Hi there,

Yes I am aware that Ethereal can't see all of the packet when it's running
on a machine the packet is generated from. However, in this particular case,
when I noticed the discrepancy between ping request and ping replies,
Ethereal was monitoring a SPAN session on a Cisco router. To my
understanding, the router copies data from one specified port to another. In
short, this is like plugging an Ethereal box into an unswitched hub,
correct?

So I still can't account for the missing bytes on the request. Are there any
known issues with SPAN sessions altering packets, that is knocking off the
odd byte here and there?

It's a minor issue, but it would be nice to know exactly in what situations
Ethereal will correctly report packet sizes

Regards,

Damien.

> -----Original Message-----
> From: Guy Harris [mailto:gharris@xxxxxxxxx] 
> Sent: Tuesday, 18 October 2005 1:23 PM
> To: Ethereal user support
> Subject: Re: [Ethereal-users] Ping packet sizes
> 
> Stewart, Damien wrote:
> 
> > I setup another PC connected to the switch on one side of 
> the link and 
> > created a SPAN session and run Ethereal. I then did a standard ping 
> > (this is on Windows BTW) from the other PC - This generates the 
> > expected
> > 74 bytes (8 bytes preamble
> 
> You're not going to see the preamble in Ethereal, unless the 
> adapter or its driver does something *REALLY* strange.
> 
> > + 6 bytes DA + 6 bytes SA + 2 bytes Type
> 
> The standard 14-byte Ethernet header.
> 
> > + 20 bytes IP header
> 
> (If there are no IP options.)
> 
> > + 32 bytes ICMP payload,
> 
> That'd be 4 bytes of standard ICMP header, 4 bytes of 
> identifier and sequence number, and 24 bytes of actual data.
> 
> If, however, there's 32 bytes of actual data in the ICMP ECHO 
> (ping) packet, that's
> 
> 	6 bytes DA + 6 bytes SA + 2 bytes Type + 20 bytes IP 
> header + 4 bytes ICMP header + 4 bytes identifier+sequence 
> number + 32 bytes actual data.
> 
> The man page (c'mon, Microsoft, admit it - they're man pages) 
> for XP's "ping" command:
> 
> 	
> http://www.microsoft.com/resources/documentation/windows/xp/al
> l/proddocs/en-us/ping.mspx
> 
> says
> 
> 	-l Size : Specifies the length, in bytes, of the Data 
> field in the Echo Request messages sent. The default is 32. 
> The maximum size is 65,527.
> 
> so you do get 32 bytes of actual data by default.
> 
> > I then proceded to reduce the ICMP payload using the "-l" (dash el) 
> > option to 1 byte.
> 
> So that'd be 6+6+2+20+4+4+1, if the payload is the "data" 
> portion of the ICMP ECHO packet.  That's 43 bytes.
> 
> > The echo request packet size drop to 56 bytes yet the reply is 60 
> > bytes! In the request ethernet frame, there is a padding of
> > 13 bytes (so 8+6+6+2+13+20+1=56) - my question is: why 56 bytes?
> 
> Good question.  Perhaps the driver, or NDIS, does some 
> padding before handing outgoing packets up to NDIS listeners 
> (such as WinPcap), but doesn't fully pad the packet to 60 bytes.
> 
> On at least some other systems (e.g., Mac OS X, but I suspect 
> it's far from the only UN*X that works this way), the driver 
> and the rest of the networking code does *no* padding before 
> handing outgoing packets to the packet capture mechanism, so 
> you really would see a 43-byte packet - as you said, for 
> outgoing packets "Ethereal doesn't report packet sizes as 
> seen by the network if its running on the same machine that's 
> generating the traffic", so it shows only 43 bytes even 
> though the packet was 60 bytes long when transmitted on the network.
> 
> 
> 


DISCLAIMER:-----------------------------------------------------------------------------------------------
This Email may contain confidential and/or privileged information and is intended 
solely for the addressee(s) named. If you have received this information in error, or
are advised that you have been posted this Email by accident, please notify the 
sender by return Email, do not redistribute it, delete the Email and keep no copies.
----------------------------------------------------------------------------------------------------------------------