TCP Warnings & already truncated mirrored traffic.

asked 2024-09-08 07:04:21 +0000

Background

Oracle Cloud Infrastructure(OCI) has VTAP(https://docs.oracle.com/en-us/ia... service similar to AWS VPC Traffic Mirroring. 'Max Packet Size' of VTAP is the capture size of the mirrored traffic, any bytes, beyond 'Max Packet Size' wont be mirrored. Also for such truncated mirrored packets, packet header parameters of the payload such as length and checksum aren't updated.

Scenario

I am running tcpdump to capture mirrored traffic on the compute node behind the target NLB of VTAP in OCI Cloud. When I use the 'Max Packet Size' on the VTAP to be 1000, my pcaps when viewed in Wireshark show for almost all packets

TCP Previous segment not captured
TCP ACKed unseen segment

1000 is more than sufficient to include all the header information for sure. The snaplen(-s parameter) for the tcpdump command is also set to 800, so tcpdump records the truncation in pcap files. Note tcpdump is running on vxlan virtual interface of the compute node, so that interface does decap to give me just original packet as seen by 'source of VTAP'. Here 'source of VTAP' is nothing but the compute node whose traffic is being mirrored by VTAP.

The expert error messages of Wireshark go away, if I use full packet capture in VTAP traffic mirroring with a 'Max packet size' of 9000 and in tcpdump too. Traffic being captured is mainly simple HTTP requests and on the source of the VTAP(from where mirrored traffic in VXLAN encapsulation is coming from).

So we have for most of the packets we have

Length of Packet as seen by VTAP Source/Compute > Original Packet Length PCAP file header > Captured Packet Length of PCAP file header aka snaplen

One theory I have is that: When Wireshark tries to analyze pcap files(captured by the tcpdump), it sees sequence/ack numbers don't add up to number of bytes in each packet it sees in pcaps and hence the errors. I think since TCP packet itself does not have length field to give itself payload length, TCP layer derives this information from the IP length field in IP packet. And the same is being done by wireshark here. It sees big IP packet length and it does not match tcp payload length it sees in the pcap file.

is my theory in the right direction? Will really appreciate help from Wireshark experts.

edit retag flag offensive close merge delete

add a comment

answered 2024-09-08 07:34:27 +0000

SYN-bit

18496 ●9 ●334 ●255 https://SYN-b.it

When capturing, the libpcap/npcap library will record how many bytes it has seen on the wire and how many bytes it has saved for each packet:

Frame 874: 1514 bytes on wire, 1000 bytes captured on interface en0, id 0

In dissecting, it uses the bytes on wire to determine how much data there really was before saving the first X bytes. As you are cutting the packets on the VTAP interface to 1000 bytes and then using a snaplength of 800 in tcpdump, you end up with 1000 bytes on wire, 800 bytes captured for any packet of size 1000 or larger. This means if the original packet was 1514 bytes for instance, that 514 bytes were missing from the perspective of the capture point. Wireshark does not know that that was on purpose, so it reports the data as missing.

I assume that when you capture full frames on the VTAP and then only slice to 800 bytes with tcpdump, the expert error messages will disappear, as the capture engine now properly sees the original size of the packets before slicing them.

If this is not the case, could you please share as small example pcap of the problem and also the wireshark version you are using for reading the truncated files?

edit flag offensive delete link

Comments

Hello Sir, Thank you for your answer. Appreciate!

YES! The error goes away with VTAP set to MAX CAPTURE SIZE of 9000 and tcpdump snaplen of 800.

As per your answer, it seems Wireshark calculates the TCP payload length from the packet byte length, tcpdump/dumpcap sees on the wire during capture aka bytes on wire. It then derives the TCP payload length from this bytes on wire. So as a downstream effect, TCP Analysis by Wireshark for seq/ack numbers will be performed, as per these untrueTCP payload length values.

Is my understanding right?

Now assuming my understanding I said above is correct && since often, AWS/OCI customers might want to limit packet size while mirroring itself for performance and cost reasons:

How can we make Wireshark perform its TCP Analysis with an IP-length field instead of using bytes on the wire?

The IP-length field will always ...(more)

mprWireshark ( 2024-09-08 21:31:15 +0000 )edit

How can we make Wireshark perform its 'TCP Analysis' with an IP-length field instead of using 'packet capture length @ the wire during tcpdump'?

Enhancements to Wireshark can be suggested through our Issues tracker on gitlab.com/wireshark. Make sure to use the enhancement request template. I do like the idea of being able to overrule the bytes on wire by the IP total length, but I would prefer that it as added as a protocol preference to the IPv4 and IPv6 dissectors instead of default behavior. You can reference this ask question in the enhancement request (as Wireshark is correct in its analysis that data was missing at the point of capture)

I do see some packets with packets on wire of length 17k

This happens in Linux when generic receive offloading is enabled on the NIC. It then collects multiple TCP segments and sends the collected TCP data in ...(more)

SYN-bit ( 2024-09-08 21:46:20 +0000 )edit

thanks again.

Can I use editcap to change the number of bytes on wire for each packet to be equal to the (IP-Length field of the packet + Length of Ethernet Header) in the pcaps?? this can fix it for Wireshark analysis too right?

mprWireshark ( 2024-09-08 21:53:20 +0000 )edit

Not in one one, but you could write a script to do it packet for packet. Or maybe split up the file in files with the same IP length, process those and then use mergecap to stitch them together...

SYN-bit ( 2024-09-09 08:47:27 +0000 )edit

A scapy script might be easier perhaps...

SYN-bit ( 2024-09-09 08:47:57 +0000 )edit

add a comment

TCP Warnings & already truncated mirrored traffic.

1 Answer

Comments

Your Answer

Question Tools

Stats

TCP Warnings & already truncated mirrored traffic. edit

1 Answer

Comments

Your Answer

Question Tools

Stats

TCP Warnings & already truncated mirrored traffic.