Ask Your Question
0

"ACKed segment that wasn't captured", but also "This is an ACK to the segment in frame: nnn".

asked 2022-11-10 15:03:53 +0000

IanW gravatar image

updated 2022-11-10 15:13:43 +0000

On Wireshark Version 4.0.1 (v4.0.1-0-ge9f3970b1527).

I have a lot of packets in a capture marked "ACKed segment that wasn't captured (common at capture start)", but also "This is an ACK to the segment in frame: nnn". Does this make sense?

I'd prepared a screen capture showing this but I'm forbidden to upload it due to lack of points. Sorry. Here's a packet export instead:

Frame 116064: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 10.27.187.1, Dst: 10.22.61.4
Transmission Control Protocol, Src Port: 62326, Dst Port: 5018, Seq: 3345995, Ack: 3916774, Len: 0
    Source Port: 62326
    Destination Port: 5018
    [Stream index: 5]
    [Conversation completeness: Incomplete (12)]
    [TCP Segment Len: 0]
    Sequence Number: 3345995    (relative sequence number)
    Sequence Number (raw): 4121653282
    [Next Sequence Number: 3345995    (relative sequence number)]
    Acknowledgment Number: 3916774    (relative ack number)
    Acknowledgment number (raw): 80821650
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x010 (ACK)
    Window: 8192
    [Calculated window size: 8192]
    [Window size scaling factor: -1 (unknown)]
    Checksum: 0xd45b [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    [Timestamps]
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 116013]
        [The RTT to ACK the segment was: 0.010588000 seconds]
        [TCP Analysis Flags]
            [Expert Info (Warning/Sequence): ACKed segment that wasn't captured (common at capture start)]
                [ACKed segment that wasn't captured (common at capture start)]
                [Severity level: Warning]
                [Group: Sequence]

Frame 116013: 108 bytes on wire (864 bits), 62 bytes captured (496 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 10.22.61.4, Dst: 10.27.187.1
Transmission Control Protocol, Src Port: 5018, Dst Port: 62326, Seq: 3916720, Ack: 3345995, Len: 54
    Source Port: 5018
    Destination Port: 62326
    [Stream index: 5]
    [Conversation completeness: Incomplete (12)]
    [TCP Segment Len: 54]
    Sequence Number: 3916720    (relative sequence number)
    Sequence Number (raw): 80821596
    [Next Sequence Number: 3916774    (relative sequence number)]
    Acknowledgment Number: 3345995    (relative ack number)
    Acknowledgment number (raw): 4121653282
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x018 (PSH, ACK)
    Window: 32736
    [Calculated window size: 32736]
    [Window size scaling factor: -1 (unknown)]
    Checksum: 0x0488 [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    [Timestamps]
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 116010]
        [The RTT to ACK the segment was: 0.000249000 seconds]
        [Bytes in flight: 54]
        [Bytes sent since last PSH flag: 54]
        [TCP Analysis Flags]
            [Expert Info (Warning/Sequence): ACKed segment that wasn't captured (common at capture start)]
                [ACKed segment that wasn't captured (common at capture start)]
                [Severity level: Warning]
                [Group: Sequence]
    TCP payload (54 bytes)
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-11-10 20:08:43 +0000

Guy Harris gravatar image

updated 2022-11-10 20:09:29 +0000

Does this make sense?

No, it doesn't; it makes no sense whatsoever, as it's self-contradictory.

Please file a bug on this on the Wireshark issue list. Attach the raw capture file (rather than a screenshot or the export text above) if you can, as that may make it easier to determine what the problem is and will make it easier to

edit flag offensive delete link more

Comments

Or it could mean that the frame in question acks not only data in the frame in question but also asks data in some other segment that's not a frame in the capture. But even in that case it should be phrased in a way to make that more obvious.

Guy Harris gravatar imageGuy Harris ( 2022-11-10 21:15:58 +0000 )edit

Many thanks, Guy.

The problem appears to start after a break in a capture file. All packets after the break appear to be flagged.

I've tested with 3.6.9 and the problem doesn't appear in that.

I shall report to the issue list as you request.

Thanks

Ian

IanW gravatar imageIanW ( 2022-11-14 08:22:35 +0000 )edit

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: 2022-11-10 15:03:53 +0000

Seen: 754 times

Last updated: Nov 10 '22