Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO
From: Ben Greear <hidden>
Date: 2017-02-24 00:31:36
On 02/23/2017 04:02 PM, Andrew Zaborowski wrote:
On 23 February 2017 at 20:01, Benjamin Beichler [off-list ref] wrote:quoted
quoted
Add a HWSIM_ATTR_RADIO_ADDR attribute to those to events/response so that a userspace medium can query the list of addresses in the simulator. When a userspace medium needs to handle a broadcast frame it can't easily implement the equivalent of what the default kernel medium does because it doesn't know who to forward the frame to. The HWSIM_CMD_GET_RADIO command is a little useless in this respect. Userspace needs to use HWSIM_CMD_GET_RADIO, then cross-reference the radio names with wiphy names using NL80211_CMD_GET_WIPHY dump, map the wiphy names to wiphy indexes (those are more useful than wiphy names because they don't change -- a wiphy name change doesn't generate an event so this can't be easily tracked), and use the NL80211_CMD_GET_INTERFACES dump to obtain the wiphy_idx to mac address mapping.I'm a bit confused, I think the medium should always know by its internal knowledge base, which node would be reachable by a broadcast.So it depends on your architecture really, you can have a setup where one userspace program creates all of the radios and registers as a medium. In this case the program will know what nodes exist, but it still won't have the hardware addresses to use in HWSIM_ATTR_ADDR_RECEIVER because there's no way to query them through netlink (?). Unless you assume that each consecutive radio gets 42:00:00:00:<n>:00 assigned. That would only work if no radios have been created before your program started because you <n> values could be off. But you might also want to do your testing from a script that first creates the radios using one utility program and runs the medium as a separate program. In that case that program can't do the equivalent of what the kernel medium does.quoted
We are also working on the MAC-Management of hwsim, which especially got weird, if you try to manage many nodes within one kernel. But I don't understand how this array with addresses could help to improve. When these addresses do not exactly match to the preconfigured MACs of hwsim, the frames would not be delivered, since they are only checked against the internal ones (or you may add a check against your list).Those addresses I try to expose are exactly the preconfigured MACs. Looking at this some more I found you can retrieve those addresses from /sys/class/ieee80211/<wiphy>/addresses (there seems to be no nl80211 API for this) since those are always in sync with the hwsim addresses, the only issue would be mapping radios to wiphys by name.
I ended up using this approach, and I created the wiphys with specific names so that I could know where to find them in debugfs. I think all of those patches made it upstream.... I'll post my hwsim related patch set in case someone wants to either apply it as is or clean it up, etc... Thanks, Ben -- Ben Greear [off-list ref] Candela Technologies Inc http://www.candelatech.com