On 02/23/2015 03:49 AM, Johannes Berg wrote: > On Tue, 2015-02-17 at 15:59 -0800, greearb@xxxxxxxxxxxxxxx wrote: >> From: Ben Greear <greearb@xxxxxxxxxxxxxxx> >> >> 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. > >> + * @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 <greearb@xxxxxxxxxxxxxxx> Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
