Jouni, thanks for the prompt and thorough feedback. I've attached an updated patch; not sure if this is OK or if I should send it again via 'git send-email'; I'm new to this patchwork thing. > Which driver are you using and would you be able to share a > wpa_supplicant debug log (ideally with both -d and -t on the command > line to include timestamps) showing this behavior both before and > after applying this patch? We are using a custom driver for QNX 7, based on driver_bsd. It is a minimal ioctl-driven driver. Sure, two logs are attached - one where the error 30 is seen in the log and the supplicant considers it an error, and one with my patch. > I've tested the SME-in-wpa_supplicant case, i.e., the functions > modified here, only with mac80211-based drivers and in those cases, it > is > mac80211 that takes care of the association comeback mechanism. Does > that not work for you or are you using a driver that does not use > mac80211? With mac80211, wpa_supplicant does not receive the > association event based on the comeback delay response and instead, > mac80211 tries automatically again at the indicated time and then > reports successful association to user space. The is an > NL80211_CMD_ASSOC_COMEBACK event to indicate this happened, but there > is no need to take any action on that from user space. Ah, that's good to know. I'm surprised I didn't find a reference to it originally, but it's been there a long time. No, we not using mac80211; our QNX network driver does not handle the comeback automatically. If it is more appropriate to do so, we could modify it, but I'm sure there are other non-mac80211 drivers that could benefit from it. Would it be worth adding a WPA_DRIVER_FLAG_* for it? Thinking about it, I don't see much harm in adding this behavior to SME unconditionally- if the kernel driver does support it, it will never make it to the supplicant, and if it does not, the supplicant has fallback support? Your call. We are happy to maintain this patch on our side, but figured it might be useful to someone else. > That should be le32, not u32, since this is defining a struct for the > payload of the information element that uses little endian byte order > for integers. Thanks. I'll take your latter feedback and remove this definition. > This should like verify that wpa_s->current_bss and > wpa_s->current_ssid are not NULL.. Thanks, will update. > That does not work on big endian CPUs. It would likely be better to > use > WPA_GET_LE32(&elems.timeout_int[1]) instead of defining this struct > ieee80211_timeout_interval which would now have need to do byte > swapping and potentially also a separate copy to avoid unaligned 32-bit accesses. Thanks, will take this approach. I'm surprised it didn't blow up in my own setup - usually unaligned access on our platform causes a SIGBUS. ________________________________ - CONFIDENTIAL- This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.
Attachment:
supplicant-error-30-patch.log
Description: supplicant-error-30-patch.log
Attachment:
supplicant-error-30-blacklist.log
Description: supplicant-error-30-blacklist.log
Attachment:
0001-SME-handle-802.11w-association-comeback.patch
Description: 0001-SME-handle-802.11w-association-comeback.patch
_______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
