You are not logged in.
Hello -
wlan_mac_ap.c in v1.5 only sends probe responses for probe requests that are sent to the broadcast address.
Is there a reason why the code does not send responses for requests that are unicast to the WARP AP's address?
We have several non-WARP devices we are working with that unicast a probe request just before sending an Authenticate. They can't associate with the WARP AP because it won't respond to a unicast probe request.
Thanks,
Dan Van Hook
Offline
Broadcast probe requests have the FF-FF-FF-FF-FF-FF broadcast address in both the addr1 (RA) and addr3 (BSSID) fields. Do your unicast probe requests have the AP's MAC address in both the addr1 and addr3 fields in the header?
I think it is line 1648 of wlan_mac_ap.c (for v1.5.1) that is causing the error you are seeing. The code for the AP's probe request processing does properly handle a unicast addr1 that matches the AP's MAC address, but still requires that addr3 be broadcast. There is no good reason for this -- that line of code dates way back to the very first release of the design. I don't have any commercial Wi-Fi devices that send unicast probe requests and overlooked that scenario when designing the AP. Out of curiosity, are you able to share what non-WARP devices you are using that do use unicast probe requests?
I'd recommend simply removing the if() clause I linked to on line 1648 to relax that requirement and allow probe responses to be sent to any probe request whose addr1 is broadcast or the MAC address of the AP. Or, if you know that your addr3 fields match the AP's MAC address, you could simply change that line to
if( wlan_addr_eq(rx_80211_header->address_3, bcast_addr) ||
wlan_addr_eq(rx_80211_header->address_3, wlan_mac_addr) ) {Offline