Re: [PATCH 2/2][RFC] mac80211_hwsim: Report radio addresses in NEW_RADIO/GET_RADIO

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 <redacted>
---
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.Beichler@uni-rostock.de
www: http://www.imd.uni-rostock.de/