Bug #1665
closedDefault maximum packet size is insufficient when VLAN tags are present (and not stripped)
Description
The default packet size in most cases ends up being 1516 bytes. This is because GetIfaceMaxHWHeaderLength in util-ioctl.c will generally return SLL_HEADER_LEN, which is 16, since the if statements at the beginning of the file won't match (they're using strcmp while the intention is to check for a prefix? I'm unclear on what the intent was).
If a VLAN tag is present and not stripped (e.g., when capturing on a bridge interface with VLAN-tagged traffic), the maximum packet size is 1518 bytes. It is 1522 bytes in the rarer case of QinQ traffic. However, suricata under the default configuration silently drops packets larger than 1516 bytes since it considers them truncated (this happens due to the checks in DecodeIPV4Packet), which leads to reassembly gaps in the presence of full and nearly-full VLAN-tagged packets.
This can be corrected by setting the default-packet-size option in suricata.yaml, but debugging this issue proved to be quite challenging. What do you think of the idea of adding a counter for when suricata drops packets because it considers them to be truncated? Also, should the maximum default size be raised, or at least the logic in GetIfaceMaxHWHeaderLength fixed to perform detection based on the interface name?
Updated by Victor Julien almost 9 years ago
- Status changed from New to Assigned
- Assignee set to Eric Leblond
- Target version set to 70
Updated by Victor Julien almost 9 years ago
We could probably add a check for this, as the behaviour is pretty consistent: IPv4 will reject the packet at 'if (unlikely(IPV4_GET_IPLEN(p) < IPV4_GET_HLEN(p))) {'. So like with the checksum offloading, we can have a threshold and issue a warning.
Updated by Victor Julien over 8 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.1rc1