client.StationInfo returns os.ErrNotExist if there are no clients connected

[0x5a17ed]

As of efdf3f4 the current implementation of client.StationInfo returns the error os.ErrNotExist if there are no clients connected to the interface even when the given interface runs in Access Point mode.

This is a weird behavior since it complicates the handling of errors returned from client.StationInfo with an additional check if the given error is os.ErrNotExist. Returning an empty array here would simplify things. Relevant koan: http://thecodelesscode.com/case/6.

Would love to hear your opinion about this @mdlayher!

[mdlayher]

Access point mode is something I never really intended for this package to be used for, but nl80211 certainly exposes a lot of functionality in various forms that could be useful.

I'm starting to wonder if it would make sense to drop the cross platform facade that never materialized, and to expose more of the nl80211 APIs in a less processed way, so that folks have more flexibility to use the primitives as they need.

I apologize for the delay, I haven't really figured out what I want the future of this package to look like yet.

[0x5a17ed]

Access point mode is something I never really intended for this package to be used for, but nl80211 certainly exposes a lot of functionality in various forms that could be useful.

Maybe it helps you if I describe the scenario in which I'm using this package. I'm using this in a service that is running on multiple wifi access points to pull out numbers indicating the utilization of the given access point. This package works really well for this and I can see the number of connected stations to the access point in question.

I'm starting to wonder if it would make sense to drop the cross platform facade that never materialized, and to expose more of the nl80211 APIs in a less processed way, so that folks have more flexibility to use the primitives as they need.

I think that some form of cross platform support would still be a nice to have. How about splitting this library up in a high-level and low-level API? The high-level part exposes the same API this library exposes at the moment and the low-level part exposes more functionality provided by the kernel nl80211 layer. I think this approach offers the best of both worlds.

I apologize for the delay, I haven't really figured out what I want the future of this package to look like yet.

No worries, thank you for sharing this package. It helped me out a bunch. 😁 The package in its current form is already quite useful. I just opened this ticket because it felt counterintuitive to me how the API of this package handles the case of no stations connected and I wanted to share the feedback.

[mdlayher]

I think that some form of cross platform support would still be a nice to have. How about splitting this library up in a high-level and low-level API? The high-level part exposes the same API this library exposes at the moment and the low-level part exposes more functionality provided by the kernel nl80211 layer. I think this approach offers the best of both worlds.

I can certainly get behind this approach. wifi could keep the same interface and we could expose an nl80211 package that only builds on Linux (and rename the current generated one to whatever else).