On 02/23/2015 03:49 AM, Johannes Berg wrote:

On Tue, 2015-02-17 at 15:59 -0800, greearb@candelatech.com wrote:

quoted

From: Ben Greear <redacted>

The goal is to allow the user-space application to properly
filter packets before sending them down to the kernel.  This
should more closely mimic what a real piece of hardware would
do.

quoted

+ * @HWSIM_CMD_NOTIFY: notify user-space about driver changes.  This is
+ * designed to help the user-space app better emulate radio hardware.
+ * This command uses:
+ *      %HWSIM_ATTR_FREQ # Notify current operating center frequency.
+ *      %HWSIM_ATTR_ADDR_TRANSMITTER # ID which radio we are notifying about.
  * @__HWSIM_CMD_MAX: enum limit

This seems a bit strange - don't we already tag packets with the
frequency? Why would you need the channel change separately? What does
that even mean? Depending on how you use this it could entirely break
off-channel operation, for example.

I was thinking about passive scans.  In that case, we would not always get a packet transmitted
when the channel changes?

I was thinking user-space would mimic a real radio that can only listen on
one channel at once (can any real radios actually listen on two channels at once?)

So, if we are off-channel, and pkt arrives for the 'main' channel, then
a real radio should drop it, right?

Of course, if user-space does not care, then it can simply ignore the channel-change
logic so I think this would be backwards compat with existing hwsim user-space apps.

Thanks,
Ben

johannes

-- 
Ben Greear [off-list ref]
Candela Technologies Inc  http://www.candelatech.com