On Mon, 2015-02-23 at 09:43 -0800, Ben Greear wrote: > > 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?
Ah, well, ok. However, hwsim doesn't actually really have a concept of the 'current channel', for example in the offchannel code it just temporarily listens on two channels ... so that's not very good for a more realistic implementation :) > 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?) No, real radios cannot do that (not really anyway - I guess if it was VHT80 it's really already listening on 4 channels but ...) > So, if we are off-channel, and pkt arrives for the 'main' channel, then > a real radio should drop it, right? Yes. > 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. Sure. But given the murky concept of channel change, and not going to PS for off-channel in hwsim etc. I think this would need a bit more design rather than just exposing the mac80211 channel change. Additionally, with chanctx support that won't even be invoked for example. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
