On Thu, 2019-04-25 at 17:29 -0700, Eric Caruso wrote:
> > > I was sort-of getting at this as a perfect example of a
> > > *property* on
> > > the Interface object, not a method. The object should just have a
> > > "MACAddressRandomization" property that you can use the standard
> > > D-Bus
> > > Properties interface to get & set. We have a lot of those
> > > already.
> > >
> > > The downside of properties is that in some language bindings you
> > > cannot
> > > receive errors from the Get & Set operations, but those language
> > > bindings are kinda broken.
> >
> > I think a property sounds fine and am not worried about the
> > bindings issue here.
> >
> > > So yes, while having these as method calls works, and (as I had
> > > suggested) a single method call is perhaps less desirable, the
> > > best-
> > > case for this is a property. Any time there's a get/set pattern,
> > > or an
> > > enable/disable pattern, that begs for a property.
> >
> > This seems right, but I'm not sure how to make this understandable
> > when the interface is going to have three states: disabled,
> > default,
> > and enabled with an explicitly specified mask.
>
> One other thing about this: getting a mask value for the property is
> actually not trivial, because we could potentially have different
> masks set up for normal scans, scheduled scans, and PNO. I'm not sure
> under which circumstances these would differ, but if they do, it's
> not
> clear which to return.
>
> The property could be a{say} of string keys ("scan", "sched_scan",
> "pno") or a{uay} with some enum representing the same, mapping the
> scan type to a mask, and we would disable it for any scan types not
> present in the map. Then an empty map would fully disable MAC address
> randomization. It would also make it much clearer what to return no
> matter which scan types have randomization enabled, or if they are
> different. This also has the benefit of an empty array not carrying
> any special meaning.
Sounds fine to me.
Dan
> > If the suggestion was not to have the user set a default but to
> > have
> > wpa_supplicant start up that way, then I'm not sure I want to do
> > that
> > because it will probably break any users who are using a MAC
> > whitelist
> > on their AP. I think it's best if this is disabled by default and
> > users can turn it on from whatever UI they have. If the default is
> > only meant for the initial setting, then having this as a property
> > with len(mask) == 0 to disable and len(mask) == 6 to set the mask
> > seems fine. Otherwise, if users can request the default mask
> > through
> > some other fashion, this might get messy.
> >
> > Thanks!
> > -Eric
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
