Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
The SSID is the Wi-Fi name; the BSSID is the address of one radio on one access point. What it reveals about roaming, sticky clients and evil twins, and how to read it on Windows, macOS and Linux.
A user says the Wi-Fi is slow at their desk, the controller shows every access point green, and the network name is the same on every floor. The name tells you nothing about which radio that laptop is talking to. That is what a BSSID is for, and this guide covers what it is, what it reveals about roaming and rogue access points, and how to read it on Windows, macOS and Linux.
The SSID is the network name. It is the string users pick from the list, up to 32 bytes long, and the access point announces it in every beacon frame. Per the IEEE definitions summarized on Wikipedia's service set page, the SSID "defines or extends a service set", which is the formal way of saying it names a group of radios that agree to behave as one network.
The BSSID is the address. A basic service set is one radio on one access point serving one network name, and its identifier is a 48-bit label in MAC address format. When a laptop associates, it associates with a BSSID, never with a name. Two access points can share an SSID all day; they cannot share a BSSID without one of them being a fake.
The ESSID is the name of the extended service set, which is what you get when several access points advertise the same SSID over the same wired network so a client can move between them. In practice the ESSID and the SSID are the same string, which is why the third term mostly turns up in Linux tools and exam questions. The practical model is simple: one name, many addresses, and the address is the one that changes as a user walks.
Count it for a real office. Six access points, each with a 2.4 GHz and a 5 GHz radio, broadcasting three networks (staff, guest, devices) comes to 36 BSSIDs behind three names. Add a 6 GHz radio on newer hardware and the count climbs again. Each of those 36 is a separate thing a client can be stuck to, scanned for, or spoofed. The network behind them is the WLAN, and the BSSID is how you tell its parts apart.
The first thing that trips a technician is that the BSSID on the client does not match the MAC address printed on the access point or shown in the controller. That is expected. Datto's access point documentation says it plainly: "each access point has a range of MAC addresses assigned to it", and the BSSID will not exactly match the one the management console lists. Meraki documents the same mechanic in more detail: the last octet of the BSSID is incremented by one for each SSID slot on the radio, so the staff network and the guest network on the same radio sit one address apart.
The controller usually shows the Ethernet interface's address, which is the base. The radios derive their own addresses from it, one per network, and some vendors set the locally administered bit, which flips the second hex digit to 2, 6, A or E. The thread below is the whole confusion in one post: a UniFi controller showing d8:b3:70:fa:58:a8 for the access point and a MacBook reporting e2:b3:70:fa:58:aa for the BSSID, with the replies explaining that the first is the wired side and the second is a locally administered address on the wireless side.
The working rule: match on the first three octets (the vendor prefix) and the middle of the address, then expect the last digit or two to differ by SSID slot and band. Most controllers list every radio's BSSID per access point somewhere in the device detail page, and that list is what you compare a client against.
A laptop decides when to leave one BSSID for another. The access points can advise, and they can refuse service, but the 802.11 standard leaves the move to the client, which is why two identical laptops on two different Wi-Fi chipsets roam differently in the same hallway.
Apple publishes its numbers, which makes a useful reference even for a Windows fleet. Per Apple's Wi-Fi roaming guide, an iPhone or iPad stays on its current BSSID until the signal drops past -70 dBm, then scans for candidates and only moves to one that is at least 8 dB stronger while it is transmitting data, or 12 dB stronger when idle. Windows laptops expose a "roaming aggressiveness" setting in the adapter driver that shifts the same thresholds. 802.11k lets the access point hand the client a list of neighbours to scan, 802.11v lets it suggest a better one, and 802.11r makes the re-authentication fast enough that a call survives it.
A sticky client is a device that never crosses its own trigger. The usual cause is an access point with its transmit power set high enough that the signal across the whole floor stays above -70 dBm, so the laptop has no reason to look. The user ends up on an access point two floors away with a signal that is fine for the beacon and terrible for a video call. The thread below is a tidy example: a two-floor UniFi setup where one access point on high power kept winning clients it should have lost, and the replies land on the fix that works in most offices, which is lowering transmit power until the cells overlap only at the edges.
The order of fixes matters. Lower transmit power first, especially on 2.4 GHz, so a client near the far access point sees a weak signal from the one it is on. Disable the lowest data rates next, so a client at the edge cannot hold a 1 Mbps link forever. Turn on 802.11k and 802.11v if the clients support them. A minimum RSSI setting that kicks weak clients comes last, because it only disconnects and the client is free to reconnect to the same radio. The BSSID is how you confirm any of this worked: watch it change as you walk.
An attacker who wants your users' credentials does not need to break your encryption. They need a radio that broadcasts your SSID with a stronger signal than the real one. MITRE catalogues this as Evil Twin, technique T1557.004, and describes the payoff: a user "may be directed to a fake login page or captive portal webpage to capture the victim's credentials." The device picks the strongest signal for a known name, and the name is the only thing most users ever see.
The BSSID is the tell. Every legitimate radio in your building has an address from your access point vendor's range and appears in your controller's inventory. A twin has the right name and the wrong address. MITRE's detection guidance for the technique lists exactly that: a legitimate SSID broadcast from an unexpected BSSID, with a stronger signal than it should have or security settings that do not match. A corporate network running WPA2-Enterprise that suddenly also appears as an open network is the same signal in a different column, and the security tier you run on each network is worth knowing before you go looking, which the WPA2 explainer covers.
Not every unknown BSSID is an attack. The more common version is the employee who brought a home router in for better coverage in the back office and named it after the company network. It still gets removed, because an open router on a live wall port is a door into the switch, but the response is a conversation rather than an incident. Either way the method is the same: keep a list of the BSSIDs you own per SSID, scan from a laptop on each floor once in a while, and walk toward the signal when one shows up that you do not.
On Windows, two commands cover it. The first shows the radio the machine is on right now; the second lists every BSSID in range with its channel and signal, which is the scan you use for rogue checks and roaming tests:
codenetsh wlan show interfaces netsh wlan show networks mode=bssid
The BSSID line in the first output is the address of the access point radio the laptop is associated with. Microsoft's netsh wlan reference documents both subcommands; the mode=bssid switch is what turns the second from a list of names into a list of addresses. The output is plain text rather than objects, so in PowerShell you parse it with Select-String 'BSSID|Signal|Channel' rather than piping to a cmdlet.
On macOS, hold Option and click the Wi-Fi icon in the menu bar. The dropdown shows the BSSID, channel, signal and noise for the connected network. The old airport command is gone as of macOS 14.4, and its replacement wdutil info prints <redacted> for the BSSID even with sudo, because Apple now gates that field behind the Location permission. For a scripted collection on Macs, your management agent needs that permission; a plain shell script does not get it.
On Linux, iw dev wlan0 link prints the connected BSSID on its first line, and nmcli -f BSSID,SSID,CHAN,SIGNAL dev wifi list gives the scan view. Swap wlan0 for whatever ip link calls the wireless interface.
For a quick visual tour of what the BSSID is and how it relates to the SSID and the access point, this one covers it in a few minutes:
Across a fleet, the useful trick is to collect netsh wlan show interfaces from every Windows laptop at once and keep the BSSID and signal columns. On OpenFrame that is a script run across a client's devices with the output collected in one place, which turns "the Wi-Fi is slow in accounting" into a list of which access point each machine in accounting is on.
Two addresses are in play on every association, and only one of them randomizes. Windows 11 offers random hardware addresses globally or per network so a laptop's own MAC is harder to track between networks. Apple's private Wi-Fi address does the same on iPhone, iPad and Mac, with three settings as of its December 2025 documentation: Off, Fixed (one private address per network, the default for WPA2 and stronger networks) and Rotating (a new address every two weeks, the default for open or weakly secured networks).
That is the client side. The BSSID is the access point's address and it stays put, which is why BSSID-based troubleshooting keeps working while MAC-based allowlists and DHCP reservations quietly break as phones rotate. The one wrinkle, as the thread above shows, is that some access point vendors use locally administered addresses for their BSSIDs, so a 2, 6, A or E in the second position does not by itself mean the radio is random or fake.
The BSSID answers four tickets that the SSID cannot. For "Wi-Fi is slow at my desk", read the BSSID on the client and match it to the floor plan; a laptop on a far access point is a power or roaming problem, not a bandwidth one. For "it drops when I walk to the meeting room", watch the BSSID while walking; if it never changes, the client is sticky, and if it changes and the call still drops, fast roaming is off. For "I see our network name but it asks for a different password", compare the BSSID to the inventory; a prefix you do not own is a rogue radio to go and find. For "the controller shows a different MAC than the laptop", it is the Ethernet address versus a radio address, and nothing is wrong.
Each of those checks takes under a minute on the client and saves a site visit. The planning side, where access points go and how many a floor needs, is covered in the small office network design checklist.
The SSID is what users see and the BSSID is what their devices connect to. Keep a list of the ones you own, learn to read one on each platform in under a minute, and the three most common Wi-Fi tickets stop being mysteries. For the wider walk through access points, bands and channel planning, start with the WLAN basics guide, and for a repeatable sweep of everything on the network, the network assessment checklist is the next read.
Content Marketing Lead
Ohayo! I run content, SEO, social, and community at Flamingo. Before IT, I worked as a correspondent for Ukraine's Public Broadcasting Company and have a Master's in journalism.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.
