OT Wireless
Search/Menu

Search the field guide, causes, requirements, and glossary

Hidden node

Two clients that cannot hear each other can both send to the same access point at once, carrier sense cannot stop them, and their frames collide at the access point where neither sender can see it.

Ben RutterIndustrial network engineer
On this page5 sections
  1. How it presents
  2. Why it happens
  3. How to confirm it
  4. The fix
  5. Prevent it at design time

Is this your problem? It presents like this

  • Retries and loss are high on frames from clients to the access point, while frames from the access point get through.
  • It depends on where clients are. Clients at opposite ends of a cell, or on opposite sides of racking or a large machine, suffer more than clients near the access point.
  • It gets worse as more clients in the cell are active at once, at peak shift and as the fleet grows.
  • The link stays up. The logs show no disconnects or deauthentications, only late and missing packets.
  • Gaps are short retry bursts and latency spikes rather than long outages.
  • It started or worsened after racking, layout, or the fleet changed, with no change to the network.
Bands
2.4 GHz5 GHz5 GHz DFS6 GHz
Not sure?
Rank the likely causes from your symptoms

Why it happens

Wi-Fi avoids collisions by listening before it sends. That works only if every transmitter can hear every other. Two clients at opposite ends of a long aisle, or on either side of a run of steel racking, can each hear the access point and not each other. NIST names narrow aisles between metal shelves among the industrial features that change propagation. Each client senses a quiet channel and sends, and the frames collide at the access point. Neither sender knows. Each sees a missing acknowledgment, backs off, and sends again.

The standard’s answer is RTS/CTS. A 1995 analysis submitted to the 802.11 working group names the hidden terminal as its main purpose: a short request and a clear-to-send reserve the air around both ends before the data goes out. The same simulations found that the handshake does not completely solve the problem. Without it, stations hidden from the rest hardly got a packet through at higher load.

By default, control traffic goes without it. The handshake starts only for frames longer than a threshold. Windows’ older Native 802.11 driver interface defaults that threshold to 2,347 bytes1, and hostapd leaves it disabled unless you set it. EtherNet/IP I/O travels in small packets, so it goes out unprotected. The 1995 analysis argued that where stations are hidden, frame size is the wrong test, and advised around 512 bytes2 only as a general setting. Protecting every frame puts an RTS and a CTS in front of each one, an overhead small frames feel most.

The handshake has a reach limit too. One analysis found that, in open space, a receiver can be disrupted by a sender up to 1.78 times3 as far away as the station it is receiving. RTS/CTS stops covering every interferer once a link is longer than 0.56 of the transmission range. A client or access point in the next cell on the same channel can miss the CTS and still collide.

Load turns a nuisance into loss. In a simulation of an 802.11ax network with hidden terminals, packet drop reached 16%4 at 4,800 packets per second, and the authors note that RTS/CTS protects the downlink far better than the uplink. A survey from the access point shows a clean cell. The collisions happen between clients the survey never asked to hear each other, and every client you add is one more that another may not hear.

How to confirm it

  1. Capture over the air beside the access point as the measurement guide describes, and compare retry rates for frames from clients with those for frames to them.
  2. Pick two affected clients and check whether each can hear the other. Capture at one client's position and look for the other client's frames.
  3. Correlate the retries with how many clients in the cell are transmitting, and with where they are when it happens.
  4. Look for another access point, or its clients, on the same channel that your access point hears and the affected clients do not.
  5. Check whether the clients use RTS/CTS, and at what frame size threshold.

The measurement guide shows how to probe, capture, and time a drop step by step.

The fix

  • Make cells smaller and move access points so that clients sharing a cell are closer to the access point and to each other.
  • Move same-channel cells further apart so a neighboring access point and its clients are not hidden contenders.
  • On clients that let you set it, try an RTS threshold low enough to cover the affected frames, and keep it only if measured retries fall by more than the airtime the handshake costs.
  • Spread a large fleet over more access points and channels so fewer clients contend in each cell.

Prevent it at design time

  • Survey from client positions, not only from the access point, and check that clients sharing a cell can hear each other.
  • Size cells by the number of active clients, and re-check them when the fleet grows.
  • Re-check cells after racking, layout, or inventory changes.
  • Keep cells that share a channel far enough apart that their clients cannot reach each other's access point.

Related causes

Terms on this page

About this page

Built from 7 sources: 2 standards bodies and labs, 2 research papers and theses and 3 vendor documents. Researched and drafted with AI assistance. How pages are made

First published
Last updated
Change history (1)
  • First published
Cite this page

Plain

Ben Rutter. "Hidden node." OT Wireless, published October 8, 2026. https://otwireless.com/causes/hidden-node/

APA 7

Rutter, B. (2026, October 8). Hidden node. OT Wireless. https://otwireless.com/causes/hidden-node/

BibTeX

@misc{rutter2026hiddennode,
  author = {Rutter, Ben},
  title = {{Hidden node}},
  year = {2026},
  howpublished = {\url{https://otwireless.com/causes/hidden-node/}},
  organization = {OT Wireless},
}