Ask Your Question
0

IPv4 total length exceeds packet length - always 8.0.69.0!

asked 2019-09-19 12:41:15 +0000

handsy gravatar image

updated 2019-09-20 08:27:02 +0000

Hi everyone, my first post on here :) I have a problem... we are capturing packets off the wire in our network but are getting a lot of "IPv4 total length exceeds packet length" errors and always from, 8.0.69.0. This IP is spurious and the destination seems to be 0.x, 5.x or 1.x, i.e. not valid either. Some googling seems to suggest that others have also seen 8.0.69.0 when working with GRE/NAT scenarios. Does anyone have any idea at all what this might be please? I'm not allowed to attach files on here at the moment unfortunately :(

UPDATE: Tried uploading to pcapr here * now removed link due to question answered *

edit retag flag offensive close merge delete

Comments

I have problem with the same IP as it shows up in my router log as DDos Attack/Ping of Death for quite some months now, may I ask what devices are you using? Which brands? Especially on the router?

ROBH gravatar imageROBH ( 2019-10-29 17:46:39 +0000 )edit

4 Answers

Sort by ยป oldest newest most voted
0

answered 2019-09-20 05:29:14 +0000

SYN-bit gravatar image

I removed the first 22 bytes of each packet (with editcap -C 22 <inputfile> <outputfile>) and then the resulting trace shows normal IP traffic (if you do the same, do you recognize the IP-addresses in the resulting trace as being normal IP adresses in your network?). So I assume, there is some (proprietary) tunneling going on with these packets, as it seems to be layered like this:

  • Ethernet Header (2c:21:72:ab:17:cc to cc:e1:7f:d6:59:63, ethertype 802.1Q)
  • Vlan header (vlan 24, ethertype 802.1Q)
  • Vlan header (vlan 24, ethertype IP)
  • Ethernet Header (xx to yy, ethertype IP)
  • IP header
  • <rest of="" normal="" ip="" packet="">

Do you recognize vlan 24 as being configured in your network on this segment? Do you recognize the juniper mac-addresses? Could you log into these Juniper devices and look at the configuration of the involved interfaces to see whether there is some Layer-2 tunneling configuration active?

edit flag offensive delete link more

Comments

Genius! Thank you so much SYN-bit. I now know where to focus my investigations.

handsy gravatar imagehandsy ( 2019-09-20 08:26:16 +0000 )edit
1

answered 2019-09-19 15:46:55 +0000

Guy Harris gravatar image

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.

edit flag offensive delete link more

Comments

Thanks, that's helpful. We continue to investigate. In the meantime if anyone else has any experience of this IP address I'd love to hear from you.

handsy gravatar imagehandsy ( 2019-09-19 16:19:47 +0000 )edit

It's not an IP address, it's the Ethernet type for IPv4 followed by the first two bytes of a typical IPv4 header (version/header length is the first byte - version is 4, length is 5 32-bit words or 20 bytes, i.e. a header without options - and type of service is the second byte, with 0 meaning the default ToS).

Guy Harris gravatar imageGuy Harris ( 2019-09-20 04:36:22 +0000 )edit
0

answered 2021-04-21 22:52:50 +0000

BigFatCat gravatar image

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.

edit flag offensive delete link more

Comments

The issue makes sense with the Juniper comments. I have captures where the Juniper mirror port truncated the Ethernet frame and recalculate a new CRC 4. The truncated data is gone, If the packet analysis software won't include the packets for analysis because of incorrect length then the individual packet record needs to be corrected. I have done this hex editor and then use different software to fix the CRC.

More information about pcap file and packet format at https://gitlab.com/wireshark/wireshark/-/wikis/Development/LibpcapFileFormat

BigFatCat gravatar imageBigFatCat ( 2021-04-24 16:16:42 +0000 )edit
0

answered 2021-04-21 11:05:44 +0000

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.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-09-19 12:41:15 +0000

Seen: 6,569 times

Last updated: Apr 21 '21