I noticed that for me 802.11r with key pushing was not working properly. I pulled up the wpad binary in an disassembler and noticed that it was apparently not calling the wpa_ft_push_pmk_r1 function from wpa_auth.c.
The code looks like this
#endif /* CONFIG_IEEE80211R_AP */
so there is an obvious reason why it would not be called (missing define). So what I found out is that when I compile wpad it is missing, but when I compile hostapd it is there.
Anybody knows why that would be? The hostapd makefile checks for CONFIG_IEEE80211R and sets CONFIG_IEEE80211R_AP then, why is that not working for wpad? On the other side half of the 802.11r stuff exists in the binary so it doesn't throw an error, it simply doesn't work.
An easy check to see if it's properly compiled is searching for "FT: Deriving and pushing PMK-R1 keys to R1KHs for STA %02x:%02x:%02x:%02x:%02x:%02x" in the binary. That string is missing in the wpad version but is there in the hostapd version.
I'm talking about the "normal" wpad and "normal" hostapd here, not the basic versions.
That sounds interesting and strange, as wpad should contain additional functionality compared to hostapd.
A brief glance at the OpenWrt Makefile did not reveal anything obvious.
Yeah I also looked at the Makefile and I was wondering if maybe for wpad the hostapd Makefile is not used? There was a split in hostapd for 802.11r between hostapd and wpa_supplicant so it can be individually changed for both. Hostapd's Makefile has something like this enabling the AP Part of 802.11r when the "overall" 802.11r is enabled:
CFLAGS += -DCONFIG_IEEE80211R_AP
If wpad has a seperate Makefile (which I haven't found yet) then this needs to be included there aswell.
I am wondering if this is a bug in upstream hostap, and manifests to us as we compile both hostapd and wpa-supplicant to be wpad.
CFLAGS += -DCONFIG_IEEE80211R -DCONFIG_IEEE80211R_AP
CFLAGS += -DCONFIG_IEEE80211R
I wonder if this difference somehow pops up for us when the multicall binary is formed.
I am cc'ing this to @nbd @daniel @blocktrron and @ldir who have done stuff with hostapd packaging.
I can't reproduce this. In my build, -DCONFIG_IEEE80211R_AP gets added to cflags correctly. If I insert a #error inside the #ifdef that you quoted, it fails as expected.
Which OpenWrt version did you reproduce this with?
That was on 19.07.6, I did a quick check by searching for the string on the latest snapshot aswell but never found it. I think I know what's going on though: The function was inlined, that's why I didn't spot it at the disassembler (so it's there, but it's not obvious) Also wpad seems to not allow debug messages at all, hostapd seems to do so. That string has the severity debug. so it's apparently never printed in wpad and only in hostapd (so it got stripped from wpad). I still have no clue why 802.11r wasn't working with wpad and is now after I replaced it with hostapd everywhere.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.