Ask Your Question
0

Missing frames in Block Ack packet in wireless monitor-mode capture...

asked 2018-07-27 22:26:30 +0000

barcaroller gravatar image

updated 2018-07-28 16:58:54 +0000

Guy Harris gravatar image

Does anyone know what "Missing frame" means in the tshark output below. Traffic was captured using Kismet, with the Wi-Fi adapter in monitor mode. One thing I've noticed is that no matter how many packets are captured (e.g. 10 million), the number of missing frames never exceeds 4095.

Frame 828: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
    Interface id: 0 (unknown)
    Interface name: unknown
    Encapsulation type: Per-Packet Information header (97)
    Arrival Time: Jul 15, 2018 17:33:54.634253000 EDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1531690434.634253000 seconds
    [Time delta from previous captured frame: 0.000012000 seconds]
    [Time delta from previous displayed frame: 0.000012000 seconds]
    [Time since reference or first frame: 72.736265000 seconds]
    Frame Number: 828
    Frame Length: 60 bytes (480 bits)
    Capture Length: 60 bytes (480 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: ppi:wlan_radio:wlan]
PPI version 0, 32 bytes
    Version: 0
    Flags: 0x00
        .... ...0 = Alignment: Not aligned
        0000 000. = Reserved: 0x00
    Header length: 32
    DLT: 105
    802.11-Common
        Field type: 802.11-Common (2)
        Field length: 20
        TSFT: 0 [invalid]
        Flags: 0x0000
            .... .... .... ...0 = FCS present flag: Absent
            .... .... .... ..0. = TSFT flag: microseconds
            .... .... .... .0.. = FCS validity: Valid
            .... .... .... 0... = PHY error flag: No errors
        Rate: 24.0 Mbps
        Channel frequency: 5805 [A 161]
        Channel flags: 0x0140
            .... .... ...0 .... = Turbo: False
            .... .... ..0. .... = Complementary Code Keying (CCK): False
            .... .... .1.. .... = Orthogonal Frequency-Division Multiplexing (OFDM): True
            .... .... 0... .... = 2 GHz spectrum: False
            .... ...1 .... .... = 5 GHz spectrum: True
            .... ..0. .... .... = Passive: False
            .... .0.. .... .... = Dynamic CCK-OFDM: False
            .... 0... .... .... = Gaussian Frequency Shift Keying (GFSK): False
        FHSS hopset: 0x00
        FHSS pattern: 0x00
        dBm antenna signal: -26
        dBm antenna noise: 0
802.11 radio information
    PHY type: 802.11a (5)
    Turbo type: Non-turbo (0)
    Data rate: 24.0 Mb/s
    Channel: 161
    Frequency: 5805MHz
    Signal strength (dBm): -26dBm
    [Duration: 32µs]
        [Preamble: 20µs]
IEEE 802.11 802.11 Block Ack, Flags: ........
    Type/Subtype: 802.11 Block Ack (0x0019)
    Frame Control Field: 0x9400
        .... ..00 = Version: 0
        .... 01.. = Type: Control frame (1)
        1001 .... = Subtype: 9
        Flags: 0x00
            .... ..00 = DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x0)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = Order flag: Not strictly ordered
    .000 0000 0000 0000 = Duration: 0 microseconds
    Receiver address: f0:97:8d:19:bd:5d
    Transmitter address: 57:68:f9:a7:de:59
    Compressed BlockAck Response
        Block Ack Control: 0x0005
            .... .... .... ...1 = BA Ack Policy: Sender Does Not Require Immediate Acknowledgement
            .... .... ...0 010. = BA Type: Compressed BlockAck (0x2)
            .... 0000 000. .... = Reserved: 0x00
            0000 .... .... .... = TID for which a Basic BlockAck frame is requested: 0x0
        Block Ack Starting Sequence Control (SSC): 0x0030
            .... .... .... 0000 = Fragment: 0
            0000 0000 0011 .... = Starting Sequence Number: 3
        Block Ack Bitmap: ff03000000000000
            Missing frame: 13
            Missing frame: 14
            Missing frame: 15
                ...
            Missing frame: 64
            Missing frame ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
0

answered 2018-07-28 09:06:05 +0000

Bob Jones gravatar image

This is a BlockAck response, where a group of MPDUs can be sent together with a single block ACK for the group, instead of one ACK for each data frame. This is an efficiency improvement. It has a sliding window: a start frame (starting sequence number 3 in your picture) and a bitmap, with a bit representing an MPDU (i.e. data frame) by sequence number, starting at the first bit/starting sequence number.

There is a lot of information on the web: https://mrncciew.com/2014/11/01/cwap-802-11-block-ack/

So either you really have missing frames in the group, and the BlockAck response is telling you this, or it is how the sender of the frame has chosen to index the ACKs. Apple devices sometimes do this ; let's say a host sends sequence number 21. If the BlockAck response has a starting sequence number of 21, then only a single bit would be set in the bitmap; all the rest would be zero. Wireshark would then interpret the zeros in the bit mask as missing data, but it really isn't. This is more likely what you see, but no way to know for sure since you only show one frame.

In your case, match up the sequence numbers of the data frames in the trace preceding the BlockAck Response and compare to the bitmap to see if they make sense.

image description

edit flag offensive delete link more

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: 2018-07-27 22:26:30 +0000

Seen: 4,754 times

Last updated: Jul 28 '18