Although I know that an 802.11B station is associated to the access point when I look at a beacon frame using CommView for WiFi it shows that there are no Non-ERP stations present. When I look at the beacon frame using AirMagnet Analyzer it shows there are Non-ERP stations present and Use Protection is enabled.
See the attached screenshots. On the left is CommView, on the right is AirMagnet
Your CommView frame was damaged, and your AirMagnet frame was good so that would be my opinion as to why they look different. When a frame is damaged you can see really weird results in the packet analyzers.
Nope, not a bad frame. I sent this to TamoSoft and they found a bug and have since sent me a fix for this error.
My hat is off to GT for noticing that your CommView decode showed a "Damaged frame". I wish I had caught that.
Protocol analyzers in general, and 802.11 protocol analyzers in particular, are notorious liars. Three examples are:
1. A frame with CRC error is decoded anyway with little or no warning.
2. Information shown "in" a frame is sometimes actually in another frame.
3. Analyzers (sometimes?) have program and decode bugs.
Be skeptical. Having two analyzers to compare is often a great help.
I hope this helps. Thanks. /criss
Thanks for the nice words Criss. Rob, can you further explain the bug that was in the software? It would be interesting to know more detail.
- GT Hill
Humm! I didn't notice that either. Now this is getting interesting. Any beacons that are non-broadcast show up as damaged, if I go and change it to broadcast it shows up fine but still has the problem with non-ERP present, The new fcd.dll provided by Tamosoft fixes the non-ERP issue but I will have to look into the damaged frame further.
If you don't mind, keep us posted. Thanks!
There is a new build on TamoSoft's website that is suppost to fix both issues. (v.5.1.464). However I am still seeing alot of corrupt packets using CommView and don't see any when I use AirMagnet. It may be a driver issue but I'm skeptical.
I have asked for a more detailed explanation of the bug's and will post them when I here back.
I do have to say that TamoSoft's support group have been exceptionally helpful getting back to me with a fix for both issues.
Here is the responce from TamoSoft support:
"There was an error in the decoder code. The program erroneously assumed that when the SSID is all zeros, the length of the SSID field is greater than 0, while in reality it turned out that it can be 0."
Thanks a lot for getting back to us Rob. Good luck in all future endeavors.