After #37634, all types of flows will be correctly decoded from userspace Hubble/Monitor, except those exceeding the amount of bytes pushed during the trace/drop notification event. Let's ignore those when we monitor less bytes through connection tracking and aggregation, and focus when providing the TRACE_PAYLOAD_LEN (128B) value.
In the case of a TCPv6-over-vxlan packet, the amount of bytes needed to decode a SYN packet with options is at least 14B (ethernet) + 20B (ipv4) + 8B (udp) + 8B (vxlan) + 14B (ethernet) + 40B (ipv6) + >=20B (tcp+opts) = >=124. In case this exceed 128B, the decode fails and simply displays [error], while the actual error was TCP data offset greater than packet length (monitor).
Given also we introduced support for IPv6 underlay, or future DSR-over-ipv6, and given that after #39650 the datapath can tell when a packet is Overlay, let's provide a new config value rather than the old TRACE_PAYLOAD_LEN to push additional bytes.
After #37634, all types of flows will be correctly decoded from userspace Hubble/Monitor, except those exceeding the amount of bytes pushed during the trace/drop notification event. Let's ignore those when we monitor less bytes through connection tracking and aggregation, and focus when providing the TRACE_PAYLOAD_LEN (128B) value.
In the case of a TCPv6-over-vxlan packet, the amount of bytes needed to decode a SYN packet with options is at least
14B (ethernet) + 20B (ipv4) + 8B (udp) + 8B (vxlan) + 14B (ethernet) + 40B (ipv6) + >=20B (tcp+opts) = >=124. In case this exceed 128B, the decode fails and simply displays[error], while the actual error wasTCP data offset greater than packet length(monitor).Given also we introduced support for IPv6 underlay, or future DSR-over-ipv6, and given that after #39650 the datapath can tell when a packet is Overlay, let's provide a new config value rather than the old TRACE_PAYLOAD_LEN to push additional bytes.