Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/23/2017 04:02 PM, Andrew Zaborowski wrote:
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 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 <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux