On Mon, Jan 06, 2020 at 10:28:21AM +0100, Johannes Berg wrote: > On Mon, 2020-01-06 at 11:26 +0200, Jouni Malinen wrote: > > The standard may claim to be fully backwards compatible, but that does > > not mean there would be guarantee of no regressions or interop issues if > > this were enabled.. I'd consider getting this in first with default > > being the functionality being disabled. Once there is some more trust in > > this actually working and not causing problems (e.g., an independent > > implementation to test against), the default could be changed in the > > future. > > You'll never find out if you don't enable it though? :) Sure, but I do not want to force that testing to unsuspecting end users when they update an unrelated device and something does not work anymore.. > But are you thinking that clients might get confused by a new extended > capability bit getting set? That's something that happens all the time. > Or clients might erroneously set the extended capability bit for > extended PTK IDs? My main concern is that latter one since there are known deployed stations that copy RSN Capabilities from AP to Association Request frame without understanding what they enable. In addition, I'd like to minimize risk on different interpretation on how CCMP/GCMP handling of different Key ID gets indicated and used in practice. That's supposed to be straightforward, but I've seen way too many interop issues in the past due to vendors managing to interpret the standard in very strange ways and/or implementing things incorrectly. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
