Every Wi-Fi network operates in one of two fundamental topologies: infrastructure mode, where devices connect through a central access point, or ad hoc mode, where devices connect directly to each other without any central coordinator. Understanding the difference is essential for anyone configuring wireless networks, troubleshooting connectivity, or designing IoT/embedded systems. This article explains both modes from first principles, including how Linux configures each, their real-world use cases, and why one has become vastly more common than the other.
Infrastructure Mode: The Standard Model
In infrastructure mode, every device (called a station, or STA) communicates through a central access point (AP). Even if two laptops on the same Wi-Fi network are sitting right next to each other, their traffic still passes through the access point rather than going directly between them.
flowchart TD
AP[Access Point] --- L1[Laptop 1]
AP --- L2[Laptop 2]
AP --- P1[Phone]
AP --- IOT[IoT Device]
This is the model used by virtually every home, office, and public Wi-Fi network in existence today.
Characteristics of Infrastructure Mode
- All traffic is routed through the access point, even between two local devices
- The access point typically also provides DHCP, internet gateway access, and centralized security policy enforcement
- Supports many simultaneous clients efficiently
- The AP handles roaming, channel selection, and can bridge to a wired network
Ad Hoc Mode: Peer-to-Peer Wireless
In ad hoc mode (also called IBSS — Independent Basic Service Set), devices connect directly to one another with no central access point at all. Every device is an equal peer.
flowchart LR
L1[Laptop 1] --- L2[Laptop 2]
L2 --- L3[Laptop 3]
L1 --- L3Characteristics of Ad Hoc Mode
- No access point required — devices communicate directly
- Typically limited to small numbers of devices in close range
- No centralized DHCP by default (though it can be configured manually or with additional software)
- Generally lower throughput and less robust range/interference handling than infrastructure mode
- Historically used for quick, temporary connections between a small number of devices (e.g., transferring files between two laptops with no router nearby)
Comparison Table: Infrastructure vs. Ad Hoc Mode
| Feature | Infrastructure Mode | Ad Hoc Mode |
|---|---|---|
| Central coordinator | Yes — access point | No — peer-to-peer |
| Typical use case | Homes, offices, public Wi-Fi | Temporary direct device-to-device links |
| Scalability | High — supports many clients | Low — best for a handful of devices |
| Internet gateway | Usually provided by the AP | Not provided by default |
| Roaming support | Yes, between multiple APs | No |
| Security options | WPA2/WPA3-Personal or Enterprise | Limited, often weaker in practice |
| Modern relevance | Dominant, virtually universal | Largely superseded by newer peer-to-peer tech |
Configuring Infrastructure Mode on Linux
This is the default and most common configuration, using nmcli as covered in our wireless networking article:
nmcli device wifi connect "MyNetwork" password "mypassword"Configuring Ad Hoc Mode on Linux
Step 1: Set the interface to ad hoc mode
sudo nmcli device disconnect wlan0
sudo iw dev wlan0 set type ibssStep 2: Bring up the interface and join/create the ad hoc network
sudo ip link set wlan0 up
sudo iw dev wlan0 ibss join MyAdHocNetwork 2412Here, 2412 is the frequency in MHz corresponding to Wi-Fi channel 1.
Step 3: Assign an IP address manually (since there’s typically no DHCP server)
sudo ip addr add 192.168.10.1/24 dev wlan0Step 4: On a second device joining the same ad hoc network
sudo iw dev wlan0 set type ibss
sudo ip link set wlan0 up
sudo iw dev wlan0 ibss join MyAdHocNetwork 2412
sudo ip addr add 192.168.10.2/24 dev wlan0Step 5: Test connectivity between the two devices
ping 192.168.10.1Why Ad Hoc Mode Has Largely Fallen Out of Favor
Ad hoc mode was more common in the early days of Wi-Fi for direct file transfers or small gaming setups, but it has been largely superseded by more modern, purpose-built peer-to-peer technologies:
| Old Approach | Modern Replacement |
|---|---|
| Ad hoc Wi-Fi for direct file transfer | Wi-Fi Direct, AirDrop, Bluetooth |
| Ad hoc for temporary local gaming | Wi-Fi Direct-based multiplayer, local network discovery protocols |
| Ad hoc for sensor mesh networks | Zigbee, Thread, or dedicated mesh Wi-Fi standards |
Modern Wi-Fi Direct achieves similar peer-to-peer goals but with better security, easier device discovery, and broader driver/hardware support than legacy ad hoc mode, which is why most consumer devices today favor it (or Bluetooth) for direct connections instead.
Real-World Use Case (Historical): Field Data Collection Without Infrastructure
Before smartphones and Wi-Fi Direct were ubiquitous, field researchers or technicians sometimes used ad hoc Wi-Fi to connect a laptop directly to a specialized measurement device in a location with no available access point — for example, in a remote environmental monitoring station.
# On the laptop
sudo iw dev wlan0 set type ibss
sudo ip link set wlan0 up
sudo iw dev wlan0 ibss join FieldSensorNet 2437
sudo ip addr add 10.10.10.1/24 dev wlan0
# On the sensor device (assuming it also supports ad hoc mode)
# similarly configured with 10.10.10.2/24
Real-World Use Case (Modern): Mesh Networking Concepts
While true legacy ad hoc mode is rare today, the concept lives on in modern mesh networking systems (like mesh Wi-Fi routers, or IoT mesh protocols like Zigbee/Thread), where devices similarly relay traffic between each other without a single central access point — though these use much more sophisticated routing protocols than the original simple IBSS ad hoc mode.
Best Practices
- Use infrastructure mode for essentially all modern practical networking needs — it’s better supported, more secure, and more scalable.
- Consider Wi-Fi Direct or Bluetooth instead of legacy ad hoc mode for direct device-to-device transfers on modern hardware.
- If you must use ad hoc mode (e.g., legacy or specialized industrial equipment), isolate it from other networks and apply manual IP addressing carefully to avoid conflicts.
- Verify driver support before attempting ad hoc mode — not all Wi-Fi chipsets/drivers support IBSS mode; check with
iw list. - Document any ad hoc network deployments thoroughly, since they’re increasingly rare and future administrators may be unfamiliar with troubleshooting them.
Troubleshooting
Problem: iw dev wlan0 set type ibss fails with “Device or resource busy”
The interface is likely still managed by NetworkManager or connected to an infrastructure network. Disconnect first:
sudo nmcli device disconnect wlan0Problem: Two devices can’t see each other in ad hoc mode
Confirm they’re using the exact same network name (IBSS ID), frequency/channel, and that both interfaces are actually up:
iw dev wlan0 info
Problem: Devices see each other but can’t communicate
Since ad hoc mode has no built-in DHCP, verify manual IP addresses are on the same subnet and don’t conflict:
ip addr show wlan0
ping <peer-ip>
Problem: Driver doesn’t support IBSS/ad hoc mode
iw list | grep -A 10 "Supported interface modes"
If IBSS isn’t listed, that hardware/driver combination simply cannot operate in ad hoc mode — consider Wi-Fi Direct or a wired connection instead.
Conclusion
Infrastructure mode — where all devices connect through a central access point — is the model behind virtually every Wi-Fi network you use today, offering better scalability, security, and centralized management. Ad hoc mode, while historically useful for direct device-to-device connections without any supporting infrastructure, has been largely superseded by more modern peer-to-peer technologies like Wi-Fi Direct and Bluetooth. Understanding both models — and knowing how to configure each with Linux’s iw and nmcli tools — gives you a complete picture of how wireless networking topology choices affect scalability, security, and practical usability.
