> 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.
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). 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. I also would propose a parameter (like you propose here) as internal permanent MAC-Address, instead of the automatic increasing MAC-Addresses, since it become complicated, if you want to use multiple userspace medium in different network namespaces, as the hwsim MACs are globally assigned. You may need to handle collisions (I don't know whether different wiphy could use the same permanent MAC), but this would be more logical for a simulation, than discover every address after creation. > > Additionally there are two addresses used by hwsim radios > (data->addresses[0] and [1]), first used at the network level and the > second used at hwsim radio level and in HWSIM_ATTR_ADDR_TRANSMITTER / > _RECEIVER. By default they differ by 0x40 in the first byte but I'm not > sure userspace can make this assumption to do the mapping from the > address inside the frame headers to the address of the hwsim receiving > radio. I suspect the network layers can change address 0 and they will > be out of sync. > > Signed-off-by: Andrew Zaborowski <andrew.zaborow...@intel.com> > --- > Additionally I tried to add a HWSIM_ATTR_WIPHY to report the wiphy index > directly without users going through wiphy name to index mapping, but > get_wiphy_idx() is internal to cfg80211. The index is exposed to > userspace and is more useful than the name so I wonder if this function > should be exported from cfg80211. I also think that would be nice to have ;-) kind regards Benjamin -- M.Sc. Benjamin Beichler Universität Rostock, Fakultät für Informatik und Elektrotechnik Institut für Angewandte Mikroelektronik und Datentechnik University of Rostock, Department of CS and EE Institute of Applied Microelectronics and CE Richard-Wagner-Straße 31 18119 Rostock Deutschland/Germany phone: +49 (0) 381 498 - 7278 email: benjamin.beich...@uni-rostock.de www: http://www.imd.uni-rostock.de/
signature.asc
Description: OpenPGP digital signature
