RaspAP AP stops accepting WiFi clients until services are restarted

[bananajoe86]

Environment

• Raspberry Pi 4
• RaspAP access point
• wlan0 internal Raspi WLAN Chip used as AP interface
• hostapd / dnsmasq / dhcpcd

Problem

The WiFi access point becomes unstable after some time. Different client devices fail to connect at different times. The problem is not related to a specific device.

Example:

• iPhone cannot connect, while another device works.
• After some time, other devices also fail.
• Restarting the network services temporarily fixes the problem.

The following commands restore normal operation:

sudo systemctl restart hostapd
sudo systemctl restart dnsmasq
sudo systemctl restart dhcpcd

Observed behavior

• Clients can sometimes complete the WPA handshake but are disconnected shortly afterwards.
• The SSID may disappear from scans during the problem.
• After restarting the services, clients can connect again.
• Changing the WiFi channel from 11 to 6 improved the situation, but did not solve the underlying problem.

Example hostapd log:

STA xx:xx:xx IEEE 802.11: associated
STA xx:xx:xx WPA: pairwise key handshake completed (RSN)
STA xx:xx:xx IEEE 802.11: disassociated

Question

Is there a known issue with RaspAP, hostapd, dnsmasq, or dhcpcd where the AP stops accepting clients after running for some time?

Any help with debugging or configuration recommendations would be appreciated.

[billz]

First result for "disassociated" in our docs.

Please search them before starting new discussions, thanks

[bananajoe86]

Hi,

thanks for your suggestions. We followed your troubleshooting advice and checked the common causes you mentioned.

We are still seeing a very strange behavior:

After restarting:

• hostapd
• dnsmasq
• dhcpcd

the access point works normally. All tested devices can connect.

However, after running for some time, the AP stops accepting new clients. Devices that are already connected continue to work without problems.

The important observation is:
When a new device tries to connect, hostapd does not receive or log the connection attempt at all. There is no association attempt, no WPA handshake and no error message in the hostapd log.

The device trying to connect is not always the same:

• sometimes an iPhone fails
• sometimes a Fire tablet fails
• other devices may fail

A restart of the three services immediately restores the ability for new clients to connect, but only temporarily.

We already checked:

• signal strength (clients are close to the AP)
• different 2.4 GHz channels (including channel 6)
• hostapd logs
• connected stations with iw dev wlan0 station dump
• system logs (dmesg) for brcmfmac/firmware issues

Because the affected client changes and already connected clients continue working, we do not think this is a client-specific issue.

At this point we are out of ideas and would appreciate any suggestions about what could cause the AP to stop receiving new association requests after running for some time.

Thanks!

[billz]

Generate a debug log along with output from the following and feed all of it to to Grok / Claude.

iw dev wlan0 station dump
iw dev wlan0 info

dmesg | grep -E 'brcmfmac|firmware|wlan0' | tail -50
sudo tcpdump -i wlan0 -n -e -s 0 'type mgt' -c 50

Have you surveyed your wireless neighborhood? Interference from overlapping BSSIDs will often bump clients off your network. This is known as co-channel interference (CCI). External factors such as this are often the root cause.

As a point of comparison, I've operated a reference Pi3B+ with RaspAP reliably for years without a service restart.

Good luck.

[bananajoe86]

Thanks for your reply.

We have already gone through most of these steps during our troubleshooting:

• iw dev wlan0 station dump (multiple times)
• iw dev wlan0 info
• dmesg for brcmfmac/firmware messages (nothing suspicious)
• changing the Wi-Fi channel (we tested channel 11 and channel 6)
• checking for interference from neighboring APs

Unfortunately, the behavior remains the same.

The only command we could not use is tcpdump, because on the Raspberry Pi's Broadcom driver it returns:

tcpdump: 802.11 link-layer types supported only on 802.11

One observation still stands out: after the AP has been running for some time, it appears to stop receiving new association attempts. Existing clients continue to work, but new clients cannot connect. In many cases there is not even a new entry in the hostapd log when a client tries to connect. Restarting hostapd, dnsmasq and dhcpcd temporarily restores normal operation.

Your comment that your reference Pi 3B+ has been running RaspAP reliably for years without service restarts is actually very helpful. It suggests that this is probably not a general RaspAP issue, but something specific to my hardware, driver or configuration. That gives me another direction to investigate.

Thanks again for taking the time to help.

[bananajoe86]

One thing I’ve noticed is that I can’t set the mode to 802.11n via the UI; it always reverts to 802.11g. I also can’t set the transmit power to "auto." I’ve already spent hours on this with ChatGPT, but unfortunately, I’m not getting anywhere.

[billz]

Addressed directly in our FAQ: Why can't I access wireless mode 'N' (802.11n)?

Transmit power is a function of what your adapter supports. Which adapter are you using?

[bananajoe86]

Thanks for your reply. I already checked the FAQ regarding wireless mode N.

My issue is not the transmit power, but that RaspAP always falls back to wireless mode g (802.11g) after saving the hotspot settings in the web interface.

My adapter is a Raspberry Pi 4 Model B internal WiFi adapter (brcmfmac). The hotspot is running on wlan0.

Current /etc/hostapd/hostapd.conf after saving through the UI only contains:

hw_mode=g

(or no hw_mode/ieee80211n entries at all), even though I select 802.11n in the RaspAP interface and use:

• WPA2
• CCMP encryption
• channel 1
• 2.4 GHz

Manual editing of /etc/hostapd/hostapd.conf works and the client reports 802.11n correctly, but any change saved through the RaspAP UI overwrites it and returns to g mode.

Is there a specific configuration file or default setting in RaspAP that controls the selected wireless mode? It seems the UI is not writing the selected hw_mode=n / ieee80211n=1 values correctly.

[billz]

There is no hw_mode=n; it doesn't exist and hostapd has never used this.

Here's a valid 802.11n config (created via the UI):

driver=nl80211
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
auth_algs=1
wpa_key_mgmt=WPA-PSK
beacon_int=100
ssid=RaspAP
channel=8
hw_mode=g
ieee80211n=1
wmm_enabled=1
wpa_passphrase=ChangeMe
interface=wlan0
wpa=2
wpa_pairwise=CCMP
country_code=US
ignore_broadcast_ssid=0

hw_mode=g + ieee80211n=1 = 2.4 GHz 802.11n (HT)

Not coincidentally, this is also RaspAP's default configuration.

Here's a book on wireless in Linux which includes a chapter on fundamentals.