Re: [PATCH] Add MAC address randomization functionality

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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.

> 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



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux