hostap and disassociated?

[David Filip]

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