-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Add Monitor Mode #5537
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Monitor Mode #5537
Conversation
Co-authored-by: anecdata <16617689+anecdata@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks really good. My only question is whether it should go in a new module so that we can enable/disable the functionality separate from wifi connectivity. That'll make it easier to shrink small builds. It could be a wifimonitor
module of its own.
This can be considered in future... we have plenty of space to play with on espressif boards for now. |
Monitor depends on part of the Just a note that Espressif says you can do Station or AP while Monitor is running, I haven't had good experiences with that. First because Monitor processes so many packets, and also if there is an AP or connected Station also running, then Monitor is limited to just that channel. So currently Monitor is controlled independently of Station/AP. Other than throughput and channel issues, Monitor can be instantiated and deinited without affecting, or being affected by, changes to Station or AP such as |
Splitting it now is much easier than doing it later. Aren't we running out of space on some boards due to the OTA partition? |
I checked the 4MB boards and all of them have upwards of 130000 bytes free. |
Co-authored-by: anecdata <16617689+anecdata@users.noreply.github.com>
- rename loss method to lost - add method to get queued packet count Co-authored-by: anecdata <16617689+anecdata@users.noreply.github.com>
I notice that When it's running, it's stable and keeps on running. |
I get a crash with just |
I added a lot of |
In code, the Singleton behaves without issue through multiple consecutive constructions, and through many cycles of construct and deinit. Normal operation is going well... one unit has been running for almost 6 days and has captured and parsed about 8 million packets. I've been trying to print-debug this, but I'm at a loss. It doesn't seem to happen with Control-C then Control-D, but does happen with Control-C then key to enter the REPL then Control-D. Something seems to get clobbered along the path from I don't fully understand this mechanism: I don't know if this is related, but detecting |
Found the bug! Well actually two bugs:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested and found no hardfault scenarios.
Also regression-tested going in and out of Station, AP, and Monitor modes repeatedly, no issues found.
Nice work, @microdev1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job fixing the crash! Thanks for continuing to work on this.
this is great! thank you for working on this |
hihi, i tried this - its nifty and seems to work on the tft feather proto ive got |
It doesn't output |
oh yeah please, that would be cool. |
Management packets are 24 bytes header, plus 0-12 bytes of fixed length body depending on management subtype, then comes variable body "Information Elements". OK, not pretty, but a rough parse and dump that I used for testing is here: |
Implement an API to monitor WiFi packets.
Thanks @anecdata for collaborating on this.