Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • wireshark wireshark
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 1,345
    • Issues 1,345
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 156
    • Merge requests 156
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • External wiki
    • External wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Wireshark Foundation
  • wiresharkwireshark
  • Issues
  • #17246
Closed
Open
Created Feb 21, 2021 by James Garringer@jgarringer

More granular filtering for MAC addresses

Summary

Provide a more granular way to filter MAC addresses. Please consider providing a mask that applies to bits within a nibble or compiling a change to the 802.11 protocol dissector that would apply to wlan.addr, wlan.ta, wlan.ra, wlan.da, and wlan.sa filters.

Many device manufacturers now randomize the MAC address during WLAN discovery, and again during WLAN association. These MAC addresses follow RFC 7042 (section 2.1) rules where the second least significant bit of the 48-bit MAC address' most significant byte is set signifying that it is locally administered. This results in the second character matching 2, 6, a, or e as follows.

x2:xx:xx:xx:xx:xx x6:xx:xx:xx:xx:xx xa:xx:xx:xx:xx:xx xe:xx:xx:xx:xx:xx

Bitwise AND will be true when attempting the following display filter. This is because the bitwise AND operator is not granular enough to mask bits within the 4-bit nibble. For example:

wlan.addr[0] & 0x02 successfully matches

a = 1010 2 = 0010 6 = 0110 e = 1110

but also matches

3 = 0011 7 = 0111 b = 1011

Because most WLAN frames are either encrypted or do not carry an Ethernet header, analysis of the local and group Ethernet bits is not viable. Examples include management WLAN traffic, such as Probe Requests which are randomized during network discovery, and Authentication and Association frames which are randomized during WLAN association.

Steps to reproduce

  1. Enable Private Wi-Fi Address in Settings > Wi-Fi > info button for current network > Private Address
  2. Capture layer 2 WLAN traffic with an Apple iOS device running iOS 14
  3. Attempt to filter for MAC address whose second most significant nibble is a 2,6,A,or E using this display filter wlan.addr[0] & 0x02

What is the current bug behavior?

Randomized and non-randomized addresses are included in the results.

What is the expected correct behavior?

Currently, this is expected behavior as current tools do not provide for bitwise masking within a nibble.

Sample capture file

See Randomized Probe Requests.pcapng attached Randomized_Probe_Requests.pcapng

Relevant logs and/or screenshots

See attached screenshot Wireshark_Enhancement_Request

Build information

3.4.3 (v3.4.3-0-g6ae6cd33)

Compiled (64-bit) with Qt 5.12.6, with libpcap, without POSIX capabilities, with GLib 2.58.3, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with Lua 5.2.4, with GnuTLS 3.6.15 and PKCS #11 (closed) support, with Gcrypt 1.8.7, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.39.2, with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.9.9, with QtMultimedia, with automatic updates using Sparkle, with SpeexDSP (using system library), with Minizip.

Running on Mac OS X 10.16, build 20D74 (Darwin 20.3.0), with Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz (with SSE4.2), with 32768 MB of physical memory, with locale C, with light display mode, with HiDPI, with libpcap version 1.9.1, with GnuTLS 3.6.15, with Gcrypt 1.8.7, with brotli 1.0.9, with zlib 1.2.11, binary plugins supported (21 loaded).

Built using clang 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.16).

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking