On 12/16/2015 09:30 AM, Adam R. Welle wrote:
Well, it was always rather awkward since it was the *second* address :)
Could somebody provide background information on why the decision was
made to use a second address for the netlink frames instead of the same
address as was used for the non-netlink frames?
I would be fine with always using the first address instead of the second,
in case that helps someone.
We could also set the address at creation time easily enough. Then it
could still be unique across many machines if you managed it.
Thanks,
Ben
I too have an obscure user-space app which uses this API :)
My app was written to account for both the old and new logic being debated,
so I can cope either way with the flip of a switch. I would just like to
say that for my purposes the patch worked better as I already intended for
my app to track MAC address changes made by a user.
I should note that I am passing these frames between virtual machines so
the use of unique addresses (instead of hard-coded 0x42 addresses) as a key
simplifies things when determining which radio transmitted a given frame
and which radio needs to receive the frame. My app has always relied on the
MAC address assigned by the user as a unique key across virtual machines.
Also, I will point out that I am not using multiple vifs on a radio but if
I were, I imagine that I would send a copy of the frame to each vif.
Adam
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
