Thanks for the reply. First of all, I want to point out that I didn't receive it in my inbox (I wasn't subscribed to the list) and only found out about it on the mailing list web archive, so hopefully I get the headers right. Also it was my first time writing to a mailing list so please let me know if there's anything I'm doing wrong. On Jan 24 12:36, Michael Richardson wrote: > João Lucas <jlucas at disroot.org> wrote: > > Hello, > > > The purpose of this patch is to allow configuring wpa_supplicant to generate > > pseudo-random MAC addresses by hashing (sha256) the SSID together with the > > permanent address, just like iwd does when the AddressRandomization option is > > set to "network". This allows having a unique consistent address for each > > network without the need for additional per-network manual > > configuration. > > Thanks. This would result in per-network-generated MAC: PNGM. > Please see: > https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-address-randomization/ > section 6 --- While the end result would be similar in most cases, the linked document does mention that PNGM should be stored on non-volatile storage, which this patch does not do since it derives the address each time. But regarding that definition, I also thought about implementing a way of fully randomizing the address and writing it to the network config, and the idea was to use the existing option mac_addr=3 and populate mac_value if omitted. But that discussion might be for a separate thread. > > Also, if I may suggest: I think it would make more sense to put randomization > > style and randomization "range" (full/same_oui) into separate options, since > > this range would also be applicable to potential future styles such as this one. > > Agreed. Great! I'll start looking into that. Also, it's important to discuss what to do about the existing options (RANDOM vs RANDOM_SAME_OUI): Break compatibility? Implicitly set the appropriate range for legacy options? Which one takes precedence if the range is also explicitly set in the config? If we were to break compatibility, we could get rid of RANDOM_SAME_OUI (which could still be achieved by using RANDOM together with the appropriate range option) and put DERIVED_FROM_ESS (or whatever we end up naming it) in its place (mac_addr=2), which would solve the INT_RANGE problem that I explained in the cover letter. > > wpa_supplicant: Implement SSID-based MAC address randomization > > I suggest using the terms that madinas made up. I'm open to suggestions on naming things, but assuming you are referring to the term PNGM, it may not be ideal considering what I pointed out regarding non-volatile storage and other possible policies that would better qualify as PNGM. > (Note that one would ideally use an entirely random mac address when > soliciting for networks.) Yes, and if I understand it correctly, that can already be achieved by setting preassoc_mac_addr to 1 or 2. Not sure if it would make sense to enforce it with PNGM, if that's what you're suggesting. Thanks, jlucas _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
