> > In any case, you could argue that starting AP and client and then > > scanning is pretty much _asking_ for trouble. > > Yes I suspected as much. It seems some firmware is just better at this > than others. Sure, that makes sense. Beacons are important, you could schedule (non- passive) scans between them, and ... yeah you're going to lose frames, but perhaps not the connection as likely. > There is one use case there that I believe Kieth is > targeting and that is new device onboarding which I'm sure your familiar > with as just about every "smart" device uses it. Where the new devices > starts an AP and your phone/App connects and provides credentials to the > "real" network. :) I always fight with that because typically it wants to transfer the network credentials from my phone (and be on the same network), but many devices I don't want to be on the same network ;-) > The tricky part is having the new device scan for > available networks while it has a client connected. Some drivers support > AP scanning which maybe is really what should be used for this? Maybe > that is optimized to actually work. That really depends how it's implemented, I wouldn't necessarily say that "AP scanning" is really better. It's still a crutch. > I guess I'll also ask, what _is_ the target use case for STA + AP > interfaces running concurrently? If scanning is unreliable then > connecting would also be most likely? so what can you actually do here? You don't _have_ to be scanning on the station all the time if all you care about is being connected to some other AP? But yeah, it's not all _that_ useful to have that combination ... and yet I guess people want it and want to live with the limitations. Especially if firmware is better than what seems to be the case here. I dunno. I don't think we support this combination for our devices, but then again we only really support very limited AP mode. johannes
