On 23 February 2017 at 20:01, Benjamin Beichler <Benjamin.Beichler@xxxxxxxxxxxxxx> wrote: >> 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. > > 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 test to use a internal hashmap, which maps a receiver MAC-Address of a > Frame to a corresponding wiphy node to efficiently deliver frames. > Additionally it would allow to add VIF with different MAC-Addresses (see > corresponding Callback for this) and update the hashmap according to > this. I believe you want to do something similar, but in the userspace. Yes, either use a lookup table for unicast frames, or deliver all frames (unicast or multicast) to all radios same as the kernel radio does. Best regards
