One Wi-Fi dongle, 50 devices and a month of network chaos
An office with roughly fifty devices. Windows, Macs, Ubiquiti and Netgear networking equipment. Most of the time, everything worked. But every four or five days, some devices within one VLAN lost internet access. For about three hours.
The colleague at the next desk could carry on working. A particularly enjoyable feature of intermittent faults: same room, same network, two different realities.
The administrator spent about a month investigating. Clearing ARP caches, renewing DHCP leases, restarting computers, inspecting traffic with Wireshark and rolling back Ubiquiti firmware. Sometimes an intervention seemed to help. Until the next incident.
Eventually, the trail led to a small USB Wi-Fi adapter. The sort of object you would expect to lose among the pens before suspecting it of disrupting an office.
The adapter was the start of the story
A member of staff wanted better Wi-Fi coverage and decided to share a connection from their own computer, using an extra USB Wi-Fi adapter.
In that configuration, the computer, through a physical or virtual network interface, claimed the IP address used by the office gateway. Some clients consequently sent their traffic to that computer instead of the real router.
A USB adapter does not seize a gateway address by itself. The fault came from connection sharing combined with an incorrect IP configuration on the host. The adapter enabled an additional networking function; the way it was configured created the conflict.
That distinction matters when fixing it. Buying another brand of adapter does not prevent a repeat. Understanding which networking function was active on the computer does.
Two devices, one address
To reach destinations outside its own IPv4 subnet, a computer normally uses a default gateway. It knows the gateway’s IP address, but it also needs the corresponding MAC address to send traffic across the local network.
ARP supplies that local address book, mapping IP addresses to MAC addresses. The computer effectively asks: who has the gateway address? It then stores the answer temporarily.
When two interfaces on the same network claim the gateway IP, clients can store different answers. One client has the real router’s MAC address in its ARP cache. Another has the address of the misconfigured computer.
For the second client, the internet appears to disappear. It may still have a strong Wi-Fi connection and a valid IP address of its own. Its traffic for destinations outside the subnet simply goes to the wrong place. Direct traffic to devices within the same subnet may still work. Signal strength tells you little about that problem.
Why only some devices, and why every few days?
Devices do not build or refresh their ARP caches simultaneously. Operating systems can also handle ARP messages differently. An address conflict can therefore leave working and affected clients side by side.
Periodic use of the computer, enabling connection sharing or a change in connection state can expose such a conflict. The four-to-five-day interval and roughly three-hour duration do not, by themselves, establish a particular ARP timer or DHCP lease period. You need to correlate events during an incident to explain that pattern.
The VLAN boundary offers another clue. ARP operates within the local network segment; routers normally do not forward these requests into other VLANs. A conflict in one VLAN need not affect the entire office. Segmentation limits the reach of the problem, although it cannot prevent every conflict inside a segment.
Why a reset can look convincing
Clearing an ARP cache forces a fresh address lookup. If the real router supplies the answer at the right moment, connectivity returns. The competing interface still exists.
A restart or DHCP renewal can also change timing and local network state. That does not establish DHCP as the cause. When several interventions happen close together, it becomes difficult to attribute recovery to a particular change.
The same applies to firmware. Improvement after a rollback does not prove a bug in Ubiquiti or Netgear equipment. The timing may be coincidental.
Wireshark remains useful. A capture made outside the incident can miss the conflict, while an arbitrary switch port generally will not expose all other clients’ traffic. Timing, the affected VLAN and the capture location determine what the recording can reveal. A carefully configured mirror port may be needed.
What to record during the next incident
Start by comparing devices before clearing caches across the office:
- Select an affected and a working device in the same VLAN. Record the time, their IP configurations and their configured gateways. Check which MAC address each currently associates with the gateway IP.
- Compare against the actual infrastructure. Check the router configuration, gateway interface and network documentation. Account for legitimate redundancy: a virtual gateway MAC address or planned failover can be normal.
- Trace the unexpected MAC address. Use the switch’s MAC address table, access point client information and endpoint records to locate the port, connection and host. A manufacturer name alone does not identify the culprit.
- Isolate the suspected host in a controlled way. Agree the interruption, preserve relevant settings and disable the specific unwanted sharing function or connection. Then recheck the gateway mapping and connectivity on affected clients.
On the suspected host, also check whether connection sharing has enabled a DHCP service, a hotspot or a network bridge.
Keeping the next workaround under control
Make it clear that staff should not enable connection sharing or network bridges independently. Give them a straightforward way to report inadequate Wi-Fi or a missing connection. Otherwise, a practical need can quickly turn into an improvised network project.
Manage those settings centrally where possible. Document gateways, VLANs and approved network equipment. Consider DHCP snooping and ARP inspection where supported, with coordinated configuration that accounts for static addresses and redundancy. Incorrectly configured protection can itself block legitimate traffic.
Separating workstations, guests and devices with VLANs remains useful. Combine it with management and documentation within each segment.
Technical background: ARP (RFC 826) and IPv4 Address Conflict Detection (RFC 5227).
A fresh investigation without changing IT providers
A recurring fault may benefit more from a separate investigation than another round of resets. Oros ICT Support Limburg can investigate alongside your existing IT administrator. There is no need to change IT providers or take out a mandatory subscription.
We agree the investigation question, scope and budget beforehand. See the pricing page for more about the service.
Does part of your office keep losing internet access? Get in touch to discuss a focused investigation →