IPv4 total length exceeds packet length - always 8.0.69.0!

edit

There appear to be 14 bytes of mysterious junk between the end of the final VLAN header and the beginning of the real IPv4 header - i.e., enough bytes to make up an extra Ethernet header, complete with an Ethernet type field value of 0x0800, for IPv4.

The 8.0.69.0 is, for example 0x08 0x00 0x45 0x00, which are two bytes of 0x0800, the Ethernet type for IPv4, followed by one byte of 0x45, which is an IP header version of 4 and an IPv4 header length of 20 bytes (5 4-byte words) - the length of an IPv4 header without any options.

Is there any traffic on the Ethernet segment on which you did the capture other than traffic between Juniper networking equipment? If not, perhaps this is something weird that Juniper devices send, in some cases, when they know they're talking to fellow Juniper devices.

The pcap has already been deleted. This is normal when the packet is truncated/sliced before it is sent to the sniffer.

The IPv4 checksum should pass because the CRC is for IPv4 header bits.

This is the math 1. Look at the bytes on the wire and bytes captured 2. Add all the layer 2 + IPv4 length bytes together

If step 2 is greater than 1, the packet was sliced.

An example of 100 ping 1. 142 bytes on the wire 2. 14 bytes MAC (12-byte MAC + 2-byte TYPE) + 128 bytes IPv4 length (20-byte IPv4 header+8-byte ICMP header + 100-byte payload) or 142 bytes.

If they are different then Wireshark reports length error.

Found same mysterious address - 8.0.69.0. The reason was in destination mac address - it starts with "4c". So wireshark recognizes not beginning of ethernet frame, but beginning of ip header.