hostap and disassociated?

Wed Aug 28 16:56:26 PDT 2024

Jamie,

Just testing one or two connections at a time right now: One from my Mac (running Ventura 13.x) and One from my “Bare Metal” OS (built using Circle running on a Raspberry Pi).

The “Bare Metal” OS I’ve tested on a RPi 3 and a RPi Zero 2W, and both exhibit the exact same behavior.  I just now compiled for a RPi 4, and see the exact same behavior there as well.

For running hostapd: I have three (3) Raspberry Pis running hostapd, two are RPi 4’s and one is a RPi 3.  I’ve been using them for other projects, without problems until now (since I just started the “bare metal” OS a couple of months ago).

Pretty much the same configuration on all of the RPis running hostapd.  One is running Buster (Debian 10 with hostapd 2.8) and two are running Bullseye (Debian 11 with hostapd 2.9).

My end goal is use my “Bare Metal” OS do real time monitoring, and send the results to a Raspberry Pi running hostapd with full Raspberry Pi OS, security, Apache web server, Python, etc., for aggregation.

I did try adding:

	interface wlan0
		nohook wpa_supplicant

And removing:

	wpa_pairwise=TKIP

But neither seems to have changed anything.

So do we know how hostapd determines when to disassociate a particular MAC address?  And is there any way to stop / alter it doing that?  Or to whitelist a MAC address from ever being disassociated?  Just grasping a straws here, looking for another way to solve this.

It may turn out that my “bare metal” WiFi client is not doing something it should, but I’m sure how to determine what that is?

Regards,

Dave.

On Aug 28, 2024, at 4:07 PM, Jamie Fargen <j at fargenable.com> wrote:

David-
Let me look at it the config. Do you know how many devices are connecting to the RPI? What RPI model you are using? And what firmware version is installed?

Regards,
-Jamei

On Wed, Aug 28, 2024 at 3:57 PM David Filip <dfilip at colornetlabs.com> wrote:
Jamie,

Here is my /etc/hostapd/hostapd.conf file:

country_code=US
bridge=br0
interface=wlan0
hw_mode=g
channel=7
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
ssid=ClearWaterways
wpa_passphrase=************

Let me know if you have any suggestions.

To confirm, I can connect without any problem — every time — from my Mac to hostapd.

Connecting from my “bare metal” OS works only every other time — unless hostapd is restarted — and when it fails, I get many disassociated errors from hostapd in syslog.  So to a novice like me, it appears as though hostapd is “remembering” something from the last “bare metal” OS connection that is preventing it from connecting again.

Thanks,

Dave.

On Aug 28, 2024, at 2:31 PM, Jamie Fargen <j at fargenable.com> wrote:

David-

Please provide your hostapd.conf file and redact any confidential information.

Regards,
-Jamie

On Wed, Aug 28, 2024 at 1:17 PM David Filip <dfilip at colornetlabs.com> wrote:
I have tried adding:

interface wlan0
 nohook wpa_supplicant

To my /etc/dhcpcd.conf and rebooted, but it has not solved the problem; it still works every “odd” time I connect, and failed every “even” time I connect (IOW, every other time).

Any thoughts as to what might be missing to make hostapd disassociate?  Every time if fails, the first message in the log is a disassociate from the MAC of my “bare metal” computer.

I’m thinking that maybe hostapd sends some sort of periodic check to make sure the connection is still good?

And maybe the open source drivers I’m using are not responding?

Again, it works every time connecting from my “bare metal” computer to a real (NETGEAR Orbi) WAP.

But it only works every other time connecting from my “bare metal” computer to hostapd.

So it appears as though hostapd is flagging my connection as bad after I disconnect (reboot) my “bare metal” computer.

When it does connect (every other time), the connecting is very stable, and I have even left it running overnight without any disconnects.

Any other thoughts?

On another subject …

I’ve tried subscribing to this mailing list by sending a plan text message to:

hostap-join at lists.infradead.org

With the single line ’subscribe’, but it does not appear to work.  Any ideas?  Is this now a closed list?  Otherwise, it looks like the moderator has to manually approve each of my messages (unless that is intentional)?

On Aug 28, 2024, at 12:53 PM, David Filip <dfilip at colornetlabs.com> wrote:

No, but I do have:

denyinterfaces wlan0

But I will try that to see if it makes a difference.

On Aug 28, 2024, at 10:46 AM, Jamie Fargen <j at fargenable.com> wrote:

In the /etc/dhcpcd.conf do you have a stanza that resembles the one below:

interface wlan0
nohook wpa_supplicant

Regards,

-Jamie

On Tue, Aug 27, 2024 at 5:16 PM David Filip <dfilip at colornetlabs.com> wrote:
Greetings,

I am having a problem related to using hostap & dnsmasq on a Raspberry Pi (RPi).  It works correctly connecting from my Macs to the RPi configured as an AP, but not consistently from a “bare metal” OS I’m working on (based on Circle), only “every other time”.  But the “bare metal” OS does work every time with my hardware AP, just not hostap.

Also, the problem appears to be related to hostap disassociating from the MAC address.

So your first reaction might be “Who cares if it doesn’t work on your 'bare metal' OS, if it works from your Mac, then hostap is working, fix your “bare metal” OS.

While I don’t entirely disagree with that, I’m trying to figure out what the problem / incompatibility is, and how to further debug and/or fix it.  Which is why I am writing this list to try to better understand how hostap is working.

By “every other time”, it is entirely consistent in that if I have hostap running and I try to connect from my “bare metal” OS, it will initially work correctly, then if I reboot the "bare metal" OS (and NOT the hostap computer), it will not work, then if I reboot the "bare metal" OS again, it will work, then if I reboot again, it won’t work, then if I reboot again it will work, etc.  I’ve also left it running overnight, and when it works, it stays connected, so it is not just an “intermittent” thing.  Also, the computers are < 10 feet apart.

Also, if I reboot the hostap computer before I reboot the “bare metal” computer, then it will always work.

Also, if I restart hostap (systemctl restart hosted) before I reboot the “bare metal” computer, then it will always work.

When it doesn’t work, I get a ton (over 300) ‘disassociated’ messages on the hostap computer, e.g. from /var/log/syslog:

May 27 03:44:40 barge-bow hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: disassociated
May 27 03:44:40 barge-bow hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: associated
May 27 03:44:40 barge-bow hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: disassociated
May 27 03:44:40 barge-bow hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: disassociated
May 27 03:44:40 barge-bow hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: disassociated
... etc > 300 times ...

Or sometimes without the second ‘associated’, and just:

Aug 26 08:58:13 demo hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: disassociated
Aug 26 08:58:13 demo hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: disassociated
Aug 26 08:58:13 demo hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: disassociated
Aug 26 08:58:13 demo hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: disassociated
Aug 26 08:58:13 demo hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: disassociated
... etc > 300 times …

When it does work correctly (every odd time, or after rebooting the hostap computer, or after restarting hostap):

May 27 03:41:43 barge-bow hostapd: wlan0: STA b8:27:eb:fe:11:c3 IEEE 802.11: associated
May 27 03:41:44 barge-bow hostapd: wlan0: STA b8:27:eb:fe:11:c3 RADIUS: starting accounting session 09EB81D0E910BBA8
May 27 03:41:44 barge-bow hostapd: wlan0: STA b8:27:eb:fe:11:c3 WPA: pairwise key handshake completed (RSN)

So my question is how / why does hostap flag a MAC address as ‘disassociated’, and is there any way through configuration to prevent that (e.g., whitelist a MAC address to never get ‘disassociated’)?

If I have a better idea of what would cause the ‘disassociated’ behavior, I might be able to figure out how to prevent it (or at least go back to the maintainer for the drivers I’m using in my ‘bare metal’ OS and telling them what hostap needs and is not getting).

Also, to confirm, the “bare metal” OS can always connect every time to my hardware AP (NETGEAR Orbi AP), this problem only occurs when connecting to a RPi running hostap.

I also have several RPis running hostap, and it behaves exactly the same using these versions:

========================================================
Raspberry Pi OS / Debian 10 / Buster

$ hostapd -v
hostapd v2.8-devel
User space daemon for IEEE 802.11 AP management,
IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
Copyright (c) 2002-2019, Jouni Malinen <j at w1.fi> and contributors
========================================================
Raspberry Pi OS / Debian 11 / Bullseye

$ hostapd v2.9
User space daemon for IEEE 802.11 AP management,
IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
Copyright (c) 2002-2019, Jouni Malinen <j at w1.fi> and contributors
========================================================

I think the key is to try to figure out why hostap keeps disassociating from the “bare metal” OS MAC address.  Any help or advice to help debug this would be appraised,

Thanks,

Dave.

_______________________________________________
Hostap mailing list
Hostap at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/hostap