First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

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

  • retag add tags

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)
IanW's avatar
3
IanW
asked 2022-11-10 15:03:53 +0000, updated 2022-11-10 15:13:43 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

0

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

Guy Harris's avatar
19.9k
Guy Harris
answered 2022-11-10 20:08:43 +0000, updated 2022-11-10 20:09:29 +0000
edit flag offensive 0 remove flag delete link

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's avatar Guy 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's avatar IanW (2022-11-14 08:22:35 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer