Change frame/tcp length on sliced packets

asked 2020-05-22 14:08:29 +0000

aurimas
1 ●1 ●1 ●1

Hi,

We are slicing packets on our packet broker ant 256 TCP bytes. And when we export files and try to read cpature with Wireshark it is all messed up, because Wireshark is interpreting sequence numbers using wrong TCP length.

Total IP length field in packets is correct so it is possible to recalculate and fix packet capture. TraceWrangler does the trick by using "Fix frame size meta data" option. Problem that TraceWrangler is Windows application and I can not use it for automating export in linux.

I have tried editcap -L but it seems does not do anything. Also tried tcpwrewrite --fixlen=pad/trunc, but also nothing gets edited.

Any idea how I could fix packet captures to make them properly readable in Wireshark?

Frame 71: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits)
Ethernet II, Src: 02:11:11:64:11:91 (02:11:11:64:11:91), Dst: 02:11:11:64:55:88 (02:11:11:64:55:88)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1302
Internet Protocol Version 4, Src: 1.1.1.1, Dst: 2.2.2.2
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x28 (DSCP: AF11, ECN: Not-ECT)
        0010 10.. = Differentiated Services Codepoint: Assured Forwarding 11 (10)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 1092
        [Expert Info (Error/Protocol): IPv4 total length exceeds packet length (296 bytes)]
            [IPv4 total length exceeds packet length (296 bytes)]
            [Severity level: Error]
            [Group: Protocol]
    Identification: 0x7d18 (32024)
    Flags: 0x4000, Don't fragment
        0... .... .... .... = Reserved bit: Not set
        .1.. .... .... .... = Don't fragment: Set
        ..0. .... .... .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 255
    Protocol: TCP (6)
    Header checksum: 0xfb71 [validation disabled]
    [Header checksum status: Unverified]
    Source: 1.1.1.1
    Destination: 2.2.2.2
Transmission Control Protocol, Src Port: 443, Dst Port: 59038, Seq: 2319763168, Ack: 462873003, Len: 256

answered 2020-05-22 14:23:08 +0000

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23790 ●4 ●950 ●227 https://www.wireshark.org

updated 2020-05-22 14:25:22 +0000

From your output:

Frame 71: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits)

This tells Wireshark that the capture file contains all 314 bytes that were transmitted, hence it gets upset when they aren't actually there. When packets are correctly sliced and written to a pcap (or pcapng) file the frame will show that less bytes were captured:

Frame 34: 1131 bytes on wire (9048 bits), 256 bytes captured (2048 bits)

The issue would appear to be with your capture file generation.

edit flag offensive delete link

Comments

314 bytes is already sliced size, actual size before slicing was:

Total Length: 1092

unfortunately I can not change how file was generated, so I am looking for a way to fix captures after slicing.

aurimas ( 2020-05-22 20:15:55 +0000 )edit

OK, then the capture file should have "1092 bytes on the wire" for that frame to be a valid capture file.

grahamb ( 2020-05-22 20:28:26 +0000 )edit

Actually it should have "Frame 1: 879 bytes on wire (7032 bits), 314 bytes captured (2512 bits)" this is what trace Wrangler sets after fixing capture. I am aware of that. But I am looking for a different way to fix packet capture in linux.

aurimas ( 2020-05-25 05:53:09 +0000 )edit

TraceWrangler probably uses the IP length field to fix up the frame length metadata in the capture file. I'm not aware of any other tools that will do this for you.

Maybe scapy can do this, it can certainly read the capture files and extract the ip.length but I'm not sure if it can then set the packet length metadata and write it out. Worth an experiment.

grahamb ( 2020-05-25 07:40:06 +0000 )edit

Thanks, I am looking into scapy right now, perhaps I will be lucky :) I have a question for my educational purpose. Am I correct thinking: whatever tool we are using for packet slicing, it should make sure to save original frame length?

aurimas ( 2020-05-25 08:29:01 +0000 )edit

I would think so. Most tools expect the information in the capture file to be correct.

grahamb ( 2020-05-25 08:31:39 +0000 )edit

add a comment

Your Answer

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

Change frame/tcp length on sliced packets

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Change frame/tcp length on sliced packets edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Change frame/tcp length on sliced packets