If I have a new network packet that has a protocol format of eth:ip:tcp (Ethernet, IP, TCP), why would one packet contain an ethernet trailer or "footer" and another one would not? What is the purpose of this footer?

TCP rides on IP packets
IP rides on Ethernet frames

I think you're looking at the protocol analyzer's view of the entire packet from the physical layer.  Is there any reason you need to examine the packet at the ethernet detail level?

[quote author=Grok link=topic=14324.msg146669#msg146669 date=1140540821]
TCP rides on IP packets
IP rides on Ethernet frames

I think you're looking at the protocol analyzer's view of the entire packet from the physical layer.  Is there any reason you need to examine the packet at the ethernet detail level?
[/quote]

I know what I'm looking at. I know what everything is. If I'm looking at the packet at the ethernet detail level, then that's what I meant to do. I would appreciate it if somone would answer my question.

I think I know what you're talking about. Google says that Ethernet has an optional trailer that contains a checksum.

However, I can't see why it sometimes exists and sometimes not, and why in all my sniffs it's 6 bytes long and they're all zero.

Sometimes when monitoring Bnet or WoW traffic I've noticed Ethereal is just wrong.

An Ethernet II Frame  looks like this

Preamble - 8 bytes ( 7 AA's ,1 AB)
Dest MAC -  6 bytes for the destination MAC
Src MAC - 6 bytes for the source MAC
Type - 2 bytes
Data(PDU) - total 46 bytes
     - 20 bytes (MAC Header)
     - 20 bytes (IP header)
     - 5 bytes PAD
     - 1 byte DATA(a single character)
CRC -  4 bytes

When data goes down the OSI model (Or TCP/IP Model (depending)) information is added at each level called headers or trailers. Information gets encapsulated at each level that helps the level below it or above it, aswell as it gives information to the OSI (TCP/IP)stack on the other computer receiving the packet.

Your packet sniffer may not be displaying ALL the information that the packet contains, it depends how the programmer coded the software to display the packet. This might be a reason why some packets are missing information, for example, with Ethereal, the programmer did not choose to show the Preamble that comes with every ethernet frame (Ethernet II (802.3(?)) and DIX) simply because there is no need to since all it does is tell the NIC when a new packet is about to come in.

[quote author=MrRaza link=topic=14324.msg146709#msg146709 date=1140568629]
Your packet sniffer may not be displaying ALL the information that the packet contains, it depends how the programmer coded the software to display the packet. This might be a reason why some packets are missing information, for example, with Ethereal, the programmer did not choose to show the Preamble that comes with every ethernet frame (Ethernet II (802.3(?)) and DIX) simply because there is no need to since all it does is tell the NIC when a new packet is about to come in.
[/quote]
Packet Sniffers don't see the preamble or the CRC.  They are processed only by the NIC and they have nothing to do with this conversation. 


I've noticed the extra bytes before.  I always suspected that it was being padded to an even length, but I really don't know.  It's wholly possible that Ethereal is just wrong, I've never checked with a different sniffer. 

I haven't done any testing on whether or not this phenomenon happens on only outbound or only inbound, or both. However, I've had packets where the TCP Data segment was blank, and this "padding" was present, and then the same situtation but the "padding" was not present. Furthermore, where the data segement is of large size, (by large I mean approximately 100 bytes), I've not gotten as many nulled "footers" before I reach the end. (This could lend evidence to your theory perhaps, iago?). I suppose I could do some more testing later, LAN-specific and remote server testing.