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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxx> 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@xxxxx> 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
