On Wed, Feb 13, 2019 at 01:36:21PM -0800, James Prestwood wrote: > And in Section 12.4.8.6.4: > > "If the Status code is UNSUPPORTED_FINITE_CYCLIC_GROUP, the protocol > instance shall check the finite cyclic group field being rejected. If > the rejected group does not match the last offered group the protocol > instance shall silently discard the message and set the t0 > retransmission) timer." I could still interpret that field as a reference to another frame (the request). Sure, it would seem that the design here was to expect the field to be included, but the language in 12.4.8.6.3 and 12.4.8.6.4 is not exactly accurate and the even those field names are spelled incorrect (they need to be using upper case if they are referring to a specific field). > So now we have 2 places that contradict Table 9-36. > > In addition, Section 12.4.8.6.4 is quite clear that "the protocol > instance shall check the finite cyclic group field being rejected", > which I don't see wpa_supplicant doing (and how could it? hostapd > doesn't include the group). So this, at the very least, shows > wpa_supplicant is violating the spec by not checking the group. And if > this is true, hostapd is in violation as well by not including the > group. I disagree with any claims of non-compliance taken into account the standard is ambiguous. As far as station behavior is concerned, I don't see any significant benefit from modifying the current implementation. > Obviously this needs to get straitened out in the spec since there is > an obvious contradiction with Table 9-36, which doesn't happen > overnight. But in terms of hostapd/wpa_s, I believe this should be > enough to make an intelligent decision on how to proceed. I initiated discussion for this to be addressed in the IEEE 802.11 maintenance effort (REVmd). So far, the direction has been more towards a modification in Table 9-36. Based on this, I added the field to the hostapd response. However, I'm not planning on modifying wpa_supplicant behavior for this taken into account the previously used hostapd implementation, the ambiguity in the current standard, and lack of any clear benefits from enforcing the field to be present in the rejection response (the station knows what it asked for and there is no case of wpa_supplicant issuing multiple requests with different groups in parallel). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
