[Jason Lixfeld <jason@xxxxxxxxxx>]

Alright, we also know that I can't count.  Sorry.  Layer 2's 8 bytes + 
8 bytes + 2 bytes does not equal 14 bytes.

On Monday, August 25, 2003, at 5:55 PM, Jason Lixfeld wrote:

> I've got some questions about what I see in tethereal which may be 
> because I lack a thorough understanding of all the protocols involved 
> here.
>
> If I use the -V option and capture some packets, I don't understand 
> what the packet length value actually represents because the length of 
> the various encapsulated headers and payload doesn't add up to what 
> the packet length states.
>
> Take the below capture as an example, as it was pulled off of an 
> Ethernet network.  The Packet Length says the packet is 114 bytes 
> long.  The way I rationalize it now, I can look down through the 
> output and count
> all the values of all the encapsulated layers and the value should 
> total 114 bytes.  Well, it doesn't so I'm missing something quite 
> obvious, which I chalk up to the fact that I don't completely get it.
>
> The obvious values (as listed below) are:
>
> 20 byte IP header
> 32 byte TCP header
> 48 byte TCP payload
> --
> 100 bytes.  I'm missing 14 bytes somewhere.
>
> Layers 3 and 4 in the below capture all report a header length.  The 
> only layer that doesn't report any sort of length is layer 2.  Is that 
> where the other 14 bytes comes from?  The two MAC addresses are 8 
> bytes long, and the type is 2 bytes.  That equals 14, but is it that 
> simple?
>
> ---
>
> Frame 2 (114 bytes on wire, 114 bytes captured)
>     Arrival Time: Aug 21, 2003 15:40:05.286540000
>     Time delta from previous packet: 0.035215000 seconds
>     Time relative to first packet: 0.035215000 seconds
>     Frame Number: 2
>     Packet Length: 114 bytes
>     Capture Length: 114 bytes
> Ethernet II, Src: 00:02:4b:b9:03:a2, Dst: 00:03:93:ea:f3:e2
>     Destination: 00:03:93:ea:f3:e2 (AppleCom_ea:f3:e2)
>     Source: 00:02:4b:b9:03:a2 (Cisco_b9:03:a2)
>     Type: IP (0x0800)
> Internet Protocol, Src Addr: 208.185.54.31 (208.185.54.31), Dst Addr: 
> 172.17.7.100 (172.17.7.100)
>     Version: 4
>     Header length: 20 bytes
>     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
>         0000 00.. = Differentiated Services Codepoint: Default (0x00)
>         .... ..0. = ECN-Capable Transport (ECT): 0
>         .... ...0 = ECN-CE: 0
>     Total Length: 100
>     Identification: 0xc82e (51246)
>     Flags: 0x04
>         .1.. = Don't fragment: Set
>         ..0. = More fragments: Not set
>     Fragment offset: 0
>     Time to live: 116
>     Protocol: TCP (0x06)
>     Header checksum: 0x8417 (correct)
>     Source: 208.185.54.31 (208.185.54.31)
>     Destination: 172.17.7.100 (172.17.7.100)
> Transmission Control Protocol, Src Port: ms-streaming (1755), Dst 
> Port: 49244 (49244), Seq: 1491084909, Ack: 2460353131, Len: 48
>     Source port: ms-streaming (1755)
>     Destination port: 49244 (49244)
>     Sequence number: 1491084909
>     Next sequence number: 1491084957
>     Acknowledgement number: 2460353131
>     Header length: 32 bytes
>     Flags: 0x0018 (PSH, ACK)
>         0... .... = Congestion Window Reduced (CWR): Not set
>         .0.. .... = ECN-Echo: Not set
>         ..0. .... = Urgent: Not set
>         ...1 .... = Acknowledgment: Set
>         .... 1... = Push: Set
>         .... .0.. = Reset: Not set
>         .... ..0. = Syn: Not set
>         .... ...0 = Fin: Not set
>     Window size: 17216
>     Checksum: 0x9e8d (correct)
>     Options: (12 bytes)
>         NOP
>         NOP
>         Time stamp: tsval 8659100, tsecr 2849866957
> Data (48 bytes)
>
> 0000  01 00 00 09 ce fa 0b b0 20 00 00 00 4d 4d 53 20   ........ ...MMS
> 0010  04 00 00 00 17 00 00 00 f0 03 00 00 00 00 00 00   
> ................
> 0020  02 00 00 00 21 00 04 00 00 00 00 00 ef f0 f0 f0   
> ....!...........
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users